アーキテクチャ・ジャーナル アーキテクトが必要ないということはない！ Joseph Hofstader 2008/10/20
Page1 Page2 Page3 Page4

■ソリューション空間

　アーキテクチャとの対立が最も明白な領域は、ソリューション空間の定義です。開発者は通常、アーキテクトが問題空間を扱うことに反対しませんが、ソリューション空間をアーキテクトが定義することに抵抗がある場合があります。多くの場合、特にアーキテクトが最新の技術的な知識を習得するのを怠っている場合、アーキテクトがソリューション空間に口出しすることに対する開発者の苦情は正当です。

　開発者のアーキテクトに対する態度は、「アーキテクトは "あぶく" を使って話し、開発者はコードを使って話す」(図 3) という私の同僚の言葉によく表現されています。コードがソフトウェア開発プロジェクトで作成される唯一の重要な成果物であるという考えは広く受け入れられていて、「Agile Manifesto ( アジャイル ソフトウェア開発宣言)」にも価値のあるものの 1 つとして記載されています。「包括的なドキュメントよりも機能するソフトウェアを尊ぶ」というのがそれですが、有能なアーキテクトはソフトウェア ソリューションの最も重要な部分は否定の余地なくコードであることを理解しています。近頃の開発環境の多くは "あぶく" からコードを作成できるようになっています。Model Driven Architecture (MDA: モデル駆動型アーキテクチャ) や Domain Specific Languages (DSL: ドメイン特化言語) をサポートするツールもその一部です。

図 3: "あぶく" を使って考えるアーキテクト

　とは言え、有能なアーキテクトはソフトウェア ソリューションはカスタム コードで実装される機能的な要件だけでできているわけではないことも理解しています (図 4)。たとえば、開発プラットフォーム、フレームワーク、インフラストラクチャ テクノロジなども含まれます。展開、セキュリティ、拡張性、パフォーマンスなど、ソフトウェア ソリューションの非機能要件も考慮する必要があります。非機能要件を軽視すると、システムで障害が発生する可能性が高くなります。

図 4: 図の一部を見る開発者

　もう 1 つ重要なソリューション空間の知識は、ソフトウェア ソリューションを実装するために使用するパターンです。パターンはソフトウェアソリューションの拡張性と再利用を考慮した開発を可能にします。これはソフトウェア ソリューションの総保有コストの低減に重要なことです。特に開発後期や製品の保守の段階で重要になります。

●技術的な洞察力

　テクノロジは、記憶にある限り急速に発展し続けてきました。私は過去10 数年にわたって無数のテクノロジを実装してきました。その中にはプロセス分散、ユーザー エクスペリエンス プログラミング言語、企業アプリケーション統合、オブジェクト リレーショナル マップ、仮想化、データ永続などのテクノロジがありました。

　テクノロジがどのように機能するかを理解しただけでは、堅牢なソフトウェア ソリューションを開発できません。優れた製品の開発には、ソリューションのどこにそのテクノロジを応用するかの理解が不可欠です。テクノロジの意図された用途にもそのテクノロジが満たす機能要件にも触れずに、テクノロジを表す Visio 図のボックスが並んでいるだけというアーキテクチャ ドキュメントを見る機会が何度かありました。このような仕事はアーキテクトの評判を悪くします。

　すべてのテクノロジを完全に理解することは誰にもできません。しかし、アーキテクトは少なくとも、ソフトウェア ソリューションのコンテキストでテクノロジの使用を要求する前に、そのテクノロジの意図と応用範囲を理解している必要があります。また、アーキテクトはテクノロジを機能要件や概念的なアーキテクチャの中の応用箇所に結び付ける必要があります。アーキテクトがそのテクノロジをどこに応用するのかを説明せずに技術的な命令を下すといういい加減な仕事に出会うことがあまりにも多すぎます。正直な話、私自身駆け出しのころに同じような間違いを犯したことがあります。

　アーキテクトはテクノロジに情熱を傾けすぎて、問題の解決が二の次になってしまうことがあります。ソフトウェア ソリューションに合ったテクノロジを選択するコツは、機能的にも非機能的にもシステム要件を満たす最小限のテクノロジを見つけることです。パフォーマンスや拡張性など、すべての品質基準を満たすソフトウェア製品を提供するには、かなりの技術的な知識が必要です。開発および展開用のプラットフォームを定義するのもアーキテクトの仕事です。

　テクノロジの発展状況を考えると、最新のトレンドに遅れないようにするのは並大抵のことではありませんが、アーキテクトには不可欠なことです。私が以前に仕事をした会社では、クライアント / サーバー レポート アプリケーションのパフォーマンス問題を抱えていました。そのアプリケーションはテクノロジを更新せずに長年使用されていました。そのソリューションを担当していたアーキテクトは、リレーショナル モデルの上にオブジェクト レイヤーを構築すれば彼のアプリケーションの問題は解決すると主張して譲ろうとしませんでした。提案されたソリューションは 10 年前なら標準的なものとして通用したかもしれませんが、この 10 年間にデータベース テクノロジは大きな進歩を遂げ、今では最適化されたレポート作成サービスがプラットフォームの一部として含まれています。そのアーキテクトが提案したソリューションは総所有コスト (開発、保守、ライセンス) を増やすだけでなく、パフォーマンスを低下させる可能性の高いものでした。幸い、そのアーキテクトは最新のテクノロジを学ぶことを拒まず、製品のアップグレードで新しいデータベース プラットフォームの能力を利用できるようにしました。

●パターン

　偉大なアーキテクトに共通の重要なスキルは、ソフトウェア ソリューションの定義でパターンを活用する方法を理解しているということです。パターンがソフトウェア開発の大黒柱の 1 つになってから 20 年以上経ちます。Gamma 他著の『Design Patterns (設計のパターン)』を始めとして、『Pattern Oriented Software Architecture (パターン指向のソフトウェア アーキテクチャ)』(POSA) シリーズの書籍、業界の指導者による各種の出版物、Hillside Group のような組織による努力などの影響力を通じて、パターンはソフトウェア評価の主要な物差しになっています。新しいテクノロジやフレームワークについて読むとき、私はそのソリューションで使用されているパターンのリストを作成してその設計の質を評価するようにしています。

　ソフトウェア開発におけるパターンの使用が主流となっているため、それはアーキテクトの不可欠なスキルになっています。パターンを活用する方法の習得には時間と努力が要求されます。私のように、パターンの専門家と一緒に仕事をしてアーキテクチャと設計について教えてもらう機会があった幸運なアーキテクトもいますが、このスキルを独学で習得するしかないアーキテクトもいます。教えてくれる人がいてもいなくても、たまたまパターンに習熟するということはありえません。それには努力が要求されます。パターンの語彙の学習過程には時間がかかります。ソフトウェアの中のどこでパターンを応用できるかを理解するには、もっと時間がかかります。パターンの学習につぎ込んだ努力は 10 倍になって戻ってきます。パターンを習得したアーキテクトは同業者と設計について気のきいた話をすることができるようになり、拡張可能なソフトウェア システムを作成できるようになります。

　ソフトウェア ソリューションでパターンを利用する主な理由は、ソリューションを容易に拡張できるようにするフレームワークを設計できるからです。ソフトウェア ソリューションは、問題領域のコンテキストでソリューションのアーキテクチャを定義するためにフレームワークを使用します。優れたソフトウェア フレームワークは通常、多数の領域で再利用できる汎用のパターンを使用して定義されています。領域固有の言語を後押ししている主な動機の 1 つは、汎用フレームワークをカスタマイズするためのグラフィカル ツールを提供することによって開発者の生産性を向上させることです。前述のように、パターンはフレームワークを定義するうえで不可欠のコンポーネントです。

　パターンの理解によって生産性が向上した多くの例を挙げることができますが、最も良い例は、前述の 1 年以上立ち往生していたプロジェクトを引き継いだ例です。以前に似たようなソリューションを設計したことがあったので、拡張可能な領域モデルの構築に必要なパターンが理解できました。ラボに入れる機器が注文され、開発要員の面接が行われている間に、私は過去の似たような仕事で使用したパターンを利用して領域モデルとフレームワークを定義できたので、開発段階でスピードを上げることができました。私が開発した最初のフレームワークによって製品を短時間で提供することができたのです。

INDEX
	［アーキテクチャ・ジャーナル］
	アーキテクトが必要ないということはない！
	1．アーキテクトは何者なのか
	2．問題空間で求められるアーキテクトのスキル
	3．ソリューション空間で求められるアーキテクトのスキル
	4．アーキテクトが注意しなければいけないこと

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）