XPとは？ペアプログラミング・TDD・リファクタリングを整理【基本情報技術者試験】

まず結論

XP（eXtreme Programming：エクストリームプログラミング）は、短いサイクルで開発と改善を繰り返すアジャイル開発手法の一つです。

基本情報技術者試験では、XPの細かな歴史よりも、代表的なプラクティスを見分けられることが重要です。

特に覚えておきたいのは次の4つです。

2人で一緒にコードを書く
→ ペアプログラミング

テストを先に作る
→ テスト駆動開発（TDD）

動作を変えずにコードを改善する
→ リファクタリング

小さく頻繁に統合する
→ 継続的インテグレーション

科目Aで「XPのプラクティスはどれか」と問われたら、まず ペアプログラミング を強く疑います。

直感的な説明

XPは、完成まで長い期間をかけて一気に作るよりも、小さく作る → テストする → 改善するを何度も繰り返す考え方です。

イメージすると、次のようになります。

小さく作る
↓
すぐにテストする
↓
コードを改善する
↓
また小さく作る

その中でも分かりやすいのが、ペアプログラミングです。

2人1組で作業し、1人がコードを書き、もう1人が内容を確認しながら進めます。役割は固定ではなく、交代しながら開発します。

1人：コードを書く
もう1人：内容を確認する
↓
役割を交代
↓
常にレビューしながら開発

つまり、XPでは開発しながら品質を高める仕組みを日常の作業に組み込んでいます。

定義・仕組み

XPは、1990年代にKent Beckらによって提唱されたソフトウェア開発手法で、アジャイル開発の代表的な考え方の一つです。

XPでは、ソフトウェア開発に有益な実践をプラクティスとして整理します。

試験対策では、すべてを暗記するより、代表的なものを役割で分けて覚えると判断しやすくなります。

プラクティス	何をする？	試験でのキーワード
ペアプログラミング	2人1組で実装する	2人、交代、レビューしながら実装
テスト駆動開発	テストを先に作ってから実装する	テスト先行
リファクタリング	外から見た動作を変えず内部構造を改善する	動作を変えず改善
継続的インテグレーション	頻繁にコードを統合しテストする	頻繁な統合
計画ゲーム	顧客と開発側で機能の優先順位やリリース計画を決める	顧客、優先順位、リリース計画
コーディング標準	チームでコードの書き方を統一する	命名・記述ルール、共有しやすいコード
ソースコードの共同所有	特定の人だけでなくチームでコードを扱う	共同所有
短期リリース	小さな単位で早く提供する	短いサイクル
YAGNI	今必要でない機能を先回りして作らない	必要になってから作る

XPでは、このような具体的な開発行動を組み合わせて、変更への対応力と品質を高めます。

共通フレームとは？システム開発プロセスを共通の言葉で整理する考え方が開発活動をプロセスとして整理する枠組みなのに対して、XPは開発チームが実際にどのように作業するかに重点を置く手法です。

基本情報技術者試験の公式な出題範囲やシラバスは、IPA：基本情報技術者試験から確認できます。

科目Aでどう出る？

科目Aでは、XPそのものの定義よりも、複数のプラクティスの説明から該当するものを選ばせる問題や、開発手法・設計手法・レビュー手法の中からXPのプラクティスを選ばせる問題として出やすいです。

判断するときは、次の順番で考えます。

その選択肢は
「実際の開発作業のやり方」か？
↓
XPらしい短い反復・テスト・共同作業か？
↓
説明のキーワードは何か？

特に次の対応を覚えておくと、選択肢を切りやすくなります。

2人で実装・役割を交代
→ ペアプログラミング

テストを先に書く
→ テスト駆動開発

内部構造だけ改善
→ リファクタリング

頻繁に統合
→ 継続的インテグレーション

顧客と優先順位・リリースを相談
→ 計画ゲーム

コードの書き方を統一
→ コーディング標準

今回のように、選択肢がすべてXPに関係している場合もあります。

その場合は「XPかどうか」ではなく、どのプラクティスの説明かまで見分ける必要があります。

用語	判断の決め手
ペアプログラミング	2人1組、役割交代、実装しながら確認
テスト駆動開発	テストを先に作る
計画ゲーム	顧客と優先順位・リリース計画を決める
コーディング標準	チームでコードの書き方を統一する
インスペクション	レビュー手法
構造化設計	構造化手法
ユースケース	要求・機能を利用者視点で整理する手法

つまり、「アジャイルっぽいか」だけではなく、「説明文の中心動作は何か」を見ることがポイントです。

どんな場面で使う？

XPは、要求変更が起こりやすく、短いサイクルで改善しながら開発したい場面と相性がよい考え方です。

例えば、次のような状況です。

利用者からのフィードバックを早く反映したい
小さな単位で頻繁にリリースしたい
テストを繰り返しながら品質を高めたい
コードをチーム全体で共有したい
仕様変更に対応しやすいコードを保ちたい

ペアプログラミングやリファクタリング、継続的インテグレーションを組み合わせることで、問題を早く見つけ、変更しやすい状態を保ちます。

よくある誤解・混同

❌ ペアプログラミングは、完成後に2人でレビューする手法

違います。

ペアプログラミングは、実装している最中から2人で作業するのがポイントです。

実装後に別の人がレビュー
→ 一般的なコードレビュー

実装中から2人で作業
→ ペアプログラミング

❌ 計画ゲームは、2人でコードを確認しながら実装する

違います。

計画ゲームは、顧客と開発側が機能の優先順位やリリース計画を相談するプラクティスです。

顧客と優先順位・リリースを相談
→ 計画ゲーム

2人で役割を交代しながら実装
→ ペアプログラミング

❌ コーディング標準は、2人で相互にコードをチェックすること

違います。

コーディング標準は、チームでコードの記述ルールをそろえることです。

「共同で開発しやすくする」という目的は近くても、役割交代して実装するペアプログラミングとは別です。

❌ インスペクションはXPの代表的プラクティス

インスペクションはレビュー手法です。

「複数人で確認する」という点は似ていますが、XPの代表的なプラクティスとして問われた場合はペアプログラミングと切り分けます。

❌ リファクタリングは機能を追加する作業

違います。

リファクタリングは、外から見た動作を変えずに内部構造を改善する作業です。

新機能を追加
→ 機能変更

動作は同じままコードを整理
→ リファクタリング

❌ テスト駆動開発は、実装が終わってからテストを書く

逆です。

テスト駆動開発では、まずテストを書き、そのテストを満たすコードを実装します。

❌ ユースケースを使えばXPである

ユースケースは、利用者とシステムのやり取りを整理する考え方です。

XP固有の代表的プラクティスではありません。

原典・一次資料で確認する

XPはKent Beckらによって発展したアジャイル開発手法です。XPの公式サイトでは、Values・Practicesなどが整理されています。

Extreme Programming公式サイト

また、XPはアジャイルソフトウェア開発宣言につながる代表的な開発手法の一つです。

FE試験ではXPの歴史を覚えるより、ペアプログラミング・テスト・リファクタリング・継続的インテグレーションなど、具体的なプラクティスを見てXPを判断することを優先します。

まとめ（試験直前用）

XPは、短いサイクルで開発・テスト・改善を繰り返すアジャイル開発手法
2人1組・役割交代・実装しながら確認 → ペアプログラミング
テストを先に作る → テスト駆動開発
動作を変えず内部構造を改善 → リファクタリング
頻繁に統合・テスト → 継続的インテグレーション
顧客と優先順位・リリース計画を相談 → 計画ゲーム
コードの書き方を統一 → コーディング標準
選択肢がすべてXP関連でも「説明文の中心動作」で切り分ける

Pair programming = XP. 2人で実装しながらレビューし、役割を交代する。

🔗 関連記事

🏠 基本情報技術者トップに戻る