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

はじめに

　アジャイル開発手法が正しいことだとわかってはいるものの、いろいろある開発手法すべてを分析しようとすれば調査だけでかなりの時間がかかってしまいます。組織にとってどの方法論が適しているかを知るにはどうしたらよいでしょうか。この2回シリーズでは、7つの人気の高い開発手法の表と裏をすべて学習するので、組織に最適な開発手法を選ぶことができるようになります。第1回では、エクストリームプログラミング（XP）、スクラム、リーンソフトウェア開発および機能駆動型開発（FDD）について説明します。

　Agile Manifestoの5周年が間近に迫っていますが、ウォータフォール型ソフトウェア開発からアジャイル開発手法とそのプラクティスへの移行の勢いは増すばかりです。ミネソタ州ミネアポリスで開かれた2006年のAgile 2006 Conferenceでは、アジャイルはもう「溝を越えたか」（『Crossing the Chasm』 Geoffrey A. Moore著、Harperbusiness、2002年8月 より）という議論が活発に交わされましたが、アジャイルが溝に到達したかという討論はありませんでした。アジャイルの手法とプロセスの正しい活用は、特に非常に困難な状況で常に高い成功率を挙げているため、アジャイルの採用に対する関心は衰えを知りません。

　しかし、組織がいったんアジャイル開発計画を採用することを決めても、行わなければならない難しい調査や意思決定が山のように残っています。特に、今日ではさまざまなアジャイル開発手法が発表されているため、ウォータフォール型モデルに慣れていた人は混乱しがちです。現在使用されている最も人気の高いアジャイル開発手法はエクストリームプログラミング（Extreme Programming：XP）、スクラム、機能駆動型開発（Feature Driven Development：FDD）、リーンソフトウェア開発、アジャイルユニファイドプロセス（Agile Unified Process：Agile UPまたはAUP）、クリスタル（Crystal）、動的システム開発手法（Dynamic Systems Development Method：DSDM）のようです。この2回シリーズでは、アジャイルの価値体系を簡単に説明し、各種の開発手法がこれらの価値をどう表しているかを分析します。特にそれぞれの開発手法の類似点と相違点に注目し、最後に、それぞれの手法がどのようなビジネスコンテキストに適しているかを簡単に分析します。

アジャイルの概要

　アジャイルなソフトウェア開発では、人、コミュニケーション、実際に動作するソフトウェア、そして変化への対応を重視します。この方針は「アジャイル宣言（Manifesto for Agile Software Development）」という形にまとめられ、開発コミュニティに大きな影響力を及ぼしています。この宣言の最も注目すべき特徴の1つは、具体的な計画やプロセスではなく、バリューステートメント（価値観、行動規範）について語っていることです。これは、「価値に重きを置く開発スタイル」というアジャイルの基本精神をよく表しています。

　すべてのアジャイル開発手法で取り組んでいるのが、短期間のイテレーションを繰り返し、イテレーションごとに、機能が追加された実際に動作するソフトウェアを引き渡す、という反復的なワークフローです。イテレーションは、本質的にはソフトウェアの小さなリリースです。通常、各イテレーションの最中には、要件定義、コーディング、テストなど、多くのアクティビティが並行して発生します。イテレーションは一般に固定された長さなので（ただし、この長さは開発手法によって異なります）、タイムボックスと呼ばれています。各イテレーションに割り当てられている時間のことをサイクルタイムと呼ぶこともあります。

　アジャイル方法論は、アクティビティとそれによって生成される成果物という点でも特徴があります。成果物（またはワークプロダクト）とそこに至るまでのステップが多い開発手法のことを「儀式度が高い（higher ceremony）」と言います。逆に、これらをあまり重視していない方法論のことを「儀式度が低い（lower ceremony）」と言います。関係する人の数や「承認（sign off）」の数も、特定の開発手法の「儀式度」を測るのに役立ちます。どのようなコンテキストでも2つの間で適切なバランスを取ることが重要です。

エクストリームプログラミング（XP）

　エクストリームプログラミング（XP）は、非常によく知られたアジャイル開発手法の1つです。その名前が示すように、XPはプログラマ中心の開発手法であり、技術的なプラクティスを重視して、実際に動作するソフトウェアを引き渡す頻度を高くすることでスキルの高い開発を推進します。XP（およびアジャイル方法論全般）は従来の手法ほど厳密でないとよく言われますが、たしかにそのような面もあります。XP（Extreme Programming）の名前の由来は、その提唱者が「それぞれの手法／プラクティスを採用して極限まで（to the extreme）実践したらどうなるだろうか。それはソフトウェアプロセスにどう影響するだろうか」という疑問を持ったことにあります。この例の1つが、コードレビューのプラクティスです。コードレビューが良いことであるならば、絶え間なくコードレビューを実行することが究極のベストプラクティスになるはずだが、それで本当に効果が上がるのだろうか？ という疑問です。ここから生まれたのが、ペアプログラミングやリファクタリングといった、単純で、効果的な設計に基づき、ビジネス価値の最適化を指向する開発プラクティスです。実際、XPのすべてのプラクティスを完全に採り入れるには、高いレベルの規律、チームワーク、スキルが求められます。

　XPとその他の開発手法との特徴的な違いの1つは、そのサイクルタイムと儀式度です。XPでは、1〜4週間の非常に短期間のイテレーションを推奨しています。また、XPは非常に儀式度が低い方法論でもあります。XPプロジェクトの最も小さい成果物としては、ストーリーカード、コード、単体テストなどがあります。

　しかし、XPを非常に有名にしているのは、その技術的なプラクティスです。XPの中心には、「コミュニケーション」「シンプルさ」「フィードバック」「勇気」という4つの価値があります。これらの価値から次の13のプラクティスが生まれています。

1. 計画ゲーム（Planning Game）
作業を徐々に計画します。

2. 小さなリリース（Small Releases）
できる限り迅速にリリースして市場化までの時間を短縮し、できる限り早くフィードバックを取得します。

3. メタファ（Metaphor）
可能であれば、開発しているシステムのメタファを定義します。例えば、ショッピングカートのメタファはオンライン受注システムを表すために幅広く使われています。

4. 単純な設計（Simple Design）
実装している機能（ユーザーストーリー）に有効な、最も単純な設計を使います。使わないかもしれないものは設計しません。

5. テスト（Testing）
何でもテストし、可能であればテストを自動化するように努めます。

6. リファクタリング（Refactoring）
システム全体を初めに設計するのではなく、進みながら設計し、必要に応じて改善を加えます。機能へのインターフェイスを変更せずに実装を変更し、自動化したテストを使ってリファクタリングの影響を判断します。

7. ペアプログラミング（Pair Programming）
2人（または3人）1組でプログラミングすることでリアルタイムでディスカッションし、要件定義、設計、テスト、プログラミングの懸念事項に対処します。

8. 共同のコード所有権（Collective Code Ownership）
チームのすべてのメンバが、いつでもどのコードにも変更を加えることができます。

9. 継続的インテグレーション（Continuous Integration）
コードベース全体を常にリビルドし、テストを自動化して繰り返します。

10. 持続的ペース（Sustainable Pace）
理想的には、チームメンバはプロジェクトの納期を守るために週40時間を超えて労働する必要はありません。一貫した、予想可能かつ繰り返し可能な引き渡しを好むマネージャは、深夜残業を回避します。

11. チーム全体（Whole Team）
チームは全体で活動します。メンバには特殊性よりも汎用性が求められます。テクノロジと必要条件すべてについて学習することが求められます。

12. コーディング標準（Coding Standards）
コミュニケーションの最大化を図るため、コーディング標準をチームで定義し、それに従って一貫性のあるコーディングプラクティスを実現します。

13. オンサイト顧客（Onsite Customer）
顧客と常に直接接することで、チームは可能な限り迅速に対応することが可能となります。

　図1に示すように、これらのプラクティスは互いに支え合っているので、いずれかのプラクティスに手を加えたり、いずれかのプラクティスをプロジェクトに組み込まないことを決めたりする場合は注意が必要です。

図1　XPのプラクティス

　XPとその他のアジャイル開発手法のもう1つの違いは、要件収集のアプローチです。XPにおける第一の要件の成果物はユーザーストーリーです。言うまでもなく、ユーザーストーリーは簡単な説明が書き込まれた単なるメモカードにすぎません。しかし、ユーザーストーリーは、実はカード（約束された機能のリマインダ）、開発者と要件提供者との間の会話、およびテスト（単体、インテグレーション、受け入れなど、すべての種類のテスト）から成り立っています。

　XPの「計画ゲーム（Planning Game）」プラクティスには、リリース計画ゲームとイテレーション計画ゲームという2種類の基本的な計画アクティビティが含まれています。それぞれの計画ゲームは、探索、コミットメント、ステアリングという3つのフェーズを特徴としています。

　リリース計画は、顧客がストーリーカードを作成し、その優先順位を付けることから始まります。プログラマはストーリーを見積もり、そこから速度を導き出すことができます。速度は、チームが定められた期間でどの程度の作業を達成できるかを表します。顧客は、希望する機能またはリリース日のいずれかに基づいてリリースのスコープを選びます。リリース計画のステアリングアクティビティは、イテレーションの境界で、計画されたリリース日までの進捗状況を追跡し、調整を簡単に加えられるときに発生します。

　イテレーション計画も、リリース計画と同様のパターンに従います。各イテレーションは、開発者がストーリーを手にして、それをタスクに分割することから始まります。プログラマはタスクの責任を受け入れ、担当するタスクを見積もります。各プログラマの負荷をこれまでの実績と比較し、負荷がかかり過ぎている人がいないかどうかを判断することで、チーム間での作業負荷のバランスを取ることができます。イテレーション中はプログラマ同士がパートナーを組み、単体テストとコードを作成することでタスクを果たします。イテレーションの最中は、チームのメンバが定期的にチームの進捗状況を確認し、この情報をチームメンバ全員に伝えて調整を図るようにします。

　XPプロジェクトでは、次のような役割が定義されています。

• 顧客
顧客は、実現する必要があるストーリーを作成して優先順位を付けます。優先順位を設定するのは顧客なので、定められたリリースで何を引き渡すかを制御するのも顧客です。顧客はストーリーを追加、削除することでリリース日を制御することができます。

• プログラマ
プログラマは、ストーリーの見積もりは集団で行いますが、見積もったタスクの責任を受け入れ、テストを作成し、コーディングすることは個人単位で行います。

• コーチ
コーチは、ソフトウェア開発プロセスを監視し、XPプロセスと手法の点でチームメンバを指導し、チームの注意を潜在的な問題や最適化に集中させます。

• トラッカ
トラッカは、チームの進捗状況を監視し、スケジュールの調整やタスクの割り当ての変更が必要になったときにチームに警告します。

スクラム

　スクラム（Scrum）はSCRUMという頭字語だと誤解されているようですが、そうではありません。スクラムという名前は、ラグビーのスクラムから来ています。ラグビーでは、軽度の反則（ボールを前に落とすなど）の後に試合を再開するときに、スクラムというプレーをします。分かりやすく言えば、チームが一丸となってボールをゴール方向に進ませることです。

　スクラムはアジャイルなプロジェクトを管理するためのプロジェクトマネジメントフレームワークです。その第一の目的は、各イテレーション後に、最高のビジネス価値を提供するソフトウェアを引き渡すことです。スクラムは「スプリント（Sprint）」という30日間のイテレーションをベースとしています。理論的には、スプリントは2週間または4週間のどちらでも構いませんが、一般に受け入れられている期間は4週間です。

　スクラムに欠かせない重要なポイントは、「プロジェクトチームは自己組織化しなければならない」ことです。つまり、チームメンバは規範的な計画や一連のタスクに従うのではなく、最初はスプリントの目標に基づき、その後は毎日のスクラムミーティングを通して、日次ベースで自ら組織的な調整を行います。チームの規模としては4〜9人が推奨されています。

　プロジェクトチームは毎日同じ時刻にミーティングを開き、プロジェクトについて話し合います。その際、立ってミーティングを行うことで、ミーティング時間を短くすることが期待されます。ミーティングは10〜15分で終了することを目標とします。各メンバは順に次の3つの質問に答えます。

1. 前回のスクラムミーティング以降に何を行ったか。
2. 現在から次のスクラムミーティングまでの間に何を行うことを計画しているか。
3. 障害があるか。

　この報告は状況ミーティングではありません。言い換えれば、チームメンバが報告するのはタスクが何パーセント完了しているかということではありません。報告するのは、どのような作業を行ったか、なぜそれを行ったか、それが完了したかどうかということです。進捗を遅らせる事態が発生した場合は、障害と見なします。障害が報告されたら、適切なチャネルに即座に上申することを含め、チームはその障害を処理する方法を決定します。

　1つのプロジェクトに複数のチームが関与している場合は、日次スクラムミーティングの階層が発生する可能性があります。これをスクラムのスクラムとも言います。例えば、3つのチームが3つの関連するスプリントで作業にかかわっているとします。この場合は、チームごとに日次スクラムミーティングを開くほかに、各チームから1人ずつメンバが集まって追加スクラムミーティングを開き、チームが連携していることを確認します。この追加スクラムからの情報は、翌日に個々のチームのスクラムにフィードバックされます。

　スクラムでも、次のような役割が定義されています。

• プロダクトオーナー
プロダクトオーナーは、チームが作成しているプロダクトの顧客またはユーザーの代表です。実際の顧客であることが理想ですが、プロダクトの顧客の協力が得られない場合は、顧客の関心を表現する人がこの役割を引き受けます。また、プロダクトチームと顧客を結び付けることもプロダクトオーナーの担当です。

• スクラムマスタ
スクラムは、障害のあるまたは緊急のプロジェクトを取り扱う方法として始まりました。スクラムマスタは、プロジェクトチームをまとめるための役割を担います。スクラムマスタの仕事は主に、チームの活動を円滑にし、報告し、優先順位が最も高い作業に焦点を当て、チームの進捗を遅らせる可能性がある障害を取り除くことです。スクラムマスタ向けの認証トレーニングがあり、3つの異なるレベルのプラクティスをサポートします。

• チームメンバ
チームのその他のメンバはすべて一般のチームメンバと見なされます。これには、開発者、アーキテクト、プロジェクトマネージャ、テスタ、データベース管理者など、あらゆる人が含まれます。スクラムではチームの概念が重要なので、スクラムマスタとプロダクトオーナーの主な役割しか実施されません。

　スクラムでは、関連する項目のリストのことを「バックログ」と呼びます。スクラムプロセスでは、プロダクトバックログ、リリースバックログ、スプリントバックログの3つのバックログが定義されています。

　プロダクトバックログは、プロダクトを引き渡すための要件がすべて示されたリストです。通常、これらの要件は概要レベルで定義され、スプリントバックログのスコープを設定する場合に使う見積もりが含まれます。リリースバックログはプロダクトバックログから引き出されたもので、要件の一覧を表します。このリストは優先順位順で、リストの各項目には一意の優先順位が割り当てられています。また、このリスト内の各要件には、プロダクトバックログで定められた見積もりよりも細分性の高い見積もりが含まれます。

　各スプリントの開始時に、プロジェクトチームはリリースバックログからの項目を分類し、一番上（最も重要な項目）から開始して、これらの項目をスプリントバックログに追加します。スプリントバックログが満杯になるくらい十分な数の項目が選択されると、スプリントバックログはロックされます。見積もりには、分析、設計、コーディング、テスト、文書化など、各項目を完了するまでの合計時間が含まれます。

　バックログに関連するもう1つの項目として、バーンダウンチャート（Burndown Chart）があります（図2を参照）。バーンダウンチャートは、現在のスプリントで完了すべきスプリントバックログ内の残存項目数を示します。そのため、チームと残存作業の進捗状況の確認に役立ちます。バーンダウンチャートの直線は、完全に安定し均等に分散した方法で作業を完了する理想的なイテレーションを表し、曲線は時間をかけて実際に完了された作業を表します。日次レコードを更新していくことで、スプリントの目標達成におけるチームの進捗状況を表すことができます。

図2　スクラムのバーンダウンチャート

　スプリントの最後に、チームは関係のあるステークホルダとミーティングを開き、どの作業が完了したかを明白にし、次のスプリントの優先順位を評価します。さらに、未処理の障害と、その影響および考えられるソリューションについても話し合います。

　最後になりますが、スクラムはプロジェクトのマネジメント面に焦点を当てたものであり、技術的なプラクティスは何も指定していないので、他のアジャイル開発手法とうまく組み合わせることができます。通常はXPと組み合わせますが、他のアプローチと組み合わせてもうまくいきます。

リーンソフトウェア開発（Lean Software Development）

　リーンソフトウェア開発は、「lean＝細身の、無駄がない」という単語の意味から、新しいダイエット法の一種であるなどと冗談を言われたりしますが、これはまったくの冗談でもありません。リーン開発は、ソフトウェアプロセスから無駄を取り除くことを目的とした開発手法であり、要件から始めて、ビジネスが要求されるシステムをどのように見ているかを取り込んでいきます。

　リーン開発の手法は、トヨタなどの企業が過去数十年に渡り完成させたリーン生産プロセスから生まれたものです。リーン開発の目標は、ビジネスが競合力を保つために必要とされる複雑なソフトウェアシステムを定義し、構築し、引き渡すという取り組みに対処することです。リーン開発は、技術的なプラクティスではなく、ソフトウェア開発のプロジェクトマネジメント面を重視している点でスクラムと似ており、特にプロジェクトのコストとROIの属性を焦点にしています。

　リーン開発の大きな柱になっているのが、「正しい」要件の収集です。要件はビジネスへの影響に基づいて評価し、明確で完全で検証可能な方法で定義しなければなりません。不完全な要件、見つからない要件、間違った要件、検証不可能な要件、競合している要件は、要件定義プロセス時に除外されます。

　このように要件を重視するため、リーンプロセスでは顧客が絶対不可欠な役割を果たします。生産の観点から見れば、リーン開発は新製品の開発のようなものと考えることができます。要件に焦点を置くことは、顧客が果たす役割と価値を具体化するのに役立ちます。開発チームが対処しているビジネス価値と機能要件について顧客からコンスタントなフィードバックを得ることが、リーンアプローチの中心的要素です。

　リーン開発では、豊富な数量的メトリックに基づいて、多くのプロジェクトが失敗する原因が構成とマネジメントにあることを明らかにします。各自がバラバラで、それぞれが孤立し、「私の問題ではない」という姿勢で進行しているプロジェクトは、リーン開発を導入すると急変します。リーン開発では、リソース関連の問題、例えばチームに適切なスキルセットがない、チームメンバが不足している、離職率が高すぎる、といった問題についての対応も試みます。この意味で、リーン開発は「根本的な原因」を重視する手法であると言えます。

　開発手法の中にはチーム内の役割の厳密な定義を求めるものもありますが、リーン開発ではもっと部局横断的なアプローチが取られます。チームメンバはシステムの機能面と技術面のクロストレーニングを受けるだけでなく、さまざまなチームメンバと協力し合ってシステム機能のビジネス価値と、解決すべきビジネス問題を理解します。

　W. Edward Deming博士の総合的品質管理（Total Quality Management：TQM）という著作から生まれたリーン生産は、主に次の2つの概念に要約することができます。

1. プロセスが重要である。
2. 人がプロセスを構築し改善する。

　TQMは50年近くに渡って改良され、製造業界での実績は折り紙付きです。TQMはメトリックを非常に重視し、メトリックもリーンソフトウェア開発の大きな役割を果たしています。

　リーンソフトウェアプロセスに加わったもっと新しい考えが『制約条件の理論（Theory of Constraints）』 （Eliyahu M. Goldratt他著、North River Pr、1999年12月）です。これも主に2つの概念から成り立ちます。

1. 制約条件を特定する。
2. 制約条件を改善/除去する。

　「制約条件の理論」は、ビジネス組織を自己完結体系として効果的に管理する方法についての知識を具体的に表したものです。

　リーンソフトウェア開発では7つのリーン原則を推進しています。この開発手法はこれらの原則を中心に展開し、リーン開発の他の面はすべてこれらの原則を補足するために作られています。7つの原則は次のとおりです。

1. 無駄を排除する
値を付加しないものはすべて排除します。

2. 品質を組み込む
プロセス全体を通して前提条件の検証と再検証を繰り返します。価値がなくなったメトリックやプラクティスは捨てます。

3. 知識を身に付ける
短期間の反復サイクルを使用して、迅速でコンスタントなフィードバックを提供し、正しいことに焦点が当てられていることを確認します。

4. コミットメントを遅らせる
決定するための知識が十分に得られるまで意思決定を行いません。問題と有効なソリューションのトレードオフをしっかりと理解することが必要です。

5. 迅速に引き渡す
ビジネス問題を見極め、その問題に対処するシステム（または機能）を引き渡すまでの時間（つまり、市場化までの時間）を最小限にします。

6. 人を尊重する
チームに成功する力を与えます。

7. 全体を最適化する
部局横断的なチームを活用して、問題（およびその問題を解決するためのシステム）の重要でクリティカルな面を見逃さないようにします。

　繰り返しますが、リーン開発はプロジェクトマネジメント面に焦点を当てる手法であり、技術的なプラクティスは何も指定していないので、ソフトウェア開発の技術的な面に焦点を当てるXPなどの他のアジャイル開発手法とうまく組み合わせることができます。

機能駆動型開発（FDD）

　ほとんどのアジャイル開発手法は一握りの原則や特定のプロセスセットから始まりますが、機能駆動型開発（FDD）の中心はドメインモデルです。ドメインのモデルを作成することが、FDDの基礎を成すステップであり、そのためにはすべてのドメインエキスパート（サブジェクトマターエキスパート（Subject Matter Expert：SME）と呼ばれる）からドメインの知識を集め、この知識を問題のドメインを表す1つの統一化モデル（つまりモデルの集合）に統合することが必要になります。このモデルとその他の要件の評価が終わると、大まかな計画が策定され、プロダクトを作成するために必要なリソースが決まります。チームが作業する推奨期間は2週間以内であるため、小さな機能セットを選びます。最初の機能セットを引き渡したら、別のセットに取り掛かります。複数のチームが並行して別々の機能セットに取り組むことができ、機能ごとにすべてアクティビティが追跡されます。

　FDDにおける基本作業単位は機能です。機能は、小さな、クライアント価値のある処理として、次のような英文の形式で表現されます。

　<action><result>[of|to|for|from]<object>.

　この表現は、「アクション（action）によって、オブジェクト（object）に結果（result）がもたらされる」と言い換えることができます。角かっこで囲まれたセクションはオプションで、機能の定義を読みやすくするためのものです。例えば、「Calculate the monthly interest rate for an adjustable rate mortgage（変動金利型住宅ローンの月利を計算する）」という機能があるとします。この例では、「calculate」が<action>、「monthly interest rate」が<result>、「an adjustable rate mortgage」が<object>です。

　機能を組み合わせて機能セットにし、機能セットを集約してサブジェクトエリアにすることができます。通常、要件はトップダウン式アプローチで収集し、システムのすべてのサブジェクトエリアを定義し、それを機能セットに分割し、最終的に機能に分割して、そこからタスクを実際に定義して見積もることができます。一般に、機能セットはビジネスアクティビティを反映し、サブジェクトエリアは一般的なビジネスプラクティスに対応します。例えば、機能セットには「預金する」「引き出す」「口座残高を表示する」などがあり、それらはすべて「口座を管理する」サブジェクトエリアに含まれます。

　FDDでは、次の順序で5つの具体的なプロセスを指定します。

1. 全体モデルを作成する
2. 機能のリストを作成する
3. 機能別に計画する
4. 機能別に設計する
5. 機能別にビルドする

　前にも述べたように、すべてのものを機能単位で計画、ビルド、管理、追跡するという点に注意してください。機能セットやサブジェクトエリアなど、他の単位を上位の計画やレポートに使用することはできますが、主となる単位は機能です。

　FDDは、他のアジャイル開発手法よりも具体的な役割と責任に依存しています。また、FDDは他のアジャイル方法論が推進しているコード所有権や成果物の共有から離れる傾向もあり、チームの役割はこれを反映しています。FDDで定義されている9つの役割は次のとおりです。

1. プロジェクトマネージャ
財務面、レポート面を含め、プロジェクトの管理面すべてを担当します。

2. チーフアーキテクト
設計セッション、コードレビュー、テクノロジの決定を含め、システムの設計全体を担当します。

3. 開発マネージャ
開発チームとそのアクティビティの調整、リソース問題の処理など、毎日の開発アクティビティを引き受けます。

4. チーフプログラマ
進行中の設計および開発アクティビティにかかわるシニア開発者。1つ以上の機能セットの担当が割り当てられます。

5. クラスオーナー
チーフプログラマの指示下で機能の実装に従って機能の設計、コーディング、テスト、文書化を行う開発者。

6. ドメインエキスパート
システムが提供すべき必須機能を定義することができるビジネス関連のステークホルダ。クライアント、ユーザー、各種アナリストなど、システムに影響する可能性のあるビジネスの仕組みについての知識を持つすべての人が含まれます。

7. テスタ
各機能が定義どおりに実行しているかどうかの検証を担当します。

8. デプロイヤ
各種環境へのコードの実際のデプロイメントだけでなく、データの定義/形式間の変換も処理します。

9. テクニカルライタ
ユーザーが最終的なシステムについて必要とするすべてのオンライン文書および印刷文書の作成と保守を担当します。

　FDDでは、いくつかの独自の固有のメカニズムを使ってプロジェクトのアクティビティと進捗状況を報告します。これらの中で最も独自性が低いものが、機能リストとタスクリストです。多くのアジャイル開発手法は何らかの種類のリストを使用して要件および要件に基づいて実行された作業を追跡します。FDDでは、これらのリストはすべて具体的な機能に対応します。

　機能が開発サイクルのどこに位置しているかを正確に把握するには、次の6つの具体的なマイルストーンを追跡する表を使います。

1. ドメインウォークスルー
2. 設計
3. 設計インスペクション
4. コード
5. コードインスペクション
6. ビルドへのプロモート

　これらのマイルストーンは、それぞれが完了した日付ごと、およびその具体的な機能を担当するチーフプログラマごとに追跡します。

　機能のマイルストーンを集めると、機能セットを示す表になります。ここから、プロジェクトのステークホルダはプロジェクトの進捗状況を判断できます。そうすることに価値があれば、機能セットを集めてサブジェクトエリアにすることもできます。また、完了した機能をプロジェクト全体で折れ線グラフを使って追跡することもできます。このグラフには、完了したすべての機能の累積総数が日単位または週単位で示されます。

　レポートの最後のグループは、FDDに非常に固有の機能セット進捗レポートです（図3を参照）。下図のようにレポートは色分けされ、プロジェクト内の各機能セット、機能セットの完了率、各エリア内の機能の数、各機能セットを担当するチーフプログラマの名前、各機能セットの完了目標年と月を示しています。薄緑色は進行中で予定どおりの機能セット、深緑色は完了した機能セット、灰色は予定より遅れている機能セットを表しています。

図3　機能セット進捗レポート（Feature Set Progress Report）

第2回の予告

　本稿1回ですべてのアジャイル開発手法を取り上げることはできませんでした。実は、2回に分けてもすべてのアジャイル開発手法を取り上げることはできないのですが、主要なものはすべて紹介したいと思っています。第2回では、アジャイルユニファイドプロセス（Agile Unified Process）、クリスタル（Crystal）、およびDSDMを分析し、説明を続けます。また、こうした内容に交えてさまざまなアプローチを概説しながら、それぞれの開発手法が真価を発揮するコンテキストを考えます。最後に、プロジェクトに適した開発手法または開発手法の組み合わせを選ぶ場合のヒントを紹介します。