アーキテクチャの評価は何でする？：ITアーキテクト的発想のススメ（4）（1/2 ページ）

これまでの連載では、アーキテクチャについて抽象的な切り口から解説してきた。今回は、もう少し具体的な、設計したアーキテクチャは、どのように評価すればいいのかという点を考えてみたい。

[東山 靖弘，＠IT]

アーキテクチャの見方を再考する

　本連載では、これまで「全体と部分」「外部と内部」「通時的と共時的」といった切り口からアーキテクチャの見方を紹介してきた（「ITアーキテクト的発想のススメ」のインデックスページ）（注1）。アーキテクチャの定義については、＠IT情報マネジメントのThe Rational Edgeの記事「ソフトウェアアーキテクチャって何なの？」（注2）においても解説されている。

　当該記事では、おおむねアーキテクチャとは「システムの基本構成原理、実装を含まない設計思想である」とされている。そのため、これまで紹介した本連載での見方は、それを受けたわけではないが、概念的、抽象的な表現が多かったかもしれない。

　そこで今回は、アーキテクチャという概念を具体化し、その評価を考えていきたい。設計思想としてのアーキテクチャの見方ではなく、現実にそのアーキテクチャを採用する場合のアーキテクチャと実装の関係、アーキテクチャの意味するものを扱う。

アーキテクチャと実装の関係

［問い］

　「この2つのアーキテクチャ、どちらの方が信頼性が高いですか」

　こういった質問を受けたことはないだろうか。システム更改などに当たり、新旧システムの比較をしたい場合によくこのような質問がでてくる。ここで言葉の定義を詳しく行うつもりはないが、この質問はもう少し詳しく書くと、以下のような趣旨でなされている場合が多い。

［問い］

　「この2つのアーキテクチャでそれぞれシステムを実装した場合に、どちらの信頼性（可用性、耐障害性、故障頻度、復旧時間……など、いろいろな意味）が高いですか」

　アーキテクチャ自体は設計思想と呼ばれるものであり、実装を含まない。例えば、ソフトウェアアーキテクチャが「コンポーネントとコンポーネント間の関係で構成される」と定義されるように、設計上の概念にすぎない。従って、その最終的な品質やコストを決定するのは、実装なのである。

　では、アーキテクトが新しいシステムのアーキテクチャを設計する際に、その優劣を評価するにはどうしたらよいのだろうか。

アーキテクチャを評価する

　初めに、アーキテクチャを評価するということの目的を確認しておこう。

　繰り返しになるが、アーキテクチャは設計原理、思想であって、それ自体は1つの設計の考え方の体系にすぎない。その体系に論理的な整合性があるかどうかという点で、正しいか間違っているかという評価ができるだけである。では、前述のように、アーキテクチャを評価しようとする目的はどこにあるのだろうか。

　アーキテクチャを選択しようとする際に、主に以下の2点を評価したいのではないだろうか。

• アーキテクチャを導入することがステークホルダーにとって価値がある
• アーキテクチャの実装に実現可能性がある

　1点目の価値は、実装されたシステムの品質やコストがその評価対象となるであろう。また、実現可能性は、実装におけるリスクの大小という形で評価するのが一般的である。

（注1）「ITアーキテクト的発想のススメ」のインデックスページ

（注2）「ソフトウェアアーキテクチャって何なの？」