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

XP、スクラム、リーンソフトウェアから駆動型開発まで

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

はじめに

　アジャイル開発手法が正しいことだとわかってはいるものの、いろいろある開発手法すべてを分析しようとすれば調査だけでかなりの時間がかかってしまいます。組織にとってどの方法論が適しているかを知るにはどうしたらよいでしょうか。この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プロセスと手法の点でチームメンバを指導し、チームの注意を潜在的な問題や最適化に集中させます。

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