スクラムによるドメイン駆動設計

ビジネスとソフトウェアの統合という観点から、スクラムとドメイン駆動設計の関係をとらえなおす。

導入

ここ数ヶ月は日本のスクラムにとって、おそらく非常に有意義な期間だったのではないかと思います。12月にJim Coplien氏による認定スクラムマスター研修、１月にGabrielle Benefield氏とJeff Sutherland博士による認定プロダクトオーナー研修が開催され、さらにInnovation Sprint 2011では野中先生とSutherland博士の対談までもが行われました。私は幸運なことに、これらのイベントにはすべて参加することができたのですが、そうやって学ぶことができた今では、スクラムのことを、一言で言うと「価値の流れを生み出すためのフレームワーク」ではないかというイメージを持っています*1。「フィードバック」や「改善」など、スクラムにとって重要な概念はいくつかありますが、いずれもこの「流れ」に関することだと考えられます。フィードバックは戻って来る流れであり、改善はスムーズに流れるようにすることだ、ということですね。

「スクラムは流れだ」ということは、逆方向から見ると、ソフトウェアの「アーキテクチャ」をどのように作るべきかということについて、スクラムは特に語らない、ということです。インクリメンタルな開発であることから、なんらかの曳光弾開発（TBD:Tracer Bullet Development）が必要になることは明らかですが*2、その中身については適用する者の手に委ねられていると言えます。

この流れとしてのスクラムをもう少し細かく見ると、この流れは２つに分解できます。１つがビジネスモデルを基に、それを実現するソフトウェアを作り出すという、プロダクトオーナーが生み出すべき流れ、もう１つが、要件をかたちにするという、スクラムマスターの助けを得て開発チームが生み出す流れ、です。この構造に対して、「では、どう作ればよいのか？」と考えた時に、ドメイン駆動設計（DDD:Domain Driven Design）が実にぴったりとはまるのです。さらに、エンタープライズという大きな枠組みの中で、ソフトウェアはどういう位置づけになるのか、ということについても、なんらかの示唆を与えてくれるようにも思います。この「Scrum + DDD」が今回のテーマです。

本日のエントリで議論する内容について全体像を描くと、おおよそ次のようになります：

プロダクトオーナーの生み出す流れ

スクラムのプラクティスにおいて、プロダクトオーナーが行うべき最重要事項はプロダクトバックログの管理です。ただし、その背景には、プロダクトの進むべき方向を示す「プロダクトビジョン」があり、さらに「プロダクトビジョン」の背景には、経営陣によって定められる「ビジネスモデル」が存在します。

どういうかたちで利益を生み出していくかという抽象的なビジネスモデルをベースに、それを実現するプロダクトのビジョンを描き、さらには実現可能な仕様（＝プロダクトバックログ）のかたちに落とすこと。これがプロダクトオーナーの仕事です。そして、このループは、ソフトウェアを作成し、実際に利益を生み出すことによって完結します。

開発チームの生み出す流れ

開発チームの流れは、プロダクトバックログから始まります。プロダクトバックログに書かれた仕様を実現し、プロダクトオーナーを始めとするステークホルダに対してデモを行うことによって、このフィードバックループは完結します。ただし、ドメイン駆動設計の文脈に当てはめると、ふるまいのほかにもう１つ実装すべきものがあると考えるべきです。

ドメイン駆動設計における重要なテーマは、「ドメインエキスパートのメンタルモデルをソフトウェアにおいて反映させること」です。これはドメインエキスパートと開発チームとの間の密接なコミュニケーションによって実現されます。ドメインエキスパートの語る言葉に耳を傾け、重要な概念を拾い上げ、概念同士の関係を丁寧にモデリングしていくのです*3。

モデル駆動設計においては、まずは概念を表現するオブジェクトの性質が注目されます。そして、一意の識別子を持ち、さまざまな状態を変遷するエンティティと、単に値だけを表現する不変の値オブジェクトが区別されます。ただし、「概念」というものは単独では意味を持たず、他の概念との関係において初めて意味を持ちます。こうした性質はモデル駆動設計にも色濃く反映されており、各概念／オブジェクト間の関連の方向性や多重度、さらになんらかの制約条件の及ぶ範囲（集約）を意識的にコントロールします。

いわゆるトランザクションスクリプトとの違いを少し整理しておきます。一般的なトランザクションスクリプトが、好き勝手にSQLを発行して必要なデータだけをフラットな構造で取得してしまうのに対し、モデル駆動設計では、アプリケーション層にスクリプト的なものがある点は変わりませんが、扱われるデータ構造は、単なるデータ構造ではなく、必ずドメインモデル（メンタルモデル）に存在する概念と結びついたエンティティなり値オブジェクトなり、ということになります*4。こうしたオブジェクトとリレーショナルデータベースとの差異を吸収し、あたかもメモリ上にあるかのように、概念／オブジェクトを操作できるようにしてくれるのがリポジトリなのです。

この構造を図示すると、次のようになるでしょう：

こうすることで、各種のドメインオブジェクトを操作するクライアントコードが、非常に豊かな表現力を持つことになるのです。

ビジネスモデルと戦略的設計

少し視野を広げて、巨大な企業で行われているビジネスを考えてみて下さい。そういうビジネスが１つのソフトウェアでまかなえることはなく、複数のソフトウェアが相互に連携し合いながら稼働することになるでしょう。そのようにして結びついたソフトウェアは、本来有機的な全体を構成すべきであり、しかもその全体はビジネスモデルを映し出すものになるべきです。そうしたいわば「メタモデル」を構築するためのアプローチが、DDDにおいて「戦略的設計」と呼ばれているものです。

戦略的設計が示すものは、大きく３つあります。それが、個々のソフトウェアの境界とソフトウェア同士のつながりを表現した地図を作ること（コンテキスト）、その中で最も重要な部分を際立たせること（蒸留／抽出）、そのようなメタなモデルに構造を当てはめること（大規模な構造／大局的な構造）、です。

第４部は全体的に抽象的な議論が多く、つかみどころがないようにも思えますが、各パターンをミクロにとらえすぎず、ジェネレーティブなパターンとして、相互の関係から理解すべきです。一例を挙げましょう。まずは特定のユビキタス言語が１つの意味を持ち得る範囲を明示的に定めます（境界づけられたコンテキスト）。次に、それらのコンテキスト内での整合性を常に維持するために継続的な統合が求められます。さらに、各コンテキスト間の関係を明らかにし、コミュニケーションで必要な変換処理や共通な場所を明らかにする（コンテキストマップ）、という具合です。

この構造を図示します（2011/01/30追記）：

スクラムのスケールアップにおいては、「メタスクラム」「チーフプロダクトオーナー」といった概念が存在します。チーフプロダクトオーナーは、企業のビジネスモデルとソフトウェア資産との平行性を保ちつつ、あるべき姿に向けていくという、壮大で非常に責任の重いロールです。こうしたロールを担う人にとって、戦略的設計は優れた武器になるのではないでしょうか。

最後に

プロセスを規定しつつ、設計については特に定めないスクラムと、設計を論じつつプロセスについては多くを語らないDDDですが、両者が持っているミクロとマクロな視点、そして徹底したビジネス指向／ユーザ指向によって、この２つの考え方はまるであつらえたようにぴったりと整合するのです。

最後に共通項をもう一つ。スクラムもDDDも、基本はイテレーティブでインクリメンタルな開発です。ドメインモデルが１度で完全なものができることはあり得ません。人の頭の中にあるメンタルモデルを引き出すことなど、そう簡単にできることではないからです。ましてや、エンタープライズレベルのアーキテクチャが１度にできるはずもありません。ミクロなレベルの流れが合わさって、マクロな流れを作り出し、そうした流れの中で、常に方向を修正しながら進化していくことになるのです。

ソフトウェア開発に携わる１人１人にとって、開発というものが目の前のif文や障害報告書を書くだけの作業ではなくなり、こうした大きな流れの中にいることを感じ取れるようになったら、それはとても素晴しいことだと思うし、そうでなければいけないのだとも思うのです。

※今年４月に開催されるQCon Tokyoでは、DDDの著者であるEric Evans氏が基調講演を行います。また、DDDの翻訳も翔泳社さんから出版が予定されています。