大規模プロジェクトにアジャイルを適用する方法−1：The Rational Edge （28）（2/4 ページ）

[Philippe Kruchten，University of British Columbia]

大規模プロジェクトへのアジャイルの導入

　アジャイル開発プロジェクトにとって最適な条件とそうではない条件を検討し、大規模プロジェクトの基本的範囲を説明していくと、「この大規模プロジェクトがアジャイル手法で管理できるのか？ 」という疑問が出てくる。その答えはイエスだ。ソフト開発者の大半がアジャイルの「スイートスポット」に近い環境で作業できるよう大規模ソフトウェア開発プロジェクトをまとめるのは（容易ではないが）可能だ。以下では、ソフトウェア開発チームがこの環境でどのように作業を進めていくのか解説する。

理想的な大規模プロジェクトの構築

　 このプロジェクトに携わる200人の中から15人構成のチームを10チーム編成し、残りの50人はこれらを結合させ、機能させる上部構造とする。15人で構成される小チームの中では、メンバーが集中配置され、それぞれに固有の開発場所が与えられ、共通の文化を共有する。ここで重要なのは、「顧客は誰か？」「その顧客に決裁権はあるか？」「自分のチーム以外とはどのようにコミュニケーションを取るのか？ 」「大規模システムは、小規模システムが漠然と結合されたものではない。まずどのように作業を開始すればよいのだろうか？」

　この巨大プロジェクトのプロジェクトマネージャとしては、このプロジェクトをさまざまな観点から立ち上げる必要がある。

　組織。プロジェクトの構造、さまざまなチーム、各自の職務分担、任務、目的を定義する必要がある。

　スケジュールとリズム。 マイルストーンや、スケジュール上でそれぞれに対応する目的を定義する必要がある。

　コミュニケーション。 各チーム同士のコミュニケーションを取り決める必要がある。

　答えの大半は、アーキテクチャチームが作り出すソフトウェアのアーキテクチャと、推敲（すいこう）フェイズの機能にある（IBM Rational Unified Process【注2】、およびMBASE【注3】プロセスフレームワーク参照）。

【注2】　P. B. Kruchten著, 「The Rational Unified Process」（: An Introduction, 3rd ed）. 2000年Addison-Wesley刊。

【注3】　A. Egyed, B. W. Boehm、D. Port、 M. Abi-Antoun共著、「Guidelines for the Life Cycle Objectives (LCO) and the Life Cycle Architecture (LCA) Deliverables for Model-Based Architecting and Software Engineering (MBASE)」、USC Los Angeles校、USC Technical Report USC-CSE-98-519, 1999年刊。

段階的な組織化：開始と詳述

　開発作業はまず7人構成の1チームだけで開始し、場所と文化なども共通し、顧客と直接やりとりできる反復型のワークフローを採用したアジャイル環境で作業を進め、デベロッパ（設計者も含む）を12人に増やしていく方法もある。しかし、当面の目標は機能するシステムを引き渡すことではなく、アーキテクチャのプロトタイプ構築で重要なユーザー要件（ユーザーの沿革、ユースケース、機能以外の要件）を必要なだけ特定することであるため、このアーキテクチャチームの目的は典型的なアジャイル開発プロジェクトとはやや異なる。このプロトタイプは以下を容易にする。

• ユースケース（および要件のほかの側面）の整理
• これらのユースケースのインプリメントをサポートするために必要な基盤メカニズムと、機能以外の重要な要件 （スケーラビリティ、パフォーマンス、可用性など）の特定
• 選択したデザインや技術を検証するためのアーキテクチャのプロトタイプ開発
• サブシステムのコードの整理
• デザインおよびコード標準、コード管理、変更申請、障害レポートなど、必要に応じて今後の開発に向けたガイドラインとツールの設定

　この最初のアーキテクチャチームは反復作業を進め、チームとして徐々に規模を拡大していく。そして、チームの人数が15人以上に達したら以下のチームに分かれていく。

• その大部分に顧客が関与する重要なアーキテクチャの選択を行う「アーキテクチャチーム」
• アーキテクチャのプロトタイプの構築およびテストを徐々に進め、何度も考え直し、問題が見つかれば元に戻って作業を繰り返す「プロトタイプチーム」

　アーキテクチャチーム（7〜12人）は、2もしくは3つのプロトタイプチーム（35人以上で構成）の顧客になる。

プロジェクトの人員配置：構築と移行

　コードの構造が明確になり安定する推敲フェイズの終わりが近づくと、それぞれが1単位のアーキテクチャを「所有」するチームが新たに編成される。（「4＋1ビューモデル」 【注4】の）実装ビューは、コードのパーティションと、チームへの所有権割り当ての基盤になる。これで、各コードが1つのチームだけと結び付く。

【注4】　P. Kruchten著、 「The 4+1 View Model of Architecture」、IEEE Software, vol. 6、1995年刊、45〜50ページ参照。

　新たに編成されたチームには、オリジナルのアーキテクチャやプロトタイプチームに参加した1〜2人のメンバーをシードして、プロジェクトの知識と新興文化を持ち込むのが理想だ。通常は、これらのシードメンバーが新しいチームの「技術リーダー」となる。このメンバーが現場設計者の役割を担い、場合によっては、残りの核となるアーキテクチャチームと顧客のやりとりを橋渡しする。

　コードの開発に参加するチームには以下の2つのタイプがある。

• 機能チーム：ユーザーの機能に直接関連するコードを開発する
• インフラストラクチャチーム：機能チームが使う共通の要素やサービスを開発したり、機能以外の要件（例：ミドルウェア、サービス、領域固有のフレームワーク、再利用可能な資産）をサポートする

　いよいよここからは、チームごとに理想的なアジリティの条件を作り出すことに務めていく。

　機能チームの顧客は実際の顧客だが、実際の顧客は複数のチームや場所ごとに細かく分散できない。これ以外はすべてインフラチームの顧客で、それぞれ相反する複数のニーズを抱えている。

　そこで、核となるアーキテクチャチームの選ばれたメンバーが顧客を演じることになる。彼らは、技術的な指示を出して実際の顧客とさまざまなチームとを仲介し、インフラチームが実現するチーム全体で共通のニーズを特定する。彼らがインフラチームの顧客担当者になるのだ。

　これにより機能チームと実際の顧客との直接的な接触が絶たれるわけではないが、このような接触は専門的、あるいは下位領域の問題が発生した場合に限るべきだ。例えば、飛行管理、レーダー情報、離着陸許可、航空情報、衝突の危険検知と解消など、航空管制システムには下位領域がいくつかある。参画する顧客が有能で、これら下位領域の裁量権を持ってさえいれば、プロジェクトは順調に進む。

　アーキテクチャとインフラのチームは、構築フェイズ全体でシステムのアーキテクチャの微調整、リファクタ、拡張を継続していくが、ほかのチームに与える混乱が最小限に抑えられるのが理想だ。

システム統合に関する注意

　この大規模プロジェクトにアジャイル手法で取り組んでいくと、システム全体の統合に向けたアプローチに関しては現実的になる必要がある。われわれは、さまざまなチームが開発した部品を組み立てるだけでなく、各チームが開発やテストを行うために適切な「環境」も同時に提供しなくてはならない。能力を超えたリソースが必要になる場合もあるため、これは各チームが自分たちの力だけでできることではなく、すべてのソフトウェアサブシステムを受け取り、システムレベルテストで施設を意のままに利用できるシステム統合チームの役目になる。このシステム統合チームは初期のプロトタイプチームから派生するもので、特殊な機器が必要になるときや、パフォーマンス、負荷、可用性、有用性といった特定のテストを担当する場合がある。