案ずることと成すこと

「案ずるより生むが易し」とはよく言われることだが、日々の開発においてコードの「生成」に対して「案ずる」ことで費やす時間は結構大きい。特に対象が個別の業務処理ではなく、基盤部分(フレームワークやライブラリなど)である場合はそれが顕著である。デザインの要素が入ると生産性が大きく下がるという話を聞いたことがあるが、規模が大きな業務アプリケーション開発では、人員を増やしてのコード作成フェーズに入った場合に作業者の手が止まらないように、デザインすべきこと(考えて決定すべきこと)を、前もって終えておく必要がある。個別の作業者の作業は仕様を実現するように与えられた基盤の上でコードを組立て、テストをすることであるのだから。
　では、デザインフェーズでの決定に時間がかかる要因は何であろうか？それを明らかにするのが本書の目的である。

１．本書でのデザインの定義
　デザインとは、ラテン語の[designare]が語源であり、意味は「計画を記号に表わす」ことである。つまり、ある問題を解決するために思考・概念の組み立てを行い、されを様々な媒体に応じて表現することと解すことができる。(wikipedia)
　多くの言葉は、狭い意味で使用される場合と、広い意味で使用される場合があるが、デザインの場合もこれが当てはまる。建築を例にすると、設計図を作成することが狭い意味でのデザインであり、部品展開して材料や道具を明らかにし、作成工程の立てて人員や資材などの調達を計画することが広い意味でのデザインとなる。
　本書では「デザイン」という言葉をソフトウェアの「システム設計」に限定して話を進める。システム設計において必要となる事柄には、以下のようなものがある。
・要件や仕様を実現するための
　・基盤部分の調査、選定、作成、テスト
　・業務機能実装のための要素分解と作業量見積もり
　・人員や資材などの調達計画の作成
　・開発環境および作業要領の作成
　・工程計画の作成

・基盤部分の作成においての
　・各種規約類の整理
　・共通ライブラリの作成
　・フレームワークの作成

２．デザインのメカニズム
　多様体的な見方：地図では、都市というような限定した場所を示す場合は平面に表示するメルカトル図法が適しているが、地球や宇宙というような平面とはとらえられない場所では、他の方式を採用する方が妥当となる場合がある。デザインにおいても、マクロ的な観点でのアプローチやアウトプットは、ミクロ的な観点でのそれとは異なるのも十分にありうることである。
２－２．マクロ的観点
　マクロ的な観点から「システム設計」の流れを記すと以下のようになる。この内、最初の3件は「システム分析」と呼ばれることが多い。
・把握：何をどうしたいのかという要件、仕様の抽出
・分離：要件、仕様を基盤共通、業務共通、業務固有へと分離
・確認：実現可能性の調査、使用可能は製品や部品などの調査
・作成：基盤部分およびモデルとなる業務要素
・計画：作業計画

２－３．ミクロ的観点
　ミクロ的な観点では、個々の作業ごとにアプローチやプロセス、およびアウトプットがあることになる。ここでは、基盤部分のライブラリ作成について記す。
・課題の把握：何をどうすればいいのか
・類似コードの調査：すでの類似のものがある、流用できないか、拡張するだけですまないか
・作成場所(クラスやパッケージ)の選定、作成
・コードの作成とテスト：狭義のデザインには実装は入らない。それは建築などでは個々の部品が実在しており、その機能性や外観が分かっており、実際の組み立てをしなくとも計画を作成できるからである。ソフトウェアの場合にはこれが当てはまらない場合が多い。

それぞれのステップにおいて、「探し、考え、比較し、決定する」ことが求められるが、これが対象により作業時間が大幅に異なってくる要因となる。だからといってこの部分を仮決定のままにしておくことは許されない、後の作業に大きな影響をあたえることになるためである。

３．決定を遅らせる要因
　多くの場合、実装そのものが困難な場合は少数であり、以下のようなことを決定するための材料が不足していることが、決定を遅くする要因になると想定される。
　・最適ゴールの悩み：
　　　そもそも、要求されていることの解決(対処)が妥当なのか
　　　ミクロ的には必要に見えるが、マクロ的にとらえれと別のアプローチの方がすぐれていないか
　　　それを採用するとそもそもの要求が無意味や不要にならないか
　・重複の悩み：
　　　すでに類似のものがあり、流用できるのではないか
　　　車輪をもう一度発明したくない
　・最適配置の悩み：
　　　作成するものをどこに配置するのがいいのか
　　　とくに作成するものが公開仕様を持つ場合は顕著
　　　配置の変更が公開仕様の変更になってしまい、影響が大きくなるため
　・最適単位の悩み：
　　　どういう単位で公開するべきか
　　　大きめの機能モジュールとしてか、小さめのライブラリやユーティリティとしてか
　　　単位の変更が公開仕様の変更になっていしまうため
　・効率の悩み：
　　　処理効率が悪くならないか
　・拡張性の悩み：
　　　将来の拡張の妨げにならないか
　・再利用の悩み：
　　　共通基盤として利用され続けられるのか

４．決定の重さ
　決定事項には重い・軽いの別がある。遅くなりがちなのはほとんどの場合、重い決定事項であるといえる。
　例えば、システムを作成する場合に、「公開仕様を限定した部品同士の組合せ」としてデザインした場合、個々の部品の実装は後回しにしたり、仮組しておいて後で取り換えるなどの融通が効く。しかし、この公開仕様部分の決定を変更することはコストが高くなる。つまり、この仕様の決定は、部品内部の変更に比較すれば重いものになる。つまり、ソフトウェア設計において「重い、軽い」は、後から簡単に手直しできるか、手直しには多くの影響を招くかの違いが大きいといえる。
　Javaなどのクラスという定義要素をもつ場合においては、以下のようなものがある。
　　簡単に手直しできるもの：影響が限定的なもの
　　　名称の変更：名称をAPI仕様にしていない場合
　　　公開仕様を固定したモジュールの取替え、組直し
　　　Private要素の移動や変更
　　大きな影響をもたらすもの：影響が大きいもの
　　　公開仕様の変更：APIや機能の変更
　　　Public要素の移動や変更