基本情報技術者 2019年 秋期 午前（科目A） 問50

XP(eXtreme Programming)において、プラクティスとして提唱されているものはどれか。【午前2 解説】

要点まとめ

• 結論: XPのプラクティスにはペアプログラミングが含まれ、継続的テストやリファクタリングと組み合わさって品質向上と知識共有を実現します。
• 根拠: XPは軽量なアジャイル手法で、具体的な実践（ペアプログラミング、TDD、継続的インテグレーション等）を明示的に推奨する点が特徴です。
• 差がつくポイント: 選択肢の用語が「XP固有のプラクティスかどうか」を判断基準にし、実践的なチーム作業を示すものを選びます。

正解の理由

よくある誤解

• 「コードレビュー＝XPのインスペクション」と混同する誤解：XPは形式的なインスペクションよりペアプログラミングの継続的な共同作業を重視します。
• 「ユースケースや構造化設計はXPのプラクティス」：それらは要求分析や設計手法であり、XPが特に推奨する日常的なプラクティス群とは性格が異なります。
• 「ペアプログラミングは全ての状況で効率が良い」と考える誤り：効果はチーム・タスクに依存し、コストと効果を評価して採用すべきです。

解法ステップ

1. 問題文から対象が「XP（eXtreme Programming）」であることを確認します。
2. XPの代表的プラクティス（ペアプログラミング、TDD、継続的インテグレーション等）を頭に思い浮かべます。
3. 各選択肢が「日常的な開発プラクティス（XPが明示的に推奨）」か、それとも別のカテゴリ（設計手法、分析手法、品質保証手段）かを分類します。
4. XPのプラクティスに該当する選択肢を選びます → ペアプログラミング（ウ）。

選択肢別の誤答解説

• ア: インスペクション
  • 説明: インスペクションは形式的なレビュー手法で、ウォーターフォールや従来の品質保証で多用されます。XPはインスペクションよりもペアプログラミングなどの継続的な協働を重視するため、XP固有のプラクティスとは言えません。
• イ: 構造化設計
  • 説明: 構造化設計は伝統的な設計技法の一種で、XPが掲げる「シンプル設計」は別概念です。構造化設計自体はXPのプラクティスには含まれません。
• ウ: ペアプログラミング
  • 説明: XPの代表的プラクティスの一つで、二人一組で共同作業しコード品質とナレッジ共有を図る手法です。したがって正解は ウ です。
• エ: ユースケースの活用
  • 説明: ユースケースは要求記述の手法であり、XPが特にプラクティスとして明示するものではありません（XPはユーザーストーリーなど軽量な要求管理を好む）。

補足コラム

FAQ