エクストリームプログラミングは、シンプルさ、コミュニケーション、フィー ドバック、そして勇気に価値を置くソフトウェア開発手法(discipline)であ る。チーム全体を一箇所に集め、シンプルなプラクティスを用いて十分なフー ドバックを得ることにより、チームの現在地点が分かるようにし、プラクティ スをチーム固有の状況に調整する能力を与える。

エクストリームプログラミングにおいては、プロジェクトへの貢献者は、 全員が「チーム全体(Whole Team)」の一部である。 チームは「顧客(The Customer)」とよばれるビジネス代表のまわりに 形成される。顧客はチームと同じ場所に席をもち、毎日チームとともに 作業する。

• Core Practices: チーム全体(Whole Team)

エクストリームプログラミングチームは、次に何を行うべきか決めるため、 プロジェクトがいつ終了するかを予測するために、シンプルなプランニングと トラッキング手法を用いる。チームは、ビジネス価値にフォーカスしてソフト ウェアを作り出す。それは、「顧客」が定義したすべてのテストをパスし、完全に 動く小さなリリースの連続の中で生み出される。

• Core Practices: 計画ゲーム(Planning Game), 小さなリリース(Small Releases), 顧客テスト(Customer Tests)

エクストリームプログラマは、ペアからなるグループとして作業する。シンプ ルな設計と徹底的にテストされたコードを用いて設計をたえず改善し、いつで も現在の要件にぴったり合うように設計を保ち続ける。

• Core Practices: シンプルなデザイン(Simple Design), ペアプログラミング(Pair Programming), テストファースト開発(Test-First Development), 設計の改善(Design Improvement)

エクストリームプログラミングチームは、システムをたえず統合して実行可能 な状態に保つ。プログラマはすべての製品コードをペアで書き、いつでもいっ しょに作業する。全員がコードを理解し、いつでも改善できるようにコードは 一貫したスタイルで書かれる。

• Core Practices: 継続的インテグレーション(Continuous Integration), コードの共同所有(Collective Code Ownership), コーディング標準(Coding Standard)

エクストリームプログラミングチームは、システムがどんなものかを表現する 共通のシンプルな絵を共有する。全員が、いつまでも持続できるペースで働く。

• Core Practices: メタファー(Metaphor), 持続可能なペース(Sustainable Pace)

XPプロジェクトへの参加者は、全員が1つの場所に座席を持ち、1つのチームの メンバとなる。このチームはビジネス側の代表 -- 「顧客」 -- を含んでいな ければならない。「顧客」は要件を与え、それにプライオリティを付け、そし てプロジェクトを「運転」する。もし「顧客」あるいはその補佐が、問題にし ているドメインの知識を持ち、実際に何が必要とされているかを知っている本 当のエンドユーザであれば最高だ。チームにはもちろんプログラマが含まれ る。チームには、「顧客」が受け入れテストを定義するのをサポートするテス ターが含まれているかもしれない。アナリストも、要件を定義する場面で「顧 客」を手助けすることができる。通常はコーチと呼ばれる人がいて、チームが うまく行くのをサポートし、全体の進行役となる。また、開発リソースを提供 し、外部との交渉をしたりチームの活動をコーディネイトする、マネジャと呼 ばれる人もいるだろう。これらの役割はどれも、必ずしも1人の個人が受け持 つ必要はない。: XP チーム全員は、できることをできるように受け持って チームに貢献する。最高のチームとは、1つのことしかできないスペシャリス トの集団ではなく、特別なスキルを持った普通の貢献者の集まりなのだ。

XPのプランニングでは、ソフトウェア開発でキーとなる2つの問題を扱う: 締 め切りまでに何が達成できるかを予測すること、そして、次に何をすべきかを 決めることだ。ここでの強調点は、何が必要とされそれにどれくらいの時間が かかるかを予測すること(これはかなり難しい)ではなく、プロジェクトを「運 転」することである(これはかなり簡単だ)。XPにはキーとなるプランニング のステップが2つある。それぞれが、この2つの問題を扱う。

1つのプラクティスである「リリースプランニング」(Release Planning)では、「顧客」が欲しい機能をプログラマに提示し、プログラ マが困難さを見積もる。コストの見積もりを得て、かつ、機能の重要さに対す る知識を持った上で、「顧客」はプロジェクトの計画を立てる。最初のリリー ス計画は当然正確さに欠ける: プライオリティも見積もりも完全なものではな く、チームが動き始めるまで、実際にどの位の速度で進めるかも分からない。 この最初のリリース計画でさえ意志決定のためには十分正確なものであるが、 加えて XP チームはリリース計画をたえず変更していく。

「イテレーションプランニング」(Iteration Planning)というプラク ティスにおいて、チームに2週間毎の方向性を与える。XPチームはソフトウェ アを2週間の「イテレーション」で構築し、イテレーションの終りには実際に実 行可能で有用なソフトウェアを提供する。「イテレーションプランニング」で は、「顧客」が次の2週間に欲しい機能を決める。プログラマはそれをタスク にブレークダウンし、それぞれのコストを見積もる(「リリースプランニング」 よりも詳細なレベルで)。前回のイテレーションで達成された作業量に基づいて、 チームは現在のイテレーションで引き受けられる分にサインアップする。

この2つのプランニングステップはとてもシンプルでありながら、とても有用 な情報とプロジェクトの「運転」を制御する手段を「顧客」の手に与える。2 週間毎に、進捗は完全に目に見えるようになる。"90%終了"というような言い 方はXPには存在しない : 機能を表現するストーリは、「完成した」か「完成 していない」かのどちらかだ。このような透明性のため、ちょっとしたおもし ろいパラドクスが生まれる。一方ではこれだけ透明なため、「顧客」は進捗が 思わしくなければプロジェクトをキャンセルしてしまうことだってできる。ま た他方では進捗がこれだけよく目に見え、次には何を仕上げるべきか決めるこ とができる。このため、XPプロジェクトはプレッシャーやストレスが小さい のに、より多くの必要機能を提供できる傾向にある。

必要とされる機能を提示するという行為の一部として、XP「顧客」は 機能が動作していることを確認するための自動化された受け入れテストを 定義する。チームはこのテストを構築し、自分自身にそして顧客に 機能が正しく実装されていることを証明する。ここで自動化が重要なのは、 時間が切迫すると手動のテストは省略されてしまうからだ。これは、 夜、いちばん暗くなってきたときにライトを消して走るようなものだ。

最高のXPチームは顧客テストをプログラマテストと 同等に扱う: テストが一旦走ったら、ずっと正しく走るように維持する。 これは、システムが改善の方向にのみ向かうこと、常に前に向かって 小刻みに進むこと、決して逆方向に滑り出さないことを意味する。

XPチームは、小さなリリースというプラクティスを2つの方法で行う。

1つめは、チームは動いていてテストされたソフトウェアを、「顧客」によって選 択されたビジネス価値を持って、毎回のイテレーションで提供すること。 「顧客」はこのソフトウェアを、どんな目的にも使うことができる。それは 評価であってもかまわないし、エンドユーザへのリリース(強く推奨する) であってもよい。もっとも重要な側面は、各イテレーションの終りに、 ソフトウェアが目に見え、顧客に手渡されることだ。こうすることで、 すべてをオープンで具体的なものに保つ。

2つめは、XPチームはエンドユーザにできる限り頻繁にリリースすること。XP でのWebプロジェクトでは毎日。受託のプロジェクトであれば毎月かそれより 頻繁に。シュリンクラップのパッケージ製品であっても4半期毎にはリリース する。

こんなに頻繁によいバージョンを作るのは不可能に思えるかもしれない。しか し、世界各地のXPチームはいつだってこういう風にやっているのだ。これにつ いて詳しくは、継続的インテグレーション (Continuous Integration)を参照して欲しい。そして、頻繁なリリース は、ここに顧客テスト(Customer Tests)およびテストファースト開発(Test-First Development)として述 べたような、XPのテストに対する徹底的なこだわりによって信頼性が保証され ていることに注意して欲しい。

XP チームはソフトウェアをシンプルな設計へと作り込む。 最初シンプルに始め、そしてプログラマテスト (programmer tests) と 設計の改善 (design improvement)によってその状態をキープするのだ。 XPチームはシステムの現在の機能性を満たすために適切な設計を 保つ。無駄な動きはなく、ソフトウェアはいつでも次の変更 への準備が整っている。

XPにおける設計は、一時的なものでも先行して行うものでもなく、いつでも行 うものだ。リリースプランニングやイテレーションプランニングにも設計のス テップはあるし、チームは素早く設計セッションを行う。さらにリファクタリ ングで設計を改訂する。XPのようなインクリメンタルでイテラティブなプロセ スでは、よい設計こそが本質的に重要だ。このため、全開発を通して、設計に これほどまでに重点が置かれているのだ。

XPのすべての製品ソフトウェアは、二人のプログラマで作成される。 二人は同じマシンに向かって横に並んで座る。このプラクティスの おかげで、すべての製品コードが少なくとも1人の他のプログラマに よってレビューされ、そしてその結果、よりよい設計、よりよいテスト、 そして、よりよいコードが生み出される。

2人のプログラマが1人分の仕事をすることは非効率 に見えるかもしれない。しかし、真実はその逆だ。 ペアプログラミングに 関する研究は、ペアで行う方がよりよいコードを一人で行ったのと 同程度の効率で生産することを示している。その通り: 二人の頭は一人の頭より良いのだ！

ペアプログラミングを試しもしないで反論するプログラマもいる。 うまくやるには少し練習も必要だし、結果を見るには2,3週間やって みる必要があるだろう。ペアプログラミングを学んだプログラマの 90%は、ペアプログラミングを好むようになる。だからわたしたちは、 チーム全体にこれを強く推奨している。

ペアを組むことは、よいコードとテストを生み出すことに加えて、 チーム全体への知識の伝達に貢献する。ペアを交代するにつれ、 全員が他人の特別な知識を学ぶことができる。プログラマは学習し、 スキルが向上し、チームにとってそして会社にとって価値がある 動きとなる。ペアを組むことは、XP と無関係にも、全員の大きな 喜びとなる。

エクストリームプログラミングは、フィードバックに関しても徹底的にこだ わっている。そしてソフトウェア開発では、よいフィードバックのためにはよ いテストが必要だ。最高のXPチームは、「テストファースト開発」プラクティ スを実践し、「まずテストを追加し、次にそれを動かす」という非常に短いサ イクルを回している。

テストを書くだけでは十分ではない: それを走らせなければならない。ここで も、エクストリームプログラミングは極限を目指す。この「プログラマテス ト」すなわち「ユニットテスト」は、すべて収集され、全ペアは毎回コードを リポジトリにリリースするたびに、プログラマテストのすべてを正しく走らせ なくてはならない(そしてペアは普通一日に2回以上リリースする)。いつでも 100%！ これで、プログラマが瞬時に自分がやったことに対するフィードバッ クを得ることになる。さらにこれらのテストは、ソフトウェアの設計が改善さ れていくにつれて、非常に貴重なサポートを提供することになる。

エクストリームプログラミングは、ビジネス価値を毎回のイテレーション で提供することに焦点をあてる。ソフトウェアプロジェクトの全般に 渡ってこれを達成するには、そのソフトウェアがうまく設計(well-design) されていなければならない。さもなければ、プロジェクトは失速し最後には 行き場を失う。だからXP は、「リファクタリング」と呼ばれる継続的な 設計改善プロセスを用いる。この名前は Martine Fowler の本のタイトル 「リファクタリング: プログラミングの体質改善テクニック」でもある。

リファクタリングのプロセスでは、重複(悪い設計の確固たる兆候だ)の削除、 そしてコードの「結合度(coupling)」を下げ、「凝集度(cohesion)」を向上す ることに注力する。高い凝集度と低い結合度は、少なくともここ30年間うまく 設計されたコードの指標であると認識されてきた。その結果、XPチームはよ い、シンプルな設計から始めて、いつでもそのソフトウェアのための、よい、 シンプルな設計を保つことになる。このおかげでチームの開発スピードは保た れ、そして事実、一般にはプロジェクトが進むにつれてスピードが上がるの だ。

リファクタリングはもちろん、設計が進化してもどこも壊れていないことを保 証する包括的なテストによって、強力にサポートされている。このため、顧客テスト(customer tests)とプロ グラマテスト(programmer tests)が決定的に重要な要素となる。XPプラク ティスは互いに依存しあっている。独立して使うよりも一緒に使った方がさら に力を発揮する。

エクストリームプログラミングチームは、いつでもシステムを完全に統合 された状態に保つ。デイリービルドなんて臆病者がやることだ: XP は一日に何度もビルドする(ある40人のXPチームでは一日に 8～10回ビルドする!)。

このプラクティスの利点は、あなたがかつて聞いたことがある(あるいは関 わっていた)プロジェクトを思い出してみるとよくわかる。ビルドが週一回も しくはそれ以下だったとすると、通常は「統合地獄」に陥る。いろんなものが 壊れ、しかも誰もなぜだか分からない。

インテグレーション(統合)の頻度が低いと、ソフトウェアプロジェクトは深刻 な問題を抱えることになる。まず1つめに、インテグレーションはよいコー ド、動くコードを出荷するために決定的に重要であるにもかかわらず、開発 チームがそれを実践しておらず、さらに、ときにはシステム全体のことをよく 知らない別の人々に任されることだってある。2つめに、インテグレーション の頻度が低いコードは、(私がよく言う)「バギーな」コードになりやすい。統 合前に行なったテストでは発見できなかった問題が、インテグレート時に忍び 込む。3つめとして、統合プロセスが弱いとコードの凍結期間が長くなる。 コードが凍結されるということは、本来ならプログラマが出荷されるべき重要 な機能に費すことができる長い期間をロスし、その機能が抑制されてしまうと いうことだ。これでは、あなたのマーケットでのポジションやエンドユーザと の関係は弱くなる。

エクストリームプログラミングプロジェクトでは、いつでも、どのペアでも、 コードのあらゆる箇所を変更することができる。これは、すべてのコードが多 数の注目を集めるという利点があり、このおかげでコードの品質が上がり欠陥 が減る。そして、もう1つの利点もある: コードが一個人に所有されている場 合は、要求された機能がヘンな場所に入れられてしまうことがよくある。これ は、あるプログラマがある機能をコードのどこかに入れようとしているが、そ のコードが自分の所有でない場合に起こる。所有者が忙しくてそれをやる暇が ないので、しかたなくその機能を本来入れる場所ではない自分のコードの中に 入れてしまうのだ。これは、醜く、保守が難しく、重複が多く、そして凝集度 の低い(悪い)プログラムを生む。

よく理解していないコードに対して、全員が盲目的に修正を入れようとする と、共同所有は問題になるだろう。XP はこの問題を解決するために、2つの技 法を使う: プログラマテスト(programmer tests)がミス を見つけるし、ペアプログラミング(pair programming) は見知らぬコードにエキスパートとペアになって取り組む最良の方法だ。 よい修正が必要な時にできるということに加えて、このプラクティスは 知識をチームに伝搬させることができる。

XPチームは共通のコーディング標準に従う。システムのすべてのコードが (とても有能な)一人の人間によって書かれたように見えるべきだ。 標準の詳細は重要ではない: 重要なのはすべてのコードが見慣れた カタチをしていること。これにはコードの共同所有も貢献する。

エクストリームプログラミングチームは、プログラムがどのように動くかにつ いての、共通したビジョンを作り出す。これが「メタファー」と呼ばれるもの だ。うまく行けば、メタファーは簡潔な記述でプログラムの動作を喚起する。 例えば、エージェントベースの情報収集システムを、「このプログラムは蜂の 巣のように動きます。花粉を求めて外に出て、集めて帰って来るのです」と説 明する。

ときどき、十分に詩的なメタファーが思い付かないことがある。たとえ鮮明な イメージがない場合でも、XPチームは共通のネーミング体系を使う。この ネーミング体系によって、システムがどのように動くのか、どこを見れば探し ている機能があるのか、あるいは追加しようとしている機能をどこに入れるの が正しいのか、確実に全員が理解するようにする。

エクストリームプログラミングチームは、長い期間エクストリームであり続け る必要がある。ハードな仕事をするが、同時に、いつまでも持続可能なペース を維持する。これは、効果的であれば残業をすることもあるということであ り、また、通常は来る週毎に生産性を最高にするように仕事をするということ だ。最近ではデスマーチプロジェクトは生産的でもないし、高品質のソフト ウェアを生産するものでもないことが、よく理解されてきている。XPチームは 勝つためにエクストリームなのであり、死ぬためにエクストリームなのではな い。

エクストリームプログラミングは、シンプルさ、コミュニケーション、 フィードバック、そして勇気に価値を置くソフトウェア開発手法である。チー ム全体を一箇所に集め、シンプルなプラクティスを用いて十分なフードバック を得ることにより、チームの現在地点が分かるようにし、プラク ティスをチーム固有の状況に調整する能力を与える。

次回の記事では、よく聞かれる共通の質問と、XP のバリエーション について議論する。

Copyright © 1999-2001, Ronald E Jeffries
Copyright © 2001, Kenji Hiranabe (Japanese Translation)