Inside-Out Principle

ソフトウェア原則の１つであるInside-Out Principleについて私の考えを書きます。

Inside-Out Principleの最大のポイントは依存性の方向を統一するということです。UIはModelに依存してはいけません。つまり、UIに変更が入っても、Modelには手を入れなくてもいいように設計しておかなければなりません。
一方、Modelから先に作ると、ユーザーからのフィードバックを得にくいというデメリットがあります。ユーザーが理解できるのはUIです。UIに関しては、ユーザーからのフィードバックを得ることができます。

では、ModelとUIのどちから先に作るのがいいのでしょうか？

私の考えでは、フェーズによって作る順番（方向）を変えます。
要求開発・提案フェーズではUIから決めていきます。つまり、操作説明書を先に作ります。これによって、操作説明書をベースにユーザーの要求を確認することができます。作成した操作説明書を元に、ユーザーとレビューを行います。開発者間での意識合わせにも使います。
ちなみに、操作説明書を最初に作成するというアプローチは決して新しいものではありません。組み込みの量産品の開発に携わったことがある人にとっては普通のことです。携帯電話やカーナビのような量産品では、操作説明書も製品と一緒に出荷されるため、操作説明書は製品発売の２，３ヶ月前に印刷工場にまわされます。よって、操作説明書は相当早いフェーズでFIXされます。操作説明書には画面のキャプチャ・イメージは必須ですが、この段階でUIモックを作っておきます。
設計・実装フェーズのモックを作る段階では、Modelから先に作ります。最後に要求開発フェーズで作ったUIモックにつなぎ込みます。Modelから先に作るのは依存性の方向を統一するためです。UIはModelに依存してはいけません。UIは変更が入りやすいからです。
その後、モックを本番用にしていきます。依存性の方向はモックを作る段階で固まっているので、どこから作っても構いませんが、UIに近いところから作るのがいいでしょう。そうすれば、顧客はUIモックから徐々に動くようになっていくソフトウェアを見ることができます。UIから先に作るので、変更の入りやすいUIに関するユーザーからの要求は、即座に動くソフトウェアに反映できます。
試験フェーズでは、Modelから先に試験します。何となくこの辺はイメージしやすいかもしれません。TDDであれば、試験フェーズというより、実装の段階で既に試験が終わっていますね。

１	要求開発・提案フェーズ	UIからModelへ。UIモックを作っておく。
２	設計・実装フェーズ（モック）	ModelからUIへ。UIモックにつなぎ込む。
３	設計・実装フェーズ（本番）	UIからModelへ。
４	試験フェーズ	ModelからUIへ。

ここで問題になるのが、１と２のギャップです。モックを作るのにモタモタしていると、ユーザーに見せるものがない状態が続きます。できれば、１回のイテレーション（１〜２週間）の間に２のフェーズ（モック）を完成させたいところです。Ruby on Railsなら瞬殺です。Javaを使う場合でも、DIを活用すればモックから本番用への移行は楽です。

モックの作成を瞬殺できるような仕組み（フレームワーク）を検討しておく必要があります。