エクストリームプログラミングは，Smalltalker として有名な Kent Beckらによって 提唱されているソフトウェア開発プロセス(開発工程)である． 正式にはエクストリームプログラミング(eXtreme Programming)， 略してエックスピー(XP)と呼ばれる．この記事でも，以下 XP と呼ぶことにする．

Kent Beck は，'99年に "Extream Programming Explained - Embrace Change" という書籍を著した．これは "EC 本" とも呼ばれ，XP のバイブルともなる． この記事では，この "EC本" を基礎に XP のエッセンスを紹介する．

XP はソフトウェアの「開発現場」がかかえている問題に，真剣に立ち向かう 新たな手法として現在最も注目を浴びている開発方法論， さらに言えば開発思想である．

XP はそのユニークさから，また， リファクタリング，ユニットテスト，パターンなどの最新オブジェクト 技術との関連から，現在米国のオブジェクト指向界で最もホットな 話題として一大ムーブメントを形成している．

まず，ソフトウェア開発現場の現状認識から始めよう．

現代ソフトウェアの「正しい」開発においては，実装を始める前に きちんとドキュメントを書き，顧客に承認を得，実装をし，テストをする． 各開発フェーズでの成果物が正確に定義され，要求分析や 設計フェーズではドキュメントが次々と生成される． 実装フェーズでは仕様通りにコードを書くのが正しい． 実装段階で気付いたよりよいアイディアを設計にフィードバック することは基本的にできない． テストのフェーズではその場でコードが修正されるが， 大きな変更は禁物だ．思わぬバグを作り込んでしまうのを恐れ， 修正はバンドエイドをあてるように行われる．再設計はこのフェーズでは 不可能だ．開発者は不自然だと思っていても，また，美しくないと思っていても パッチをあてるようにソフトウェアを修正する．保守になるとさらに事態は悲惨 になる．その場しのぎの修正が重なり，ソフトウェアはほぼ理解不能の 目もあてられぬ姿となっている．あちらを直すとこちらが壊れる． この時点では，設計時のドキュメントは全く役立たずだ． このようにして，ソフトウェアは「熱力学 第2法則」にしたがってエントロピーが増大する方向，すなわち崩壊へと向かう．

一方で顧客はわがままだ． 1ヵ月前と違ったことを平気で要求する．顧客の視点ではほんの小さな変更でも， ソフトウェア全体に大変更が加わることも多い．そこで開発者は残業の連続になる． それでも顧客が要求する納期には間に合わない．しばしば，開発者と顧客は敵対 関係となる．本来は，有用なソフトウェアを開発する，という目標を共有している にもかかわらず．

また，開発が終了するとほとんどのドキュメントは すでに現実のコードとはズレてしまっている．ドキュメントは 形式的に納品するが，読まれるあてはない．すなわち，ライト・オンリーだ． 最近では繰り返し型の開発がもてはやされ，UML(Unified Modeling Language) のように統一的な記法もある程度は浸透したが，基本的に現状は変わっていない のではないだろうか．

オブジェクト指向がこういった問題をすべて解決する， と思われていた時代もあった．もしかしたらコンポーネント技術が解決する かもしれない，とも．．．．しかしそれは嘘っぱちだ． 変更の伝搬を最小限に押さえたり， ソフトウェアの再利用率を高めることは可能かもしれない． しかし，開発プロセス，開発方法論，およびそれをとりまく 人間系に対してアプローチをしない限り， 根本的な人間の行動原理 は変えられない．工学的な技術だけでは，この問題は解決できないのである．

ややネガティヴな現状認識となったが，少くとも これまでの多くの開発方法論は，ソフトウェアを工学として捉えており， 人間系の要素についての視点が小さかったと言える． もちろん，ソフトウェアはできるかぎり工学 として議論されるべきであるし，それが可能な領域もある．しかし，現場の ソフトウェア開発は工学に乗らない部分が大きいことは，そこに身を置く 開発者であれば誰しもが気付いていた．

XP は，ソフトウェアがハードウェア生産のような製造工程に乗るという 前提をまず切り捨てる． かつて，開発工程通りにうまく進み，リリースされ，保守された アプリケーションはどれくらいあるだろうか． その代わり，XP ではこの問題に取り組む視点として，「コミュニケーション」を 新たなパラダイムの中心に据えている． こういった問題に悩んだ経験がある読者ならば，きっと Gerald M. Weingerg 一連の著作や，Tom Demarcoの「ピープルウェア」， さらにさかのぼって Frederick P. Brooks の 「人月の神話」を読んでいるに違いない．このように，これまでも人間系に 焦点をあてた著作はあった．しかし，XP のように具体的な手法を示して ソフトウェア開発の方法論にまで体系化したものは無かった． XP は，顧客とのコミュニケーション，開発者間のコミュニケーションに 焦点をあてることで，現場のソフトウェア開発者に一筋の光を与えた，という紹介は ややドラマチックすぎるだろうか．

さて，次の節からは，XP がどのように「コミュニケーション」を手法 にまで体系化しているかを紹介して行こう．

まず，開発リスクを早期に軽減することを主眼におき，繰り返し型 (iterative)の開発を取り入れている点は，RUP(Rational Unified Process) な どのオブジェクト指向プロセスと同じである． ただし，次の点が XP の大きな特徴と言えよう．

• 開発の中でコーディングおよびテストという工程に特に重点を置いている
• 初期設計よりもリファクタリングによる再設計を重視している
• すぐにでも始められるライトウェイトな方法論である
• 明確な言葉で XP を行うための「12のプラクティス」が示されている

そして何より，「プログラマは人間である」という温かな視点による思想 が全体を通して流れていること，これが XP の人気の最大の秘密だと筆者は 思っている．

Embrace Change - 変化ヲ抱擁セヨ

この呪文めいた言葉は，Kent Beck による本の副題として掲げられている． 時間を横軸に，ソフトウェアの変更にかかるコストを縦軸にプロットする． この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左)． すなわち，要求分析，設計，実装，テスト，保守，と時間が進むにつれ， 変更にかかるコストが増大するというのだ． 現在までのソフトウェア開発プロセスは，この仮定上の議論が多数 だったのである．XP はこの曲線を平坦にできるのではないか， また，そうできたとしたら，全く違った方針でプロジェクトに立ち 向かえるのではないか，という挑戦をしている(図右)．

「変化ヲ抱擁セヨ」とは，変化を嫌うのではなく 変化が起こることを自然なこととして受け入れよう， という XP の基本姿勢を表明している．

Kent Beck は，"Extream Programming Explained - Embrace Change" の中で，はじめて"EC"という言葉を"European Community"でも "Electronic Commerce"でもなく，"Embrace Change"として使った．

XP では，開発チームが最も大切にすべきことを「4つの価値」として示している．

• コミュニケーション(Communication)
• シンプルさ(Simplicity)
• フィードバック(Feedback)
• 勇気(Courage)

「コミュニケーション」は，前述の通り XP が新たなパラダイムの中心に 据えているテーマである．顧客とのコミュニケーション，開発者間の コミュニケーションを大切にしている．

「シンプルさ」では， 最初から設計に複雑さを持ち込むことを嫌っている．後から必要になるだろうと 予測して，柔軟な設計を行うことは，XP では悪である．現時点で必要 最小限の設計を行う．これを「たぶん動くであろう最も単純な設計」 (The Simplest Thing That Could Possibly Work)と呼ぶ．なぜ，最初から 柔軟に設計しないのか．なぜなら，そういった必要は起こらないことが あるからだ．使われそうだが，必要かどうか現時点で分からない設計 をしようとする人がいたら，その人には，「それは必要にならない！」 (You Are not Going to Need It -- YAGNI)と忠告しよう． 常に最小の初期投資で賄う．極端な例で言うと，あるクラスに， ある属性のsetメソッドを作る場面を考える．ついでに，get メソッド も追加したくなるだろう．しかし，XP ではそれを「行ってはならない」のだ． 仮に「ついで」であろうとも，現時点で必要かどうか分からないメ ソッドを追加してソフトウェアの行数を増やしてはならない．必要 になった時点で始めて，それを追加するのが XP 流だ．

「フィードバック」は XP を動作させるための大切な回路だ． 頻繁なフィードバックがあってこそ，XP は機能する． Kent Beck は，XP をはじめての自動車運転練習に例えている．

母を横に乗せ，ハンドルを握り... 最初はうまく行きました．でも， ちょっと油断した瞬間，車は車道を外れて砂利に突っ込んでしまいました． 母は車を道に戻すと，初めて運転とは何かを教えてくれました．

「運転で大切なのは，車を正しい方向に進めることじゃないのよ．大切 なのは，常に注意を払って細かく左右に方向修正していくことなの．」

これが，XP のパラダイム，とりわけフィードバックの重要性を 説明するのにもっとも有効なメタファーであろう．このフィードバック を得る為に，XP では特にテスティングに重きが置かれている．

「勇気」は，前の3つの価値があって始めて可能になる． 時には大きなソフトウェア変更を行う方がよい，という場面に遭遇する． 勇敢さは，無謀と紙一重である．その一重は，「コミュニケーション」が できていて，プログラムの設計が「シンプル」であり，さらに，変更を 行った結果が即座に「フィードバック」される仕組みがあってはじめて 乗り越えられる．

Communication + Simplicity + Feedback = Courage

XP の 4つの価値

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

「4つの価値」の元に， XP は具体的な 「12のプラクティス」を示している．プラクティス(practice)とは， 経験に基づいて有用性が立証された実践項目のこと．以下が，その 12のプラクティスである．

• 計画ゲーム(The Planning Game)
  ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める．
  
• 小さなリリース(Small Releases)
  新バージョンを非常に短いサイクルでリリース．
  
• メタファー(Metaphor)
  システムの動きを示すメタファーを共有．
  
• シンプルデザイン(Simple Design)
  シンプルに設計．余分な複雑さは悪．
  
• テスティング(Testing)
  プログラマは継続的にユニットテストを書く． 顧客は機能テストを書く。
  
• リファクタリング(Refactoring)
  システムの動作を変えることなくシステムを再設計．
  
• ペアプログラミング(Pair Programming)
  コードは２人のプログラマにより一台のマシンで．
  
• 共同所有権(Collective Ownership)
  誰でもどのコードでも修正できる。
  
• 継続的インテグレーション(Continuous Integration)
  一日に何回もビルドし，テストを 100% パスさせる．
  
• 週40時間(40-Hour Week)
  週４０時間以上の仕事はよい結果を生まない．
  
• オンサイト顧客(On-Site Customer)
  顧客をフルタイムでチームに加える．
  
• コーディング標準(Coding Standards)
  全プログラマがコーディング標準に従う．

この中で，もっとも目を引くのは「ペアプログラミング」ではないだろうか． 日本では，「設計レビュー」というプラクティスが多くの現場で 品質を上げることがよく知られている．「ペアプログラミング」では， そのレビューをコードを書いている端から行っている，と捉えること ができる．複雑で説明が難しいコードは，自然と排除されることになる． また，教育的側面からも，「ペアプログラミング」はおもしろい効果 が期待できる．すなわち，シニアプログラマとジュニアプログラマをペアに する，という手法が使える．ここでもコミュニケーションがキーだ．

「ペアプログラミング」を行うためには，「コーディング標準」が必須である． その場で，ソースコードのインデント付けなどの細かいプログラミングスタイル の問題を議論したくはないのだ． また，「共同所有権」も必然である．誰もが，どの 部分でも変更できる，とは言っても，ここでも円滑なコミュニケーションが 成り立っていなければ破綻することは言うまでもない．

日本では難しいと思われるプラクティスの1つが「オンサイト顧客」である． 顧客をフルタイムでプロジェクトにアサインできる，という環境は ほとんどないかもしれない．「オンサイト顧客」の役割は，「テスティング」の 一部である機能テスト(あるいは少くとも仕様)を書いてもらうことである． XP では仕様書を書かない，というと語弊があるが，ドキュメントの役割は 小さい．その代わりに顧客と合意を取るのは，テストなのである． テストの通過をもって，顧客の意図する仕様を開発側が作れたかどうか を評価するのである．ここに表れているのはゲーム性だ． テストを自動化することで，テスト100% 通過を快感にできる． 顧客と開発という，ともすれば敵対 する2つのサイドが，テストというゲームで目標を共有する． 機能テストの成績が 100% に近づくと，顧客は新たなテストを投入する． 開発がビルドする最新リリースが，それらにも全て 100% パスすれば 1回のイテレーションが終了し，全員でパーティーだ．

見積りにおいてもこのゲーム性は重要である．顧客はストーリーカードと呼ばれる， システムの動作シナリオを書く．ストーリーカードは，優先度と共に提示される． 開発側は，ストーリーカードをタスクに分割し，見積りを提示する． 「計画ゲーム」と呼ばれるこのアクティビティは， あたかもカードゲームのようである．

「シンプルデザイン」は，「リファクタリング」を常に行うことで保たれる． 「一度，ただ一度だけ」(Once and Only Once)と呼ばれる原則は，シンプルさの 価値に通じる． 同じコードの重複を見つけたら，それは「リファクタリング」せねばならない． ただし，その「リファクタリング」を行う勇気を与えるのは， 「テスティング」である．必ずユニットテストと機能テスト を準備することで，今行った「リファクタリング」がシステムを壊していないか，を すぐに確かめられる．さらに，「継続的インテグレーション」と「小さなリリース」 によって，短い時間でフィードバックを得ることができる． また，XP では大きな初期設計(Big Design Upfront)をしない． 「リファクタリング」を通じて設計を漸進的に進化させる(Designing Through Refactoring)手法が採られる． 最初に方向を決めて突き進むのではなく，頻繁に設計を調整するのだ．

XP ではテストを非常に重視しているのは，前にも述べた通りだ． ．Kent Beck 流に言うなら，もし会社が火事に なったら真っ先に持って逃げるのは仕様書ではなく，ソースコードと テストコードだ．仕様書は動かないが，テストは動く． テストはプロジェクトの最後まで必ずメンテナンスされなければならない． テストはプログラマにとって退屈な作業だ，と思われている．しかし， XP ではユニットテストツールによって，ゲーム感覚でテストができる． 実際，ユニットテストを導入してみると，テストに夢中になるプログラマ がでて来る．これを(デザインパターンで有名な)Erich Gammaは 「テスト熱中症」(Test Infected)と名付けた．ユニットテストツール については，後述する．

また，コーディング時には「テストファースト」という手法がよく使われる． 実際の製品コードのクラスを書く前に，ユニットテストクラスを作る． これによって，製品コードのクラス仕様が明確になるし， 自分が今から書くクラスを利用するクライアントの立場で仕様を検討できる．

もう1つ，XP で大切なのは開発者が感じるリズムである．まずユニットテストを 準備し，コーディングして，テストを100% 通過させる．機能を追加し， リファクタリングし，即座に再度ユニットテストを 100% 通過させる． これは短い周期，プログラミン グペアが感じるリズムである．これとは別に，計画ゲーム，イテレーション， インテグレーション，機能テスト，リリースという，より長い周期のリズム もある．こちらは開発チーム全体が共有するものだ． この2つのリズムが XP のハートビートとなり，チー ムは一体感とライブ感の中で開発を進める．

「週40時間」というプラクティスはプログラマの憧れであろう． 誰もがそうあったらいい，と思いながらもなかなか実現が難しい ことも良く知っている．こういったことも含めてプラクティスとして 記述しているのが，XP の凄いところである．しかし，実際に ペアプログラミングを経験してみると，週40時間というのは納得が いく作業時間であるらしい．ペアプログラミングでは常に2人 で作業をするために集中力を必要とし，非常に疲れるという．

このように，12のプラクティスはどの一つを取ってもそれだけで成り立つ ものではない．12がお互いに依存しあっていて，それらが一体となって XP と呼ばれる開発のリズムを作り出している．

おもしろいことに，XP の現場ではアナログツールが大活躍する，という 点を指摘しておこう． XP でのコミュニケーションに活躍するのは，UML 記法でもケースツールでも ない．アナログで手に取れる簡単な道具が好んで用いられる． 「計画ゲーム」は「ホワイトボード」のある部屋で行われる． 顧客は「ストーリーカード」を使って機能を表現し，ブレイクダウンされた 作業は「タスクカード」に書き出される．タスクからクラスを切り出す際の 責務分担の決定には，「CRC カード」を使う． また，リリースされたプログラム のテスト結果や，プロジェクトのリリース計画は， 「大きな模造紙」に描いて壁に貼り出される，といった具合だ．

XP の開発プロセスを図に示す．

まず，「計画ゲーム」では，ユーザが書いたストーリーカードを 基にプランニングが行われる．そこでは， システムを表現する比喩(メタファー)が投入される． ユーザーストーリーは，プログラマが見積り可能な分量のタスクに分割される． これらから，リリース計画が決定される．「イテレーション」によって 実装，ユニットテストが行われ，継続的インテグレーションによって 最新バージョンが作成される．最新バージョンに対して機能テストが行われ， それを 100% パスすることで，小さなリリースが行われる． 全過程で，フィードバックが行われること， また，サイクルが非常に短いことが，XP の特徴である． 1イテレーションは1～4週間．継続的インテグレーションと機能テスト は少くとも日に1度である．

XP では，リファクタリングによる再設計や 複数人によるコードの変更をプラクティスの中に含 んでいる．これを支えているのは，ユニットテストを非常に 短いサイクルで行うことができる環境である． Eric Gamma と Kent Beck とは，このテスト環境を「テスティングフレームワーク」 呼んだ．

Java 用のテスティングフレームワークである，JUnit による 簡単なテストの例を見てみよう．この例では，x, y という2つの 属性を持つ数学2次元ベクトルクラス(Vector2d)の length メソッドを テストしている．まず，テスティングフレームワークで準備されている， TestCase クラスを拡張し，Vector2dTest というクラスを作成する． その中で，testLength というメソッドを定義し，Vector2d クラスの length メソッドをテストするのだ．そして，suite という static メソッドを 定義し，作ったテストメソッドを登録する．これで準備は終わりだ．

public class Vector2d {
    private double x, y;
    public Vector2d(double x, double y) {
        this.x = x;
        this.y = y;
    }
    public double length() {
        return Math.sqrt(x*x + x*x);    // バグ
        // return Math.sqrt(x*x + y*y); // 正しい
    }
}

import junit.framework.*;
public class Vector2dTest extends TestCase {
    public Vector2dTest(String name) {
        super(name);
    }
    public void testLength() {
        Vector2d v = new Vector2d(3, 4);
        double expected = 5;
        assertEquals(expected, v.length());
    }
    public static Test suite() {
        TestSuite suite = new TestSuite(); 
        suite.addTest(new Vector2dTest("testLength")); 
        return suite;
    }
}

2つのクラスをコンパイルした後，実行は以下のように行う．

> java junit.ui.TestRunner Vector2dTest

すると，次のような画面でテストが行われる．この例では， テストが失敗している．testLength の中で，期待していた値 と，テスト値がずれている，という例外が発生している．

これを，正しいコードに直して再度コンパイルする．JUnit を走らせると 赤だったバーが今度は緑に変わり，すべてのテストがパスしたことを知らせてくれる．

現在，さまざまな言語に対してこのユニットテストをサポートする ツールが発表されており，JUnit(Java), CppUnit(C++), VBUnit(Visual Basic) などが存在する． さらに，日本発のスクリプト言語 Ruby 対応の RubyUnit や Microsoft の .NET の全言語に対応した，NUnit も既に存在している．

XP の概要を聞いて，多くの読者はその「アーキテクチャ不在」の 方法論に不安を感じる．

現代的なソフトウェア開発では，アーキテクチャの設計もしくは決定が ソフトウェア開発のキーを握るの重要なアクティビティとなっている． アーキテクチャは，作ろうとしているソフトウェアの全体図となり， 各開発者はその中で自分が担当する部分のポジショニングを行う． アーキテクチャを美しく設計し，アプリケーションのライフタイムに渡って これが崩れないように監視をしていくことが，保守可能なソフトウェア を開発するための必須要件のように思われている．

しかし，XP ではアーキテクチャについては，非常に少い言葉でしか 語られていない．それは，「メタファー」である． 全員がアプリケーションの機能と内部構造を想起できるような 現実世界の比喩(メタファー)を共有することが，特に重要視されている．

また，最初のイテレーションに置いて，ソフトウェアの機能を端的に 示し，全体構造を形作るために有効と思われるストーリーを選ぶこと． その中でアーキテクチャは創発すると捉えられる．

さらに，ストーリーが追加される毎に最初のアーキテクチャを 維持するのが難しくなった場合，アーキテクチャをも再設計する 勇気を持つことが重要である，と言われている．

もちろん，再設計には，充実した機能テストや 継続的インテグレーション，小さいリリースなどが重要な プラクティスとして機能していることが前提である．

ここで，幾つか XP の背景，XP が登場した経緯を書いてみたい． エクストリームプログラミングは，なぜそう呼ばれるのか． 1つのイメージを思い浮かべてもらいたい．グラフィックエコライザーのように， たくさんの調節用のスライドバーが着いたパネルがある．1つ1つのバーには， ソフトウェアプロジェクトに必要な実践項目が書かれいる．

XP では，いくつものバーの中で前述の12のプラクティスのバーだけを ボリューム10にまで上げた状態をイメージしている． これはある意味で極端(エクストリーム)な状態である．しかし， Kent Beck は，この状態で行われるプロジェクトが安定していてかつ 生産性の高いものだということを発見し，この名前を付けた．

XP の父と呼ばれる資格がある人は3人．Ward Cunningham, Kent Beck, Ron Jeffries だ． WardとKentの2人は，ソフトウェアパターンの開祖となる 一派でもある．Kent Beck は 1987年にSmalltalkでユーザインター フェイスの設計を行った時に，建築家 C.Alexanderのアイディアを取り入れ， OOPSLA'87で"Using Pattern Languages for Object-Oriented Programs"として発表している．また，Ward Cunningham は PLoP(Pattern Language of Programming) の父とも呼ばれ， PLoP'94の議長を務めている．2人は，Hillside Group を生み出し， パターンコミュニティで大きな役割を果たした．XP の 12のプラクティス をよく見ると，それらはパターン言語を形成している，ということ もできる．

Ron Jeffries は，Kent Beck に招かれて最初の XP プロジェクトである伝説の C3プロジェクト(Crysler payroll project)に参加した． このプロジェクトには，Martin Fowler も参加している． そのプロジェクトで Kent Beck は Smalltalk, パターンの経験を 活かしながら，初めて12のプラクティスバーを10にまで上げることを試した． Ron Jeffries の実践を通して XP は形あるものへとなったと言える．

Kent Beck は'99に"Extream Programming Explained - Embrace Change" という最初のXPの本を書き，12のプラクティスを示し，この手法を 体系化した．

Martin Fowler は'99に"Refactoring"を著したが，これはXP の12のプラクティスの1つとしてXPを支える中核であると同時に，XPの 実プロジェクトの中で実践され，収集されて初めて効果が 立証された技術である．

今年の冬に，Kent Beck の最初の XP の著作 "eXtreme Programming Explained - embrace chaange" が，邦訳出版の予定だそうである． 現在米国では既にこの本以降，数冊の XP 関連書籍の 出版が「XP Series」としてAddison-Wesley から決まっている．

また，2000年10月に米国で開催された「OOPSLA 2000」(Conference On Object-Oriented Programming, Systems, Languages and Applications)では， XP関連のセミナーが多数実施され，多くの“XPグッズ”が配られていた(写真)． 2001年は XP が大ブレイクしそうな予感の年である．

コミュニケーションに焦点を当てた新しい開発方法論，XP の概要を紹介した． 前にも述べたが，XP の魅力は，その人間的な視点にある． 上記で述べた以外にも，コーチと呼ばれる役割を果たす人は， 会議の場におかしを買って来るべきだ，などということが 冗談ではなく書かれている．一緒に物を食べる，という行為が コミュニケーションに与える影響に関しては，誰もが経験を持っている はずだ．XP は明らかにソフトウェアを工学を超える射程を持つ．

この小記事をまとめるにあたって， 日本語 XP メーリングリスト(XP-jp) での議論を参考にさせて頂いた．XP-jp のみなさんに深く感謝する．

XP-jp メーリングリスト は自由参加であり，XP 関連の各種話題や，メーリングリスト内での実験仮想XPなども 活発に行われている．興味のある方は，以下から入会できる．

http://www.ObjectClub.jp/community/XP-jp/

また，上記サイトでは Martin Fowler の「分厚すぎるドキュメント」， 「設計の終焉?」，および Kent Beck の「テスト熱中症」などの翻訳， さらに，Ron Jeffries がまとめた XPractices(XP実践集) の翻訳も見ることが可能だ．

XP は少々過激な側面があり，これが読者のプロジェクトに適用できる かどうかはすぐには判断できないだろう．実際，10人程度のプロジェクトが XP 適用の限界であると言われている．しかし，ユニットテストやペアプログラミング などは，今すぐにでも試して見る価値はある． これから日本でも本格的に XP の適用が試され， その有効性についての議論が行われるだろう．

最後になったが， この記事に関して，個別にコメントとヒントを頂いた， 矢崎博英さん， 平澤章さん， 上手裕さん， 名須川竜太さん，さらに，写真を提供頂いた，井上健さん に感謝します．ありがとうございました．