対象試験と出題頻度
XP(エクストリームプログラミング)は、基本情報技術者・応用情報技術者で出題されるテーマです。
アジャイル開発の代表的手法として、スクラムとの違いや、ペアプログラミング・テスト駆動開発(TDD)・リファクタリングといったプラクティスを正しく区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB(標準)覚えておくと有利
用語の定義
情報処理試験を勉強していると、「XPって聞いたことはあるけど、結局スクラムと何が違うの?」と混乱しがちです。
XP(エクストリームプログラミング/Extreme Programming)とは、一言で言うと
「変更を歓迎し、短いサイクルで動くソフトウェアを作り続けるアジャイル開発手法」
のことです。
イメージとしては、「毎日味見しながら作る料理」です。
レシピを最初に完璧に決めて最後まで突っ走るのではなく、一口作っては味見し、足りなければ調味料を足し、必要なら作り直す。お客さんの好みが途中で変わっても柔軟に対応する。これがXPの考え方です。
1999年にKent Beck(ケント・ベック)氏が提唱した手法で、「うまくいくプラクティスを”極端(Extreme)”なまでに徹底する」という発想から名付けられました。
📊 XPの基本情報
| 項目 | 内容 |
|---|---|
| 正式名称 | eXtreme Programming(エクストリームプログラミング) |
| 提唱者 | Kent Beck(ケント・ベック)/1999年 |
| 分類 | アジャイル開発手法の一種 |
| 適した規模 | 少人数(10名程度まで)のチーム開発 |
| 5つの価値 | コミュニケーション・シンプルさ・フィードバック・勇気・尊重 |
解説
従来のウォーターフォール開発では、要件定義から設計・実装・テストまでを順序通りに進め、後戻りを極力避ける考え方が主流でした。
しかし、ビジネス環境の変化が速くなった現代では、開発途中で「やっぱりこの機能を変えたい」というニーズが頻繁に発生します。
変更を「コスト」ではなく「歓迎すべきもの」として扱うために生まれたのがXPです。
5つの価値(Values)
XPの土台には、チームが共有すべき5つの価値観があります。
| 価値 | 意味 |
|---|---|
| コミュニケーション | 対面の対話でメンバー・顧客と密に情報共有する |
| シンプルさ | 今必要なものだけを作る(YAGNI原則:You Aren’t Gonna Need It) |
| フィードバック | 短いサイクルで結果を確認し、次の判断材料にする |
| 勇気 | 問題があれば設計を捨てて作り直す決断ができる |
| 尊重 | メンバー同士・顧客との相互信頼(後年に追加) |
主要プラクティス(試験頻出)
XPには十数個のプラクティス(具体的な実践方法)があります。試験で頻出のものを押さえます。
| プラクティス | 内容 |
|---|---|
| ペアプログラミング | 2人1組で1台のPCを使って実装。1人が書き、1人がレビューしながら進める |
| テスト駆動開発(TDD) | テストコードを先に書き、それを通すように本体コードを実装する |
| リファクタリング | 外部から見た振る舞いを変えずに、内部構造を改善する |
| 継続的インテグレーション | コードを頻繁に統合し、自動ビルド・自動テストで品質を保つ |
| 小さなリリース | 短いサイクルで動くソフトウェアを顧客に届け続ける |
| オンサイト顧客 | 顧客が開発チームと同じ場所に常駐し、即座に質問・判断ができる |
| 共同所有 | コードはチーム全員のもの。誰でも修正してよい |
| YAGNI | 「今必要ないものは作らない」という原則 |
図解:XPの開発サイクル
XPの短いイテレーションサイクル
繰り返し回す
ゲーム
を書く
実装
クタリング
リリース
▲ 時計回りに①→②→③→④→⑤と進み、再び①へ戻る(数日〜2週間程度の周期)
テスト駆動開発(TDD)の流れをコードで体感
XPの中核プラクティスであるTDDは「Red→Green→Refactor」の3ステップで進めます。簡単な例で示します。
# ① Red:失敗するテストを先に書く
def test_add():
assert add(2, 3) == 5 # ← まだ add 関数は無い。当然失敗
# ② Green:テストを通す最小限のコードを書く
def add(a, b):
return a + b # ← テストが通る
# ③ Refactor:振る舞いを変えずに整える
def add(a: int, b: int) -> int:
"""2つの整数の和を返す"""
return a + b # ← 型ヒントとdocstringを追加
スクラムとの違い
| 観点 | XP | スクラム |
|---|---|---|
| 重点 | 技術プラクティス(実装の質) | プロジェクト管理(進め方の枠組み) |
| イテレーション | 1〜2週間 | 1〜4週間(スプリント) |
| 役割 | 顧客・開発者・コーチ等 | PO・スクラムマスター・開発チーム |
| 変更受け入れ | イテレーション中でも歓迎 | スプリント中は原則固定 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 XPの核心を3行で
・1999年にKent Beckが提唱した、変更を歓迎するアジャイル開発手法
・5つの価値(コミュニケーション・シンプルさ・フィードバック・勇気・尊重)が土台
・代表的プラクティスはペアプログラミング・TDD・リファクタリング・継続的インテグレーション
試験ではこう出る!
XPはFE・APの午前問題で、開発手法の選択肢の1つとして繰り返し登場します。出題パターンは大きく2つです。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H30秋 午前 問50 |
XPのプラクティスとして適切なものを選ぶ問題。 | ・「ペアプログラミング」が正解 ・スパイラル開発・段階的詳細化等がひっかけ |
| AP H29春 午前 問49 |
XPのプラクティスのうちリファクタリングの説明を選ぶ問題。 | ・「外部から見た振る舞いを変えずに内部構造を改善」が正解 ・テスト駆動開発・継続的インテグレーションの説明と混同させる |
| AP H27春 午前 問50 |
XPで導入が推奨されるテストファースト開発の効果を問う問題。 | ・テストコードを先に書くことの目的を理解しているか ・TDDのRed-Green-Refactorの流れ |
| FE R元秋 午前 問50 |
アジャイル手法の中からXPの特徴を選ぶ問題。 | ・スクラム・リーン開発との区別 ・「テスト駆動」「ペアプロ」のキーワード |
📝 IPA試験での出題パターン
パターン1:「XPのプラクティスを選べ」
4つの選択肢から、ペアプログラミング・TDD・リファクタリング・継続的インテグレーションのいずれかを選ばせる形式。ひっかけとして「段階的詳細化」(構造化技法)、「データ中心アプローチ」、「スパイラルモデル」など別手法の用語が紛れ込みます。
パターン2:「プラクティスの説明を選べ」
リファクタリングを問う場合、「外部から見た振る舞いを変えずに、内部構造を改善する」が正解。「バグを修正する」「機能を追加する」と書かれていたら不正解です。リファクタリングは”動作を変えない”ことが定義の核です。
頻出キーワード:ペアプログラミング、テスト駆動開発(TDD)、リファクタリング、継続的インテグレーション、オンサイト顧客、YAGNI、Kent Beck
プラクティスは十数個ありますが、試験ではここまででOKです。マイナーなプラクティス名(メタファー、計画ゲームなど)まで深追いする必要はありません。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. XP(エクストリームプログラミング)の説明として、最も適切なものはどれでしょうか?
- A. システムを段階的に試作品(プロトタイプ)として作り、利用者の評価を反映しながら最終形に近づけていく開発手法。
- B. 要件定義・設計・実装・テストの各工程を順番に進め、原則として前工程に戻らない開発手法。
- C. 変更を歓迎し、ペアプログラミングやテスト駆動開発などのプラクティスを徹底することで、短いサイクルで動くソフトウェアを作り続けるアジャイル開発手法。
正解と解説を見る
正解:C
解説:
XPはKent Beckが提唱したアジャイル開発手法であり、ペアプログラミング・テスト駆動開発・リファクタリングなどの具体的プラクティスを徹底するのが特徴です。「変更を歓迎」「短いサイクル」「動くソフトウェア」というキーワードがXPを特定する目印です。
選択肢Aはプロトタイピングモデルの説明です。試作品を作って評価を繰り返す手法であり、XPとは別の開発モデルです。選択肢Bはウォーターフォールモデルの説明です。工程を順番に進めて後戻りしない方式であり、変更を歓迎するXPとは正反対の考え方になります。
よくある質問(FAQ)
Q. ペアプログラミングは生産性が半分になりませんか?
行数ベースで見れば一時的に低下しますが、レビューを実装と同時に行うためバグが減り、設計品質が向上します。結果として手戻り工数が削減され、トータルでは同等以上の生産性になるとXPでは主張します。試験では「コードレビューが常時行われる」「知識が共有される」がペアプロのメリットとして問われます。
Q. リファクタリングとデバッグはどう違いますか?
目的が根本的に異なります。デバッグは「バグを取り除いて動作を正しくする」作業であり、振る舞いを変える行為です。一方リファクタリングは「外部から見た振る舞いは変えずに、内部のコード構造だけを改善する」作業です。両者を混同した選択肢が応用情報の頻出ひっかけパターンになっています。
Q. XPは大規模プロジェクトに向いていますか?
向いていません。XPは10名程度までの少人数チームを前提としています。オンサイト顧客や共同所有といったプラクティスは、メンバー全員が密にコミュニケーションを取れる規模でこそ機能するためです。大規模開発ではSAFeやLeSSなどのスケーリングフレームワークを併用するか、別の手法を検討します。
Q. XPの「オンサイト顧客」は現代でも実践されていますか?
原型のまま実践される例は減りました。リモートワークの普及とともに、ビデオ会議やチャットツールを通じて顧客代理(プロダクトオーナーなど)と即時にやり取りする形に進化しています。ただし「顧客との距離を縮めて素早くフィードバックを得る」という思想は、現代のアジャイル開発にも色濃く受け継がれています。
Q. アジャイルソフトウェア開発宣言とXPの関係は?
XPは「アジャイルソフトウェア開発宣言」(2001年)が発表される前から存在した手法で、Kent BeckはこのXP実践者の1人として宣言の起草に参加しました。XPはアジャイルの代表例ですが、アジャイル=XPではありません。アジャイルという大きな傘の下に、XP・スクラム・FDD・リーン開発などが並列に存在する関係です。