反復型で進めるアジャイル（機敏な）開発手法のXP（eXtreme Programming）。その日本ユーザグループの倉貫義人氏が、ITサービス会社におけるXPの活用法「Enterprise XP（EXP）」を提唱している。XPとの違いなどについて、倉貫氏に聞いた。
——EXPとは何ですか？
ユーザー企業が仕様を決め、ITサービス会社が実装するという、日本では一般的な受託開発現場でXPを活用するための工夫をまとめたものです。具体的には、契約を2段階で結び、最初の契約では要件定義に重きを置き、小さくても実際に動くシステムをリリースします。次の契約では、リリースしたシステムから得たフィードバックを加えながら、システムを追加・修整しながら規模を拡大していくのです。
第1段階では、システム・リリースを短期に繰り返せるXPにより、あやふやなユーザーの要求を固めます。要求が固まった後の第2段階は、XPでもウォータフォール型でも構いません。これにより見積もりの精度も、あいまいで変わりやすい要求を基にするよりも、かなり向上します。XPは要求定義に向いていると思います。
——なぜEXPにたどり着いたのですか？
XPは、発表当初の2000年ごろと比べれば、確実に浸透しています。ただし、開発者がユーザー企業に属していれば、XPをどんどん進めていけるだけの情報量はあるのですが、ITサービス会社にいると状況は一変します。XPの教科書である「エクストリーム・プログラミング入門」（ケント・ベック著、ピアソン・エデュケーション）において、ユーザー企業が自ら開発する米国の状況を反映し、受託開発におけるXPのあり方に言及していないからです。ベック氏自身、「技術者よりに書きすぎた」と反省しています。
——EXPを成功させるポイントは？
XPの実践項目の一つに、ユーザーとベンダーが一緒の場所で設計・開発・テストを進める「オンサイト顧客」があります。しかし日本では、ユーザーを長時間拘束することは非現実的なため、「スペックホルダー」という項目を考案しました。スペックホルダーは、業務に詳しい開発者で、ユーザーにとっては開発チームの代表を、開発チームにとってはユーザーの代理人になります。
そのほか、ユーザーの目の前でホワイトボードを使ってモデリングを進める「その場でモデリング」という実践項目も考案しています。モデリングは打ち合わせ前に済ませておくのですが、実際にユーザーの目の前でモデリングを再現することで「どう考えたのか」という考えが共有できますし、ユーザーからも「出来上がったモデル図をただ説明されるよりも理解しやすい」と言われます。
——次は何に取り組みたいですか？
保守フェーズへのXPの適用です。追加・修整を短いサイクルで繰り返しユーザーの追加要求を実現する保守は、XPとよく似ています。そこで今後は、システム開発の発想を変え、最低限稼働するシステムをITサービス会社が自らのコストで開発し、ユーザーに提供。ユーザーがXPを使ってシステムをカイゼンする“改善型開発”を提案したいですね。
初版から5年後に改訂された「XP エクストリーム・プログラミング入門」の第二版で、ベック氏は、「XPとは社会改革（social change）である」と表現しています。社会改革は言いすぎかも知れませんが、XPによる“改善型開発”は日本のシステム・インテグレーション・ビジネスの根本を変える可能性もあります。
