尊敬するDOAの先輩である、渡辺さんがこう書いている。

「データモデルなきアジャイル」の危うさ、より

その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。
業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。

それに対して、稲見さんがこんなコメントをしている。

アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達は、データモデルは書いています。また、FDDという手法では、ドメインモデリングから始めると有る様に、データモデルが出発点です。

ぼくも実はこの考えには基本賛成である。というか、確かにデータモデルを初期に設計しなければならない場面はかなりあると思う。このへんのことを少し書いておきたい。

ピュアなアジャイルでは、機能を縦スライスで作る。UIからDBまで、細い縦の線をつなぎ、それをユーザのフィードバックを得ながら太くしていく。ぼくはこれをたとえるのに、ぼくは水越さんが書いてくれたこのケーキをよく使う。

つまり、ケーキをつくるのに、一層目のスポンジ、二層目、そしてクリームを塗って最後にイチゴを乗せる、という作り方ではなく、まさに、すぐに食べられるショートケーキを縦に作っていくのだ。

この利点は明らかで、作り終えるまでの半完成品（仕掛、在庫）が少なく、仕様変更のインパクトが引くいこと。また、ユーザに食べさせることで、フィードバックを早期に得、より効果的な仕様を引き出せることだ。

ケーキ屋がもしホールケーキを作らず、ショートケーキで作ることができたなら、売れ残りリスクを低く抑えることができ、かつ、フレッシュなショートケーキをいつでもお客に食べてもらえる。ということになる。これは、要求がなかなか固まらないシステムや、要求のゆれが大きなシステムでは、とっても有効で、ここがアジャイルのポイントだ。ここまでが原則論。

ところが、全体に与える影響が極めて大きく、後戻りしにくい「スポンジ層」というのが存在する。そのひとつが渡辺さんの言われているデータモデルである。データモデルはアプリケーション全体に影響を与え、データモデルの後での変更は高くつくのである。このように、「後戻りが高くつく」ような意思決定は、どうしても先に行う必要があり、そのような制約をもったものには、データモデルのほかにも、

• 開発言語
• レイヤーアーキテクチャ
• セキュリティ
• スケーラビリティ（※ここは後で議論）
• 。。。

などがある。これらは「リーンソフトウェア開発」において、高リスク制約（High Stakes Constraint）と呼ばれている。左の図は、2003のMary Poppendieckの講演につかわれた図。もともと、変更を受け入れるのがアジャイルの姿勢であり、どうやったら「後で変更できる」というオプションを開発のライフサイクルにおいてキープし続けるか、というのがアジャイルのテーマなのだが、変更コストが極端に高いものはしょうがないのだ。（ちなみに、それでも意思決定を遅らせたい場合、「セットベース設計」を使う、というのがリーンソフトウェア開発。合わせてリーンソフトウェア開発全体の資料をここに共有しておきます。

でも、ポイントはこの高リスク制約は非常に少なく、「決定を遅らせる工夫」をすることが大切。実はリーンソフトウェア開発では、データモデルも、高リスク制約には入っていない。（ぼくは、場面－たとえば渡辺さんの言われるような基幹業務システム－によっては入ると思っている）

このバランスの話をすると、プロジェクトや製品の文脈によって一概には言えない（だから、文脈ごとに考える必要がある）。Barry Boehm は、このバランスをこんな図（需要供給バランスの図に似ている）で表している。

横軸に、「設計への投資時間」を、縦軸に「設計しすぎ、および、設計しなさすぎ、のリスク」をとって、プロジェクトごとにプロットする。当然、設計や計画に多くの先行投資をし決定事項を多くつくってから開発すれば、設計不十分というリスクを抑える。ところが逆に、設計しすぎて先行投資しすぎるリスクが高まるのだ。

そして、この損益分岐はプロジェクト毎に異なる、というのがベームの主張である。さらに、これはプロジェクト毎、ではなく、サブシステムごと、レイヤーごと、など細分化して適用できるため、先ほどのメアリーの主張とあわせると、

高リスク制約を抜き出して、そこだけは、設計を十分に行え。そうでない部分は変更可能性を保ち、アジャイルに進めるべし、ただし、高リスク制約は思ったよりも多くないぞよ。となる。

最後の但し書きについて一言。

高リスク制約と思われていたものが、最近変更コストが低くなった、という例も本当に多い。たとえば、インフラアーキテクチャの選定と構成は、クラウドが出てから本当に劇的に変わった。先日、AWSの玉川さんと話していて分かったのだが、いまや、机上の推定と計算でインフラの構成を決めているなんて時代遅れだ。クラウドでは、マシンやロードバランサー、コア数やCPUスペックまで、プログラムのように変更できる。すなわち、変更可能性が飛躍的に向上した。こうなると、「緻密に設計する」のではなく、「まずやってみる」、とか、「やって見て、足りなかったら変更する」という方が圧倒的に、コストが低い。

これは、少し年代が高い人は分かると思うが、昔はマシンの時間が高価で、コンパイルにとても時間がかかったから、机上デバッグしていたのに、今は一人ひとつのPCが当たり前になり、IDEが進化してその場でどんどんコンパイルできるようになった。こうなると、「机上デバッグ」なんてするよりも「まずはコンパイルしてみる」という方が圧倒的に生産性が高い。

そんなわけで、高リスク制約と思われているものでも、最近は後で変更が可能となってきたものが多い。それに、工夫すれば後で変更するオプションをできるだけ維持しながら開発できる。こう考えることで、できるだけ、ユーザに見える動くソフトウェアを、すばやく提供すること、すなわち、ケーキを縦に作ることが可能になってきた。

それに、クラウドをはじめ、試すコスト、はどんどん下がっている。ケーキをどれだけ縦に切れるか、その勾配はどんどん垂直に近くなっているのである。

P.S.
ところで、実際に苺ショートケーキ、だが、最近はホールケーキをカットするのでなく、まさに、ショートケーキで作る、とうい話を聞いたことがある。この話の真偽を知っている方はぜひ教えて欲しい。

P.P.S.
また、データモデリングをアジャイルの中でどう扱うか、という話はScott Amblerが昔からしていて、Agile Data とか、Agile Modeling という分野がある。ぼくも、Astah をMindmapと組み合わせて、もっともっとホワイトボード的に使い、Agile Modeling の分野に活用したいと考えている。

（※9/6 追記

• Kentさんによる同様の課題と考察の記事がよくまとまっています。
• kiro さんより、「髙杉のショートケーキ」は、どんなサイズでも作れる、との情報を得る。

）