連載
» 2006年05月16日 12時00分 公開

The Rational Edge:ソフトウェアアーキテクトの役割 (1/2)

The Rational Edgeより:もし、ソフトウェアプロジェクトのマネジャーが映画業界用語でいう(作業完了の責任者である)プロデューサーならば、ソフトウェアアーキテクトは(作業を成功させ、最終的に利害関係者のニーズも満たす立場にある)監督だといえる。4回シリーズの2回目となる本稿では、ソフトウェアアーキテクトの役割について解説する。

[Peter Eeles(レベル:初級 IBMシニアITアーキテクト),@IT]

 今回は、ソフトウェアアーキテクチャを説明する4回シリーズの第2回目(第1回目は「ソフトウェアアーキテクチャって何なの?」を参照)となる。第1回目ではアーキテクチャとは何かを明確にした。そこで、今回はアーキテクチャの作成責任者であるアーキテクトについて考える。アーキテクトの役割はおそらく、どのソフトウェア開発プロジェクトにおいても最もその手腕を問われるものだろう。アーキテクトはプロジェクトの技術責任者であり、最終的にはプロジェクトの成否について技術面の責任を持つことになる。

 IEEEでは「アーキテクト」を次のように定義している。

 [アーキテクトとは]システムアーキテクチャを統括する個人、チーム、あるいは組織を指す(注1)。


注1 IEEE Computer Society、IEEE Recommended Practice for Architectural Description of Software-Intensive Systems:IEEE Std 1471-2000。


 プロジェクトの技術責任者として、アーキテクトには深いよりむしろ幅広い特性やスキルが一般的に要求される(ただし、アーキテクトには特定の分野に関する高いスキルが要求される)。

アーキテクトは技術リーダー

 まず第1に、アーキテクトは技術面のリーダーである。つまり、アーキテクトは技術スキルだけでなく指導力も発揮する必要がある。この指導力は、組織内での立場だけでなく、アーキテクト自身の資質によって発揮されるものでもある。

 組織内での立場という点では、アーキテクトはプロジェクトの技術責任者であり、技術的判断を下す権限を持っている。一方のプロジェクトマネジャーは、リソース、スケジュール、およびコストといったプロジェクトプランの管理の方に重点を置く。映画業界に例えると、プロジェクトマネジャーは(確実に作業を完了させる)プロデューサー、一方のアーキテクトは(確実に作業を成功させる)監督ということになる。このような立場にある結果、アーキテクトとプロジェクトマネジャーはプロジェクトの公的人格を表すことになり、両者はチームとなってプロジェクトに関する外部との主な接触を行う。特にアーキテクトは、アーキテクチャの作成に投じられた投資と、それが組織に与える価値を唱道しなくてはならない。

 また、アーキテクチャの依存内容によってタスクの順序や特定の時点で必要なスキルが決まるため、アーキテクトはアーキテクチャに関連するチーム編成にも関与し、その結果プランニング作業にも積極的に寄与する必要がある。これに関連することとして、アーキテクトの成功とチームの品質は深い関係にあるため、新メンバーの面接にも同席することが非常に望ましい。

 アーキテクトが発揮する資質に関しては、ほかのチームメンバーとのやりとりもリーダーシップだと説明できる。特に、アーキテクトは自ら実例を示してリードし、自信を持って方向を決める必要がある。成功しているアーキテクトは人を重視し、どのアーキテクトも自分のチームのメンバーにとって信頼の置ける相談相手や指導者となることに時間を割く。これはプロジェクトだけでなく、支援の必要なチームメンバーにとってもメリットであり、最も貴重な資産(組織の人材)のスキルが向上することから最終的には組織にとってもメリットとなる。

 さらに、アーキテクトは具体的な成果を上げることに重点を置き、技術面でプロジェクトの原動力となる必要がある。アーキテクトは(多くの場合プレッシャーを受けながら)判断を下し、確実にこれらの判断が関係者に伝わり、理解され、そして最終的にインプリメントされるようにしなくてはならない。

アーキテクトの役割はチームが遂行する場合も

 役割と人間は別だ。1人の人間が複数の役割を果たすこともでき(例えば、Maryは開発者であり、テスターでもあるなど)、1つの役割を複数の人間が遂行することもある(例えば、MaryとJohnがテスターの役割を果たしているなど)。アーキテクトの役割を果たすのにかなり幅広いスキルが要求されることを考えれば、アーキテクトの役割を複数の人間が遂行するケースも多くなる。こうすることで、スキルを複数の個人に分散し、それぞれが自分の経験をその役割に生かせるようになる。特に、ビジネス面と各種技術分野の両方の理解に必要なスキルは、複数の個人に分散する形が最適だ。しかし、その結果生まれるチームは「バランスの取れた」ものでなくてはならない。本稿では全体を通じて、個人もしくはチームのいずれによっても遂行される役割を指して「アーキテクト」という言葉を使用する。

 [チームは]相互に補完するスキルを持った人々の集まりで、共通の目的、業績目標、そして自分たちがお互いに責任を持つアプローチに対し最大の努力を払う(注2)。


注2 Jon R. KatzenbachおよびDouglas K. Smith共著。「The Wisdom of Teams」Harvard Business School Press、1993年刊。


 もしチームでアーキテクトの役割を演じるのであれば、ビジョンを持ち、アーキテクチャチーム全体のコーディネートを任せられる主任アーキテクトを1人任命することが重要だ。全体をコーディネートできる責任者が不在だと、アーキテクチャチームのメンバーが結束したアーキテクチャを生み出せなかったり、判断を下すことができなくなったり危険がある。

 アーキテクチャの概念を初めて知ったようなチームには、この共通の目的、目標、そしてアプローチを達成するため、チームの憲章を作成して公表しておくことを推奨する(注3)。


注3 Philippe Kruchten、「The Architects -- The Software Architecture Team」。First Working IFIP Conference on Software Architecture(WICSA1)の議事録。Patrick Donohoe(編集)。Kluwer Academic Publishing、1999年刊。


 優秀なアーキテクトは、自分の長所と短所が分かっている。アーキテクトの役割をチームが演じるのかどうかにかかわりなく、アーキテクトは多数の「信頼できるアドバイザー」にサポートされている場合が多い。このようなアーキテクトは、自分たちの欠点を認めていて、必要なスキルを取得するか、他人と協力して知識の溝を埋めることでこれらの短所を補っている。複数の人間が集まれば知識の幅が広がり、深くなるため、最良のアーキテクチャは個人ではなくチームから生まれるのが普通だ。

 アーキテクチャチームの概念で1つ落とし穴があるとすれば、それはほかの部署から、有益でなく単に知的なものしか生み出さない「現実的でないもの」に見られる場合があることだ。この誤解は、1)必ず利害関係者全員の意見を積極的に聞き、2)アーキテクチャとその価値を継続的に伝え、3)組織の政治的駆け引きを意識することで、最初から最小限に抑えることができる。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ