XPに興味を持つようになったのはそんなに古いことではなく、ここ二年ぐらいだ。ふとしたきっかけで思い立ち、eXtreme Programming eXplained を原文で読んで、「これはもしかしたらすごいんではないの？」と驚嘆したのだった。
まず、提唱者のケント=ベックが推奨しているプラクティスのひとつづつに驚いた。「計画ゲーム」をとってみよう。スコープ管理が大切だとは誰もが知っている。しかし私たちが（少なくとも私が）そう口にするとき、本当に意味しているのは、「スコープの拡大を抑制せよ」という意味である。ケント=ベックは、スコープを自由変数として扱い積極的に制御せよ、という。このとき彼の言わんとしていることは、たとえ当初想定されていた機能であっても重要性の低いものは削ぎ落とせ、しかもサブシステムや画面・帳票といった大粒度の単位だけではなく「機能特性（feature)」という小粒度の単位でも削ぎ落とせということだ。反対に、重要性が高い機能特性なら後になってでも盛り込めとも言う。しかもそれを二、三週間おきにやれという。私はこんなにきめ細かいレベルでスコープを制御している例を見たことがなかった。しかし言われてみると、決して不可能とも不合理とも思えない。
もうひとつ例をあげよう。「シンプルな設計」というプラクティスだ。私はシステムを設計するときに前もってあらゆる可能性を考えるのが好きだ。設計しているときに時おり訪れる「読み切った！」という感覚は何にも換えがたい報奨だとつねづね思っていた。ところがケント=ベックは、今まさに目の前におかれている要件を実現するために必要最小限の設計のみをせよ、さきざきのことまで読みきろうとするな、それは無駄になるから、と言う。これはショックだった。しかし私の過去の経験を思い出しても、このアドバイスに接してから経験したことに照らしても、「読み切った」結果としてシステムに持ち込んだ複雑な設計が無駄になっているケースはたしかに相当にあると気づいた。
自動化テストの実施、リファクタリング、ペアプログラミングについては言わずもがなだろう。「もしこうであったらいいのにな」という感じで一度か二度かは考えたことはあるが、しかし、常に視野のはずれにあって「白目の部分で見ている」ことがらに、いきなり目の焦点をあわせられたような感じがしたのである。
プラクティスに対するこうした驚きに重なって、別のレベルでの驚きもあった。ケント=ベックは、XPの４つの「価値」として「コミュニケーション」「シンプルさ」「フィードバック」「勇気」を取り上げ、それを具体的にふえんした一連の「原則」を行動基準とし、さらにその行動基準に即した具体的な活動として「プラクティス」群を置いた。
プラクティスは相互に支えあうと同時に、全体として４つの「価値」を育む。すなわちXPには、チーム内の価値と行動のシステムを進化させていくための正のフィードバックループが二重に組み込まれている。たとえば、「ペアプログラミング」していると、必要なすべての「自動化テスト」を書こうという心理的な動機付けが働くだろうし、同時に「コミュニケーション」という価値にコミットする傾向がメンバーの心のうちに育まれるだろう。他のプラクティスにも同様のことがいえる。そして実はこうしたフィードバックループが適切に機能するための原動力として、XPではチームに対する帰属意識やチームメンバ間の尊敬の気持ちがうまく活用されている（これは私見だが）。こういう言い方をすると「甘い」と言われるかもしれないが、自分が尊敬する相手から尊敬されたいという欲求は人間にとって根源的なものではないか。
XP以前の方法論は、プロジェクトを運営していくためにさまざまなルール（規制）を用いることを当然の前提として、その規制のありかた、たとえばドキュメントの書式をどう設計するかといったことを、関心の中心に置いていた。これに対してXPは、上述したような価値と行動の体系を通じて、チーム内に、成果志向の、なかばインフォーマルな社会的関係を醸成することを重視しているように思える。これはどちらかいっぽうですむような問題ではないだろう。また、システム開発のすべての問題にXPが答えているわけでもない。たとえば要件定義の進め方はXPではブラックボックス扱いされている。また、メンバーの帰属意識や仲間意識に多くを負っているだけに、そうした意識を損なう要因が優勢な環境に置かれたXPプロジェクトは簡単に瓦解するだろう（そんな環境ではXPであろうがなかろうがそもそもあまり働きたくないが）。
しかしこうした限界を持ちながらも、XPが示したビジョンは注目に値する。これから何十年あるいは何世紀かにわたってシステム開発という仕事に、XPは深い影響を及ぼすのではないか。
