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

[Philippe Kruchten，University of British Columbia]

アジャイルの「スイートスポット」の条件は？

　 この時点では、われわれのプロジェクトは方向付けと推敲のフェイズが完了しており、機能およびインフラストラクチャチームが編成されていて、プロジェクトの作成／移行フェイズが始まろうとしている。図1は方向付け、推敲、作成／移行 フェイズにおけるチーム構造の進化を示している。アジャイルの「スイートスポット」に近いところで作業できるのが「青」チームで、それを実現するために必要なコミュニケーションと仲介手段を提供するのが「緑」チームだ。

　方向付けと推敲のフェイズでは、顧客のニーズに基づきシステムアーキテクチャのプロトタイプが作成され、小規模で複数の機能をこなすチームをどこに配置し、効率的に作業を進めるために上部構造をどうするかなど、これがチーム構造の原案になる。

　

図1 時間の経過に伴うチーム構造の展開（クリックすると拡大）

【立ちはだかる問題】

　以上の設定にはいくつかの危険が待ち構えている。想定される問題の一部を以下で説明する。

◇ チーム間の依存

　われわれは、理想的（スイートスポット）なアジャイル開発プロジェクトでは一般的に発生しない問題を生み出した。先に指摘したように、機能チームをはじめ、どのチームも別のチームの顧客となり、何らかの機能の提供ではそのチームに依存する。コードの開発とテストを進めるに当たってこの依存の影響を減らすには、チームが「ユーザー側の視点」に立ったテストを構築するだけではなく、控え、代理、あるいは模型も構築してインフラチームの顧客としての役割を果たしていく必要がある。

◇ ストーブの煙突

　機能チームはそれぞれが単独プロジェクトとなり、最終的には、チーム全体で機能の大部分が重複して開発される。これは、チームメンバーが地理的に分散したり、共通の文化を共有せずに活動する組織が多いとさらに悪化する。

　改善策はあるだろうか？ アーキテクチャチームは、何らかのコミュニケーション仲介手段を提供し、定期的に設計の審査に関与し、ほかのチームから人材を獲得してくる必要がある。同チームは、インフラチームが開発する共通のコードや機能を特定でき、チーム同士で再利用すべき要素を指摘できる。 また、可能な場合はチーム間でのスタッフのローテーションを提案することもできる。

図2 「ストーブの煙突」効果の削減。AからBへの改善は、さまざまなチーム間で共通のコードを特定および開発し、それに対応した組織を用意することを示している（クリックすると拡大）

◇ 不均衡

　作業負荷はチーム間で一様でないため、負担の大きいチームが作業の遅延や品質の低下によってプロジェクト全体に悪影響を与える可能性がある。この不均衡は、チームメンバーが持つ専門知識の組み合わせに起因する場合もある。これに対するソリューションとしては、サブシステムとチームでの人員配置（割合）の変更　知識や専門技術を拡散するためのスタッフのローテーション、そして負担の小さいチームから大きいチームへのスタッフの一時的な配置転換などがある。

◇ コミュニケーションの崩壊

　チーム間のコミュニケーションが非効率的になると、遅延、頓挫、作業の中断へとつながる可能性が出てくる。設計者は作業に介入し、関係者間のダイレクトなコミュニケーションを確立および促進する必要がある。

◇ 時期尚早の過剰配置

　一般に、方向付けから推敲のフェイズにあまり多くの人材を参加させることは良くない。だが、これらのフェイズで一部のスタッフを遊ばせておくしか選択肢がない場合は、その一部を小規模アジャイル開発プロジェクトに参加させ、初日から確実に必要になってくるシステムのパーツを開発させることも考えられる。

◇ 共通目標の喪失、焦点の欠如

　繰り返しになるが、小さいチームはそれぞれが目的を持って作業を進める。しかしこれらのチームは、細かい部品ではなく、完成したシステムを引き渡して初めて成功といえることを決して忘れてはならない。ほかのチームと競争しているわけではないのだ。各チームは何にでも耳を傾け、改良点などを提案し、プロジェクトの作業負荷のバランスを常に見直す準備を整えておく必要がある。

◇ 二段リズム（ネスティングされた2つのビート）

　ライフサイクルが数年単位と長い場合は、プロジェクトの「ビート」でプロジェクトのタイミングを2段階に分割する必要も出てくる。 図3は、「スクラム」を毎日実施し、1カ月の反復サイクルで作業を進める開発チームを示している【注5】。しかし、このビートはシステムの主要ステップが6カ月、システム増分のスクラムが1〜2週間という遅いシステムレベルビートに内包されている。

【注5】　M. Beedle、K. Schwaber共著、「Agile Software Development with SCRUM」、2002年Prentice-Hall刊参照。

図3 2つのビート（スクラムのスクラム）（クリックすると拡大）

◇ マニュアルの整備

　「文書化」という不幸の言葉を口にするとすべてが崩壊する、という話をよく聞く。これでプロジェクトはアジャイルでなくなるという。しかし、そうではない。プロジェクトマネージャは、重要な問題を解決し、完成したプロジェクトを全体的に効率化できる必要な部分にだけ、永久保存する成果物（ドキュメントやモデルなど）を導入すべきだ【注6】。

【注6】　契約上の目的、あるいはFAAやFDAといった標準や認定機関への提出目的で用意しなくてはならない書類は差し当たり無視する。これらの必要書類は必ずしもプロジェクト組織のメリットにはならない。いずれにせよ、これらについては別の機会に説明する。

　アーキテクチャ。設計者は、チームが全体的に拡大し、構造、原理、メタファーを新人に繰り返し説明しなくてはならず、無理な作業を強いられるようなことを避けるため、ある時点でアーキテクチャを文書化する必要が出てくる。詳細に文書化されたアーキテクチャは、チームのメンバー全員にとって明確な唯一の参考資料になる。デザインのアーキテクチャ以外の部分が独立した資料として文書化されることはない。ただし、それらはコード中にコメントの形で残され、JavaDocなどのツールがあれば必要なときに抽出できる。

　要件。当初、要件は非常に流動的なままだが、さまざまな機能チームがインプリメンテーションを進めていくとユースケースが集まり、機能以外の要件と併せて整理され、トレースとテストが促進されると同時にユーザーマニュアルやトレーニングの出発点になる。

◇ リスク、問題、バックログ

　リスクの問題とバックログは各チームレベルで処理する。チーム単独では迅速に解決できないリスクの問題とバックログの要素に限り、プロジェクトレベルで対応するようにする。一般的に、技術的な問題はアーキテクチャチームが処理し、組織的な問題（人員配置やリソースなど）はプロジェクト管理チームが処理する。問題は、「所有する」チームが明確でない、あるいは問題が2チームにまたがるといった場合に多く発生する。設計者は、これらの問題を解決すべく仲介しなくてはならない。開発環境では、局所的あるいは全体的な問題を処理する際にプロジェクト全体で一般的に利用できるツール（ClearQuestなど）があると有効だ。

◇ プロセス

　業務、標準、ガイドライン、およびテンプレートに関する記述は、組織全体における業務の一貫性を高めるために明確にしておくべきだ。プロセスが明確に記述してあれば完成に向けて努力するチームに役立つが、これを頭ごなしに強制すべきではない。

◇ 具体例

　筆者には、アジャイルテクニックを使えば大規模プロジェクトを少なくとも一部でも管理できる証拠があるのだろうか？ 突然何の根拠もなくこのように言い出したのだろうか？ 必ずしもそういうわけではない。筆者が個人的に携わった大規模な反復開発プロジェクトでは、この戦略の側面の多くが応用されている。以下に例を3つ挙げる。

• 1.Ship System 2000 （SS2000）。スウェーデンのPhilips／Bofors/NobelTech/CelsiusTechが開発した船舶管制システムの1つ【注7】。
• 2.The Canadian Automated Air Traffic System （CAATS）。カナダのHughes Electronics/Raytheonが開発【注8】。

【注7】　L. Brownsword、P. Clements共著、「A Case Study in Successful Product Line Development」、Software Engineering Institute、Technical report CMU/SEI-96-TR-035、1996年刊参照。

【注8】K. Toth、P. Kruchten、T. Paine共著、「Modernizing Air Traffic Control Through Modern Software Methods」、38th Annual Air Traffic Control Association Conference、テネシー州ナッシュビル：ATCA、1993年刊。

P. Kruchten著、「Iterative Software Development for Large Ada Programs」Proc. Ada-Europeカンファレンス、スイス、モントルー、vol. LNCS 1088、A. Strohmeier, Ed.：Springer-Verlag, 1996年刊、101〜110ページ。

P. Kruchten、C. J. Thompson共著、「An Object-Oriented, Distributed Architecture for Large Scale Systems」、Proc. of Tri-Ada'94、 ボルティモア、1994年11月：ACM、1994年刊を参照。

　これらのプロジェクトはいずれも、筆者が前述した大規模プロジェクトの特性を持っている。チーム構造とアーキテクチャを適合させる（アーキテクチャチーム、統合チーム、ユーザー機能およびインフラチーム）という概念は、SS2000プロジェクトを示す図4のように、ソフトウェアアーキテクチャのスタティックビューに適合するはずだ。これらの概念は、ユースケースの導入によってCAATSプロジェクトに応用され、洗練された。さらに、幸運にも顧客を説得し、現場のエンドユーザー全員とやりとりをすることができた。アーキテクチャチームは、コミュニケーションを引き受け、さまざまなチームで問題が発生しても即座に解決することができた【注9】。

【注9】　設計者とアーキテクチャチームの役割についてはP. Kruchten著、「The Software Architect, and the Software Architecture Team」、Software Architecture, P. Donohue, Ed.、1999年、Kluwer Academic Publishers刊、565〜583ページに説明がある。

図4 SS2000とCAATSでは、チーム構造がアーキテクチャの実装ビュー（コードビュー）と完全に合致した。詳細についてはP. KruchtenおよびC. J. Thompson共著の、「An Object-Oriented、Distributed Architecture for Large Scale Systems」 in Proc. of Tri-Ada'94, ボルティモア、1994年11月：ACM、1994年を参照（クリックすると拡大）

　もう1つの大規模プロジェクトは別種のものだった。

• 3. Rational Software Corporationが開発したRational Suiteは、デベロッパが700人、引き渡しビートは6カ月だった。

　Rational Suiteを開発した製品グループは、十数チームが世界各国8カ所に分散し、マサチューセッツ州レキシントンの製品定義（つまり顧客担当者）、アーキテクチャチーム、そして中央統合チームで構成された。機能チームは各サイトに集中配置された。各チームはその原点、歴史、そして文化に応じて多かれ少なかれアジャイルだった。各チームは、中央の製品チームが課すビートと適合するよう調整された内部のビートを持っている。ブリティッシュコロンビア州バンクーバーを拠点とした筆者のチームは非常にアジャイルで、毎日ビルドを用意し、隔週程度ごとにメジャーリリースを出すなど、戦術上の多数の変更に適応した。

　これらの概念をインプリメントした反復プロジェクトは、成功したさまざまな異型を含め、Rational Softwareの同僚が数年前に多数報告してくれた。