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


Philippe Kruchten （pbk@ece.ubc.ca)
University of British Columbia
2004/9/29

---

　The Rational Edge より：本稿では、通常ならばアジリティの範囲を超えると見なされる大規模プロジェクトにアジャイルソフトウェア開発手法を適用するテクニックを説明する。筆者は、ソフトウェアアーキテクチャチームが地理、文化、あるいは専門を超えてアーキテクチャ部分に重点を置くコーディングチームに提供できるコミュニケーション能力について説明している。

---

　

　筆者は、「大規模」プロジェクトに取り組む際、「アジャイルプロセスのスケールアップ」という言い回しをよく耳にし、それが可能か不可能かをめぐるさまざまな意見も耳にする。以下の解説では、この問題を逆の方向から見てみたい。つまり、もしアジャイルプロセスがある程度明確な状況で機能するならば、大半の作業が最適なアジャイルの条件下で進み、このような条件下で優れた手法をすべて使えるよう大規模プロジェクトを変えることは可能だろうか？ と。その場合、結果はどうなるのだろう。コストは？ 組織や個人への制約はどうだろうか。

◆ アジャイル開発プロジェクトの「スイートスポット」

　アジャイル開発プロジェクトにとって理想的な条件とは何か？ アジャイル手法が成功する可能性はどのような条件で最も高いか？

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　小グループ。プロジェクトチームの人数が10〜15人以下の場合は、1対1で内容の充実したコミュニケーションを維持することが可能だ。だがこれも、チームの人数が20人を超える辺りから難しくなっていく。少人数のチームでは、成果物の受け渡しが発生する職務（アナリスト、デザイナー、プログラマ、テスター）の専門化は一切不要だ。

　集中配置。これも内容の充実した同時コミュニケーションが可能だ。

　顧客の存在。プロジェクトチームが顧客と直接コミュニケーションを取れる場合は、定期的な軌道修正が容易になり、プロジェクト終了時にはより優れた製品が生み出される。さらにチームは、開発中のソフトウェアが対処すべきニーズに関し、裁量権を与えられた優秀な顧客担当者と直接コミュニケーションを取り続けられる。

　業務アプリケーション。アジャイル開発は、組み込みリアルタイムシステムなどのほかのプロジェクトより、インタラクティブなアプリケーションを構築する業務ソフトウェアプロジェクトの方がうまく機能する。

　新規開発。アジャイル手法は、保守プロジェクトよりも「グリーンフィールド」プロジェクトと呼ばれる新規ソフトウェアプロジェクトに適している。

　RADプログラミング環境。 アジリティには、コードの開発からテスト、そしてコードの共同所有まで迅速な作業を実現するRAD環境が必要だ。開発チームが日単位で開発作業を行い、月単位で引き渡しを行うのが理想だ。

　短いライフサイクル。プロジェクト期間は数カ月を超えてはならず、内部で速く（1日）回転するのが理想だ。

　共通の文化。用語や暗黙の処理に関して情報を共有し、デベロッパ各自の業務は相互に素早く調整する。

　アジャイル開発プロジェクトのスイートスポットには、情報を変更管理ツールや洗練されたモデリングツールなどの中間成果物に託さなくてはならない要素がいくつかある。このことに疑問の余地はない。最も利害関係の深い顧客とのコミュニケーションを含め、コミュニケーションは直接取りたい。注意してもらいたいのは、筆者はいま挙げたスイートスポットを外すとアジャイル開発が機能しないといっているのではない。上の各項目は完ぺきな事例を示しているにすぎない。

◆ アジャイル開発プロジェクトの「ビタースポット」

　 「スイートスポット」を逆から見れば、アジャイル開発プロジェクトの「ビタースポット」を指摘できる。アジャイル開発プロジェクトを危機に陥れる条件は以下のとおり。

　大グループ。1対1のコミュニケーションが可能でも、適切な相手を特定するのが難しい場合、特にチームメンバーの一部にコミュニケーションが集中するとアジャイル手法は崩壊する傾向がある。コミュニケーションが同時性を失い始め、チームは要望やプロジェクト情報の管理に、特定のチャネルやストレージメカニズムなど、さまざまな形式の記録に頼るようになる。

　分散チーム。これも、準備が不要な素早いコミュニケーションを困難にする。各種電子メディア（電話、インターネット会議ツール、インスタントメッセージングシステム）も使えるが、組織は、即時性のないコミュニケーションにはドキュメントを用意し、重要案件について決定する場合は出張を選ぼうとする。

　決裁権のある顧客担当者の不在。このような状況では、要件（およびその要件に関する説明、交渉、フィードバック）がドキュメント、時々行われるミーティング、そして管理階層や組織の枠を超えて各所で下される判断を経て、遠回りで非効率的に展開する傾向にある。

　長期サイクル。プロジェクトの開始から2年以上経過して初めて最初の引き渡しを行うとなれば、これはもはやアジャイル手法ではない。担当者の異動は避けられず、これがプロジェクト内の「記憶の消失」へとつながり、進ちょく状況を見極めたり、単純にチームを奮起させる中間点や短期目標を探すことが難しくなる。

　非効率的プログラミング環境。自動化されたツールがないと、開発所要時間が延び、コードの共同所有がなくなり、設計者からコーディング担当者、コーディング担当者からテスターへといった成果物の引き渡しが迅速に進まない。

　開発文化の違い。これは、下請け業者や外注業者など、複数の組織が関与する場合に多く見られる。これを修正するにはプロセスを大幅に明確化する必要があるが、これはそのプロセス自身が主導的立場から誘導することを意味する。「プロセスの要求なので」といわれたら逆らえない。

　極端なケースとして、これまでの大規模プロジェクトは、分散環境、複数組織、長期プロジェクトサイクル、人事異動の混乱で発生する不均衡を補ってくれる人材より文書化にプロジェクトマネージャが固執し、開発の全段階で大量のドキュメントだけに頼ってきたことに注目したい。

◆ 大規模プロジェクト

　筆者は先日、「あのような大規模プロジェクトには二度とかかわりたくない」という話を聞いた。まあ現実問題として、アジャイルプロセスが台頭してきても大規模プロジェクトはなくならないだろう。H. Erdogmus【注1】は、「規模は致命傷にはならなくとも何らかの障害になる」と書いているが、この障害は大量の摩擦を生み、プロジェクトを大幅に遅らせる。通信、指揮管理、プログラミングツールの各システムの開発など、筆者は自分のキャリアの大半で大規模プロジェクトに携わってきた。ここでは便宜上、「でも、20人でなく25人だったらどうなのか？」あるいは「チームが2カ所にしか分散していなかったらどうなのか？」といった限界条件に関する質問を回避するため、極めて大規模なプロジェクトについて説明する。

---

【注1】　H. Erdogmus著、「Let's Scale Agile Up」、Agile Times, vol. 2、2003年刊、6〜7ページ

---

　ここで説明する大規模プロジェクトには以下のような特徴がある。

• 200人
• 時間帯が異なる複数の地域に分散
• 作業者は3社の企業が管理
• ライフサイクルは最初の引き渡しまで2年半、その後は6カ月ごとにアップデート

　プロジェクト規模の大小にかかわらず実現しなくてはならない条件がいくつかある。

• 良好なプログラミング環境
• 技術力のある人材
• 顧客とのコンタクト

　この大規模プロジェクトと小規模プロジェクトの比較を容易にするため、最適なこれらの特性が3つすべてそろっているものと仮定する。

　しかし、研究室内のプログラマが利用できる交換機や潜水艦シミュレータの数が限られる場合など、大規模プロジェクトではデベロッパ全員が特定のテスト機能をすぐに利用できないこともある。小規模プロジェクトでは通常はこのようにならない。

1/4

INDEX
The Rational Edge 大規模プロジェクトにアジャイルを適用する方法
	Page1 アジャイル開発プロジェクトの「スイートスポット」
	Page2 大規模プロジェクトへのアジャイルの導入
	Page3 アジャイルの「スイートスポット」の条件は？
	Page4 まとめ：大規模アジャイルを成功させるポイント

本記事は「The Rational Edge」に掲載された「Scaling down large projects to meet the agile “sweet spot”」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）

情報マネージャのための「今日のひと言」 - 2010/2/10 『徹底する』　経営実践のコツは凡事徹底です。経営で最も慎まなければならないことは、うまい方法ばかりを探し求め過ぎることです。整理・整頓の……>>続きはクリック

操作もマニュアルも分かりやすい！ ユーザー視点で開発されたPC管理ツール New！

仮想化すればコストは削減できるか？ 仮想化に必要な「3つの視点」を解説する

情報漏えいで会社の社会的信用を失う前に ＠ITメールソリューションLive! in Tokyo

コスト削減・信頼性向上をまとめて満たす “高信頼Linux”を構築する方法とは？

SEの作業時間の大部分を占めるドキュメン ト作成。これを短縮するツールを紹介

＠IT Specialヘ