小野沢博文（アクセンチュア テクノロジー・アーキテクチャ・グループ プリンシパル）
2007/7/30

■アーキテクトの役割とスキル

　以下では、現在の私が考えているITアーキテクトの役割とスキルを、作業の時間軸に沿ってまとめてみます。

（1）ソリューションを提案する

　営業、コンサルタント、プロジェクト・マネージャなどのほかの担当者と協力して、顧客が何を実現したいのかを引き出したうえで、ソリューションを提案するのもアーキテクトの役割です。また、「何を」だけではなく、顧客が「なぜ」それを欲しているのかを見極めたうえで、目的実現のためのより適した提案を行うことも必要です。この作業の主担当は営業やコンサルタントですが、顧客の要求をくみ上げて技術的に実現可能なソリューションを提案するうえで、アーキテクトも重要な役割を果たします。

　ここでは、技術やIT業界の動向、さらには顧客の業界動向に対する幅広い知見とともに、コミュニケーション能力と提案能力が要求されます。

（2）システム構造を決定する

　顧客が実現したいものが明確になったら、それを実現するためのシステムの構造を決定します。この決定のためには、さまざまなトレードオフの調整が必要になります。予算、人員、スケジュールをはじめとする各種制約条件が最初から与えられていて、それらに基づいてアーキテクトが密室にこもってシステム構造を決定するということはあり得ず、通常はさまざまな制約条件を関係者と交渉・調整しつつ、それらの条件の中で構築可能なシステム構造をインタラクティブに決定していきます。

　このためアーキテクトには、設計能力以外に、コミュニケーション能力や交渉能力が要求されます。

（3）システム構造と実現方式を詳細化する

　予算、人員、スケジュールが決まり、プロジェクトがスタートすると、アーキテクトはシステム構造をさらに詳細化し、実現方式を決定していきます。その際、複数の実現方式候補を挙げ、必要に応じて実機でのプロトタイプを実施しつつ、実現方式を最終決定していきます。

　ここでは、全般的な設計能力とともに、個別技術に対する深い知識とスキルが要求されます。例えば、ソフトウェア設計を担当するアーキテクトであれば、ミドルウェア製品や開発環境、さらにコーディング・スキルを有し、リスクの高い領域のプロトタイプを迅速に作成して評価できなければなりません。

（4）実現方式を説明し合意を得る

　プロジェクト開始後も、あらゆる局面で顧客やプロジェクト・マネージャ、開発者などの関係者に、システムの実現方式や設計内容を説明し、合意を得ていく必要があります。従って、プロジェクトのあらゆるフェイズを通じてコミュニケーション能力が常に必要になります。

（5）システム全体の整合性を確保する

　ほとんどの場合、複数のアーキテクトや開発者が参加することになりますが、個々の作業や成果物の順序と整合性を綿密に調整しないと、プロジェクトは大混乱に陥り、システムのエントロピーは増大の一途をたどってしまいます。そのため、アーキテクトは全体のアーキテクチャ方針の作成と、プロジェクトのライフサイクルを通じて、要件とアーキテクチャ、アーキテクチャの構成要素間、実行アーキテクチャと運用アーキテクチャ、設計と実装といったさまざまな要素間の整合性確保に奔走することになります。

　そのためには、技術スキルとコミュニケーション能力はもちろんですが、譲れないところについては最後まで一貫性を守るという確固とした意志が必要になります。

（6）アーキテクト・チームをマネージする

　アーキテクト・チームを統括するリード・アーキテクトには、上記に加えて、作業計画作成、メンバーへのタスク割り振り、進ちょく管理、メンタリングといったマネージャとしての役割も加わります。こうしたマネジメント作業を通常のプロジェクト・マネージャに任せるかどうかは議論の余地のあるところですが、設計の粒度や深度に密接に関連する作業や、アーキテクトのスキル管理に関する作業は、やはり経験豊富なアーキテクトが担当すべきだと思います。

　こうした作業のためには、当然ながらプロジェクト管理能力、コミュニケーション能力、さらにコーチング能力が重要になります。

■アーキテクトにもコーディング・スキルが必要か

　以上、アーキテクトの役割とスキルをざっと見てきましたが、最後に、「アーキテクトにもコーディング・スキルが必要なのか」という最初の質問に立ち返ってみたいと思います。

　ここでもまた、オーケストラの指揮者に登場してもらいます。ほとんどのプロの指揮者は、ピアノやバイオリンといった何らかの楽器を演奏することができます。指揮という仕事だけを考えれば、指揮者自らに楽器演奏のスキルは必要ないように見えますが、自分が指揮する曲のイメージをつかむためにも、演奏者に適切な指示を与えるためにも、楽器演奏のスキルが必須だと思います。

　アーキテクチャ設計の現場では、アーキテクトは最終システムのイメージを具体的に頭に描けなければなりません。ソフトウェア担当のアーキテクトであれば、自分が設計したフレームワークの実装コードをイメージし、さらにその上に構築される業務アプリケーションの実装コードもイメージできなくてはなりません。インフラ担当のアーキテクトであれば、ハードウェア機器やネットワーク機器の実装をイメージできていなければなりません。

　いずれの場合も、アーキテクトが最終的な実装コードを書いたり、本番機器の設定を行ったりする必要はありませんが、必要に応じてプロトタイプを作成したり、機器の設定変更をして動作を検証するといったスキルが必要なのです。

　実装をイメージしないでアーキテクチャを設計した場合、アーキテクトが気付いているかどうかは別として、そのアーキテクチャはそのままでは実装できないため、下流工程のどこかで、誰かが苦労してアーキテクチャの修正作業を行い、ギャップを埋めているはずです。

　結局、顧客が望むシステムをきちっと作るために要求されるのは、技術至上主義のアーキテクトでもなく、逆に実装をイメージできないアーキテクトでもなく、設計スキル、実装スキル、ヒューマン・スキルをバランスよく併せ持ったアーキテクトなのです。

筆者プロフィール

小野沢博文――現在、アクセンチュアにおいて、ITアーキテクトとしてさまざまな開発プロジェクトに参加すると同時に、SOAプログラムの推進を行っている。アクセンチュア入社以前は、アイオナ・テクノロジーズ、TCSI、日本DEC、富士通において、CORBA、J2EE、Webサービスなどの技術コンサルタント、ITアーキテクト、メインフレームSEとして活躍。著書は、『Webサービス実践プログラミング』（翔泳社刊）、『CORBA完全解説』（ソフト・リサーチ・センター刊）など多数。

＠IT自分戦略研究所の関連記事
＠ITで学ぶITアーキテクトの基礎
いまお薦めのスキルはこれだ！ 2007年春版
ITエンジニアに旬なスキルは何か？
技術スキルは生の声から学べ！