Sstrhsrtj

エクストリーム・プログラミング、XP（英: extreme programming）は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。1999年に書籍『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』によって発表された。

XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。柔軟性の高い開発手法であるが、古典的には開発が進むにつれ変更コストは大きくなると言うことを前提に開発手法が構築されているのに対して、自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している。この変更コストが増大しないという前提^[1]が破綻すると、この手法も破綻する。

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

背景

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

従来の手法は、変更コストは開発が進むにつれ増大するという前提に立っている。それ故に、将来発生するかもしれない仕様やロジックの変更は可能な限り早い段階で検出しなくてはならないとしていた。しかし実際には、初期の段階で将来起きうる全ての問題を予見することはほぼ不可能であるため、従来の手法はしばしば開発に失敗を引き起こしてきた。

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

5つの価値

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

• コミュニケーション


• シンプル


• フィードバック


• 勇気


• 尊重

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

プラクティス

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

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

共同のプラクティス

反復

開発を反復から構成する（⇒反復型開発）。全体の開発期間はイテレーションと呼ぶ1〜2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返し、徐々に完全なシステムを構築していく。またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。

このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。

共通の用語

用語集を作成し、チーム全員（開発者・管理者・顧客）の使用する用語とその概念の不一致を解消する。

開けた作業空間

会話しやすく、作業に打ち込める雰囲気を作る。顧客も含めて一箇所に集まって作業を行う。

回顧（頻繁な振り返り）

現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境、体制を構築しておく。

開発のプラクティス

テスト駆動開発

実装を行うより先に、テストを作成する。実装は、そのテストをパスすることを目標に行う。テストを先に作成することで、求める機能が明確化され、シンプルな設計が可能になる。なお、このテストは、部品単位での正確性を確認するユニットテスト（ホワイトボックステスト）と、全体が顧客の要求を満たしているかを確認する受け入れテスト（ブラックボックステスト）の観点で作成する。テストは、自動テストであることが推奨される。なぜなら、それによって、コードの共同所有、リファクタリング、頻繁な結合が可能になるため^[2]、開発が進んでも変更コストの増大を抑制することができる^[3][4]。

ペアプログラミング

プログラミングは、二人一組で行う。一人がコードを書き、もう一人はそれをチェックしながら、仕様書を確認したり全体構造を考えたりするなど、ナビゲートを行う。二人は、この役割を定期的に交代しながら仕事を進める。ナビゲータのサポートにより、以下の効果が得られる。

• 細々とした問題の解決に要する時間が短くなる。


• 常にコードレビューを行うことができる


• 集中力が持続する。


• コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ。

リファクタリング

完成済みのコードでも、随時、改善処置を行う。この際、外部から見た動作は変更させずに、内部構造がより見通し良く優れたものになるようにする。テストが作成されていることが前提になる。

ソースコードの共同所有

誰が作ったソースコードであっても、開発チーム全員が断りなく修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。

継続的インテグレーション

単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。少なくとも一日に一回は、結合テストを行う。また、全体のコンパイルおよび自動テストを行うための継続的インテグレーション用のコンピュータを準備することが推奨されている^[5]。

YAGNI

You Aren't Going to Need It.（必要なことだけ行う）。先を見据えて、前払い的に機能を増やし、実装を複雑化させることは避ける^[6]。むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。これにより、後のイレギュラーな変更に対応しやすいようにする。シンプルで洗練され、安定性の高い機能・コードのまま、同時に将来的な汎用性も高めることは問題ないが、把握を難しくし、不安定化を招く機能・コードは、可能な限り削り落とす。

管理者のプラクティス

責任の受け入れ

援護

四半期毎の見直し

ミラー

今どういう状態かをチームに知らせる。

最適なペースの仕事

知的作業には、週40時間の労働時間が最適である。特にXPでは、集中力を高めて効果を高めることを重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適切ではない。そのため、計画的に開発スピードの調整を行う。

顧客のプラクティス

ストーリーの作成

求める機能のコンセプトを短い文章で記したストーリーカードを作成する。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。

リリース計画

どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。

受け入れテスト

イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。もし満足できない場合は、それを指摘する。

短期リリース

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする。

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

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

プログラマの受入れ

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

関連項目

• ペアプログラミング


• リファクタリング


• SUnit


• JUnit


• xUnit


• テスト駆動開発


• ユニットテスト・フレームワーク一覧

参考文献

• ケント・ベック(著)、長瀬嘉秀(監訳)、永田渉、飯塚麻理香(訳)『XPエクストリーム・プログラミング入門：ソフトウェア開発の究極の手法』ピアソン・エデュケーション、2000。ISBN 489471275X
  

参照

1. 
   ^ 設計の終焉?
   


2. 
   ^ Unit Tests
   


3. 
   ^ Surprise! Software Rots!
   


4. 
   ^ Acceptance Tests
   


5. 
   ^ Dedicated Integration Computer
   


6. 
   ^ Never Add Functionality Early
   

外部リンク

• Extreme Programming: A Gentle Introduction.


• オブジェクト倶楽部 XP-jp