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らしい短い反復・テスト・共同作業か？

特に次のキーワードはXPを強く示します。

2人で実装
→ ペアプログラミング

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

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

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

一方、次のような用語はXPそのもののプラクティスとは切り分けます。

用語	見る方向
インスペクション	レビュー手法
構造化設計	構造化手法
ユースケース	要求・機能を利用者視点で整理する手法
ペアプログラミング	XPの代表的プラクティス

つまり、「アジャイルっぽいか」だけではなく、「XPの具体的な実践か」を見ることがポイントです。

どんな場面で使う？

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

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

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

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

よくある誤解・混同

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

違います。

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

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

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

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

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

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

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

違います。

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

新機能を追加
→ 機能変更

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

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

逆です。

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

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

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

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

まとめ（試験直前用）

XPは、短いサイクルで開発・テスト・改善を繰り返すアジャイル開発手法
2人1組で実装する → ペアプログラミング
テストを先に作る → テスト駆動開発
動作を変えず内部構造を改善 → リファクタリング
頻繁に統合・テスト → 継続的インテグレーション
インスペクションはレビュー手法、構造化設計は構造化手法、ユースケースは要求・機能を整理する手法
科目Aでは「XPの具体的なプラクティスか」で選択肢を切る

Pair programming = XP. 2人で実装しながらレビューする。

🔗 関連記事

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