7つのアジャイル開発手法の実践ガイド（第2回）

はじめに

　本稿は、さまざまなアジャイル開発手法を紹介する2回シリーズの記事の第2回です。本シリーズでは、7つの人気の高い開発手法の表と裏をすべて学習し、組織に最適な開発手法の組み合わせを選べるようになることを目的としています。第1回では、アジャイルの概要を説明し、エクストリームプログラミング（Extreme Programming：XP）、スクラム、リーン、機能駆動型開発（Feature Driven Development：FDD）について説明しました。第2回では、アジャイルユニファイドプロセス（Agile Unified Process：AUP）、クリスタル、動的システム開発手法（Dynamic Systems Development Method：DSDM）について説明し、それから7つの手法を比較検討します（第1回を読んでいない方は、以下の記事を先にお読みください）。

過去の記事

• 7つのアジャイル開発手法の実践ガイド（第1回）

アジャイルユニファイドプロセス

　ユニファイドプロセス（UP）は、漸増反復的なソフトウェア開発プロセスフレームワークです。UPはしばしば「儀式度が高い」と見なされますが、それはソフトウェアプロジェクトに関係する多数のアクティビティと成果物を指定するからです。UPを発展させたプロセスフレームワークはいくつかありますが、最も人気が高いのはIBMによるラショナルユニファイドプロセス（Rational Unified Process：RUP）です。アジャイルユニファイドプロセス（AUP）はUPのアジャイル版であり、Scott Amblerによって整理され、Craig Larmanらによって文書化されました。AmblerはAUPを「大きな単位では連続的、小さな単位では反復的な性質を持ち、時間の経過と共に漸増的なリリースを引き渡す」と要約しています。

　AUPプロジェクトでは、リスク管理が重要な役割を果たします。AUPでは、危険性の高い要素を開発の早い段階で処理することを重視します。そのための手段として、通常はリスクリストを早期に作成し、開発プロセス全体を通して保守します。AUPでは、実行可能なアーキテクチャのベースラインを早期に開発することも重視します。つまり、このアーキテクチャコアを推敲（Elaboration）フェーズで開発することで、重要な要件と仮定の妥当性を検証し、技術的なリスクに対処します。

　Amblerは、AUPを「大きな単位では連続的」と表現した際に、開始（Inception）、推敲（Elaboration）、構築（Construction）、移行（Transition）という、UPプロジェクトの4つの主要なフェーズに言及しています。これらのフェーズは連続的に発生し、各フェーズは指定されたマイルストーンが達成されたときに終了します。

• 開始 ― 開始フェーズでは、新しいシステムの適用範囲に関して共通の理解を育み、候補となるアーキテクチャを明確にします。
• 推敲 ― 推敲フェーズでは、システム要件に対するチームの理解を広げ、候補となるアーキテクチャの妥当性を検証します。
• 構築 ― 構築フェーズでは、システムの開発を行います。
• 移行 ― 移行フェーズでは、システムテストを行い、システムをプロダクション環境に配備します。

　AUPは、各フェーズが1つ以上のイテレーションに分割されるという点で、「小さな単位では反復的」です。AUPの規律はUPの規律のサブセットであり、モデル、実装、テスト、デプロイメント、コンフィグレーション管理、プロジェクト管理、環境を含んでいます。大部分のイテレーションでは、AUPの7つの規律のすべてが並列的に生じます（図1を参照）それぞれの規律は、プロジェクトをそのビジョンの達成に近づけるアクティビティを表します。

図1　ユニファイドプロセスのフェーズと規律（イメージはIBM提供）

クリスタル

　クリスタルとは、実際には1つの開発手法ではなく、プロジェクトの規模や複雑さによって変わる開発手法ファミリを指しています。クリスタルという名称は、創案者であるAlistair Cockburnが、この開発手法ファミリの全体に対して付けたものです。個々の開発手法には、結晶の地質学的な硬度に対応する色にちなんだ名称が付けられ、そこれによってプロジェクトの規模と重大度が表現されます。Cockburnは一連の開発手法の可能性を指摘したのですが、これまでのところ私たちの知っている実装は、クリア（Clear）、イエロー（Yellow）、オレンジ（Orange）、オレンジWeb（Orange Web）、レッド（Red）、マルーン（Maroon）だけです。

　クリスタルのこれらのフレーバーは多くの要素を共有していますが、Cockburnが上方互換性や下方互換性を意図していないことに注意してください。クリスタルクリアプロジェクトとして開始されるプロジェクトの場合、クリスタルマルーンプロジェクトへの移行を考えるべきではありません。Cockburnが暗に言っていることは、プロジェクトをマルーンプロジェクトに変えるなら、マルーンプロジェクトの特性とプラクティスを採用すべきであって、元のクリスタルクリアのプラクティスを時間の経過と共に「発展」させようと考えてはいけないということです。

　クリスタルのどの実装を選ぶにしても、7つの重要な原則が共通に存在します。

1. 頻繁な引き渡し
プロジェクトの所有者／顧客は、2〜3ヶ月ごとにチームから成果物を受け取るものと期待できます。プロジェクトの規模や重大度が大きくなると、成果物がプロダクション環境に投入されない場合もありますが、利害関係者は中間バージョンを確認し、フィードバックを返すことができます。

2. 継続的なフィードバック
プロジェクトチーム全体で定期的に集まって、プロジェクトのアクティビティについて相談します。また、利害関係者とも定期的に会って、期待どおりの方向に進んでいること確認し、プロジェクトに影響するような新たな発見があれば通知します。

3. 不断のコミュニケーション
小規模なプロジェクトでは、チーム全体が同じ部屋にいることが期待されますが、大規模なプロジェクトでは、同じ施設に配置されることが期待されます。どんなプロジェクトでも、要件を定義する人物と頻繁にやり取りすることが期待されます。

4. 安全
クリスタルはソフトウェア開発の安全面を重視するという点に特徴があります。これには2つの形態があります。1つは、チームのメンバが効果的に作業でき、プロジェクトの期間中に報復を恐れずに真実を話すことのでる安全な環境を作ることです。これは大部分のアジャイル開発手法に当てはまります。もう1つは、クリスタル独特のもので、各ソフトウェアプロジェクトの目的はそれぞれ異なり、ある種のソフトウェアプロジェクトはエンドユーザーの安全に大きな影響を与えるということを認識することです。例えば、スペースシャトルのシステムはレシピ整理システムよりもずっと重大です。

5. 焦点
チームのメンバは、他の各メンバが担当する、優先度の高い作業を把握していることが期待されます。

6. ユーザーとのやり取り
クリスタルでは、大部分のアジャイル開発手法と同様、プロジェクトチームが開発するシステムのユーザーと意見交換することが期待されます。

7. 自動化されたテストと統合
クリスタルには、プロジェクト機能を検証するための機能がいろいろあります。バージョン管理、自動化されたテスト、システムコンポーネントの頻繁な統合をサポートするには、管理システムを整備する必要があります。

　プロジェクトの規模と重大度はクリスタルの重要なコンセプトです。規模はプロジェクトにかかわる人数によって定義されます。この点について特筆すべきことはありませんが、チームの規模が大きくなると、構造、成果物、プロジェクト管理についての儀式度が高くなっていきます。

　重大度はシステムによってもたらされる被害の可能性として定義されます。例えば、正しく動作しない生命維持装置は、ゲーム記録を保存できないビデオゲームよりも大きな被害をもたらすでしょう。プロジェクトの重大度が高い場合は、期待される要求物を確実に引き渡せるようにするために、プロジェクトの厳格さも高める必要があります。

　図2は、各プロジェクトでどのクリスタル開発手法を選ぶべきかを示したものです。クリスタルの特徴の1つは、規模と重大度に基づいたプロジェクトを評価することです。プロジェクトの規模が大きくなる（図の右方向に進む）につれて、プロジェクトが大きくなり、困難さが増大するので、より包括的な（より暗色の）クリスタルが必要になります。また、プロジェクトの重大度が大きくなる（図の上方向に進む）につれ、追加される要件に合わせて、開発手法のいろいろな面（チームが生成する成果物など）を整備する必要性が出てきます。ただし、重大度はクリスタルの色には影響しません。

図2　クリスタル開発手法ファミリ

　図2のセル内の英字はプロジェクトの重大度を表しています。

• C ＝ Comfort（快適さ）
• D ＝ Discretionary Money（余裕資金）
• E ＝ Essential Money（基本資金）
• L ＝ Life（生命）

　セル内の数字はプロジェクトチームの最大規模を表しています（図2の下部を参照）。6人までのチームの場合は、クリスタルクリアがうまく適合します。7〜20人のチームの場合は、増大した分の規模を管理するメカニズムを備えたクリスタルイエローが適合します。75〜80人のチームの場合は、クリスタルレッドがうまく適合します。同じ1〜6人のプロジェクトでも、原子スプリッタを扱うチームであれば、アマチュアバンドのWebサイトを作成するチームよりもやや厳しい抑制均衡が必要になるでしょう。

　クリスタルクリアとクリスタルオレンジのプロジェクトに関するデータは大量に公開されているので、これらの開発手法をもう少し詳しく見ていくことにします。

クリスタルクリア

　プロジェクトの規模と重大度が大きくなると、クリスタル開発手法における役割が変化します。定義される役割が最も少ないのが「クリア」で、最も多いのが「マルーン」です。クリスタルクリアプロジェクトで定義される最低限の役割は次のものです。

• スポンサー
• 上級設計者
• プログラマ

　クリスタルクリアでは、すべてのチームメンバが同じ部屋で一緒に仕事をすることが期待されます。もっと複雑なコミュニケーションのサポートは指定されません。最も重要な役割は上級設計者です。上級設計者には、必要な技術的意思決定をすべて行うことが期待されます。プロジェクトマネージャ、ビジネスアナリスト、テスト担当者といった役割は、すべてのチームメンバの間で分担されます。

　クリスタルクリアでは、実際に動作するソフトウェアを2〜3ヶ月ごとに引き渡すことが期待されます。チームは必要ならイテレーションを小刻みにすることもできますが、期待されるリリースは60〜90日ごとです。

　クリスタルクリアで要求されるドキュメントは最小限のものです。というのも、プロジェクトのマイルストーンは一般にソフトウェアの実際の引き渡しであって、書かれたドキュメントではないからです。追加の成果物や、独自のコーディング標準、テストプラクティスなどを定義するのはチームの責任です。

クリスタルオレンジ

　オレンジプロジェクトになると、役割の数はずっと多くなります。役割は組織に応じて変わる可能性がありますが、一般にはアーキテクト、スポンサー、ビジネスアナリスト、プロジェクトマネージャといった伝統的な役割が含まれます。

　プロジェクトが大規模になると、検証の必要性が増大するので、プロセス全体にわたる構造を整備するために特別な気配りが行われます。また、テストがさらに重視され、チーム内のサブグループごとにテスト担当者を設けることが期待されます。

　クリスタルオレンジプロジェクトは典型的な中規模プロジェクトと言えます。

　クリスタルオレンジでは、実際に動作するソフトウェアを3〜4ヶ月ごとに引き渡すことが期待されます。チームは必要ならイテレーションを小刻みにすることもできますが、期待されるリリースは90〜120日ごとです。

　クリスタルオレンジでは、次のような成果物を定義します。

• 要件ドキュメント
• リリースシーケンス（スケジュール）
• プロジェクトスケジュール
• ステータスレポート
• UI設計書（UIがある場合）
• オブジェクトモデル
• ユーザーマニュアル
• テストケース

　クリスタルクリアと同様、チームは引き渡す成果物について独自の標準とガイドラインを定義する責任があります。

動的システム開発手法

　動的システム開発手法（DSDM）は、技術ではなくビジネスの視点で考える人たちによって1990年代の後半に英国で開発されました。DSDMは今ではDSDMコンソーシアムによって管理されており、おそらく英国で実施されている最も人気の高いアジャイル開発技法でしょう。DSDMは技術的にはフレームワークと見なされます。このフレームワークのバージョン管理（およびリリースの管理）はコンソーシアムによって行われています。

　DSDMは重量級のアジャイルアプローチの1つです。もともとは高速アプリケーション開発（Rapid Application Development：RAD）の拡張として開発されたもので、ビジネス指向の創始者のベストプラクティスを組み入れています。

　DSDMプロジェクトは3つのフェーズから成ります（図3も参照）。

• プリプロジェクト ― プロジェクトの開始前に行われるべきものです。
• プロジェクトライフサイクル ― 実際のプロジェクトが行われます。このフェーズは5つのステージに分けられます。
• 実現可能性調査
• ビジネス調査
• 機能モデルイテレーション
• 設計と構築イテレーション
• 実装
• ポストプロジェクトフェーズ ― プロジェクトの終了後に行われるべきものです。

図3　DSDMライフサイクル。DSDMプロジェクトの3つのフェーズは多くのステップから成る

　DSDMには次のような9つの原則があります。

1. 積極的なユーザー関与が絶対に必要である。
2. チームに引き渡しの権限が与えられなければならない。
3. 頻繁な引き渡しが鍵である。
4. 受け入れの主たる条件は現在のビジネスニーズを満たす機能の引き渡しである。
5. 反復的で漸増的な引き渡しが不可欠である。
6. プロジェクトライフサイクル中に行われた変更はすべて元に戻せる。
7. 要件は高いレベルで基準化される。
8. プロジェクトライフサイクル全体で統合されたテストが期待される。
9. すべての利害関係者間の協力が不可欠である。

　DSDMのルーツはビジネスにあるため、DSDMが予算内で期日どおりに機能を引き渡すことを重視しても不思議はないでしょう。これを達成するため、各プロジェクトがいくつかのチャンクに分割され、それぞれのチャンクには、ある決まった数の機能と予算と時間が割り当てられます。時間と予算は両方とも固定されているので、プロジェクトが時間または予算をオーバーしそうになった場合は、最も重要性の低い機能が削られ、将来のプロジェクトに先送りされます。機能（要件）の優先度は次のルールによって決められます。

• 必ず実現しなければならない要件（MUST）
• 可能な限り実現すべき要件（SHOULD）
• 引き渡しに大きな影響が出なければ実現した方が良い要件（COULD）
• 十分な時間が残っていれば実現したい要件（WOULD）

　MUST、SHOULD、COULD、WOULDは一般にMoSCoWという頭字語で表されます。

　DSDMでは、要件に対するユーザーフィードバックは非常に重要で、プロジェクトフェーズの早期に作成されるプロトタイプで大きな意味を持つとされています。これらは要件を精緻化し、すべての利害関係者の期待を明確化するために使われます。

　DSDMはプロジェクトチームが使用すべきテストアプローチを指定しませんが、プロジェクトライフサイクルフェーズ全体にわたってテストを実行するように求めています。ライフサイクルのすべての面にテスト担当者が関与して、テストの機会が最大化されるようにしなければなりません。

　プロジェクトの要件と機能について議論するためのフォーラムを利害関係者に提供するため、ワークショップが使用されます。こうしたワークショップは必要に応じて何度でも実施できます。モデリングはワークショップに似ていますが、システムの技術的な部分や、ビジネスドメインのようなビジュアルモデルが効果的な他の部分を生み出したり伝達したりするために、技術チームメンバによって実施されます。

　DSDMでは固定的なコントロールを行うため、プロジェクトのさまざまな面を制御するコンフィグレーション管理システムが必要になります。

　DSDMはプロジェクト規模の上限を、それぞれが6人のメンバから成る6つのチームに設定しているように見えます。チームの人数がもっと多い場合もあるかもしれませんが、そうした事例を裏付けるようなドキュメントを見つけることはできませんでした。DSDMはビジネス的なベストプラクティスの上に築かれたので、生命維持装置、有毒廃棄物管理、原子炉といった、安全が重視されるシステムに使用するのは望ましくありません。この点には注意すべきです。

比較

　この2回シリーズで取り上げた開発手法には、それぞれ長所と短所があります（表1を参照）。XP、スクラム、リーン、FDDの詳細については、第1回をお読みください。

　どの開発手法も、それぞれ固有の長所と短所を持っているため、状況によって適不適があります。

表1

　表2は、この2回シリーズで取り上げた開発手法を比較し、プロジェクトの状況に合わせて適切なアプローチを選定するための目安を示そうとしたものです。適しているものを「√」で、適していないものを「X」で、どちらとも言えないものを「-」で表しています。

　表2の情報はいかなる科学的メトリックも表していませんし、各開発手法の創案者が表明している目標を表しているわけでもありません。しかし、これは著者たちの直接体験によるものなので、それぞれのチームがこれらの開発手法を（全面的または部分的に）採用する際の参考になるはずです。

表2

　表3は、各開発手法の目標に対する著者たちの解釈を簡潔に表現したものです。

　与えられた環境に対するアジャイル開発手法の適合性を類別する2つの方法として、プロジェクトの規模と重大度があります。これによってアジャイル開発手法の適合性を完全に捉えることはできないとしても、おおまかに理解するには非常に好都合です。Alistair Cockburnは、これらの特性に基づいて開発手法を比較するスケールを開発しました。図4では、これまでに取り上げた開発手法を、著者たちの経験と観察に基づいてプロットしてみました。

図4　各開発手法の適合性に対する著者たちの経験と観察に基づいた評価をCockburnのスケールで表したもの

　図4が示しているように、XPは一般に小規模で非常に動的なプロジェクトに最も適しています。ただし、XPのプラクティスの多くは、他の管理手法との組み合わせにより価値をもたらすことができます。XPは開発者が何百人もいる企業にも適用されていますが、大規模なプロジェクトを扱うというのは各企業が行うべきカスタマイズであり、継続的で迅速なフィードバックと単純さを旨とするXPプロセスの本来の姿ではありません。

　AUPは儀式度が高いプロセスを提供します。このようなプロセスは、大人数のチーム、分散チーム、重要度の高いシステムに適していると考えられます。採用する側の企業文化がウォータフォール型のプロセスからゆっくりと変化しそうなら、アジャイル的な考え方に徐々に慣れるという意味で、AUPがうってつけでしょう。

　スクラムとリーンは、プロセス全体を管理し、ビジネス価値を最大化し、無駄を少なくする方法に焦点を当てたフレームワークです。スクラムとリーンは技術的プラクティスを指定しないので、XPなどの開発手法や企業の既存の開発手法を補完することができます。

　DSDMはアジャイルの中でも重くて儀式度の高い手法であり、しかも非常にビジネス中心的です。AUPに似ている点が多くありますが、リスクよりも現在のビジネス価値を重視しています。

　クリスタルはプロジェクトの規模と重大度によって変わる開発手法のファミリです。プロジェクトの規模や重大度が大きくなるにつれて、より重大なプロジェクトに必要な高い安全度や大人数のチームという重荷をサポートするためのメカニズムが追加されます。

　FDDは興味深い混合物です。FDDはそれ自体で完結したアジャイルプロセスとして機能することもできますが、スクラム、リーン、またはXPと組み合わせて、統合された技法を生み出すこともできます。

　注意してほしいのですが、アジャイルにせよ何にせよ、そのまま実施されることを想定している方法論はありません。採用率と成功の機会を大きくするには、適用するコンテキストでカスタマイズする必要があります。