「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」の発表資料が素晴らしい #devsumi

デブサミ2014の発表資料を読んでいて、僕の中では「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」が一番心に残った。
ラフなメモ書き。
以下の発表資料の文章を引用している。

【元ネタ】
Developers Summit 2014 で「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」という内容で発表してきました - sifue's blog

Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」 from Yoshimura Soichiro

2014/02/14 デブサミ2014【14-A-6】Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所 #devsumiA - Togetterまとめ

【0】背景

この発表資料は、「Scalaを使ってWebサイトを構築、運営してみようとしているリーダーさん向け」。

ニコニコ動画のPHPソースがレガシー遺産という負債となっていた。
リファクタリングしたものの、抜本的な対策が必要と痛感。
そこで、ニコ生動画を書き直すニコ生2プロジェクトが発足した。

目的は、スケーラビリティ・フォールトトレランス・保守性・パフォーマンスの品質を担保すること。
チームは4人から始まった。

【1】Scala

Scalaの利点は、静的型付けを持ち、保守性も高そう。
そして、関数プログラミングによる並列処理も実装可能。

但し、PHPプログラマからScalaへ移る場合、アルゴリズムとデータ構造、関数型プログラミングの考え方などのサポートが必要。
社内で勉強会を開く、など。

【2】PlayFramework＋ドメイン駆動開発

ドメイン駆動設計で、UI層→アプリケーション層→ドメイン層→インフラ層の4層構造というレイヤードアーキテクチャ。
ユビキタス言語を使ったドメインという業務知識の共有。

コアの蒸留、汎用サブドメインの分離によるモジュール化。

Play2/Scalaはドメイン駆動設計を実践するのにとても良いフレームワーク。

・CoCがきつくなく好き勝手フォルダが掘れる。
・マルチプロジェクト機能でサブモジュールの依存関係を作れ、レイヤー ドアーキテクチャの強制できる。ドメイン層、インフラ層はplayに依存しないただのjar。
・case classがエンティティと値オブジェクトの作成のコストを下げる。例えば、インフラ層ORMのマッピングクラスとドメイン層のエンティティを分けることなどが苦にならない。
・play2を捨てられるように開発することが可能。

僕の感想としては、この部分が一番なるほど、と感じた所。
ドメイン駆動設計では、ドメインが明確になるために、オブジェクト指向設計の長所を適用できる。
更に、ドメイン駆動設計は小規模リリースと相性の良い設計手法なので、新しいフレームワークの基盤の上に機能を少しずつ追加していく時に役立つだろう。

但し、ドメイン駆動設計は敷居が高い。
「リファクタリング」「UMLモデリングの本質」「アナリシスパターン」「エンタープライズ アプリケーションアーキテクチャパターン」の4冊を読んでおかないと、「ドメイン駆動設計」の凄さが分からない。

この点も僕も同感。
振り返ってみれば、僕も、Javaの勉強のために「リファクタリング」、オブジェクト指向設計の勉強のために「UMLモデリングの本質」「アナリシスパターン」、アーキテクチャ設計のために「エンタープライズ アプリケーションアーキテクチャパターン」を読んでいたから、「ドメイン駆動設計」に出てくるたいていのパターン名が何を意味していてどんな背景から生まれたのか、はすぐに分かった。
つまり、ドメイン駆動設計は、先人の設計手法の積み重ねの上にある。

ドメイン駆動設計をいち早く理解するには、下記のYouTube資料が良いらしい。
視聴してみると、確かに「何がドメインであり、何がドメインでないか」はよく分かるのでお勧め。

20110409_DevLOVE「Building Blocks」_都元ダイスケさん - YouTube

また、ScalaのWebフレームワークであるPlayフレームワークを使っている点も上手い。
Struts→Seasar、Spring→Wicket、Playへ発展した経緯を考えると、RailsのようなPlayフレームワークは、今後のJavaプログラマには必須のフレームワークになるだろう。

Javaの常識を変えるPlay framework入門

ScalaのWebアプリケーションフレームワーク「Play Framework」入門　～（1）環境構築とスタートアップアプリの作成 （1/6）：CodeZine

但し、Play2/Scalaの弱点として、下記が挙げられていた。
今後のPlay2/Scalaの改善点になるだろう。

1. sbtが遅すぎる。
　　→proxyを作ったり、良いマシンを使うぐらいしかない
2. Play2のscalaテンプレートが、コンパイル遅く、文法がデザイナー にやさしくない仕様。
　　→Groovyテンプレートで作成。 github/dwangoでフォークしたも のを公開中
3. テストで困るobjectとtraitと関数引数。
　　→specs2のmockitoの制約。objectのモック作れない、traitはmixin が必要、ジェネリクスパラメーターが付いた関数引数のメソッド を拡張できない。

【3】Scrumはリーダーを育てる

「自身のウォーターフォール開発とアジャイル開発のプロジェクトマネージャ経験」として、以下の苦い経験があった。

1. 過去4度のフォーターフォール開発と、大失敗の経験。
　→要求が変更されてしまうと地獄。不確定要素に対応するためのバッファ重要。最後のしわ寄せは品質に。
2. 要件が確定できない、また、要求の優先順位が日々変わる場合、アジャイルとスクラムの考えが良い
　→日々変わるチームの目標への柔軟な対応が必要なWeb開発

「Scrumはリーダーを育てるのにすばらしい手法である」理由は下記の通り。

・会議体が固定
・JIRA/GreenHopperなどのサポートツール
・書籍が充実している
・プランニングポーカーでの見積もりが、スクラムマスターを孤立させない
・全員が全ての帽子をかぶるので段階的にスクラムマスターにさせ ることが可能

この点は、すごく納得した。
開発チームを運営する役割であるプロジェクトリーダーには、アジャイル開発やWF型開発に限らず、最低限3つのスキルが必要だと思っている。

一つ目は、体制図。
つまり、案件に出てくる利害関係者の関係をグラフにまとめたもの。
普通は、プロジェクト立上げ時に真っ先に書くべきもの。パワポやVisioなどで書く。
WF型開発の大規模プロジェクトほど、利害関係者が多くなり、誰がどんな役割で動くべきか、をきちんと定義しないと、無駄なコミュニケーションばかり増えて、プロジェクトが進まなくなる。

Scrumの良い点は、アジャイルなスクラムチームには、プロダクトオーナー・スクラムマスター・チームの3つだけでロールが十分であると定義していること。
更には、「ニワトリとブタ」の話のように、スクラムチームに所属していない利害関係者から開発チームを守る仕組みが提供されていること。
これによって、体制図はとても簡単な構造になり、コミュニケーションを取りやすくなれる。
また、それぞれの役割が明確なので、Scrumのフレームワークに従って行動すればいい。

2つ目は、概要スケジュール。
つまり、タスクの詳細を書いたガントチャートではなく、各工程、各プロセスの前後関係を明確にしたPERT図。
普通は、プロジェクト立上げ時に、マイルストーンを意識しながら、どんな工程が必要かを洗い出し、各工程のInとOutをつなげて書くので、自然にPERT図になる。
この概要スケジュールを元に、概算で見積りし、詳細なスケジュールを落としこんでいく。

Scrumでは、大まかなリリース計画(ロードマップ)をプロダクトオーナーが決めて、それを実現するためにストーリーに分割してバックログへ優先順位ごとに並べる。
開発チームは、バックログのストーリーの順に従って開発していくだけでいい。
また、スプリントごとに出荷してデモするから、利害関係者も定期的にソフトウェアを評価して、ロードマップ通りに進んでいるかをチェックすることもできる。

3つ目は、コミュニケーション計画。
つまり、体制図に書かれた利害関係者といつどこでどんな会議をするのか、という会議体の構成図。
普通は、顧客との月次進捗定例、複数の開発チームリーダー同士の週次の課題管理定例、開発チーム内の毎日の朝会、などがコミュニケーション計画になるだろう。
これらの会議体がスムーズに運営されなければ、プロジェクトの障害や課題がスムーズにエスカレーションされず、納期が遅れたり、品質悪化の原因になる。

しかし、たいていは、会議の運営コストが大きすぎて、プロジェクトリーダーは常に会議の資料の準備に追われたり、1日が打合せだけで終わってしまう時も多い。

Scrumの良い点は、デイリースクラムという毎朝の15分の朝会が会議体として決まっていて、その会議だけで十分であること。
デイリースクラムで進捗を確認できるだけでなく、メンバーが抱える課題を早期に見つけ出すこともできる。
更に、スプリントの最後には、製品評価であるスプリントデモや、スプリントをふりかえるスプリントレビューがフレームワークとして準備されているので、定期的に直近のスプリントを評価し、改善策を考えるきっかけにもなる。
「スクラムマスターはScrumプロセスの守護神」という考え方は、この会議体のスムーズな運営によって支えられているわけだ。

発表資料では、上記以外にも、「スクラムマスターも常にプレーイングマネージャーであれるようにする」「ユーザの要求理解に時間をかける」「企画と相談する時は、重要度ではなく常に要件の優先度で議論する」「インフラチームや他チームとの共同作業は合流バッファを考える」など、プロマネがプロジェクト管理で気を付けるべき点について、たくさんの経験談が含まれていて、とても参考になった。