エクストリーム・プログラミング（XP）入門｜初版→第2版で何が変わったのか

この記事の対象読者

• TDDやペアプロは知っているが、XPを体系的に学んだことがない方
• 「XPの12のプラクティス」は聞いたことがあるが、第2版で再構成されたことを知らない方
• アジャイル開発の歴史的背景を理解したい方

はじめに

「TDDはやっているけど、エクストリーム・プログラミングの本は読んだことがない」

「ペアプロやCIは知っているけど、それがXPの一部だとは意識していなかった」

こういう開発者は多いのではないでしょうか。実際、TDD、ペアプログラミング、継続的インテグレーション（CI）、リファクタリング。これらはすべてXPのプラクティスとして体系化されたものです。個々のプラクティスは広く普及しましたが、それらを束ねるXPという思想体系を知る開発者は意外と少ないのが現状です。

さらに、「XPのプラクティス」として語られるものの多くは1999年の初版に基づいています。しかし、Kent Beckは2004年の第2版でプラクティスの構成を大幅に変更しました。この変更は「XPの成熟」を反映したものですが、あまり知られていません。

この記事では、Kent Beckの原著を一次情報として、XPの全体像を初版→第2版の変遷とともに解説します。

XPの誕生 — C3プロジェクトとKent Beck

Chrysler C3プロジェクト

XPの起源は、1996年にさかのぼります。

Kent Beckは、Chrysler社の給与計算システム「C3（Chrysler Comprehensive Compensation System）」プロジェクトに参加しました。このプロジェクトは、既存のCOBOLシステムをSmalltalkで再構築するものでした。

Beckはこのプロジェクトで、それまで個別に実践されていた開発手法（テストファースト、ペアプログラミング、短いリリースサイクルなど）を1つの統合された方法論として結びつけました。そして、各プラクティスを「極端に（Extreme）」徹底することで、ソフトウェア開発のベストプラクティスを最大限に活用する手法を確立しました。

なお、C3プロジェクトの拠点はデトロイト（ミシガン州）でした。これは後にテスト駆動開発の流派を語るときに「デトロイト派」の名前の由来となります。テスト流派の詳細については以下の記事で詳しく解説しています。

「エクストリーム」の意味

XPの命名について、Beckは初版の中で次のように説明しています。

If code reviews are good, we'll review code all the time (pair programming). If testing is good, everybody will test all the time (unit testing), even the customers (functional testing). If design is good, we'll make it part of everybody's daily business (refactoring). （コードレビューが良いなら、常にレビューしよう（ペアプログラミング）。テストが良いなら、全員が常にテストしよう（ユニットテスト）、顧客さえも（機能テスト）。設計が良いなら、それを全員の日常業務にしよう（リファクタリング）。）

― Kent Beck『Extreme Programming Explained』初版、Chapter 1

つまり「エクストリーム」とは過激という意味ではなく、良いプラクティスを極限まで徹底するという思想を表しています。

初版の出版（1999年）

1999年、Beckは『Extreme Programming Explained: Embrace Change』を出版しました。副題の「Embrace Change（変化を抱擁せよ）」が象徴するように、XPは変化を敵ではなく味方にすることを基本姿勢としています。

この書籍は、ソフトウェア開発方法論のあり方を変える1冊となりました。2年後の2001年には、BeckはMartin Fowler、Robert C. Martin、Ward Cunninghamらと共に「アジャイルソフトウェア開発宣言」に署名。XPはアジャイルムーブメントの中核的存在となりました。

初版XPの構造 — 4つの価値と12のプラクティス

初版のXPは、4つの価値（Values） を土台に、12のプラクティス（Practices） で構成されています。

4つの価値

Beckは、プラクティスの根底にある思想を「価値」として定義しました。

価値	概要
コミュニケーション（Communication）	チーム内の情報共有を最大化する。問題の多くはコミュニケーション不足に起因する
シンプリシティ（Simplicity）	「今必要なもの」だけを作る。将来の想定で複雑にしない
フィードバック（Feedback）	素早くフィードバックを得て、方向を修正する。テスト、短いリリース、顧客との対話
勇気（Courage）	動いているコードを捨てる勇気。問題に正面から向き合う勇気

12のプラクティス

初版では、以下の12のプラクティスが定義されています。

#	プラクティス	概要
1	計画ゲーム（Planning Game）	ビジネス側と技術側が協力してリリース計画を立てる
2	小さなリリース（Small Releases）	短いサイクルで動くソフトウェアをリリースする
3	メタファー（Metaphor）	システム全体を表す共通の比喩を使って設計を導く
4	シンプルな設計（Simple Design）	現在の要求を満たす最もシンプルな設計を選ぶ
5	テスト（Testing）	プログラマは単体テストを書き、顧客は機能テストを書く
6	リファクタリング（Refactoring）	振る舞いを変えずにコードの構造を改善する
7	ペアプログラミング（Pair Programming）	2人1組でコードを書く。常時コードレビューの実現
8	共同所有（Collective Ownership）	誰でもどのコードでも変更できる
9	継続的インテグレーション（Continuous Integration）	1日に何度もコードを統合し、テストを実行する
10	週40時間（40-Hour Week）	持続可能なペースで働く。疲労はバグと判断ミスを生む
11	オンサイト顧客（On-site Customer）	顧客がチームと同じ場所で働く
12	コーディング規約（Coding Standards）	チーム全体で統一されたコーディングルールを使う

初版の特徴は、これら12のプラクティスが相互に補強し合う関係にあることです。Beckの表現を借りれば、プラクティスは単独では脆いが、組み合わせることで強固になります。

たとえば、ペアプログラミング（#7）は共同所有（#8）を支え、共同所有はリファクタリング（#6）を可能にし、リファクタリングはシンプルな設計（#4）を維持し、シンプルな設計はテスト（#5）を書きやすくします。

第2版での変化 — 何が、なぜ変わったのか

2004年、Beckは Cynthia Andres と共著で第2版『Extreme Programming Explained: Embrace Change, 2nd Edition』を出版しました（日本語訳：『エクストリームプログラミング』角征典訳、オーム社、2015年）。

第2版は単なる改訂ではなく、XPの構造そのものを再設計したものです。

変更1：5つ目の価値「リスペクト」の追加

第2版では、4つの価値にリスペクト（Respect） が追加されました。

Every person whose life is touched by software development has equal value as a human being. （ソフトウェア開発に関わるすべての人は、人間として等しい価値を持つ。）

― Kent Beck『Extreme Programming Explained』第2版、Chapter 2

Beckがリスペクトを追加した背景には、XPの実践現場で見えてきた課題があります。初版の4つの価値（コミュニケーション、シンプリシティ、フィードバック、勇気）は技術的なプラクティスを支える価値としては十分でしたが、チームの人間関係を支える価値が欠けていました。

ペアプログラミングで相手の意見を尊重する。顧客の要望を真剣に受け止める。チームメンバーの持続可能なペースを守る。これらはすべて、リスペクトなしには成り立ちません。Beckは第2版で、ソフトウェア開発が本質的に人間の活動であることをより明確に打ち出しました。

変更2：12のプラクティス → 主要プラクティス＋導出プラクティスへの再構成

第2版での最大の構造変更は、プラクティスの分類方法です。

初版の「12のプラクティス」は、すべてが同列に並んでいました。第2版ではこれを、主要プラクティス（Primary Practices） と導出プラクティス（Corollary Practices） の2層に再構成しています。

Beckはこの変更の意図を次のように説明しています。

The primary practices are useful independent of what else you are doing. The corollary practices are likely to be difficult or dangerous without first mastering the primary practices. （主要プラクティスは、他に何をしていようと単独で有用である。導出プラクティスは、主要プラクティスを先に習得していないと困難または危険になりがちだ。）

― Kent Beck『Extreme Programming Explained』第2版、Chapter 8

つまり、初版では「12のプラクティスは相互に補強し合う」と説明していたものを、第2版では依存関係に基づいて明確に優先順位をつけたのです。

初版 → 第2版 対比表

初版（1999年）	第2版（2004年）	変化
価値
コミュニケーション	コミュニケーション	継続
シンプリシティ	シンプリシティ	継続
フィードバック	フィードバック	継続
勇気	勇気	継続
—	リスペクト	追加
プラクティス
計画ゲーム	週次サイクル / 四半期サイクル	具体化・分割
小さなリリース	インクリメンタルデプロイメント（導出）	導出へ移動
メタファー	—（削除）	削除
シンプルな設計	インクリメンタルな設計	名称・概念を変更
テスト	テストファーストプログラミング	より明確に
リファクタリング	インクリメンタルな設計に統合	統合
ペアプログラミング	ペアプログラミング	継続
共同所有	共有コード（導出）	導出へ移動
継続的インテグレーション	継続的インテグレーション	継続
週40時間	いきいきとした仕事	名称変更
オンサイト顧客	チーム全体 / 本物の顧客の参加（導出）	分割・再配置
コーディング規約	—（暗黙の前提に）	独立プラクティスとしては削除
—	同席	新規追加
—	情報満載のワークスペース	新規追加
—	ストーリー	新規追加
—	スラック	新規追加
—	10分ビルド	新規追加

なぜ「メタファー」は削除されたのか

初版で特徴的だった「メタファー」は、第2版で唯一完全に削除されたプラクティスです。

メタファーとは、「システム全体を一つの比喩で表現し、チーム全体の設計理解を共有する」というプラクティスでした。たとえば「このシステムはデスクトップのメタファーで設計する」のように使います。

しかし、実際の現場ではこのプラクティスは使いにくいものでした。適切なメタファーを見つけること自体が難しく、無理に比喩を当てはめると逆に混乱を招くケースが報告されていました。第2版ではメタファーは独立したプラクティスとしては登場せず、設計に関する考え方は「インクリメンタルな設計」の文脈で扱われるようになりました。

主要プラクティス（Primary Practices）の解説

第2版の主要プラクティス13個を解説します。

チーム環境に関するプラクティス

同席（Sit Together）

チーム全員が同じ物理的空間で働く。Beckはこれを「コミュニケーションの帯域幅を最大化する最も簡単な方法」としています。

チーム全体（Whole Team）

プロジェクトに必要なスキルと視点をすべて持つメンバーでチームを構成する。初版の「オンサイト顧客」を拡張し、顧客だけでなくテスター、デザイナーなど必要な役割すべてをチームに含める考え方です。

情報満載のワークスペース（Informative Workspace）

ワークスペースを見るだけでプロジェクトの状態が分かるようにする。タスクボード、バーンダウンチャートなどの可視化。

いきいきとした仕事（Energized Work）

初版の「週40時間」の発展形。名称が変わった理由は、重要なのは「40時間」という数字ではなく持続可能なエネルギーで働くことだとBeckが考えたためです。

開発プラクティス

ペアプログラミング（Pair Programming）

2人1組でコードを書く。初版から継続。常時コードレビュー、知識の共有、集中力の維持を実現します。

ストーリー（Stories）

初版の「計画ゲーム」から派生。顧客が望む機能を短いストーリーとして記述する。後のユーザーストーリーの原型です。

週次サイクル（Weekly Cycle）

週の始めに今週のストーリーを選び、週末までに完了させる。初版の「計画ゲーム」のイテレーション計画を、より具体的な週単位のリズムとして定義しました。

四半期サイクル（Quarterly Cycle）

四半期ごとにプロジェクトの方向性を見直す。週次サイクルとの2層構造で、短期と中期のフィードバックループを構成します。

スラック（Slack）

計画に余裕（スラック）を持たせる。第2版で新規追加されたプラクティスで、過負荷がチームを壊すという初版以降の実践からの学びを反映しています。

10分ビルド（Ten-Minute Build）

ビルドとすべてのテストを10分以内に実行できるようにする。初版にはなかったプラクティスで、CIの実効性を担保する具体的な基準として追加されました。

継続的インテグレーション（Continuous Integration）

コードを頻繁に統合し、テストを自動実行する。初版から継続。現代のCI/CDパイプラインの思想的起源です。

テストファーストプログラミング（Test-First Programming）

コードを書く前にテストを書く。初版の「テスト」をより明確に「テストファースト」として定義しました。これがTDD（テスト駆動開発）の基盤です。

TDDの詳細やテスト流派の違いについては、以下の記事で詳しく解説しています。

テストの全体戦略（単体テスト・結合テスト・E2Eの配分）については、こちらの記事をご覧ください。

インクリメンタルな設計（Incremental Design）

初版の「シンプルな設計」と「リファクタリング」を統合した概念。最初からすべてを設計するのではなく、日々の作業の中で設計を進化させていく。必要なときに必要な設計を行い、不要な複雑さを取り除き続けます。

導出プラクティス（Corollary Practices）の解説

導出プラクティスは、主要プラクティスの習熟を前提として効果を発揮するものです。

#	プラクティス	概要
1	本物の顧客の参加	実際のエンドユーザーをチームに巻き込む
2	インクリメンタルデプロイメント	大規模リリースではなく段階的にデプロイする
3	チームの継続性	チームメンバーを頻繁に入れ替えない
4	チームの縮小	チームの能力向上に合わせて人数を減らし、余った人を新チームに
5	根本原因分析	欠陥が見つかったら、なぜそれが起きたかを追究する
6	共有コード	誰でもどのコードでも改善できる（初版の「共同所有」）
7	コードとテスト	永続的な成果物はコードとテストだけ。ドキュメントは必要最小限
8	単一コードベース	ブランチを最小限にし、メインラインで開発する
9	デイリーデプロイメント	毎日本番にデプロイする
10	交渉によるスコープ契約	固定スコープではなく、スコープを交渉可能にする契約形態
11	利用時払い	使った分だけ支払うビジネスモデル

「デイリーデプロイメント」が導出プラクティスに分類されているのは注目に値します。毎日デプロイするには、テストファーストプログラミング、CI、10分ビルドなどの主要プラクティスがすでに機能していることが前提となるからです。

XPが現代の開発に残したもの

XPが1999年に提唱したプラクティスの多くは、25年以上を経て業界の標準となりました。

当たり前になったプラクティス

XPのプラクティス	現代の姿
テストファースト	TDD、テスト自動化
継続的インテグレーション	CI/CDパイプライン（GitHub Actions等）
リファクタリング	IDEのリファクタリング機能、コードレビュー文化
ペアプログラミング	ペアプロ、モブプログラミング
小さなリリース	アジャイル開発、2週間スプリント
10分ビルド	高速ビルドツール（Vite、esbuild等）

アジャイルマニフェストとの関係

2001年、Kent Beckを含む17人のソフトウェア開発者が「アジャイルソフトウェア開発宣言」に署名しました。XPはアジャイルの中でも最も具体的なプラクティスを持つ方法論です。

アジャイルマニフェストの4つの価値は、XPの思想と強く共鳴しています。

アジャイルマニフェスト	XPとの対応
個人と対話 > プロセスとツール	コミュニケーション、ペアプロ、同席
動くソフトウェア > 包括的なドキュメント	小さなリリース、コードとテスト
顧客との協調 > 契約交渉	チーム全体、本物の顧客の参加
変化への対応 > 計画に従うこと	インクリメンタルな設計、週次サイクル

ScrumとXPの関係

XPとScrumはしばしば比較されますが、競合ではなく補完関係にあります。

• Scrumはプロジェクト管理のフレームワーク。役割（プロダクトオーナー、スクラムマスター）、イベント（スプリント、デイリースクラム）、成果物（プロダクトバックログ）を定義する。何を作り、どう管理するかに焦点を当てる
• XPはエンジニアリングプラクティスの方法論。テストファースト、ペアプロ、CI、リファクタリングなど。どう作るかに焦点を当てる

多くのチームが「Scrumで管理し、XPのプラクティスで開発する」という組み合わせを採用しています。Scrumがプロジェクトのリズムを提供し、XPがコードの品質を保証するという役割分担です。

まとめ

XPは、TDDやペアプロ、CIといった個々のプラクティスの「寄せ集め」ではありません。価値に裏打ちされた、相互に補強し合うプラクティスの体系です。

初版から第2版への変遷は、XPの思想的な成熟を示しています。

	初版（1999年）	第2版（2004年）
価値	4つ	5つ（＋リスペクト）
プラクティス	12（同列）	主要13＋導出11（依存関係で分類）
設計観	シンプルな設計＋リファクタリング	インクリメンタルな設計（統合）
導入姿勢	全プラクティスを一括導入	主要プラクティスから段階的に

第2版で「リスペクト」が追加され、プラクティスに優先順位が付けられたことは、XPが技術的なベストプラクティスの集合から持続可能なチーム開発のための思想体系へと進化したことを物語っています。

個々のプラクティスを「つまみ食い」するだけでも効果はありますが、XPの真価はプラクティス間の相互補強にあります。テストファーストがリファクタリングを支え、ペアプログラミングが知識の共有を促し、CIがフィードバックの速度を上げる。この連鎖こそが、XPの設計思想の核心です。