ソフトウエア開発の思想である「eXtreme Programming（XP）」の普及を目指す日本XPユーザグループ（XPJUG）は2005年9月3日，東京お台場の日本科学未来館でXPの祭典「XP祭り2005」を開催した。XPにかかわっていたり興味を持っているソフトウエア開発者が一堂に会し，講演あり，XP体感ワークショップあり，パネル討論あり，寸劇あり，1テーマ5分のプレゼンテーションを競うライトニング・トークスあり，懇親会ありと盛りだくさんの1日を過ごした。XP祭りは2002年から毎年開催されており，今回が4回目である。
今回のXP祭りは，四つの講演のうち三つまでが「顧客の真の要求をいかに引き出すか」をテーマにしていたのが特徴的だった。企業システムの開発では，仕様変更などによりプロジェクトが破滅的なスケジュールに追い込まれるデスマーチや，完成したが使われない，あるいは役に立たないシステムが後を絶たない。こうした事態を防ぐため，開発の上流工程で顧客の要求をしっかりと把握することが重要だと従来から言われてきた。しかし現実には，顧客自身にすら「あるべき要求」がわかっていないことは多い。講演では，この状況をいかに打破するかについて，いくつもの興味深い提言が行われた。
XPで顧客の要求を「試作」する
XPJUG代表の倉貫義人氏（写真1）は，同氏が考えた「エンタープライズXP（EXP）」という新しい概念を披露した。従来のXPはいわゆる下流工程に適用するものだが，これを上流工程にも応用しようというアイディアだ。同氏によれば，上流工程は「工数による契約」「顧客の巻き込みが重要」「方式決定のためにプログラミングのスキルが必要」「少数精鋭で実施」といった点が実はXPに似ているため，XPの適用が可能だという。また，XPの適用に合わせ，上流工程を「試作工程」，下流工程を「製作工程」と呼ぶことも提唱した。試作工程でXPによる反復を繰り返すことで，要件やスコープ（システムの適用範囲）のあいまいさを排除できる。製作工程で使うフレームワークを試作工程から「収穫」できるのもメリットだという。
「三種の神器」で真の要求を引き出す
軽量コンテナSeasar2の開発で知られるSeasarプロジェクトのひがやすを氏（写真2）は「ユーザー中心設計」と題して講演した。同氏は，要件定義では顧客がシステムのできあがりをイメージするための「見える化」が重要だと主張した。見える化されていないと顧客が真の要求に気付けず，また，開発者が要求をどう理解しているかを顧客が確認できないからだ。ただ，見える化にはUMLのようなものは使えないという。UMLはあくまで開発者のためのものであり，一般の顧客は理解できないからだ。
ひが氏は，見える化のための「三種の神器」として「UIモックアップ」「操作マニュアル」「業務手順書」を挙げた。UIモックアップは，本物のシステムを想像できるような「紙芝居」で，HTMLで記述することが多いという。デザインに凝ったりロジックを含む必要はない。顧客との意思疎通に使うだけでなく，デザイナにそのまま渡すことで，デザインのスタート・ポイントにもなる。操作マニュアルは，UIモックアップのスクリーン・ショットに操作法を書き加えて作る。従来のシステム開発では，操作マニュアルは開発の終盤か開発が終わってから作成するのが一般的だった。これを最初に作ることで，システムの操作イメージを見える化する。いわば「逆転の発想」である。業務手順書は，顧客の業務の仕様を見える化するものだ。「手作業でやるとしたらどんな手順でやるか」を洗い出していく。注意点は，開発言語的な要素を出さないこと。開発者の視点ではなくあくまで顧客の視点で手順を記述する。
顧客の要求は「開発」すべきもの
豆蔵取締役の萩本順三氏（写真3）は，同氏が設立にかかわった要求開発アライアンスが推進する「要求開発方法論（Openthology）」を紹介した。要求分析や要求定義のように「要求がすでに存在する」と考えるのではなく，業務を分析することにより「要求を開発する」方法論である。
萩本氏は，よいシステムが開発できない理由として「業務管理者の論理」「システム開発者の論理」「業務担当者の論理」の間に壁があることを指摘。業務管理者と開発者の間にコミュニケーションがあるが業務担当者が疎外されている場合は「使われないシステム」ができ，業務担当者と開発者の間にコミュニケーションがあるが業務管理者が疎外されている場合は「レア・ケースのシステム化（正しくないものを正しく作る）」になってしまうという。要求開発は，この三者が意見を交換できる場を用意したうえで，開発者が業務管理者の意見と業務担当者の意見の間で微妙なバランスを取らなければならない。このためには，問題を取り除くための「折衝力」，メンバーの技術を支える「メンターリング能力」，メンバーの活動を円滑化する「ファシリテーション力」，プロジェクトを推進する「プロセス推進力」といった様々な能力が要求されるという。
開発者の幸せを実現するPF
これら三つの講演が「顧客の要求」を主なテーマにしていたのに対し，永和システムマネジメントの平鍋健児氏（写真4）は，XPの本筋の話題ともいえる「プロジェクト・ファシリテーション（PF）」を紹介した。PFは，目に見えないプロセスやソフトの内容を「見える化」することで，プロジェクトの運営を円滑にするもの。プロジェクトマネジメント（PM）が「動脈」だとすると，PFは「静脈」に相当する。PFは，プロジェクトを成功させることに加え，開発者がよりよい人生の時間を過ごせるようにすることも目的とする。
PFでは，受け入れテストを通過した要求数を紙に書き出す「バーンダウン・チャート」，個人の作業の状況を見える化する「かんばん」，立ったまま15分で行う「朝会」，2人の討議で使う小型のホワイト・ボード「ペア・ボード」など，さまざまなツールを使う。ただ，こうしたツールはあくまでとっかかりであり，プロジェクトに合わなければやめてもいいという。PFで重要なのは，情報がパッとわかる「見える化」，行動を進めるため「リズム」，気付いたことを定着/他に伝播させるための「名前付け」，開発者同士の対立を避ける「問題対私たちの構図」の四つの原則である。PFはソフトウエア開発だけでなく，営業や企画など，知的作業になら何でも適用できるという。
ITには革命を起こす力がある
「XPのみらい」と題して行われたパネル討論でも，興味深い発言が相次いだ（写真5）。パネリストとして，講演を行ったひが氏，萩本氏，平鍋氏に加え，「ソフトウエア・ファクトリ」というソフトウエア工学の方法論を推進しているマイクロソフトの萩原正義氏，XPの実践家として知られる東芝医用システムエンジニアリングの関将俊氏も参加した。
議論の中では，フレームワーク開発者であるひが氏が「フレームワークは嫌い。強制されるのが一番嫌い」と発言し，会場の笑いを誘った。また，関氏は「フレームワーク開発チームをアプリケーション開発チームから分けるデメリットは大きい」と発言して会場から大きな拍手を浴びた。「フレームワーク開発チームが作った俺様フレームワークを下々のアプリケーション開発チームが使うという構造になっていると，フレームワークが間違っていてもヒエラルキ的にフィードバックできなくなってしまう。そうするとフレームワークの問題点を避けるようなへなちょこコードを書かざるを得なくなる」（関氏）。
パネルの最後には，司会の倉貫氏が「XP祭りの講演はボランティアだが，それでも発表を行う理由は何か」とパネリストに質問した。それぞれの分野の第一人者の言葉だけに，いずれの回答も開発者が勇気付けられるようなものだった。各々の発言は以下の通り。
- 萩本氏「生きている証。自己表現をみんなで分かち合うため」
- ひが氏「ペイフォワードが基本にある。いろんなことを教えてもらったり受けて今の私がある。これを他の人にも伝えたい」
- 関氏「他のプログラマがうまくなるのを見るのが楽しい」
- 萩原氏「今は後世から見ると革命が起きている時期。ITには産業を興す力がある。そういう仕事に就けたのは非常にうれしい」
- 平鍋氏「昔はアインシュタインになりたかった。人にインパクトや感動を与えるのが強いモチベーションになっている」
