技術制約とアーキテクチャドライバー その２

アーキテクチャドライバーに登場する４種類の要素は、それぞれ次のように定義されています。

• ビジネス制約＆技術制約
設計段階以前にすでに決められている束縛条件
• ハイレベル機能要件
システムが実行すべき大まかな機能
• 品質特性要件
可用性、パフォーマンス、セキュリティといったシステムが保持すべき特性

前回お話したように、ハイレベル機能要件はこの４種類の要素の中でアーキテクチャの構造決定への影響が最も小さいと考えられています。ビジネス制約や技術制約は、文字通り "制約" で交渉の余地はありません。 例えば、製品の納期や開発に使用するプログラミング言語、データベース、ミドルウェアなどがそれです。「データベースは MySQL を使ってほしい」とクライアントから言われた場合、アーキテクチャドキュメントのどこかに必ず MySQL が描かれていないといけません。Tony 先生は、ソフトウェアアーキテクチャを建築物にたとえて、これらの制約は "load bearing wall" みたいなものだ、と言っていました。そこにどっしりと固定されて設計の際にいやでも考慮しなければならない耐力壁に見立ててるんでしょうね。このように、ビジネス制約、技術制約、品質特性要件がアーキテクチャの構造決定に大きく関係してくることがわかります。

さて、概念的な話はここまでにして MSE の Studio プロジェクトに話を移したいと思います。Studio プロジェクトは MSE プログラムの全期間（16か月間）に渡って行われる、いわばソフトウェア開発のトレーニングです（Studio プロジェクトのアーカイブサイトはこちらから）。
プログラムの最初に5人のクライアントがそれぞれのプロジェクトについてプレゼンを行い、そのプレゼンをもとに生徒が取り組みたいプロジェクトをピックアップします。私が入学したときにプレゼンをしたクライアントは 5 人。そのうちの 4人が CMU もしくは SEI 関係者で、私のプロジェクトのクライアントだけが外部の方でした。

全般的に言って私の年の Studio プロジェクトには実世界のプロジェクトに見られるようなビジネス制約はありません。なので、完成したシステムに対する Return on Investment はどれくらいでなければならないとか、システムはアップグレードを続けながら最低十年は使えなければならないというような制約は私の年の Studio プロジェクトにはありません。

ただ、どのクライアントも技術制約ははっきりしていました。最も多かった技術制約が Eclipse プラットフォームをベースに開発することでした。私のプロジェクトもそれに当てはまります。しかし、私のプロジェクトはそれに加えて、とある開発プラットフォーム X を採用してほしいという制約がありました。これが killer でした。関連書籍はこの世に一冊もなし。オフィシャルウェブサイトはあるものの、そこの技術文書には私たちが探している API の説明はなく、多くの時間を費やしても欲しい情報が手に入らないため、X の概要が全くつかめないという状態が続いていました。技術制約が把握できなければアーキテクチャのデザインもできない。そこで春学期にチームでたどり着いた決断が、このX の API を使うモジュールの数を最小限にして、そのモジュールを他から隠ぺいするということでした。そうすれば、それらのモジュールの実装が遅れても、システムの大部分は実装することが可能だからです。

夏学期が始まってから私のチームが直面していた問題は、X のソースコードはすべて公開されているにも関わらず、コードベースがあまりに大きく API ドキュメントがないため、私たちのプロジェクトに必要な API を特定することができないというものでした。ある週に、私を含めメンバー数人で合計約40時間コードリーディングを行いましたが、目的があいまいなそのコードリーディングはあまり有益ではありませんでした。その週以来、X の API を使うモジュールの実装を納期までに仕上げるのは無理なんじゃないか、なんて不安にずっと駆られていました。そう、ある朝チームメンバーの一人がひとつの打開策をもってオフィスにやってくるまでは・・・