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

■問題空間

　問題空間の定義、そして最終的にソフトウェア ソリューションの範囲の設定には、何を構築するかの理解、さらには問題領域の知識とそのソリューションの中で情報がどう流れるのかの概念化が要求されます。以下の各セクションで詳しく説明しますが、これらのスキルはソフトウェア ソリューションの用途を理解し、提案されたソリューションをすべての関係者に説明するときに不可欠です。

●問題領域の知識

　ソフトウェア ソリューションの問題領域には水平型と垂直型があります。水平型領域は、ワークフローの自動化のように異業種間で応用できます。垂直型領域は、通信のように、その業種特有のものです。問題領域はサブ領域に細分化したり、大きな領域に統合したりできます。垂直型領域内のサブ領域の例は、通信でのネットワークのアクティブ化です。サブ領域の大きな水平型領域への統合の例は、企業アプリケーション統合製品でのワークフローです。

　ソフトウェア ソリューションを定義するときに考慮する必要のある標準規格やプロトコルを設定する規格策定団体や垂直業界グループが多数あります。これらの組織には、垂直型業界領域に特有の組織と、水平型業界領域に特有の組織があります。TMForum は、特定の通信業界の管理プロトコルを設定する垂直型組織の例です。W3C は Web サービスのようなテクノロジを含む水平型の World Wide Web 領域の標準規格を設定します。

　領域に関する知識の価値は IT マネージャーによって過小評価される場合があります。私は通信会社で仕事をしたことがありますが、そこの IT リーダーは、組織の構造をビジネス領域に照準を絞った "優秀な中心的人材" を取り囲む構成から、領域の知識とは無関係に、技術的なスキルに基づいた人材の "プール" で構成されるように改革しようとしました。Web 開発のような水平型領域に配置された人材には、このモデルはよく機能しました。Web インターフェイスは多くの製品で使用され、そのスキルは垂直型領域全体に応用できます。"人材プール" 構造が失敗したのは、ネットワーク アクティブ化のような業種に特有の垂直型サブ領域でした。サービスを調達してアクティブ化する方法を理解するには、プロビジョニング プロセス、インターフェイス、プロトコル、およびその通信サービスを構成するネットワーク デバイスの標準規格についての詳しい知識が要求されます。

　領域に関する深い知識の習得には時間がかかる場合が少なくありません。すべてのプロジェクトで担当者がその領域の詳細にわたる知識をリリースごとに習得しなければならないとしたら、生産性が大幅に低下します。機能の提供にかかる時間が一定になるように機能が十分に分解されている場合を想定すると、生産性はその領域の知識の習得にかかる時間に比例して低下します。逆に、1 つの業務に対応する各垂直型領域の周りに "優秀な中心的人材" を維持することもコストがかさむ方法です。開発の仕事は、その時間枠内で均等に進行することはめったにありません。一定数の人材を 1 つのプロジェクトに割り当て、ソリューション機能の提供に向けた取り組みが休止状態のときにもそのまま維持しておくことは、他の開発業務の生産性低下をもたらします。

　テクノロジ企業は一般に、アーキテクトを領域の専門家として起用し、人材プールをさまざまなプロジェクトで利用することでバランスをとっています。この方法は、垂直型領域での知識の習得にかかる時間を最小限に抑えることで生産性を向上します。この体制では、開発要員に仕事を始めさせる前に、予備調査をすることもできるので、開発での生産性を一貫して維持するのにも役立ちます。このアプローチには柔軟な雇用モデルの応用という追加の利点があります。つまり、開発要員は契約社員で補充できる一方、契約が終了したときに貴重な専門家が会社を去るということがありません。

●概念レベルでの思考

　アーキテクトの任務の一部は、相手が技術者か非技術者かを問わず、関係者にソリューションを説明することです。ソフトウェア ソリューションの機能的な要件の達成が気がかりな関係者にソフトウェア ソリューションを説明するには、それを概念化する能力が不可欠です。全員が技術的な詳細について知識や関心があるとは限りません。ソフトウェア ソリューションの開発に取り掛かる前に、概念的なアーキテクチャを定義すると、製品の市場範囲を定義するのに必要なフィードバック ループの促進に役立ちます。仕事の規模と製品コストの最初の見積もりを出すのにも役立ちます。

　概念的なモデルはソフトウェア アーキテクチャに最も関連した成果物です。通常、概念的なモデルはソフトウェア システムの機能的な要件を満たす構成要素とその要素がソフトウェア ソリューションのどこ (ユーザー インターフェイス、ドメイン レイヤー、その他) に応用されるかを示します。概念的なモデルでは、提案されたソリューションにおける情報の流れを示すために図を使用することがよくあります。ソフトウェア システムが他の製品やソリューションのコンポーネントで構成されている場合、概念的なアーキテクチャにはソリューションのさまざまな部分にアクセスするためのプロトコルが含まれていることがよくあります。

　適切な粒度を応用することは、概念的なモデルを定義するうえで最も頭を悩ませる問題です。概念的なアーキテクチャでは、特定のプラットフォームやテクノロジに触れるべきではありませんが、サブシステムへのアクセスで使用するプロトコルは例外です。私は一度、1 年以上 "分析麻痺" 状態になっていたプロジェクトをアーキテクトとして引き継いだことがあります。キャッチアップするためにドキュメントを読みましたが、概念的なアーキテクチャの中身としては、テクノロジの名前が入ったボックスがいくつかあるだけで、システムの機能との関係については何も言及されていませんでした。そのドキュメントを読んで、なぜそのシステムの開発ができなかったかがわかりました。必要な機能にまったく触れられていないため、何を開発する必要があるのかを理解することが困難でした。

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

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

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