エクストリーム・プログラミング

出典: フリー百科事典『ウィキペディア（Wikipedia）』

エクストリーム・プログラミング(Extreme Programming, XP)は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法であり、特にビジネス上の要求が刻々と変わるような状況に向いた開発手法である。1999年に書籍Extreme Programming Explained - Embrace Change(邦訳XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法)によって発表された。

XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。

XPは比較的少人数の開発にもっとも適用しやすく、10～12個からなる具体的なプラクティス(実践)が定義されている。XPはドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。

[編集] XPの背景

XPは、既存の開発方法論に対するアンチテーゼとしてみることができる。既存の開発手法においては、SPA、CMM(能力成熟度モデル)にもとづく厳格なソフトウェア開発手法、あるいは重量開発手法(この名称は軽量開発手法論者によって使用され始めたのもので異論がある)が用いられてきた。ここでは、ドキュメントが重視され、正しいソフトウェアを作るためには仕様が正しく定義されて、正しい手順（たとえば仕様凍結など）を踏む必要があるとされてきた。しかし、現実のソフトウェア開発においては、このような前提のもとでの開発は数限りなく失敗を引き起こしてきた。

ケント・ベックらは、書籍Extreme Programming Explained - Embrace Changeの副題(変化を抱擁せよ)にあるように、このようなソフトウェア開発に伴う変化を、確定させて凍結しようとするのではなく、当然あるべきものとして積極的に対応できることを目指した。実際、XPが台頭した1990年代後半のアメリカでは、IT革命のもとで、ECサイトを代表とする日々刻々とビジネス条件が変化する、開発スピードが最優先であるような状況が生まれていた。そうではなくても、ソフトウェア開発全般にダウンサイジング・オープン化の潮流の元で、難易度の高い短期開発が必要となっていた。そのような状況下でXPは一つのブームを生むことになる。

[編集] XPと４つの価値

XPでは、そのすべての原理となる４つの価値が存在する。それは、

コミュニケーション
シンプル
フィードバック
勇気

である。これら４つの価値は各プラクティスに影響を与え、XPの根幹をなす。

[編集] XPのプラクティス

XPには、開発チームが行うべきいくつかのプラクティス(習慣、実践)が定められている。これらのプラクティスを実行することが、XPを実行することと言える。

初期では12のプラクティスがあったが、数度の改定を得て数が増え、対象者の立場ごとに4種類に分類されるようになった。しかし本質的には変化することなく、その内容をより理解しやすくするための改定となっている。

共同のプラクティス
- 反復
  
  開発を反復から構成する（⇒反復型開発）。全体の開発期間はイテレーションと呼ぶ１～２週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返す。またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。このように反復によって、徐々に完全なシステムを構築していく手法を取る。このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。
- 共通の用語
  
  用語集を作成し、チーム全員（開発者・管理者・顧客）の使用する用語とその概念の不一致を解消する。
- 開けた作業空間
  
  会話しやすく、作業に打ち込める雰囲気を作る。
- 回顧(頻繁な振り返り)
  
  現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境、体制を構築しておく。
開発のプラクティス
- テスト駆動開発
  
  実装を行うより先に、自動化されたテストないしは手順の明確化されたテストを作成する。実装はそのテストをパスすることを目標に行う。テストを先に作成することで、求める機能が明確化され、シンプルな設計が可能になる。
- ペアプログラミング
  
  二人一組で実装を行い、一人が実際のコードを書き、もう一人はそれをチェックしながらナビゲートする。この役割を随時交代しながら作業を進める。これによって、細々した問題解決に要する時間が短かくなる、常にコードレビューを行うことができる、集中力が持続する、コードの詳細を理解したメンバーが常に２人以上いることで後々のコード共有に役立つ、などの多彩な効果が得られる。
- リファクタリング
  
  完成済みのコードでも、随時、改善処置を行う。この際、外部から見た動作は変更させずに、内部構造がより見通し良く優れたものになるようにする。テストが作成されていることが前提になる。
- ソースコードの共同所有
  
  誰が作ったソースコードであっても、開発チーム全員が断り無く修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。
- 継続した結合
  
  単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。少なくとも一日に一回は、結合テストを行う。
- YAGNI
  
  You Aren't Going to Need It.（今必要なことだけ行う）。先の事を考えて、前払い的に機能を増やし、実装を複雑化させる事は避ける。むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。このことで後のイレギュラーな変更に対応しやすいようにする。
管理者のプラクティス
- 責任の受け入れ
- 援護
- 四半期毎の見直し
- ミラー
  
  今どういう状態かをチームに知らせる。
- 最適なペースの仕事
  
  知的作業には週40時間の労働時間が最適である。特にXPでは、集中力を高めて効果を生む事を重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適さない。そのため、計画的に開発スピードの調整を行う。
顧客のプラクティス
- ストーリーの作成
  
  求める機能のコンセプトを短い文章で記したストーリーカードを作成する。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。
- リリース計画
  
  どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。
- 受け入れテスト
  
  イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。もし満足できない場合は、それを指摘する。
- 短期リリース

これらの個々のプラクティスが、お互いを補いあい補強しあう事で、XPという一つの方法論を成り立たせている。

しかし、ソフトウェア業界の現状においては、この全てのプラクティスを同時に実行することは非常に困難であるため、テスト駆動開発やリファクタリングなど、単独でもある程度有効なプラクティスだけが、一部導入されているケースが多い。

[編集] XPとプログラマ

XPを熱狂的に受け入れたのはプログラマであった。 XPは、ドキュメントを不要だとはしていないまでも、ソースコードを重視する。また、中長期的な計画に従うことよりも、こまかく計画を見直し修正していくことを行う（逆に、このような特徴は、XPがプロジェクト管理者にとっては採用に二の足を踏む一つの要因であった）。また、XPではユニットテストと呼ばれる、プログラムコードとテストコードを表裏一体、一体的に同時に開発していく。プログラマがXPを好む理由は、このようなプログラマの不安を解消する仕掛けを具体的なプラクティスとしてさまざまに備えているためである。