ソフトウェアアーキテクティングのメリット：The Rational Edge（2/4 ページ）

[Peter Eeles，＠IT]

アーキテクティングは計画プロセスを支援する

　アーキテクティングのプロセスは各方面の土台になる。これらに直接関係することから、アーキテクチャがデザインとインプリメンテーション作業をサポートすることは明らかだ。しかし、アーキテクティングのプロセスが実現するメリットとして大きいのは、おそらくプロジェクト計画のサポートに関するものや、スケジューリング、作業配分、コスト分析、リスク管理、およびスキル開発を中心としたプロジェクトの管理作業全般だろう。アーキテクティングのプロセスは、これらの案件をすべてサポートできる。だから、アーキテクトとプロジェクトマネジャーは密接な関係を維持する必要がある。このようなサポートは、アーキテクチャがシステム内の重要なコンポーネントや、それらの関係を特定していることが大きな要因になっている。説明のためにあえて簡単に描いた図1のUMLコンポーネント図をご覧いただきたい。この図には、4つのコンポーネントと、それらの間の依存関係が示されている。

図1　アーキテクチャ上重要な要素を示すUMLコンポーネント図

　スケジューリングに関しては、依存関係がこれらの要素を検討する順番を示している。例えば、インプリメンテーションの観点から見ると、依存関係から「Error Log」コンポーネントを真っ先にインプリメントする必要があることが分かる。ほかのすべてのコンポーネントがこのコンポーネントを使うためだ。そして次は、「Customer Management」と「Fulfillment」の両コンポーネントを並行してインプリメントできる。これらが相互に依存していないためだ。最後に、これら2つのコンポーネントをインプリメントしたら「Account Management」コンポーネントがインプリメントできる。そして、この情報から図2のようなガントチャート（プロジェクトマネジャーにとって重要なプランニングツールの1つ）を作成することができる。示されている各タスクの所要時間には検討の余地もあるが、アーキテクチャの各要素の複雑性から部分的に導き出すことは可能だ。

図2　アーキテクチャ上重要な要素の間の依存関係に基づくガントチャート

　多くの理由からこれがかなり簡略化されているのは明らかだ。例えば、これらの要素はどれも1つのコンポーネントとしてインプリメントされる可能性は低い。そうするにはあまりに複雑過ぎるためだ。また、各要素のインプリメンテーションを並行して進められるよう「細切れ」あるいは部分的にインプリメンテーションを行うことも可能だ。わたしは、単にこの原理を証明するためにこの例を用いている。

　作業配分に関しても、特定のスキルが必要とされ、そのために作業を割り当てる特定の資源（人材）が必要な分野の確認にもアーキテクチャが役立つ。

　アーキテクトは、プロジェクトの費用見積もりも支援することができる。プロジェクトに関連するコストは、さまざまなところから発生してくる。タスクの所要時間や、それぞれに割り当てられるリソースから人件費を判断できるようになることは明らかだ。アーキテクトは、引き渡されるシステムでサードパーティー製コンポーネントを採用した場合のサードパーティー製コンポーネントのコストや、開発作業のサポートに必要なツールのコストの判断も支援する。これは、設計者や実装担当者などの各チームメンバーの効率的な共同作業を可能にする適切な開発環境の選択もアーキテクトの関与する作業の1つであるためだ。

　アーキテクトはもう1つ、プロジェクトに関連する技術リスクの特定や管理にも重点を置く。技術リスクの管理には、各リスクの優先順位づけや、適切なリスク緩和戦略の識別などがある。優先事項やリスク緩和戦略は、情報としてプロジェクトマネジャーに伝えられる。

　最後にアーキテクチャは、プロジェクトに必要なスキルについての情報を提供するソリューションの、個々のコンポーネントを識別する。もしプロジェクトの中、もしくは組織の中に十分な資源がない場合は、スキルの獲得が必要とされる分野の特定に、これが役立つことは明らかだ。このことは、既存の人材を開発する、アウトソーシングを利用する、あるは新規採用を実施することなどで実現できる。