Extreme Programming（XP）：価値観とプラクティス
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Extreme Programming（XP）は、優れたエンジニアリング習慣を論理的な限界まで突き詰めるべきだと主張するアジャイル手法です。他のフレームワークが作業をどう管理するかを伝えるのに対し、XPはコードをどのように書き、テストし、インテグレーションするかを具体的に指示します。
Kent Beckは1990年代後半にChrysler Comprehensive Compensationプロジェクトに携わる中でXPを提唱しました。彼は、物事が深刻になったときにソフトウェアチームが時折使用していたプラクティス、例えばテストを先に書いたり、パートナーとコードをレビューしたりする習慣が、常に適用されたときに最もよく機能することに気づきました。XPはその洞察を、どのチームでも採用できる価値観とプラクティスのセットへと体系化したものです。
Extreme Programmingとは何か？
Extreme Programmingは、頻繁なリリース、継続的なフィードバック、厳格なエンジニアリング規律を中心に構築されたアジャイル手法です。実証済みのソフトウェアクラフトマンシップの習慣を一貫したフレームワークにまとめ、チームが短い週次または隔週のイテレーションで本番環境対応のソフトウェアを出荷できるようにします。
Scrum がプロセスと儀式に主に焦点を当てるのとは異なり、XPは具体的な技術的プラクティスを規定します。テストをコードの前に書くこと、1日に数回作業をインテグレーションすること、設計をいつでも変更できるほどシンプルに保つことを指示します。
主要データ
- 継続的インテグレーションを実践しているチームは、コードインテグレーションサイクルが最大65%速くなります（DORA State of DevOps Report、2023年）。
- テスト駆動開発（TDD）は、制御された研究で欠陥率を40〜80%削減します（Microsoft Research / IBM Research、2008年）。
- 2024年現在、XPのプラクティスはプロのソフトウェアチームの約14%の作業習慣に組み込まれており、多くは Scrum と組み合わせて使用されています（State of Agile Report、2024年）。
XPはBeckが立ち上げを支援したAgile Manifestoと哲学的なルーツを共有しています。しかし、XPはマニフェストより2年前に生まれており、エンジニアリング行動の規定においてさらに踏み込んでいます。
XPの5つのバリュー
XPはその背後にある考え方について明確です。これら5つのバリューがXPチームのすべての意思決定を形作ります。
Communication（コミュニケーション）。 人々がコミュニケーションをやめると問題は悪化します。XPは、開発者、テスター、およびチームに組み込まれた顧客担当者の間で、常に対面での会話を求めます。
Simplicity（シンプルさ）。 今日必要なものだけを構築します。XPチームは投機的な設計に抵抗し、現在の問題を解決する最もシンプルなソリューションを選びます。これにより、明日のコード変更が容易になります。
Feedback（フィードバック）。 短いサイクルはフィードバックを素早く得るために存在します。フィードバックは、秒単位で実行されるユニットテスト、毎時間実行されるインテグレーションビルド、そして毎週実際の機能をレビューする顧客から得られます。
Courage（勇気）。 良いエンジニアリング上の決断は、時に不快なものです。XPはチームにデッドコードを削除し、容赦なくリファクタリングし、締め切りが現実的でないときに顧客に伝えることを求めます。それには勇気が必要です。
Respect（尊重）。 チームメンバー全員の貢献が重要です。尊重とは、誰も他者の作業を意図的に壊すコードを出荷せず、懸念を最後まで聞かずに却下しないことを意味します。
XPの12のコアプラクティス
XPはプラクティスを4つのグループに整理しています。以下のグループ分けはKent Beckの原典の定式化を反映しています。
細かいフィードバック
| プラクティス | 内容 |
|---|---|
| ペアプログラミング | 2人の開発者が1台のワークステーションを共有します。1人がコードを書き、もう1人がリアルタイムでレビューします。役割は頻繁に交代します。 |
| テスト駆動開発（TDD） | まず失敗するテストを書きます。次にそれを通過するのに十分なコードだけを書きます。その後リファクタリングします。 |
| プランニングゲーム | 顧客と開発者が各イテレーションで何を構築するかを決め、工数を見積もります。詳細はスプリントプランニングで扱います。 |
| 全チーム（オンサイト顧客） | 実際の顧客またはビジネス担当者がフルタイムでチームに参加し、質問に答え、Featureをすぐに受け入れるか却下します。 |
継続的なプロセス
| プラクティス | 内容 |
|---|---|
| 継続的インテグレーション（CI） | 開発者は1日に何度も共有コードベースに作業をインテグレーションします。すべてのコミットで自動テストが実行されます。 |
| リファクタリング | 動作を変えずにコードの内部構造を継続的に改善します。技術的負債を決して蓄積しません。 |
| 小さなリリース | 理想的には週次で、動くソフトウェアをユーザーまたはステージングに短いサイクルで出荷します。大規模な一斉リリースのために作業をまとめません。 |
共有の理解
| プラクティス | 内容 |
|---|---|
| 集合的オーナーシップ | どの開発者もいつでもコードベースのどの部分も変更できます。誰もモジュールを「所有」しません。チームがすべてを所有します。 |
| コーディング標準 | チーム全体が一貫したスタイルに合意するので、どの開発者もストレスなく任意のコードを読んで修正できます。 |
| システムメタファー | チームはシステムがどのように機能するかを説明するための共有された単純なストーリーを使用します。これにより、重いドキュメントなしに全員のアーキテクチャへの理解を揃えます。 |
| シンプルな設計 | システムは常に、すべてのテストを通過しチームの意図を表現する最もシンプルな設計を反映します。複雑さは発見された瞬間に取り除かれます。 |
プログラマーの健康
| プラクティス | 内容 |
|---|---|
| 持続可能なペース（週40時間） | 誰も継続的に残業しません。疲弊した開発者はミスを犯し、負債を蓄積します。XPは持続可能なペースを絶対条件として扱います。 |
XPのメリット
欠陥はすぐに表面化する。 TDDとCIは、リグレッションが発生した瞬間に検出します。3つの Sprint 後に原因を特定しにくくなってからではありません。
変更コストが低い。 シンプルな設計と継続的なリファクタリングにより、コードベースは変更が高価な形に固まることがありません。要件が変わったとき、そしてそれは必ず変わりますが、XPチームは書き直しなしに適応できます。
顧客の信頼が高まる。 顧客担当者が毎週動くソフトウェアを確認するため、リリース時に不快な驚きはありません。ステークホルダーは実際のデモンストレーションされた進捗に基づいてチームを方向転換できます。
チームの知識が広がる。 ペアプログラミングと集合的オーナーシップにより、特定の個人が単一障害点にはなりません。誰かが離脱しても、コードベースの知識はチームに残ります。
別のQAフェーズなしの品質。 テストは開発のすべての時間に組み込まれています。品質は終わりのゲートではなく、作業の継続的な属性です。
XPの制限と向かないケース
XPはどこでも適切とは限りません。苦手な場面を紹介します。
分散チーム。 ペアプログラミングは対面で最も効果的です。リモートペアリングツールは助けになりますが、異なるタイムゾーンの開発者間では、プラクティスは自発的なフィードバックの一部を失います。
大規模または安定したチーム。 XPは一般的に5〜12人の開発者からなる小規模チーム向けに設計されています。大規模なプログラムでは、追加ツールなしに集合的オーナーシップと継続的インテグレーションの調整オーバーヘッドが大幅に増加する可能性があります。
規制または安全性が重要なコンテキスト。 航空宇宙、医療機器、金融コンプライアンスなどの業界では、XPの最小ドキュメントの好みと相反する詳細な事前ドキュメントとサインオフが求められることが多いです。XPのプラクティスはコンプライアンスワークフローと共存できますが、慎重な適応が必要です。
自動テストに不慣れなチーム。 TDDには文化的な変革が必要です。テストを先に書いたことがないチームはXPのペースに圧倒されるかもしれません。段階的な導入、まずはCIとコーディング標準から始めることが、12のプラクティスを一度に採用するよりもうまく機能する傾向があります。
要件が固定されて変わらない場合。 XPの価値は適応性から来ます。契約がすべての要件を事前に定義し、変更にペナルティが課される場合、XPの柔軟性は無駄になり、計画駆動のアプローチがプロジェクトにより適するかもしれません。
チームでXPを導入する方法
XPは段階的に導入するのが最善です。12の新しいプラクティスを一夜にしてチームに押し付けることはほとんど定着しません。
ステップ1：コーディング標準に合意する
何より先に、チームは1つの共有コーディングスタイルに揃え、リンティングまたはフォーマットツールを通じて強制します。これは摩擦が少なく、XPの残りが構築される共有理解を生み出します。
ステップ2：継続的インテグレーションを導入する
すべてのコミットで自動テストを実行するCIパイプラインをセットアップします。最初はテストスイートが小さくても、頻繁にインテグレーションし、失敗を即座に修正する習慣が、チームが作業について考える方法を変えます。
ステップ3：複雑な作業にペアプログラミングを始める
最初から全タスクにペアを義務付けないでください。最も複雑またはリスクの高い作業から始めます。チームは問題がいかに素早く検出されるかを見ると、より多くペアリングしたいと思うことが多いです。
ステップ4：テスト駆動開発を段階的に採用する
1つの新しい機能を選んでTDDで一から構築します。欠陥率とリファクタリングの自信を、従来の方法で構築された機能と比較してください。証拠は通常、どんな主張よりも懐疑論者を説得します。
ステップ5：計画サイクルに顧客担当者を参加させる
プランニングゲームは、本物のプロダクト権限を持つ人が参加して初めて機能します。専用のオンサイト顧客が現実的でない場合は、ビジネスステークホルダーがストーリーをレビューし、質問に答え、完成したユーザーストーリーを受け入れる定期的なリズム（週次または隔週）を確立します。明確な受け入れ基準と共有のDefinition of Doneとペアにしてください。
XP対Scrum
XPとScrum はどちらもアジャイルですが、異なるレベルで機能します。多くのチームが両方を同時に実行しています。
| 次元 | XP | Scrum |
|---|---|---|
| フォーカス | エンジニアリングプラクティスとコード品質 | チームプロセスと Sprint 管理 |
| イテレーション期間 | 1週間（通常） | 1〜4週間（Sprint） |
| 技術プラクティスの規定 | あり（TDD、CI、ペアプログラミングなど） | なし |
| 役割 | 開発者、顧客、コーチ | Product Owner、Scrum Master、開発チーム |
| 顧客の関与 | オンサイト担当者がフルタイム | Product Owner が Sprint セレモニーに参加 |
| イテレーション中の変更 | 小さければ許可 | 一般的に Sprint 中は非推奨 |
| 一般的な組み合わせ | Scrum Sprint 内のXPエンジニアリングプラクティス | 同じ |
Scrumを実行しているチームは、Sprint 内でTDDやCIなどのXPプラクティスを採用することが多いです。Scrum は管理ラッパーを提供し、XPはエンジニアリング規律を提供します。この組み合わせは「Scrum/XP」と呼ばれることもあり、実際に最も一般的なアジャイル設定の1つです。
アジャイルアプローチの組み合わせにさらに柔軟性が必要なチームは、Scrum のリズムに Kanban スタイルのフロー管理を取り入れたScrumbanを使用することがあります。単一チームを超えて拡張する組織には、Scaled Agile Framework (SAFe)がチームレベルのXPプラクティスを収容しながら上位の調整レイヤーを追加できます。
よくある質問
Extreme Programmingは今日でも使われていますか？
はい。XPのプラクティスは非常に健在であり、しばしばXPと明示的には呼ばないScrum チームの中に組み込まれています。継続的インテグレーション、TDD、ペアプログラミングは、XPが2000年代初頭にその価値を証明したことから、現代のソフトウェア開発の標準的なプラクティスになっています。
XPとScrum を組み合わせることはできますか？
もちろんです。多くのチームがそうしています。Scrum は Sprint 構造、セレモニー、バックログ管理を担当します。XPはそれらの Sprint 内でコードが実際にどのように書かれてテストされるかを担当します。2つのフレームワークは競合するのではなく、補完的です。
XPのプランニングゲームとは何ですか？
プランニングゲームはXPのイテレーション計画へのアプローチです。顧客は自分たちのニーズを説明するストーリーを書き、開発者は工数を見積もります。一緒に次のイテレーションに何が収まるかを決めます。Scrum のスプリントプランニングセッションと似ていますが、顧客がスコープを決定する上でより積極的なリアルタイムの役割を果たします。
XPはフルタイムのペアプログラミングを必要としますか？
必ずしもそうではありません。XPはほとんどの本番コードでペアプログラミングを推奨しますが、多くのチームはそれを選択的に、特に複雑、高リスク、または不慣れな作業に適用します。目標はより多くの問題により多くの目を向けることであり、ルールへの厳格な遵守ではありません。
TDDとユニットテストの違いは何ですか？
ユニットテストとは、すでに存在するコードを検証するためにテストを書くことを意味します。TDDはその順序を逆にします。まず（失敗する）テストを書き、次にそれを通過する最小限のコードを書き、その後設計をクリーンアップします。この順序が重要なのは、コードを書く前にコードが何をすべきかを考えることを強制するからです。
まとめ
XPは利用可能な最も技術的に厳格なアジャイル手法のひとつです。そのプラクティスが時の試練に耐えてきたのは、ソフトウェア品質問題の根本原因、つまり遅いインテグレーション、テストの欠如、過度に複雑な設計、不十分なコミュニケーションに直接対処しているからです。XPを真剣に取り組むチームは、変更しやすく、テストしやすく、引き継ぎやすいコードを生み出す傾向があります。
1つまたは2つのプラクティスから始め、影響を測定し、そこから積み上げていきます。12のプラクティスの完全なセットは目的地であり、出発点ではありません。
関連記事
Senior Operations & Growth Strategist