■

前回、方式設計のミッションと思われる（ちょっと自身ない）を列挙してみました。こうすると、方式設計とはプロジェクトそのものをデザインする工程だと思ったです。

ソフトウェア・デザインと同様、この設計が後の工程に与える影響は少なくないです。無駄なタスクやリスクの見過ごしがいったいどんな結末を生むのか、いくつかのパターンは皆さん見た事、体感した事があると思います。

このうち、まずシステム基盤設計に着目します。
例えば、帳票を印刷するからプリンタが必須とか、Webシステムだからブラウザを使うとか、提供方式によって必要となるシステムの構成要素があります。そういったものを洗い出して決定していくのがこのシステム基盤設計です。システム基盤の構成を決めておかないとそもそも後に続かないのと、ここである程度リスクを見込むことができるので非常に重要です。

次いで、そのシステム基盤の上に乗せるアプリケーションの基礎を設計します。
それがアプリケーション基盤です。通常、アプリケーションには色々な機能がありますが、それらの機能から同じ制御を共通化して、可能な限りそれぞれの機能を軽量化する事で後の工程のコストを可能な限り削り取ります。ここで変な設計をすれば、一つの機能を実装するのに必要なコストが増えますから、プロジェクトを活かすも殺すもココ次第、と自分は考えています。

ただし、設計者から開発者に至るまで全て有能なアーキテクトだった場合は、もしかしたらアッサリ乗り切れるかも知れません。。。まぁそんな人たちが集まって、アーキテクチャ定義なしで開発なんてあり得ないでしょうけど。

ここまで決めれば、要件はもうある訳ですから、何をどう作れば良いか見えますよね。つまりタスクが必然的に洗い出されますし、リスクも見えてきます。