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

エクストリーム・プログラミング、XP（テンプレート:Lang-en-short）は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。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を好む理由は、このようなプログラマの不安を解消する仕掛けを具体的なプラクティスとしてさまざまに備えているためである。

参考文献

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

参照

外部リンク

テンプレート:Link GA

[1] 設計の終焉?

[2] Acceptance Tests

[3] Unit Tests

[4] Surprise! Software Rots!

[5] Dedicated Integration Computer

[6] Never Add Functionality Early

[1]

[2]

[3]

[4]

[5]

[6]