eXtreme Programming がしたい！ (日経BP 日経ソフトウエア 2002年5月号特集 「XPはソフトウエア開発をどう変えたか？」の原稿を元に再構成) (山本 啓二・水谷 雅宏)

ペアプロの日々

プロトタイピングは、前述のとおり機能単位で担当分けを行いました。その「機能単位」というのも、必ずしもきちんとしたモジュール分割によるものではなく、要件を顧客の目でグルーピングしたものだったので、個々のモジュールが複雑に依存しあっていたり、重複コードが発生したりしていました。また、担当者は自分の担当個所しか知らずに進めており、他の担当者の作業についてはブラックボックスになっていました。秩序立ったモジュール分割に基づいているならば、そのような状況は必ずしも悪いものではありませんが、この場合にそのまま進めるのは混乱を深めるばかりだったでしょう。

XP的に言うとトラックナンバー（注6）がほとんど１だったこともネックでした。全員がすべてを熟知する必要があるとは思えませんが、誰かが怪我でもしたときのためにも、他の誰かひとりはホットスタンバイしていてほしかったのです。

このあたりで、「XPで行こう！」という雰囲気が、チームの中で明確になってきました。まず顧客のニーズとして、要件の変更や急なリリースにも対応して欲しい、ということがありました。それ以上に、ペアプロが刺激的であったことがメンバーのやる気を引き出したようです。しかし、メンバーの全員がXPを全面的に肯定していたわけではありません。
「あれ？ Ctrlキーが効かないよ？」
「あ、すみません。CapsとCtrl入れ替えてるんです」

こんなつまらないようなことでも、開発者には結構なストレスになります。エディタやキーボードはチーム内で揃えるに越したことはないようですが、そんなことまでチームで縛ること自体、不満が出ないといえば嘘になるでしょう。ペアプロだとスピードが落ちるとか、プログラムを書くところを人に見られているのは恥ずかしいといった意見もありましたが、複数の視点を持ち議論しながら進められるペアプロが、実用的で楽しい一面があることは誰もが認めていました。

「このクラス重くなりすぎてると思いません？」
「だいぶ大きくなったから、少し見通しが悪くなってきてますね。でもクラスの責務ははっきりしているから、変にクラスを分割するとよけいわかりにくくならないかな」
「JavaMail（注7）を直接使ってるメール送受信のコードが結構入ってきてますよね。それってJavaMailのラッパーとして切り出して、別クラスにしとくと嬉しいと思うんですけど」
「なるほど、そこでJavaMailへの依存を切りやすくもなる、と。うーん、それは確かに悪くないと思うけど、このアプリの中ではメール送受信はすでにこのパッケージに集約されてますしね。メールがらみのAPIを切り出すとすると、パッケージ全体に影響のある大きいリファクタリングになって、少し過剰な気がするんですよね」

そんな話をしながら、コードを書き、手近な紙にクラス図やシーケンス図を書きます。あとに残すようなドキュメントではなく、議論の助けになればよいので、ごく簡単なラフスケッチです。

XPでは、「分析・設計・実装・試験」のアクティビティが並行して行われます(図2-1～図2-3参照)。クラス設計にあたる作業がテストケースの設計であるといえるでしょう。もっと上のレイヤの設計や分析は、シンプルデザインとリファクタリングが担っています。さらにテストケースはドキュメントとしても利用できますし、プログラムの変更にしたがってちゃんとメンテナンスされていきます。それらはすべてペアプログラミングの中で実施されていくのです。

XPで一番有名なプラクティスであるペアプロは、そのようにXPを実践していく上でも中心となるプラクティスです。しかし、ペアの組み方など、なかなか簡単ではありません。

わたしたちは、毎朝のスタンドアップミーティングでその日の午前中から作業を進めるペアを決定しました。プライオリティの高いストーリーにサインアップしているメンバーから優先的に、ペアになって欲しい相手を指定する、というのが基本スタイルです。ただ、そればかりだと上手くいかずに偏ってしまったりもしますので、適宜コーチが「篠原さんの今のタスクは、土屋さんと組むと上手くいくと思うけどどう？」とか、「西田さん、ずっとマスターメンテ関係ばっかりですよね。ちょっとメール送信機能のところなんか覗いておきたくありません？」などと誘導したりもします。 ペアの交代は、出来るだけ一日の間に一回はするようにしていました(朝ペアを組んで、午後一回交代、翌朝また別のペアに……)。交代するのに切りの良いタイミングは各ストーリーで違いますので、それもまたコーチが調整します。

問題に引っかかって、ペアが揃って煮詰まってしまっているときなどは、新しい人の眼から見るとすぐ解決したりします。コーチが直接アドバイスすることもありますが、その機会にペアを交代させてみたりもします。ただその場合、他の人と「交代させられた」人が「自分が抜けたとたんに解決した」とは思わないように、気を使う必要があります。

ペアの個性というのも出るようになっていました。ある人とペアでやっていると考え込みすぎて煮詰まってしまう人が、他の人と組むと考慮が浅いうちに走ってしまっていたりしました。そうといって、組む相手がそういうタイプだからそっちに引っ張られるというばかりでもないようで、このあたりはなかなか定量的には量れないようです。

昔から新人研修などのOJTをペアプロ的にやることは行われていたと思いますが、わたしたちのチームでも、途中、翌年度入社予定(そういえばもう再来週くらいに入社してくるんですね)のインターンを迎えて、ペアプロに参加してもらったこともありました。もともとコードは書けたので、品質のことやプロセスのこと、顧客のニーズのことなど、ペアプロの間にいろいろなことを吸収して帰ってもらいました。たくさん宿題も与えてあるので、彼がやってくるのが楽しみです。

楽しくなくちゃXPじゃない－Second eXtreme Iteration

顧客のストーリー

そうこうするうちに、ビジネス側から次リリースに向けた要件が、ユースケースと画面仕様という形であがってきました。本来のXPであればストーリーカードを書いてもらうところでしたが、水谷と顧客のあいだでは、画面仕様をベースにユースケースの説明をする、という形で進めていたため、顧客チームにとってはいまさらストーリーカードに落とす必要がなかったためです。

開発チームは、出揃ったユースケースを前に、さてこいつをどうやって料理してやろうか、とわくわくしていました。まずはボリュームを量ってスケジュールを立て、ストーリーの割り振りをする必要があります。ユースケース一覧を元にExcelなどで管理をすることも可能でした。しかし、メンバーの全員が作業のボリュームを直感的に理解し、進捗を常に把握していくためには、アナログな紙ベースの管理に勝るものはありません。また、ユースケースの粒度は、視点としては揃っていたものの実装工数としては大小取り混ぜられたものでした。

また、カットオーバーの期日だけが決まっており、そこから逆算し、工程を均してできあがったようなスケジュールに何の信憑性もないことはわかっています。開発者たちは(不本意ながら！)そうした経験をたくさん積んできています。今回についていえば、コンサルタントによって実現性は検証され、ボリュームも直感的にいって現実的な範囲に絞られてはいたのですが、担当者がサインアップして見積もることで、スケジュールを押し付けられたものでないと感じることが大事だと考えました。

そこでわたしたちはユースケース一覧を前に、ストーリーカードを起こしていきました。ユースケースを分割したり、あるいは関連する小さいユースケースを取り混ぜたりして、ボリュームをそろえていきます。XPでは、「上司からの内線電話も鳴らず、総務や経理からの割り込みもなく、自分が一番仕事のしやすい環境で、ぶっ通しに集中してそのタスクに取り組める一日」を理想エンジニアリング日（注8）と呼んでいます。1ストーリーのボリュームとして、おおよそ3理想日程度に揃えていきます。だいたい1理想日のボリュームは、実際には3人日程度かかるものと考えられています。この辺はトラッキングして調整したりします。

基本的にストーリーカードを書くのは、そのストーリーにサインアップしようと思っているメンバーで、コーチはそれに助言を与えていきます。サインアップしたメンバーは、そのストーリーについて顧客の考えを充分に理解した仕様ホルダーになり、また全体の進捗の中で確実にそのストーリーを完了させることが求められます。仕様ホルダーとは、開発側のメンバーで、ある範囲の仕様について確実に把握している人、のことを指しています。ユーザから導き出される機能要件・非機能要件について、ユーザと同等以上に理解していなくてはなりません。他の開発メンバーが担当個所について疑問に思った場合や、プロマネが要求変更を把握したい場合などは、仕様ホルダーに対して問合せることになります。

XPでやった場合は、あるストーリーについてのプライマリの仕様ホルダーはサインアップした1名になります。仕様ホルダーとペアを組んだ人のそれぞれが、バックアップ系としてホールドしていくことになり、トラックナンバーが1にはならないようにします。

メンバーがストーリーを選ぶ基準はそれぞれでした。「自分がそれまでかかわっていなかった分野をやってみたい」あるいは逆に「熟知している部分だから自分がやるのが一番間違いないだろう」とか、「顧客にとってこの機能は重要そうだ」、「ここは技術的に面白いチャレンジができそうだ」など、思い思いの観点でストーリーを選んでいきます。ただ、わたしたちのチームは協調性がありすぎたのか、ストーリーの取り合いになるより譲り合いになることが多かったようです。「自分で仕事が選べる」ことに慣れていなかったためもあるでしょう。それでも、できる限り自発的にストーリーを選んでいくことが大事で、そうでなかったストーリーは、サインアップしたメンバーが仕様ホルダーになりきれなかったり、他のメンバーが持つストーリーのペアにかかりきりで進められなかったりもしました。

この作業は開発チームが行い、水谷はそれを隣で楽しそうに眺めながら自分の仕事をしています。なにか質問があればすぐ答えをもらえる状態で進めましたが、半日もかからずに全部のユースケースをストーリーカードにしました。この作業によって開発チームは顧客のニーズを汲むことができましたので、大変重要な工程だったと思います。水谷の表情が曇ったのはこのあとです。メンバーがストーリーを見積もってみると、彼の考えていた工数を大きく超えることがわかったからです。

ここでわたしたちは短い議論をしました。顧客のビューに立っている水谷にとり、実現できる機能が減ることが嬉しいわけはありません。しかも、彼自身の経験に照らしてこれならいけるだろうというまでに顧客と調整をしてきた結果なのですから、彼の見積りを否定されたようでもあり、顧客に合わせる顔がないとも感じたはずです。

しかし、開発チームとしては、これ以上ストーリーを詰め込んだ場合、充分な品質が保証できなくなるであろうと説明しました。スケジュールが厳しくなってくると、削減されるのはいつも品質向上の工数です。顧客としても月に500時間働いて書いたような品質のコードは無用ということで、イテレーションを短く取り結果をフィードバックすることで、今後の見積りの精度を上げていくことを条件に、当初よりは開発チームの見積りに近づいた線で同意ができました。

タスクカードを書いてみた。

ビジネス側の要件に沿ってストーリーがリストアップされましたので、次はサインアップ、タスクカード化に進みます。サインアップは前の工程で大体済んでいるようなものなので、各自が担当するストーリーを分割してタスクカードを作っていきます。

プライオリティの高いところから、開発チーム全体が集まってタスクカードにしました。初めてのことなので、どんなことをタスクにすればいいのかが今ひとつわからなかったためです。タスクは純粋にテクニカルなものと見なして、開発チームの作業量をはっきりさせるため、「ストーリーを完成させるために必要な作業」はすべてタスクに挙げることにしました。

そうすると、「自動ビルド環境を作る」とか「デザイナさんが作ったHTMLをチェックする」とか、特定のストーリーに紐付けにくいタスクがたくさん出てきます。わたしたちは、それらもどこかのストーリーに織り込みました。「自動ビルド環境を作る」のはプライオリティが高いので最初にやるストーリーに、「デザイナさんが作ったHTML」は後から届くので届く予定の時期に行っているはずのストーリーに、といった感じでした。これは少し失敗だった気がします。見積りが曖昧になってしまいますし、ストーリー間の依存関係が複雑になってしまいます。「技術的な準備を行う」といったストーリーを別途立てて、その中にタスクを入れていれば、開発のボリュームと付随する作業のボリュームを関連づけて計測できたかもしれません。

ビルドも自動化

わたしたちはCVS（注9） とant（注10）を併用し開発環境を構築していたので、それを利用してビルドも自動化していました。Linux上にCVSサーバを構築して、同じマシンのcronでCVSから最新版のチェックアウトとリビルドを行ったわけです。

開発者がソースをリポジトリにチェックインする際には、全テストケースを実行してエラーがないことを確認してから行う、というのが建前ではありました。しかし、データベースと連携して大量データのCRUDを試験したりJ2EE環境のテストがあったり、テストケースは日々充実してくるとともに重くもなってきます。このイテレーションの終わりごろには、全テストケースを実行するには小一時間かかるようになっていました。こうなってくると、ちょっと書いてちょっとテストしてすぐチェックイン、というリズムが失われてきます。

そこで開発チームは、手を入れた部分に影響を受けるはずのテストだけを実施すればよいことにしました。全体のテストケースの実行、テスト失敗時のエラーメール送信などをサーバマシンで定期的に行うことにしたのです。テストケースはCompositeパターンになっているので、たとえばパッケージ内のテストケースをまとめたテストスイートを作っていけば保守も容易になります。想定した範囲を超えて他のテストケースを失敗させるようであれば、それは依存関係が正しく保たれていないことを意味するわけですから、改修が必要な問題も検出できる……つもりでした。

実際には、テストケース自身のバグがあったり、テストケース同士に依存関係が生じてしまったり、それもコードレベルではなくテストデータを介した依存関係があったり、必ずしも原因追求は容易なこととばかりは限りませんでした。特に、テストデータを介した依存関係は非常に見つけにくいものでした。全体テストが失敗すると、ひどいときには一日以上も実装を止めて対処しなくてはならなかったこともあります。

これはテストケース自身がテストされることがない以上、簡単には解消できない問題と思われます。テストケースもペアプログラミングで書かれるものですし、既存のクラスを拡張する場合は、本体のコードよりもテストケースのコードによりよく目を通すものですから、コードの品質としてはそれなりのものになっていたはずです。

問題を一番難しくしていたのは、テストケース自身のモジュール分割がうまくいっていなかったことだと考えています。テストケースはその性格上、検査対象の値が多くハードコード(良くてもクラス定数として定義)されるものですので、保守はそれなりに難しくなるものです。複数のテストケースがテストデータを介して依存しあうのが問題だからテストデータを切り分けようといっても、実効のあるテストデータを毎回そんな大量に用意するのは大変ですので、できるものなら流用したいわけです。この問題について、わたしたちは決定的な解決策を見つけていません。読者の皆さんの中でよいアイディアをお持ちの方がいれば、ぜひわたしたちに連絡（注11）をください。

それでも全体テストとクリーンビルドの自動化には大きなメリットがありました。テスト時間が長くなりすぎてしまうという問題については、たとえば並列実行などの手段で回避できる場合もあるでしょう。わたしたちも次の機会には手法を改善して、皆さんにもまたお知らせできればいいと思っています。

・ XP-jp Mailing List
http://objectclub.esm.co.jp/eXtremeProgramming/

リリースに向けて

全体スケジュール表をご覧になればおわかりいただけると思いますが、このプロジェクトでは、7ヶ月間の開発期間を大きく4回のイテレーションに分け、その中で通産10回のリリースを行いました。後述するシステムテスト工数も含め、他にも顧客のオペレータへ技術訓練を行ったり、データセンタへのインストールまで、そのたびに煩雑な作業が発生しました。定型的な作業であれば自動化してしまうところですが必ずしもそうでばかりはないですし、ここでトラブルがあれば、最悪の場合、施設に訪れていただいているエンドユーザの目に触れることになりますので、最後は結局人手になります。この作業が、当初の予想を超えてかなりな負荷になりました。段々に習熟してくるものとはいえ、物理的に削減できない時間もあります。スモールリリースを行う際には気をつけておきたいところです。

さて、年末に向けて最終リリースの開発が完了し、リリースパッケージを作成することになりました。顧客からは、次期開発があればまたわたしたちに頼むと仰っていただいており、先方としては技術ドキュメントは必要ない、とのことでした。最終版のユースケースとデータベース仕様書、各種マニュアルとインストーラだけを作ればよいわけです。これが最後のストーリーになります。

しかしXPといえども、回りつづけているプロジェクトであればこそドキュメント不要ということになりますが、何ヶ月かののちにテストケースやソースコードと走り書きのUMLの断片、ストーリーカードとタスクカードから記憶を掘り起こして追加開発を行うのは困難なことでしょう。そこで、内部向けドキュメントとして、ソースコードからリバースエンジニアリングしたクラス図、シーケンス図、パッケージ図などを作成しました。ドキュメント作成もメンテナンスの苦労さえなければ、それほどの工数はかかりません。

すべてがXPになる－eXtreme Project

できたこと、できなかったこと

今回わたしたちがXPをプロジェクトに適用してみて、XPのプラクティスとしてできたこととできなかったことがあります。(表3 12プラクティス実施結果　参照してください)

計画ゲーム、オンサイト顧客といった顧客が重要なアクターになるプラクティスについては、擬似顧客というロールを導入することで、ほとんど確実に行えました。ビジネス上のキーパーソンである顧客の担当者が、開発チームにつきっきりになるというのは、今の日本のビジネス慣習上ちょっと受け入れられにくいものでしょうが、今回の手法はそれに対する現実解であったものと思います。プロキシを置く以上ある程度のレスポンスの低下は発生しますし、擬似顧客自身が行ったり来たりで、100%オンサイトにはなりません。このあたりも二重化するなどの手段は取れそうです。

ただ、本来、ストーリーカードにはそれに対応した自動受入テストがセットであるべきです。今回わたしたちが実現できなかったプラクティスのうち、もっとも重要だったはずと感じているのがこの自動受入テストです。ユニットテストだけを自動化したところで、本当にリグレッションテストに通っているのか、リファクタリングした拍子に本来必要なクラスをテストごと失ってはいないか、という不安が残ったのです。自分が書いたコードが、本当に顧客の求めているものと一致しているのか、ストーリーが完了したと自信を持って云えるのはいつなのかわからなくなってしまったのです。

そのため「システムテスト」という独立した工程を準備する必要が生まれてしまい、イテレーションが進むにつれてその工数は膨らみました。「今日ここまでのところをリリースしてくれ」と云われてもそれは不可能になってしまったのです。これは実際に大きな損失でした。イテレーションの途中で、顧客が「突然だけど、来月イベントをやることになったんだ。それにあわせて、例の機能を盛り込んだバージョンをリリースしてくれないか？ 他のの機能は後回しにしてもらっていいから、工数的にはそれで足りるはずだよね」といいました。これはＸPの精神に照らしても顧客の正当な権利だったので、わたしたちは無理矢理システムテストの工程を割り込ませて、XPでなくとも許されないような残業もしましたが、そのリリースで予定していたいくつかのストーリーは後回しになってしまいました。後のイテレーションで取り返せたものもありますが、お蔵入りになってしまったアイディアもありました。リリース作業の工数のことも含めて、小規模リリースについては改善の余地があります。

それだけでなく、Kent Beckも最初のXPプロジェクトでシステムテストという工程を設けてしまい、それは大きな失敗だったと述べていますが、開発と試験を切り離すことは、開発者の中に「どうせバグがあったとしても後の試験で見つけてくれるさ」という気分を生んでしまいます。実際に落ちる品質ももちろんですが、本当の問題は別にあります。「いつでも顧客のビジネスに一致したものを最高品質で作り続けているんだ」という想いが開発者に誇りをもたらし、高いモチベーションを持って働きつづけることを可能にします。「どうせ使われるかどうかわからない機能だし」とか、「どうせ……」とつぶやきながらの仕事は、誰にとってもいいことがありません。こうした状況は早く打開すべきだったのです。

今回は、わたしたちの顧客自身はテストを書くことができませんし、それを代行できたはずの水谷はすでにオーバーワークでしたので、このうえ自動テストのスクリプトコードを書く余力はありませんでした。しかし、それで仮に開発工数が削られることになったとしても、わたしたちは開発チームから顧客をサポートして自動受入テストを書くメンバーを割く必要があったのです。

また、それに関連した失敗のひとつは、要求を管理するものとして、ユースケースとストーリーカードの二重管理になってしまったことです。本来であればストーリーカード自体を顧客がメンテナンスする(XP的には古いカードは破り捨て、新しいカードを書く)に越したことはなかったのですが、そうはいきませんでした。水谷がフルタイムで開発者と共にいられたわけではなく、むしろ本当の顧客のそばにいる時間を長く取る必要があったため、水谷はユースケースを持ち運んでいました。そのユースケースとストーリーカードの同期に漏れが生じたり時間がかかったりしたことがありました。

ストーリーカードやタスクカード、グラフといったアナログな紙ベースのツールというのは、メンバーが状況やボリューム、内容を把握するにはとてもいいツールでした。きれいなExcelの表を作る必要などまったく感じることはありませんでしたが、如何せんアナログの方が手間がかかる場面というのはあります。

大量のカードを、簡単にコピーしておき複数の版からdifｆを取ってマージする、というのはなかなか困難でしょう。ネットワーク越しにやりとりするわけにもいきません。こうなってくると、やはり本物のオンサイト顧客を持つ体制のほうが、少なくとも便利ではあるなぁと思わざるを得ません。

だからといって本当のオンサイト顧客でやるしか手がないというのも残念な話です。この問題についてもさらに改善の手立てを探していこうと思います。いい手段を思いついた方はぜひわたしたちにも教えてください。

リファクタリングとシンプルデザインについては微妙なところです。過剰な設計を前もって行うことはしない、というYAGNI(You're NOT gonna need it)を心がけてはいましたが、結果としては重複コードを充分に排除しきれてはおらず、リファクタリングが不足した感があります。また、時折コード全体に影響のあるような大規模なリファクタリングが必要になることもありました。そうなると全体テストや継続的インテグレーションに失敗する状況が続いてしまいます。このあたりは、「必要充分な設計」を前もっては掴みきれないことによるものでしょう。わたしたちはフレームワークを持っていたことで、検討されたアーキテクチャ設計を流用できましたから、だいぶ助けられたと思います。しかし、わたしたちのプロジェクトからフレームワークへのフィードバックは簡単ではありません。フレームワークやコンポーネントといった流れとXPをどう連携させるか。これについては今後も実践の中で答えを探していかなくてはならなさそうです。

共同所有権については、CVSを利用することで実現できました。CVSについては、ソースファイルを編集する際に、リポジトリ内のファイルを排他制御しません。誰かが編集中のソースを他のユーザも編集できるので、編集したいファイルがぶつかってもボトルネックにはなりません。その代わり、ソースファイルをチェックインしようとすると、他のユーザの編集内容とコンフリクトすることがあります。機械的にマージしてすむというものでもないので、ともするとここで時間を取られることがあります。これはツールの使いこなしでずいぶん解消できることでしょう。

コーディング標準は、あまり強い縛りはもうけませんでした。Sunの提供するコーディング規約（注12） をそのまま利用しただけで、一番読みなれたソースコードであるJDKのソースコードに準拠する、というのが唯一の方針でした。それで一般的な規約としては充分でしたが、メソッドやクラスの命名について悩むことが多かったので、そのあたりにも少し指針を用意しても良かったように思います。事前の分析・設計工程を持たないため、そこで名前を検討するのが設計の代わりになったとも考えられるのですが。

比喩(メタファ)は、開発チーム主導ではほとんど使っていませんでした。顧客チームがビジネスを検討する際に、多くの比喩を出してくれていたのでそれに乗って議論・開発しました。もしそうでなかったなら開発チーム内で比喩を作ることは大事だったろうと思います。UMLやデザインパターンもそうですが、XPに限らず、コミュニケーションを円滑にするための道具を活用しなくては上手くいきません。

最後に、週40時間についてですが、ほとんど実現できませんでした(読者の皆さんの溜め息が聞こえてくるようです……)。全体をならすと週45時間～55時間といったところでしょうか。よく言われることですが、ペアプロはとても疲れますので、この稼動時間はちょっと辛いものでした。それでも「週40時間」という目標を置き、速度を測定しながらやったことで、ハードな時期には品質や効率が下がる、ということをまざまざと感じることができました。感覚的に云うと、普段8時間で100の分量、100の品質のものを作っているとしたら、12時間にしたときには75の品質で140の分量のものを作っている感じです。個人差もあるでしょうが、1.5倍の時間で1.5倍の量は作れませんし、品質×分量が単純な掛け算だとすると、わずか5%くらいの生産量向上になります。残業好きの管理者の方にはぜひこのあたりを理解してもらいたいと思います。

12のプラクティスより4つの価値

XPに興味を持つ人たちは、これらのプラクティスがXPの本質ではないことを理解する必要があると思います。ペアプロだとか週40時間のように、XPに興味を引くキーワードを散りばめているのは、XPの産みの親たちの上手い戦略です。わたしたちもまんまと乗せられましたが、戦略に乗せられてXPに眼を向けた後は、XPの本質である4つの価値に主眼を置くべきです。

XPでいう4つの価値とは「シンプルさ、フィードバック、コミュニケーション、勇気」を指します。

airplane rule（注13）を持ち出すまでもなく、シンプルであることは美しく堅牢という価値を持ちます。技術者にとっての美意識の問題のようですが、顧客にとっても、「支払った分だけ必要なものだけが手に入る」というシンプルさは、これまでのソフトウエア開発ではほとんど不可能だった価値です。それをどのように実現していくかを、顧客と開発者が共に考えることが大切なのでしょう。

日々新しいことに臨みつづけるソフトウエア開発の現場では、教科書どおりに行くことなどひとつとしてありません。顧客と自分たち自身、ソフトウエアそのものから、フィードバックを受けつづけていかねばなりません。XPも含め、各種の開発方法論は、その踏み台くらいのつもりでいたほうがよいでしょう。見積り精度向上のためのトラッキングも大事ですが、そればかりでなく、自分たちの新しいプラクティスを生み出す工夫・改善活動のために、実践からのフィードバックを受けつづけたいものです。

「変化ヲ抱擁セヨ(Embrace Change)」というのは素敵なコピーでした。変化は恐怖感を伴うために必ず抵抗を受けるものです。「ヨクないこともあるけど、いままでなんとかやってこられたじゃないか。ここでそんなことして、上手くいかなかったらどうするんだ？」そういって現状維持を求める人に、恐怖に打ち克つ勇気を与えてあげられるのがXPです。根拠のない勇気は蛮勇ですが、XPの掲げる勇気は、テスティングを始めとするプラクティスで武装されているのです。「テスティングで上手くいくこともあるのはわかったよ。でも、こんな危険だってあるじゃないか、それはどうするんだ」。そんな抵抗を受けることがあるでしょう。そのときは、あなたがXPに新しいプラクティスを付け加えるチャンスです。

そして、ソフトウエア開発は、開発者と顧客とで作り上げるチームが、それまでになかった解決策を創造する人間のプロセスです。工場の稼働率や生産効率を語るのと同じ文脈では語ることができません。プロジェクトチームを機能させるのは、メンバー同士の有機的な繋がりで、それはシナプスのように刺激を受けて成長します。堅苦しい会議やキレイに作った進捗管理表は、コミュニケーションの道具ではありません。それが必要なこともあるでしょうが、有機的なチームを成長させる役には立ちません。それよりも、タスクカードやストーリーカードを前に、キーボードを叩きながら、喫煙所でばったり出会ったときに、要するにほとんどいつでもチャットします。それが大事な刺激になります。リリースが無事に済んだときには、みんなでなにかおいしいものを食べて騒ぎましょう。そうすればきっと、明日からもっとうまく楽しくプログラミングできるようになります。

それでは、Happy eXtreme Programming!

表3 12プラクティス実施結果

（注6）トラックナンバーとは、プロジェクトメンバーの何人がトラックにはねられると、人員を追加したとしてもプロジェクトが崩壊するかを表す数字で、最悪は１になります。「簡単に取替えが効くような、組織の歯車にはなりたくない」なんてことは思うものですが、簡単に取替えが効かないならなおさら代わりは用意しておかないと、風邪ひとつ引けなくなってしまいます。やっぱり重要な個所ほど冗長構成にしておかなくてはいけませんね。

（注7）http://java.sun.com/j2ee/ja/javamail/index.html

（注8）各開発チームで、この単位には好きな名前をつけるといいと言います。XP本にはチームのみんなが好きなお菓子から「グミベア」と名付けたりした例が出ています。わたしたちは、Javaのキャラクターに敬意を表して「デューク」と呼びました。「お、今週は予定より2デュークも進んでるぞ！」 Duke:http://java.sun.com/features/1999/05/duke.html

（注9）フリーのバージョン管理システムとしてデファクトスタンダードとなっている。http://www.cvshome.org/

（注10）Unix/C環境におけるmakeに似た、Java用ビルドツール。さまざまなプラグインが提供されており、JUnitなどのテスティングフレームワークもantから実行できる。http://jakarta.apache.org/ant/

（注11）冒頭のアドレスまで直接メールをいただくか、XP-jpなど関連するメーリングリストに投稿をいただけると嬉しく思います。

（注12）http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

（注13）複雑になればなるほど故障が増えることを飛行機に喩えた言葉。二つエンジンを持つ飛行機は、単発エンジンの飛行機の二倍エンジンに問題を抱えることになる。
http://www.tuxedo.org/~esr/jargon/html/entry/airplane-rule.html