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

The Rational Edgeより：シリーズ最後の4回目となる本稿では、企業やIT部門が安定したソフトウェアアーキテクチャから享受できるメリットについてPeter Eelesが解説する。

[Peter Eeles（IBMシニアITアーキテクト），＠IT]

　筆者による本シリーズの第1回目「ソフトウェアアーキテクチャって何なの？（前編）」は、ソフトウェアアーキテクチャとは何かについて書いた。2回目「ソフトウェアアーキテクトの役割」はソフトウェアアーキテクトが果たす役割の特性について説明し、3回目「ソフトウェアアーキテクティングのプロセス」はソフトウェアアーキテクティングのプロセスの基礎にあるテーマ、つまり特性について考察した。シリーズ最後の4回目となる本稿では、企業やIT部門が安定したソフトウェアアーキテクチャから享受できるメリットについて説明する。

　大まかにいえば、ソフトウェアアーキテクティングとはコスト削減、品質向上、スケジュールどおりの引き渡し、要件どおりの引き渡しにとって重要な要因だ。本稿では、これらの目的達成に寄与する具体的なメリットに重点を置いて解説する。アーキテクトとしては、時に自分たちの存在を正当化しておく必要があることも指摘しておきたい。本稿では、アーキテクティングをソフトウェア開発プロセスの非常に重要な部分として扱うために有益な手段もいくつか示す。

◆ アーキテクティングはシステム品質を向上させる

　システムの機能は、アーキテクチャを構成する各種要素のやりとりを通じて、そのアーキテクチャにサポートされている。しかし、アーキテクティングにおける重要な特性の1つが、システム品質の達成手段だ。パフォーマンス、セキュリティ、および維持管理性といった品質は、統一されたアーキテクチャのビジョンなくしては達成できない。これらの品質が、アーキテクチャの1つの要素に限定されるのではなく、アーキテクチャ全体に広がっているためだ。例えば、パフォーマンス要件に対応するには、アーキテクチャ内の各コンポーネントの実行に必要な時間と、内部コンポーネント間のコミュニケーションに必要な時間も検討しなくてはならない可能性がある。同様に、セキュリティ要件への対応には、コンポーネント間のコミュニケーション特性を検討し、必要に応じて具体的な「セキュリティ対応」コンポーネントを投入しなくてはならない場合もある。これらの懸念はすべてアーキテクチャに関係するものであり、例では、個々のコンポーネントや、これらの間のつながりに関係する。

　アーキテクティング関連のメリットの1つが、このような品質をプロジェクトライフサイクルの早い時期に評価できるようになることだ。アーキテクチャのプロトタイプは、このような品質への対応を保証するだけの目的で作成されることも多い。机上で見るアーキテクチャがいかに優れていても、アーキテクチャがそのような品質を達成したかどうかは実行可能なソフトウェアを使う以外に測定方法がないため、これは重要なことなのだ。

◆ アーキテクティングは意見の一致を実現する

　アーキテクティングのプロセスは、これがシステムソリューションをめぐる議論を実現する手段となり、さまざまな関係者間の意見の一致につながる。このような議論をサポートするために、アーキテクティングのプロセスは、アーキテクチャが明確に話し合われ、理解されているよう確実を期す必要がある。効果的な伝達が行われたアーキテクチャは、判断やトレードオフに関する議論、審査の促進、そして合意が実現する。逆に、伝達がうまく行われなかったアーキテクチャでは、このような議論が出てこない。このように意見が集まらないと、その結果完成するアーキテクチャは品質の低いものとなる可能性が高い。

　これと関連して、アーキテクチャはトレーニングの一環として、アーキテクト（およびそのビジョン）と新旧両メンバーの意見の一致を促進することもできる。ここでも、このようなメリットを実現するためには、アーキテクチャが効果的に伝達される必要がある。インプリメントするものに対して明確なビジョンを持った開発チームの方が、製品を思いどおりにインプリメントできる可能性が高い。

　そのためにも、アーキテクチャは適切にドキュメント化しておくことが重要であり、それがアーキテクトの重要な責務の1つだ。同様に、アーキテクチャが提示要件を満たしているかどうかを示すには、実証用アーキテクチャの作成が非常に優れた手段となる。

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

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

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

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

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

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

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

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

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

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