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

AUP、クリスタル、DSDMの紹介と各アジャイル手法の比較

クリスタル

　クリスタルとは、実際には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がある場合）
• オブジェクトモデル
• ユーザーマニュアル
• テストケース

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