QCon Tokyo 2011に参加しました。
Keynoteを発表してくださったDDD InventorのEric Evansさんはとてもゆったりした話し方をされる方でした。DDDの一部分を語られていましたが、一つ一つの詳細を聞いてみたくなります。
Evansさんの発表で気になったのが「Model Exploration Whirlpool」と「Bounded Context」というキーワード。DDD本をまだ読んではいないのですが、「Model Exploration Whirlpool」についてはWebに資料（PDF）あったので少し読んでみました。（以下、適当訳）
Code Probe（コードを綿密に調べる）
・テストとしてのコードシナリオ
・厳密さの追加
・言語を洗練する
・解決方法を探求する
・ミスを生み出すChallenge Model
・新しいシナリオをもって挑むScenario
・ストーリーを語る
・新しいアイデアを出す
・厳しい部分に再フォーカスする
・コアなドメインに再フォーカスするModel
・モデルの目的を考える
・状態を実地検証する
・ソリューションを実地検証する
・言語を探求する
・ミスを生み出すHarvest ＆ Document
・シナリオを参照する
・モデルの小さな部分を正当化する
・ほとんどのアイデアを置いていくアジャイルやリーンソフトウェア開発ではモデリングに奮闘することが多く、一つのタスクをその時に完全にモデリングするために、都合よくデザインして結果を得ようとしてしまう。それにより、内部デザインとUXの両方に空洞ができてしまう。
また、モデリングやデザインをしないことで、イケてないシステムモデルが採用されてしまう。モデリングは素直にモデリングとすることと同じ意味にならない（upfront modelingとは異なると書かれている。upfrontは「前もっての」「重要な」「直接的な」という意味もある）。実際に、素直なモデリングはDDDに呪いをかけてしまう。なぜなら、それは我々がかかわるプロジェクトのコンテキスト内で、洗練されたドメインナレッジの一部分をモデリングしているにすぎないからだ。実際に、素直なモデリングによって、プロジェクト初期のまだ知らない大切な情報に到達することが難しくなってしまう。
モデル探求の渦（The Model Exploration）は、アジャイルやリーン開発の哲学にマッチした素直なモデリングの代替案を提供する。この渦は、開発プロセスの一部ではなく、必要なときに渦を作りだしていくことを意味する。
ウォーターフォールの場合、初期に時間をかけて”工程”としてモデリングするが、モデリングはそこで完了するわけではない。アジャイル開発の場合は、イテレーションに区切られるため、それぞれのイテレーションでモデリングすることができ、そのナレッジを次のイテレーションで活用できるため優れている。
モデリングに時期は設定しないほうがよいが、例として以下のタイミングでモデリングをするといい。
ステークホルダーとの関係が悪化したしたとき
解決案が問題よりも複雑になってしまったとき
ベロシティが遅くなってしまったとき
チームが新しいドメイン領域にとりかかるときリーン開発の場合は、モデリングをPush型ではなくPull型として考える必要がある。
この渦に、チームが飛び込む必要があるサインを見つけたなら、渦のポイントポイントに飛び込ませるといい。ただ、いきなり、素敵なモデリングアイデアが出るわけではないので、また別の日に試したりするなど反復することが重要で、いつか新しい道しるべを見つけだし、そこへと加速していくはずだ。
補足
- あくまでうずまきはSTEPではなく、渦巻状のダイヤグラム
- 注意深く選んだ項目になっているので、全部を網羅しているわけではない。細かくしすぎると全体が見えなくなってしまうのでこうなっている
モデリングを「探求」というところがとても印象的でした。モデリングで完全なパターンを生み出すのではなく、探して見つける。探して見つけるというアプローチには共感できますね。
また、「どのタイミングでモデリングするか？」の例が面白い。ステークホルダとの関係悪化をモデリングのタイミングとするなんて考えもしませんでした。私なら関係修復を考えるでしょう。しかし、よく考えてみると、そうなるということは、システム的な欠点があると考えても不思議ではないので、モデルを見直すタイミングとしていいシグナル（そうなると困ることだけれど）のかもしれません。
DDD恐るべし。そして、深い。
最後に、DevLOVEのDDDカンファレンスで集められたメッセージがありました。
旅と子育てとアジャイルコーチのブログ「世界」 