
The Rational Edge (30)
アジャイル開発:成熟期の到来、その道のり
Gary Pollice
Professor of Practice,
Worcester Polytechnic Institute
2004/11/25
◆ アジリティの跳躍
そして今年(2004年)、その答えは出た。XP/Agile Universeカンファレンスの第4回目となるXP/Agile Universe 2004は、8月にカナダのカルガリーで開催された(今年は、2000年以来ヨーロッパで開催されているXP2000と2003年に始まったAgile Development Conferenceという、アジャイル開発に特化したほかの2つのカンファレンスも開催されている(注6)。
- - PR -
Webテストのスクリプトを作成するチュートリアルでは、筆者のパートナーがワシントンにある企業のIT部門出身の品質エンジニアを務めた。このセッションでは顧客も積極的に発言し、組織改善の方法について知ろうと素晴らしい質問をしていた。彼らは、アジリティとXPがかつてのように極端な手法でないことを明確に感じていた。
今年のカンファレンスで顕著だったもう1つの特徴は、コンサルタントや第一人者たちが裏方に回り、プレゼンターの多くはカンファレンスにとって新しい顔触れとなり、新しい発想を持ち込んできたことだ。Kent Beck氏、Martin Fowler氏、Ward Cunningham氏などの古参は欠席したが、それでもカンファレンスは盛況だった。
筆者の意見では、今回とこれまでの違いを最も印象的に示していたのが実証ワークショップだった。20人以上の参加者があり、何と、その中の13人が実際にソフトウェアを開発するプロだった。われわれは、何を測定し、何が測定に重要なのかに焦点を当てた。そして2つのグループに分かれ、企業や現場の人間にそれぞれ重要な測定基準に焦点を当てた。ゴールはかなり意欲的なもので、われわれは測定すべきものだけでなく、そのデータの測定や分析の方法、そして最適な測定方法まで特定したいと考えていた。このワークショップの結果はもうすぐ公開され、本稿にもそこへのリンクを用意する。
活気を見せたもう1つの兆候は、前回よりも幅広い方面のソフトウェア開発コミュニティの関係者がカンファレンスに集まったことだ。RUPやDSDM(Dynamic Systems Development Method)など、ほかのプロセスをめぐる議論もあった。オープンスペースでは、RUPの発展に非常に大きな影響を与え、現在はバンクーバーのブリティッシュコロンビア大学で教鞭を執るPhilippe Kruchten氏が、XPなどのアジャイル手法におけるアーキテクチャの役割に関する議論を提案していた(注7)。この議論に参加した人の大半は、特に大規模プロジェクトにおいて、別途取り組むだけの重要性がアーキテクチャにはあると考えているようだった。しかし少数派も、XP手法に注目すればアーキテクチャは自然に進化する、などと積極的に意見を出していた。
参加者の間には、カンファレンスを通じて健全な論争や対話があった。Mary Poppendieck氏は、主流との意見の相違を埋めるためにコミュニティが焦点を当てるべき点について語った。同氏によると、カギを握るのは照会先となる優れた顧客の獲得だという。初期導入に踏み切らない企業は、調査会社の情報に関係なく、製品に関する同業他社の成功を基本に考えて購入判断を下すのだ。
Craig Larman氏はMary Poppendieck氏とは対照的に、手法の有効性に関連した事実に基づくデータの収集が顧客拡大のカギだ、と主張した。筆者の意見では、カンファレンスを締めくくる同氏の基調講演はカンファレンスのハイライトだった。同氏は、ウォーターフォール手法、スパイラルモデル、DoDの7つの2167および2167Aライフサイクルモデルの出現までさかのぼり、アジャイルプロセスの「歴史と形跡」について語った。同氏はWinston Royce氏などの発想が誤解され、業界にウォーターフォールモデルを押し付けたことでRoyce氏など後に不当に厳しく非難された経緯を慎重に語った。Larman氏は、長年の誤解と誤った宣伝につながり、誤って引用された部分を具体的に指摘した。
同氏の講演が非常に素晴らしかったのは、同氏がアジリティ自体を押し付けていなかった点だ。同氏が本当に関心を示しているのは、誰でも質の高いソフトウェアを効果的に開発できるようになることだ。アジャイル手法はツールキットの中のツールの1つにすぎない。第1の要点は、アジリティの背景にある概念が以前からあり、その間多くの人々が迷走したものの、それをわれわれがいまになって再発見しつつあることだ。
◆ 成熟したXPはプロセスの中で幅広く採用されていく
筆者は先に、XP/Agile Universe 2004が最後のXP/Agile Universeカンファレンスだと述べた。これは良いことだ。来年になると、Agile Development Conferenceと統合され、それがアジャイル手法関連で最大のカンファレンスになる。カンファレンスが2つあると対立が生まれ、アジャイル活動の打撃になる。多くの人々はこのことを認識していたが、すべての関係者が集結してカンファレンスを1つに集約するまでにはしばらく時間がかかってしまった。
筆者は来年に向けて2つの予想を立てている。まず1つ目は、アジャイル手法の利用が大幅に拡大するというものだ。Grady Booch氏が2年前に指摘したように、ソフトウェアは5〜9人で開発するケースが大半を占めるが、アジャイル手法、特にXPは小規模チームに最適だ。2つ目の予想は、アジャイル手法の採用が拡大するにつれ、RUPなど、ほかの手法やプロセスの採用も拡大するというものだ。なぜだろう? XPは、それが適するところでは有効だが、大半のチームは単純にすべての手法を採用することはできない。これらは大規模組織には適しておらず、ソフトウェア開発のライフサイクル全体はカバーしていない。
その代わり多くにとっては、RUPが新しくなるごとに、このようなプロセスフレームワークをカスタマイズしてアジャイルの事例にすることが容易になっていくことが分かるだろう。中規模から大規模の組織は、柔軟でカスタマイズ可能なプロセスを用意することのメリットを理解するようになり、自分たちのプロセスにとって最高の手法を取り入れることを望むようになる。経験主義者らがこれらの手法の生み出すメリットの測定や宣伝によってその役割を果たし続ければ、ますます多くの組織が納得するようになる。
[注1] YAGNIは「You Ain’t Gonna Need It(必要ない)」、DTSTTCPWは「Do the Simplest Thing That Could Possibly Work(可能な限り簡単に)」の略。
[注2] Martin Fowlerは、UML関連で史上最も人気の高い書籍、「UML Distilled」の著者。
[注3] The Rational Edgeの2001年3月および2001年4月号参照。
[注4] Laurie Williams氏には、ペアプログラミングなどの手法の有効性計測に関する多彩な著書がある。詳細は同氏のWebサイト参照。
[注5] この手法の説明はThe Rational Edgeの2002年10月号の記事参照。
[注6] 毎年カンファレンスの名前は数字1けた分変わる。最初のカンファレンスはXP2000だったが、今年はXP2004だった。
[注7] オープンスペースとは、参加者が話題を提案し、関心を示す人が十分な数に達すると議論のスレッドが始まる場所。
[参考]
・The Agile Alliance Web Site。 アジリティに関する最新情報を知るために最適な場所。
・“Agile Software Development”、Alistair Cockburn著、2001年Addison-Wesley刊
・“Agile and Iterative Development: A Manager’s Guide”、Craig Larman氏著、2003年Addison-Wesley刊
・“Extreme Programming Examined”、Giancarlo Succi、Michele Marchesi共著、2001年Addison Wesley刊
・“Strengthening the Case for Pair Programming”、Laurie Williams氏ほか著、IEEE Software、2000年7月および8月号
|
2/2
|
|
INDEX |
||
| The Rational Edge アジャイル、成熟期の到来とこれまでの道のり |
||
| Page1 アジリティ:黎明期 |
||
| Page2 アジリティの跳躍 |
||
|
本記事は「The Rational Edge」に掲載された「Agility comes of age」をアットマーク・アイティが翻訳したものです。 |
| IT Architect 連載記事一覧 |
The Rational Edge
米ラショナルソフトウェアがWeb上で毎月更新するオブジェクト指向開発のための論文集「The Rational Edge」を@ITが厳選して翻訳
- 第1回 要件仕様の決定に時間を割かない結末は?
- 第2回 先駆者に学ぶ「開発プロセス改善の原則」
- 第3回 あるプロジェクトリーダーの成功ストーリー
- 第4回 ソフト開発の変革というWebサービスの可能性
- 第5回 プロダクト・マネジメントを成功に導くには
- 第6回 分散コンピューティング時代のテスト手法
- 第7回 プロジェクトの特性に合わせた要件定義手法の選択
- 第8回 優秀なテスターの育成と訓練方法
- 第9回 「アジャイル」「RUP」「Rational XDE」の融合
- 第10回 Dr.ユースケースの “ユースケース人生相談”
- 第11回 Webサービスのテスト技法進化論
- 第12回 要件定義の考古学
- 第13回 チェスとソフト開発、その相関関係を探る
- 第14回 開発計画が破たんするには理由がある
- 第15回 要件定義の管理技術(Lv0〜Lv5)
- 第16回 オン・デマンドの波をキャッチしろ
- 第17回 オープンソース時代のテスト手法、そのノウハウ
- 第18回 オープンソース時代のテスト手法、テストのロードマップ
- 第19回 オープンソース時代のテスト手法、テストのまとめ
- 第20回 『オープン』の正体 (前編)
- 第21回 『オープン』の正体 (後編)
- 第22回 サブシステムの「なに?」「なぜ?」「どうやって?」
- 第23回 サブシステムとはモデリング概念である
- 第24回 アスペクト指向プログラミング オーバービュー
- 第25回 「プロジェクト管理」を管理するために
- 第26回 レッスン1:何もせずに取り残されるな
- 第27回 レッスン3:相違に注意を払え
- 第28回 大規模プロジェクトにアジャイルを適用する方法(前編)
- 第29回 大規模プロジェクトにアジャイルを適用する方法(後編)
- 第30回 アジャイル開発:成熟期の到来、その道のり
- 第31回 UML 2.0のキホン:コンポーネント図の詳細解説
- 第32回 コーディングの知恵を要件定義で利用する
- 第33回 隣のテストチームが優秀ないくつかの理由(前編)
- 第34回 隣のテストチームが優秀ないくつかの理由(後編)
- 第35回 中国のソフトウェア開発現場はこんなにスゴイ
- 第36回 ソフトウェア開発の「いま」と「近未来」の話
- 第37回 ルネサンスの巨匠たちに学ぶエンジニアリングの技
- 第38回 オブジェクト指向を超えて
- 第39回 ユーザー要件を引出すテクニック
- 第40回 ITプロジェクトを見える化する
- 第41回 ソフトウェアアーキテクチャって何なの?(前編)
- 第42回 ソフトウェアアーキテクチャって何なの?(後編)
- 第43回 ソフトウェアアーキテクトの役割
- 第44回 ソフトウェアアーキテクティングのプロセス
- 第45回 ソフトウェアアーキテクティングのメリット
- 第46回 ウォーターフォールから反復型への移行手順
- 第47回 トランザクション管理の複雑性を克服する パート1
- 第48回 トランザクション管理の複雑性を克服する パート2
- 第49回 汎用グラフィカルモデリング言語「SysML」 パート1
- 第50回 グラフィカルなモデル言語で製品構造を記述
- 第51回 キミのコードが汚い理由
- 第52回 「設計」や「構築」よりも重宝されるスキル
- 第53回 専門家に聞くモデル駆動開発のメカニズム
- 第54回 プロジェクトのはじめに計画を立てるのは無謀
- 第55回 「この開発プロジェクトは中止!」の基準
- 第56回 なるほど! ビジネスユースケース
- 第57回 そうだったのか! システムユースケース
- 第58回 不完全なコードは推敲フェイズで潰しておきたい
- 第59回 ビルドが全滅する原因
- 第60回 初歩の「Perl」「Python」「Ruby」
- 第61回 開発プロジェクトを「統治」するベストプラクティス
- 第62回 開発プロジェクト「統治」のピンポイント解説
- 第63回 反復開発の「ここはぜひカバーしたいポイント」
- 第64回 開発プロセス導入のアンチパターン
- 第65回 プロセスはチャンスが訪れるたびに改善する
- 第66回 自己管理型チームの利点と弱点
- 第67回 人事評価と開発者のモチベーション
- 第68回 鈍重な開発チームは鈍重なシステムを作る?
- 第69回 ソフトウェアが複雑なのは仕方がない?
- 第70回 ソフトウェアの複雑性を手なずける
- 第71回 見積もりの精度 Accuracy of Estimation
- 第72回 アジャイル開発の広範な普及を目指して
- 第73回 アジャイルとシステムテストの新たな関係(前編)
- 第74回 アジャイルとシステムテストの新たな関係(後編)
ホワイトペーパー(TechTargetジャパン)
|
|

