ソフトウェアアーキテクトの役割：The Rational Edge（2/2 ページ）

アーキテクトにはソフトウェア開発プロセスの理解が必要

　アーキテクトには、ソフトウェア開発プロセスに対する正しい認識が必要だ。このプロセスによって、チームメンバー全員の良好な協力が保証されるからだ。優れたプロセスは、関係する役割、着手している作業、作成した成果物、そして役割間の引き継ぎ場所を明確にしている。アーキテクトはチームメンバーの多くと毎日やりとりするため、アーキテクトには自分たちの役割と責任を理解することが重要になる。開発チームは毎日アーキテクトからの指示を仰ぎ、その方法まで聞いてくることも多い。従って、アーキテクトの役割とプロジェクトマネジャーの役割との間には明らかに重複部分が存在する。

アーキテクトにはビジネスドメインの知識が必要

　アーキテクトは、ソフトウェア開発について把握するだけでなくビジネスドメインも理解することが非常に望ましい（必須だとの意見もある）。

　［ドメインとは］その分野に従事する人々が理解する一連の概念や用語によって説明される知識や活動の範囲である（注4）。

　このような知識があれば、アーキテクトはさらに詳しい情報を得て、システムの必要要件に貢献し、「適切な」要件（つまり、アーキテクトのドメインに関する知識に基づき検討すべき要件）を確実に取得できるようになる。また、特定のドメインが、それに適用できる特定のアーキテクチャパターンのセットと関連付けられている場合も多い。この関連付けを知っておくことも、アーキテクトには大いに役立つ。

　従って、優れたアーキテクトはソフトウェア開発に関する知識とビジネスドメインに関する知識のバランスが優れている。アーキテクトがソフトウェア開発は理解していてもビジネスドメインを理解していないのでは、アーキテクトが不安を抱かないか精通している部分だけを反映し、問題には適さないソリューションが開発されてしまう。

　アーキテクトがビジネスドメインに精通していなくてはならないもう1つの理由は、アーキテクチャに対して起こり得る変更をアーキテクトが予測しなくてはならないからだ。アーキテクチャが導入先の環境に強い影響を受けることを考えると、ビジネスドメインに対する理解があれば、アーキテクチャの観点から変更される可能性の高い部分と安定している部分について、アーキテクトが豊富な情報に基づき判断を下せるようになる。例えば、もし将来のある時点で新しい監督機関の基準に従う必要があることをアーキテクトが認識しているなら、そのシステム運用中にそれが規定されることになった場合に備え、この部分をアーキテクチャで加味する必要がある。

アーキテクトには技術知識が必要

　設計作業の中には技術知識が必要な部分がある。そこで、アーキテクトは一定レベルの技術的スキルを維持しておく必要がある。しかし、アーキテクトが技術の専門家である必要はない。これは本シリーズのパート1にも関係することだ。アーキテクチャは重要な要素に重点を置いている。それはつまり、アーキテクトは重要な技術的要素だけを考え、詳細な部分まで心配する必要はないということだ。技術はかなり頻繁に変化するため、アーキテクトにはこれらの変化に遅れずついていくことが絶対不可欠だ。

アーキテクトには設計スキルが必要

　構築作業は設計に限定されるものではないが、構築にとって設計が重要なことは明らかだ。従って、重要なデザイン判断はアーキテクチャが具体化するため、アーキテクトには高い設計スキルが必要になる。このような判断が、重要な構造設計判断、特定のパターンの選択、ガイドラインの詳述などを表す。システムのアーキテクチャの整合性を保証するためには、これらの要素を「全面的に」適用し、システムの成功に向けて広範囲に影響を与えることが一般的に必要だ。従って、このような要素は適切な設計スキルを持った人物が特定しなくてはならない。

アーキテクトにはプログラミングスキルが必要

　プロジェクトの開発担当者は、アーキテクトがコミュニケーションを取らなくてはならない最も重要なグループの1つだ。何しろ、最終的な実行イメージソフトウェアは彼らの成果物から生まれるのだ。アーキテクトと開発者との間のコミュニケーションは、開発者の作業を正しく評価できて初めて効率的になる。従って、必ずしもコードを書かない場合でも、アーキテクトには一定レベルのプログラミングスキルが必要になる。

　どこかで成功を収めているアーキテクトの大半は、筋金入りのプログラマだった経験を持ち、一般的にはそこでビジネスを覚えてきた。技術が進化し、新しいプログラミング言語が出てきても、優れたアーキテクトはどのプログラミング言語でもその概念を抽出し、その知識を適用して新しいプログラミング言語を必要な深さまで学習する。この知識がなければ、アーキテクトはインプリメンテーションの構成やプログラミング標準の採用といったインプリメンテーションでアーキテクチャ上重要な要素に関する判断を下せなくなり、アーキテクトと開発者との間にコミュニケーション障壁が生まれてくる。

アーキテクトは優れた伝達者であれ

　アーキテクトに関係するすべての「ソフトスキル」の中で最も重要なのがコミュニケーションだ。有効なコミュニケーションには多数の側面があり、アーキテクトはそれらすべてに堪能でなくてはならない。具体的には、アーキテクトには読む、書く、プレゼンテーションを行うといった有効な言語スキルが必要になる。さらに、そのコミュニケーションは双方向になる。アーキテクトは聞くこと、観察すること、そして話すことにも優れていなくてはならない。

　有効にコミュニケーションが取れることは、多くの理由からプロジェクトの成功にとって重要なスキルだ。利害関係者とのコミュニケーションが、彼らのニーズを理解し、利害関係者との合意を確実にする（そして維持する）形でアーキテクチャの情報を伝えるのに特に重要であることは明らかだ。アーキテクトは情報をチームに渡すことだけに責任があるのではなく、彼らのやる気を起こさせる必要もあるため、プロジェクトチームとのコミュニケーションは特に重要だ。アーキテクトには具体的に、アーキテクトだけが理解して価値を認めるようなものでなく、全体で共有できるシステムのビジョンを伝える責任（そしてコミュニケーションを強化する責任）がある。

アーキテクトには判断が必要

　分かることが少なく、すべての選択肢を検討する時間がなく、結果を出すことを求めるプレッシャーの掛かる環境で判断を下せないアーキテクトは、成功する可能性が低い。このような環境は十分予想されるものであり、成功しているアーキテクトはこの状況を変えようとするのではなく、事実として受け入れる。従って、アーキテクトはプロジェクト進行中に自分の判断を修正し、何度か譲歩もしなくてはならないため、「強心臓」でなくてはならない。Philippe Kruchten氏いわく、「ソフトウェアアーキテクトの日常では、最適といえないデザイン判断が十分理解されることなくいつまでも次々に下されていく」（注5）。

　判断を下せないと、プロジェクトが徐々に台無しにされていく。プロジェクトチームはアーキテクトに対する信頼を失い、アーキテクチャを待っている人々が必要な作業を進められないため、プロジェクトマネジャーが不安になっていく。そこに最も大きな危険がある。アーキテクトがアーキテクチャに関する判断を下さず、しかもそれを文書にも残していないと、チームメンバーがそれぞれ勝手に（もしかすると誤った）判断を下していくようになる。

アーキテクトには組織の政治的駆け引きに対する認識が必要

　成功を収めているアーキテクトは、技術しか頭にないマニアではない。彼らは政治的駆け引きにも抜け目がなく、組織のどこが力を持っているのかを意識している。この知識は、適切な人に確実に情報を伝え、プロジェクトに対するサポートを適切に浸透させるために利用される。政治的駆け引きを無視することは、まさに愚直である。現実問題として、プロジェクトチームがシステムを投入した後にも組織の中では多くの力が作用しており、これらを考慮に入れる必要があるのだ。

アーキテクトは交渉人であれ

　構築作業の多くの側面を考慮すると、アーキテクトは多くの利害関係者とコミュニケーションを取ることになる。これらのやりとりの中には、交渉スキルが必要なものもある。例えばアーキテクトは、できるだけ早い段階で、プロジェクトのリスクを最小限に抑えることに特に重点を置く。この作業にかける時間は、アーキテクチャを安定化させるための時間と同意である。要件にはリスクも伴うため、リスクを排除するには、リスクがかかわる要件を排除、もしくは減らすことも必要だ。従って、このような要件を（利害関係者とアーキテクトが）相互に合意できる立場で「先送り」することも考えられる。そのためには、アーキテクトがさまざまなトレードオフの結果を明確にする有能な交渉人である必要がある。

　本稿ではソフトウェアアーキテクトの特性を明確にすることに重点を置いてきた。本シリーズの残りでは、構築プロセスの特性と、アーキテクチャを基本的IT資産として扱うメリットに重点を置いていく。