【ソフトウェア開発技術】変化を抱擁するアジャイルの雄！「エクストリームプログラミング（XP）」｜情報処理問題1000本ノック
仕様変更やトラブルは開発の「敵」ではなく、当然起こる「前提」である。そんな逆転の発想から生まれたアジャイル開発手法の代表格「エクストリームプログラミング（XP）」の行動指針と特徴を攻略しましょう。
1. 【 問題 】：ソフトウェア開発プロセス（XPの特徴とプラクティス）
【 問題 】 アジャイル開発手法の一つである「エクストリームプログラミング（XP）」の特徴や、実践すべき行動指針（プラクティス）として、不適切なものはどれでしょうか？
(ア) 継続的なインテグレーション（CI）の実施
(イ) 最初から正しく行う（完璧な初期設計）
(ウ) 短期間でのリリース
(エ) 反復（イテレーション）型の開発
2. 正解：
正解： (イ) 最初から正しく行う
3. 解説：「完璧なフライング」よりも「柔軟な修正」を重視する
エクストリームプログラミング（XP）は、「変化を受け入れる（Embrace Change）」をスローガンに掲げる開発手法です。
従来のウォーターフォール開発のように「最初の設計段階で100%完璧（正しく）に仕様を決め、その通りに作る」という一発勝負のやり方を否定します。XPでは、最初は必要最小限のシンプルなコードを書き、プログラムを頻繁に合体させて自動テストする「継続的インテグレーション（CI）」や、数週間単位の「短期間でのリリース」「反復型開発」を繰り返すことで、徐々にシステムを正しく育てていきます。
| プラクティス名 | 具体的な開発の行動・ルール |
|---|---|
| テスト駆動開発（TDD） | プログラムを書く前に、まずそのプログラムの「テストコード」を先に作成する。 |
| ペアプログラミング | 1台のPCの前に2人のプログラマが座り、1人がコードを書き、もう1人がチェックする。 |
| リファクタリング | プログラムの動き（外部仕様）を変えずに、内部のソースコードを綺麗に整理する。 |
| 継続的インテグレーション | 作ったコードを1日に何度もメインシステムに合体させ、自動テストでバグを即時発見する。 |
1. 理解のコツ: 「車の運転」に例えてみましょう。
・「最初から正しく行う」というのは、『東京から大阪まで運転する際、出発前に全ての交差点の信号のタイミングや、前の車の動きを完璧に予測し、ハンドルを1ミリも修正せずに目的地に到着しようとする』ようなものです。現実には絶対に不可能です。
・XPの思想は、『とりあえず出発し、道が曲がっていたらハンドルを切り、前の車が止まったらブレーキを踏む（＝リファクタリングや仕様変更に対応する）』という柔軟な運転です。小さな反復（イテレーション）を繰り返し、常にテストという「カーナビ」で現在地を確認しながら進むため、最初の段階で完璧を目指す必要はありません。この『変化にその都度、爆速で適応していく』というスタンスがXPの真髄です。
2. 試験対策の視点: ITパスポート、基本情報技術者、応用情報技術者の開発技術分野において、アジャイル開発の具体的な手法として定番の出題です。問題文の「不適切なもの」として、今回のように「最初から完璧に」「最初の段階で詳細な仕様決定を」「厳格な計画遵守」といった、ウォーターフォール型の特徴が混入するパターンが非常に多いです。
また、XPに関する問題では、上の表に挙げた「テスト駆動開発」「ペアプログラミング」「リファクタリング」といった『具体的なプラクティスの名前と中身の組み合わせ』が単独の4択問題として直接狙われます。これらは一見すると「やりすぎ（極端＝Extreme）」に見えるルールですが、これらを徹底することでチーム全体の開発速度と品質を爆発的に高めることができる、というXPならではのユニークな特徴をセットで覚えておきましょう。
4. まとめ
「最初の設計段階での完璧（正しく行うこと）を目指さず、数週間単位の短期間の反復開発、テスト駆動開発、継続的インテグレーションなどを駆使して、仕様変更に柔軟に対応していくアジャイル開発手法」。これがエクストリームプログラミング（XP）です。アジャイル開発ならではの「変化を前提とする」という思想の根底を、しっかりと記憶に刻んでおきましょう！