Advanced Ruby：RubyUnit (Testing Framework) -XPをはじめよう
Document Actions
Advanced Ruby：RubyUnit (Testing Framework)
Part 1 : XP をはじめよう
スライドショー版はこちら (PowerPoint)
はじめに
RubyUnit は，eXtreme Programing (XP) とよばれる開発手法において単体テスト用に使われるツール： Testing Framewrok (xUnit) の Ruby 版です．RubyUnit の説明をする前に，まず RubyUnit 開発のきっかけとなった XP について説明しましょう．
XP (eXtreme Programming) とは
XP は，最近もっとも注目されているソフトウェア開発方法論の一つです．
- 小人数（2人から10人程度）による開発
- 仕様がはっきりせず，変更が絶えないプロジェクト
に適しています．eXtreme, 「極端プログラミング」と名づけられた背景には，次のような考え方があります．
「もし，XXX が開発にとっていいことなら，その XXX を最大限にまで引き上げよう」
つまり，開発を成功に導く要素を極端なレベルまで引き上げてしまえ，ということです．そのうちのいくつかとして，例えば・・
- コードレビューするのがいいんだったら，いつもコードレビューしよう
- テストするのがいいんだったら，いつもテストしよう
ということを行います．前者は，いつも 2人でコーディングするペアプログラミングとして，後者はコードを修正するたびに行う Unit Test と顧客がそのシステムを承認するために行う Acceptance Test (Functional Test) として実践されます．
Embrace Change - 変更を受け入れよう
ソフトウェア開発には仕様変更がつきものです．そのため，開発方法論，特にオブジェクト指向では昔から次のようなことが言われています：
「将来の仕様変更を予想し，それに柔軟に対応できるような設計にしよう」
これは，本当に正しいのでしょうか？ XP ではまずこの考え方に疑問を投げかけています．その理由として
- 将来の仕様変更を予測することはできない
- 柔軟性をもたせるのは，コストがかかる
- 必要以上に柔軟性をもたせれば，設計が複雑になる
などの問題が挙げられます．それでは，なぜ将来にそなえて柔軟性のある設計にしなければならない，といわれ続けているのでしょうか？ そのためにまず 変更コストカーブ について説明します．
変更コストカーブとは，ある仕様変更に対するコストが開発プロセスが進むにつれてどれぐらい変わっていくかを表したグラフです．従来の開発方法論では，開発の後段階になればなるほど指数関数的にコストが増大すると考えられています．
ところが，次のような開発プロセスだったらどうでしょうか？
この場合は，開発プロセスの後段階になっても変更コストがそれほどかかりません．もしそういう開発が存在するなら，今ある仕様でもっとも簡単な設計にするのがベストでしょう．本当にあるかどうかわからない仕様変更を予想して，今開発コストを投資する必要はありません．仕様変更があったときに初めて修正すればよいのです．
XPを理解するには，このことを押さえておく必要があります．つまり，
「XP は変更コストカーブがそれほど増えない開発である」
ということです．もちろん，この前提条件が正しいかどうかを見極める必要がありますが，以上のことを踏まえておかないと XP を誤解する恐れがありますので注意してください．
例えば，XP がこれまでの常識と最も相反しているルールは
You're not gonna need it!
だと思います．このルールは，将来必要になるだろうからと思って早めにその機能を追加するな，ということです．これは，変更コストカーブがそれほど増えないということが前提となって成り立つ話なので，それを文字通り受け止めることは危険です．また，これは問題を先送りする，ということでもありません．その前に XP ではやらなければならないことがたくさんあります．
XP の 4つのものさし
XP では，開発プロジェクト成功のカギを握る「ものさし」として，次の4つを挙げています：
- Communication
- Simplicity
- Feedback
- Courage
つまり，これら 4つを追求し改善していくことが XP 開発者に求められることなのです．そのため，XP ではこの4つを自然に良くしていくためのルールや習慣が定められています．つまり，XPとは
「Communication, Simplicity, Feedback, Courage の4つのものさし」
「それらを高めるための小さなルールと習慣」
で成り立っているといえるでしょう．ここでいうルールと習慣とは，例えば最初にいったペアプログラミング，Unit Test などのことです．
さて，4つのものさしについて説明しましょう．
Communication は，顧客と開発者とのコミュニケーション，開発者間のコミュニケーションを表します．XP は，人と人とのコミュニケーションを特に重視します．開発文書は，コミュニケーションの手段としてはあくまで二次的なものであり，XP においては開発文書を重要視しません．Planning Game と呼ばれる顧客と開発者どうしによる開発計画とスケジュールを決めるミーティングや，ペアプログラミングによる開発者間のコミュニケーションの向上を促進する習慣が定義されています．
また XP は，Simplicity - 簡単であることを重視します．将来の仕様変更にそなえて今の設計を複雑にすることよりも，今の仕様を満たす簡単な設計にするようにします．これは，Do the simplest thing that could possibly work や You're not gonna need it というルールによって支えられています．
そして，XP では絶えず Feedback によって開発を進めていくのが特徴です．追加・修正をできるかぎり小さなステップで行い，ステップが終わるごとにテストで検証します．テストを重視し，テストを頻繁に行うのが XP の特徴です．
最後に， Courage - 勇気，つまり失敗を恐れないことです．勇気は信頼があればこそ生まれてきます．顧客との信頼関係があればこそ，開発方針の大きな変更を行うことができたり，テストコードによって支えられているからこそ，設計の大幅な見なおしやリファクタリングができるようになるのです．
ペアプログラミング
XP プロジェクトの一番の特徴は，ペアプログラミングにあるといえます．ペアプログラミングは，一つのモニタに向かって 2人がかりで作業を行うことです．またペアプログラミングは毎回同じペアで行うわけではありません．少なくとも毎日，できれば日に1，2回ペアを入れかえる必要があります．
ここでは，ペアプログラミングのメリットを先ほどの4つのものさしの観点から見てみましょう．
Communication
毎回ペアを組んで作業を行うことによって，開発メンバのコミュニケーションはかなり向上します．しかも絶えずペアが入れ替わるため，各メンバは開発のほとんどの部分を知ることになります．開発方針の重要な決定は開発メンバ全体にすぐに広まり，各メンバが間違いをする可能性はかなり減ります．
Simplicity
ペアを組んで作業をということは，絶えずパートナーにコードの説明を行いながら開発しているということになります．相手に説明できないような複雑なコードは，自然になくなっていきます．
Feedback
Simplicity と同じく，ペアプログラミングでは，絶えずパートナーがコードレビューを行っている状態になります．細かいミスやおかしなコードは，パートナーによって指摘されフィードバックされます．
Courage
開発作業では，乗り越えられないような障害にぶつかることがよくあります．また，イヤな仕事をしなければならない場面も多いでしょう．そのとき 1人でするより，2人で作業を行うことでその困難に立ち向かえるようになります．この勇気と信頼を与えてくれることこそがペアプログラミング最大のメリットといえるでしょう．
ペアプログラミングの問題点とアドバイス
もちろん，ペアプログラミングには問題点もあります．ここでは，そのことについても触れておきましょう．
開発コストが2倍に増える？
管理者の立場から見た場合，一番問題なのがペアプログラミングをすると人月が2倍になるのではないか？ということです．ただでさえ人材不足なのに，開発コストを倍にするのは馬鹿げています．
ペアプログラミングの生産性については，Laurie Williams という人が実験をして検証を行っています（ Pairprogramming.com ）．これによると，初めのうちは，ペアプログラミングを行う場合，個人でプログラミングを行うケースと比べて 1.5倍の人月がかかるが，すぐに 15% 増しぐらいの人月に落ち着くそうです．したがって単純に2倍増える，ということではありません．
しかしそれでも 15% の生産コストが残っています．でも，一方でペアプログラミングはバグの生産性も低くなります．先ほどの Williams さんの研究によればバグの発生も 15% 減るという結果になっています．それでは，ペアプログラミングのメリットはどこにもないのか？ ということになりますがそうではありません．変更コストカーブの話を思い出してください．通常の方法論による開発では，変更コストカーブの増大はかなり大きいのです．後になってバグを発見，修正するコストを考えると，ペアプログラミングの方がかなり経済的といえます．それだけではなく，設計がよくなるなど他のメリットも無視できません．
能力主義・成果主義と合わない？
最近は，能力主義や成果主義を導入する企業が増えています．ペアプログラミングをしていると，開発者全員がシステム全体にかかわることになるため，誰がどの機能を担当し，どれだけの仕事をした，ということが明確にならないでしょう．しかし，開発者どうしのコミュニケーションが増すので開発者同士では，お互いの長所と短所をよく理解できるようになります．企業が求める成果主義にどう対応するかは難しいところですが，例えば，プロジェクトリーダーや開発者同士が評価していくのであれば，より正当な評価ができるようになるかもしれません．
ペアを組みたがらないプログラマ
中にはどうしてもペアを組みたがらないプログラマもいるでしょう．しかし，ペアプログラミングを何ヶ月かやった後では，ほとんどの人がペアプログラミングを好むようになります．たとえ，生産性が少し下がったとしてもです．それは，ペアプログラミングの方が楽しい，といえるからでしょう．最初のうちは，イヤかもしれませんが，何ヶ月かやってみることをお勧めします．
それでも，やっぱりペアを組むのがイヤという人がいるでしょう．そういう人は，コミュニケーションを重視する XP には向いていません．僕もそういう人とはペアを組みたくありません．XP のことなんかきれいさっぱり忘れてください（笑）．
結構疲れる
少しでもやったことがある人ならわかると思いますが，ペアプログラミングは疲れます．いままで黙々とプログラミングしていた人には，一日中パートナーに説明したり，レビューするのはつらいでしょう．1人のときのように，疲れたら内緒で仕事をサボることができなくなります．気分が乗らないときに，メーリングリストで発言する，ということもできません．慣れるまでは，強制的に休憩時間を入れ，一人で休む時間を作りましょう．何ヶ月かすると，最初ほど疲れることはなくなります．またXPには，Fourty Hour Week というルールもあります．ようするにあまり働きすぎるな，ということです．
ペアプロ太り
XP では，ペアプログラミングでお菓子を食べながら楽しくプログラミング，というスタイルが多いです．一時期，開発メンバがそれぞれ好きなお菓子を買ってきてペアプログラミング，ということがありました．さすがにそれも何ヶ月も続くと太ってくるので，今はお菓子を控えてます．健康のためにお菓子の食べ過ぎに注意しましょう．
Unit Test
ペアプログラミングの次に特徴として挙げられるのは，Unit Test です．XP では，開発コードの他にその開発コードを検証するためのテストコードを大量に書きます．今回のチュートリアルでお話する RubyUnit は，テストコードを書いて簡単に実行するためのフレームワークです．RubyUnit については，後で助田君の方から説明があります．
さて，XPでは開発コードよりもテストコードの方がコード量が多くなるのが普通です．しかもそれらのテストコードは，セルフチェック機能を付けなければなりません．つまり，テストコードのプログラムを実行するだけで，テストをパスしたかどうかテストコード自身が判断できなければなりません．そして，テストコードはいつもすべてのテストをパスする必要があります．また，テストコードを先に書いてそれを満たす開発コードを後に書くという Test First Programming が推奨されています．
ここでも，Unit Test のメリットを先ほどの4つのものさしの観点から見てみましょう．
Communication
テストコードは，それ自身クラスの使い方を表した仕様書と見なすことができます．そのテストコードはいつも 100% パスするような状態に保たれているため，完全に正しい情報となります．また，境界条件や例外処理など，文章として説明しにくい仕様もテストコードとして表すことができます．他人に自分のクラスを説明するときにも，まずテストコードを見せるところから始めます．
Simplicity
Test First Programming では，実装する前にまずそのクラスがどういう使われ方をするかをテストコードで表します．こうすることで，先にクラスの詳細ではなくインターフェイスに注目することになり，きれいな使いやすいクラス設計になるよう促進されます．
また，テストしやすいコードである，ということは優れたクラス設計の条件です．テストできるレイヤとテストしにくいレイヤを分けることで，一つのメソッドにいろんな機能を詰め込むようなことがなくなります．
Feedback
XP では，少しコードを書いてはテストするという非常に短いサイクルでコーディングを行います．test a little, code a little, test a little, code a little, ... というリズムにのってすばやくコードを書いていくのが特徴です．少し書いてはすぐテストを行うので，バグの発見が非常に速くなり，デバッグが苦になることはあまりありません．
Courage
ペアプログラミングと同様，Unit Test が与えてくれるのは，勇気と信頼です．大量のテストコードに守られているからこそ，開発の後段階になっても思い切ったリファクタリングが可能になります．テストコードを書く習慣をつけることによって自分のコードの信頼性ははるかに増すことがわかります．
Unit Test の問題点とアドバイス
プログラマはテストを書くのが好きになる？
Eric Gamma が Testing Framework を使うとプログラマは「テスト熱中症」になって，テストコードが好きになる，といっていますが今までそんなことを思ったことはありません．セルフチェック機能がついたテストを書くのはかなり労力が必要です．そのため，ペアプログラミングで得られる Courage でテストコードを書く困難さを乗り越えましょう．
XP で一番楽しいのは，リファクタリングです．テストコードに支えられたコードをリファクタリングして，無駄なコードを一気に消すときが一番楽しい．だから，テストによって支えられた「リファクタリング熱中症」というのが本当のところでしょう．プログラマは，リファクタリングで自分のプログラムをきれいにしたいからテストコードを書きたくなるのです．
Unit Test だけでは不十分
実際には Unit Test だけでは不十分だし，そのテストコードを過信するのは禁物です．やはり全体を通したテストが必要です．XP では，この部分を Acceptance Test(Functional Test) で補っています．できれば，このテストも自動化して頻繁にテストできる環境を作るようにすべきでしょう．かなり難しいですが．
トートロジーになってしまったテスト
当たり前のことですが，テストコードには答えを書かなくてはなりません．実際の値と，あらかじめ用意した答えが等しいかどうかを調べるのがセルフチェック機能のついたテストの役割です．このとき，テストコードを凝りすぎて，いろんな場面を想定して答えを算出するコードをテスト側に書いてしまうと，結局実装コードと同じになってしまうことがよくあります．これではなんのためにテストコードを書いたのかわかりません．
例えば，いろんな検索条件を指定して SQL 文を出力する Query クラスのテストをしたい，と思ったとしましょう．この場合，SQL文の文字列比較をするテストコードを書いてもあまり意味がありません．テストコード側にもいろんな検索条件があった場合のSQL文の答えを用意する必要があるため，結局テストコードと実装コードが同じようなプログラムになってしまうからです．その場合は，元のクラス設計を見直してみましょう．例えば，先ほどの Query クラスの場合，Query クラスを実行すると Result オブジェクトを生成する，という仕様に変更し，テストコード側は Result オブジェクトの中身を検証する，という風に工夫しましょう．
テストのための戦略を練ろう
一般にクラスはそれ単体で動くことはありません．いくつかのクラスと協調しながら動作する場合がほとんどです．その場合，いきなりトップレベルのクラスのテストコードから書き始めるのは得策ではありません．クラス A のテストをパスするには クラス B と C が必要で，クラス B のテストをパスするには，クラス D と E が必要で・・，となるとすぐに Test First Programming は破綻します．もちろん stub を作ってトップダウンに実装していくことも可能ですが，難しいでしょう．
こういうふうに，タスクのスタックがオーバーフローしてしまいそうな場合は，少し時間をとって CRC カードセッション をしてみましょう．XP では，クラス設計に CRC カードセッション を行うのが普通です．ですが，この部分は CRC カードにこだわる必要はないと思います．ある程度方針がきまったら，ボトムアップで実装していきます．こうすると test a little, code a little, ... のリズムにそって開発できるでしょう．
XP をはじめよう
さて，ここからは実際に XP を導入していくための戦略やアドバイスの話に入っていきたいと思います．
実は，今までお話した XP の説明には，一番重要な顧客とのコミュニケーションの部分が欠けています．XP は顧客指向・顧客参加型の開発方法論で，短い繰り返し開発によって顧客がプロジェクトの舵をとる，というのが最大の特徴だからです．このことをもっとも表しているルールが On-Site Customer でしょう．開発チームにフルタイムで質問に答えてくれる顧客を迎える，ということです．XP では，ユーザがしなければならないことはたくさんあります．
僕は XP を導入するのは少なくとも日本では難しいと考えています．その理由がユーザが積極的に開発に関わらなければならない，というところです．こっちがお金を払ってるんだから，後はよろしくやってね，というユーザがほとんどではないでしょうか．だから，XP の顧客とのコミュニケーションをよくするルールや習慣は，XP の実践項目の中では最難関といえます．
でも，XP の一部のルールや習慣を導入して 実際にやってみるのはいいことだと思います．ここでは，顧客とのコミュニケーションの部分を省き，開発の側から XP を導入していく戦略について説明します．
XP ミニマムセット
XP の中でも，一番実践しやすいのがペアプログラミングと Unit Test です．XP では，他にも10個程度のルールと習慣があり，もちろん，XP を提唱している Kent Beck は，すべての項目を実践することを望んでいると思います．でも最初のとっかかりとしてはこの 2つの項目を実行してみることをお勧めします．
また，開発メンバーの人数としては， 4人程度から始めるのが最適だと思います．2人だと毎日ペアを入れかえることができないため，一日中ペアプログラミングをやるのは結構つらくなります．楽屋が別々の漫才コンビのようになってしまうかもしれません．また，3人の奇数メンバーでは，ペアを組むときあまった 1人にどういう作業を割り当てればいいのか決めるのが難しく，一人で担当している部分がどうしても弱くなってしまいます．メンバー集めの人数としては，やはり 4人程度が適当でしょう．したがって
- 4人程度の開発メンバー
- ペアプログラミング
- Unit Test
の 3つを XP ミニマムセットと勝手に命名することにします．これは，僕が勝手にそう名づけているだけであって 一般に XP で使われている用語ではないことに注意してください．この XP ミニマムセットを XP 開発へのとっかかりとして実行してみてはいかがでしょうか．このうち，人数についてはある程度変わってしまっても仕方ないと思います．僕のプロジェクトの場合は，最初 2人から始まり，それから1人ずつ増えて現在 4名の開発者でペアプログラミングを行っています．
XP ミニマムセットの問題点
完全な XP ではない
僕が提案する XP ミニマムセットで，ペアプログラミングと Unit Test の 2つを実行するだけでもシステムの品質と信頼性は格段に上がると思います．ですが，これはあくまでも開発サイドに限った話であって，顧客サイドの部分は欠落しているのです．このことを認識しないと思わぬ落とし穴にはまってしまう危険性があることを認識しておいた方がいいでしょう．
顧客とのインターフェイスは従来通りに
あくまで開発内部の XP を実践し，顧客とのコミュニケーションの部分を実践していないことから，顧客との関係を XP 流で行うとかえって顧客からの信頼性を失うことになりかねません．つまり，基本設計書や詳細設計書，データベース仕様書などを従来の開発方法と同じように納品するようにしないと，仕様もきちんと煮詰めずいいかげんな開発をしている，一体どういうことだ，と顧客から疑われる可能性があります．
逆に，開発者間の文書については，XP 流にばっさりなくしてしまいしょう．開発文書はプログラムソースだ，ということでいいと思います．顧客へ提出する文書は，ペアワーキングで作ってしまいましょう．イヤな仕事はペアで行うのが一番です．
変更を受け入れてよいか？
XP では，本来 Planning Game と呼ばれる打ち合わせで，開発する機能とスケジュールを顧客と開発者合意の上で調整します．この Planning Game を行わない以上，顧客からの仕様変更には弱いという従来の開発方法論と同じ問題点をかかえていることを認識しなければなりません．もちろん開発側だけをみればそうではないですが，本来あるべき XP の変更コストカーブではない可能性があります．
このことを認識しないまま XP 流に顧客からの仕様変更を受け入れても，顧客が開発の舵をとっているわけではないため，開発コストがどんどん増えていく赤字プロジェクトになってしまうかもしれません．
周りの人を説得しよう
さて，以上のことを踏まえた上で XP ミニマムセットを実際の開発に導入していくことを考えましょう．
上司の説得
まず最初に問題なのは，ペアプログラミングをいかに納得させるかです．ペアプログラミングをしていると，いやでも上司にバレます（笑）．とりあえず開発コストが 2倍になるという誤解を解かなくてはなりません．この点は，先ほど述べた通り，Laurie Williams さんの研究結果を引き合いに出して説得します．数週間の慣らし期間のあとは 15% 程度の開発コストが増える，という事実を認めてもらった上で，それに勝るペアプログラミングのメリットを強調しましょう．
- 開発サイクルのテストフェーズに行く前に，多くのバグがなくなる
- プログラム設計がよくなり，コード量も減る
- 2人で考えることによって問題解決が早くなる
- 開発メンバの教育コストが減る
- すべての開発メンバがプロジェクト全体を見渡すことになる
- 開発知識が自然に広がるため，プロジェクトの管理コストが減る
- メンバ入れ替えや補充を行ってもリスクが少ない
- ペアプログラミングは楽しい→優秀な人が退職することがなくなる（？）
こういった点を強調し，少しぐらい開発コストが増えても，ペアプログラミングのメリットははるかに大きいということを納得してもらいましょう．
メンバへの説明
一通り XP を説明した後，XP の実践には，開発者のスキルをそれほど要求しない，ということを説明して安心してもらいましょう．僕にはよく理解できませんが，XP は少数精鋭で優れた技術者が集まらないとできない，という誤解をしている人がいます．そんなことはありませんよ．
そもそも開発者をスキルが高い，低いという単純な判断基準で見ることはどうかと思います．開発者はそれぞれ個性があり，いろいろな仕事を経験しています．長所もあれば短所もあります．XPで開発者間のコミュニケーションが増す結果として，今より自分の長所をもっと発揮できる可能性が広がるでしょう．
今やっている開発プロジェクトでは，Javaやインターネットに詳しい人，Windowsに詳しい人，OracleやUnixに詳しい人それぞれ毎日いっしょに開発を進めています．各メンバの知識を共有できるというのはとても素晴らしいことです．なんでもかんでも最初から一人で勉強して開発する，ということは時間の無駄だし，そもそも無理なのです．
最初は Testing Framework の使い方から
ペアプログラミングには，ある程度慣らし期間が必要です．最初に行う作業としては，Testing Framework の勉強をペアプログラミングで行うことをお勧めします．これは，開発者全員が Unit Test のコードを書けるようになる必要があるからです．
題材は，このチュートリアルの後半で助田君が説明する簡単なものから始めればよいでしょう．その内容をペアでやってみることをお勧めします．また助田君が書いた RubyUnit の本も発売される予定ですので，その本に載っているサンプルをやってみるといいでしょう．
RubyUnit で限らなくて，たとえば Java の Testing Framework である JUnit の使い方を勉強するのであれば，William Wake さんのチュートリアルをお勧めします．
- The Test/Code Cycle in XP: Part 1, Model
http://users.vnet.net/wwake/xp/xp0002/index.shtml - The Test/Code Cycle in XP: Part 2, GUI
http://users.vnet.net/wwake/xp/xp0001/index.shtml
これはペアでやる必要もないと思いますが，Testing Framework の構造を知りたい方は，僕のホームページにある
- Kent Beck Testing Framework 入門
http://member.nifty.ne.jp/masarl/article/testing-framework.html
を参考にしてみてください．なお，この記事はデザインパターンを知っていることを前提にして書かれているのでデザインパターンを知らない開発者にはつらいかもしれません．
Test First Programming の習慣をつけよう
Testing Framework の使い方自体はそんなに難しいものではありません．身につけなければならないのは，開発コードよりテストコードを先に書く，という習慣です．この習慣を身に付けるようにしないと，すぐテストコードを書かなくなってしまいます．テストコードを書くのは難しいし，すでにちゃんと動いているコードに対して，新しくテストコードをおこすのはかなり面倒な作業ですから．
Test First Programming による Unit Test を書く手順は，次のようになります（後半で助田君が実際のコード例を交えながら解説します）．
- テストクラスを作ろう
まず，これから作ろうというクラスのテストクラスを RubyUnit などの Testing Framework を使って書きます．
- クラスのラフスケッチを書こう
これから作るクラスがすでに用意されているものとして，頭の中でイメージします．それをそのままテストクラスのテストメソッド（メソッド名は test という単純なものでよい）に書きます．test メソッドの中に
- まず オブジェクトを new して
- これこれこういうメソッドを呼べば
- こういう結果になるはずだ
ということをスケッチしていきます．最初は，あまり欲張らず，正常系の単純なコードだけにします．
- コンパイルが通る程度に実装し，テストコード実行
次にコンパイルが通る程度のコードを書きます．つまり，ラフスケッチで書いたクラスとメソッドの宣言のみで中身は書かずにそのままにしておきます．その後，テストコードを実行してテストがちゃんと失敗するかどうか確認します．これは，テストコードをテストするために必要な作業です．いきなり中身を実装してしまわないようにしてください．
- とりあえずテストが通るようにしよう
コードが汚くてもかまいません．テストコードが通りさえすればいい，というレベルの品質でコードを実装します．また，後々必要になるだろうという理由で例外処理や境界条件のチェックを考えた実装もしないようにします．これは，テストコードの漏れを防ぐためで，例外処理や境界条件のテストを書いたときに実装するようにしましょう．
- リファクタリングしよう
パートナーと相談して，もっとわかりやすいメソッド名はないか，もっと単純に書けないかいっしょに考えます．少しリファクタリングしてはテストを実行し，いつもすべてのテストをパスするようにします．このとき，機能を追加したくなる気持ちをぐっと押さえたほうがいいでしょう．新しい機能は，まずテストを書いてからです．
- テストを強化しよう
境界条件，例外処理のテストなどを書いてテストを強化します．テストを書いてはコードを修正，リファクタリングをするようにします．
- 新しいメソッドのラフスケッチを書こう
さらにクラスに必要なメソッドに対してテストコードを追加します．そして3番目から6番目の項目を順次行っていきます．
以上のことを何度も繰り返し，プログラムを作っていくのが Test First Programming のプログラミングスタイルです．
ペアの割り当て
ペアの割り当てについては，XP ではこうしましょうと特に明記されていないようです．そこで，ここでは実際に僕のプロジェクトで使っているやり方を紹介しましょう．
毎朝ペアアップミーティングをしよう
毎朝開発者みんなで集まりミーティングをします．開発者の進捗を聞いて，今日はどのペアで行こうということをその場で決めてしまいます．開発メンバの特性をみて，ペア両方の人が不得意な作業を割り当てないようにしましょう．
頻繁にペアを入れ替えよう
毎日ペアを入れ替え，できることなら一日に 2回ペアを入れ替えて開発知識が特定の人に偏らないようにします．初めのうちは，どのペアで行くか開発者のことを考えて組み合わせする必要がありますが，開発が進むと，メンバの知識も底上げされ，どのペアで行くかということをあまり考えなくて済むようになります．そういう場合は，単純にローテーションを決めて順番にペアを入れ替えます．
うちの開発チームでは，ペアを決めるために紙でこんなものを作ってます．
ペアを入れかえる毎に上の三角柱をころがします．その後，どのペアがどの作業をやるかペアアップミーティングで決めます．
パートナーがいないときは
奇数人数の開発チームや，一時的にメンバがいなくて奇数人になった場合，ペアを組めない人が一人出てきてしまいます．XPでは，すべてのコードをペアで開発するように，となっていますが現実問題としてそんなことはできないでしょう．しょうがないので，その人にはなるべく簡単な仕事を割り当てるようにします．もちろん一人で作業をしたところは，テストコードに不備があったり，品質が落ちてしまうことを覚悟しなくてはなりません．
最初はペアでやるよう指導しよう
開発者は，いままで一人で作業することに慣れているため，最初のうちはなかなかペアで作業しようとしません．自分の席に戻って個別に作業し，その後ペアでレビューするという効率の悪いことをしてしまいます．最初の一ヶ月ぐらいは，プロジェクトリーダがいつもペアで作業するよう指導していった方がいいでしょう．しばらくすると，開発メンバのコミュニケーションが増した結果，自然にペアで作業するようになりなります．単独で仕事する方がやりにくい，というぐらいになります．もともと開発者は会話するのが好きだからだと思います．
CRCカードセッション
CRCカードセッションでクラス設計
1000 行程度のプログラムならともかく，Test First Programming といってもいきなりテストコードから書き始めることはできません．トップレベルのクラスのテストコードから書き始めると，そのクラスを実現するためにまた別のクラスのテストコードが必要になり，そのクラスを実現するためにまた別のクラスのテストコードが必要になり・・と，通らないテストの数がどんどん増えていきます．ついには実装すべきプログラムのスタックが溜まりすぎてスタックオーバーフローになってしまいます．こうならないためにもある程度クラス設計をしておき，ボトムアップで開発していく方が良いでしょう．
新しい機能を実装する最初に開発者全員が集まり，CRCカードセッションを行います．これは，その機能で必要なクラスの洗い出しをして，各クラスの大まかな役割を決めるためのミーティングです．でも，規模が小さいのならペアで個別に行ってもかまいません．
CRCカードとは
CRCカードセッションをするため，文具屋さんに行ってインデックスカード（情報カード）を買ってきましょう．３×５のサイズぐらいが適当です．CRCカードの一枚が一つのクラスを表しています．
このように一枚のカードに，
- クラス名
- クラスの役割 (Responsibility)
- 協調するクラス (Collaborator)
を書きます．Class, Responsibility, Collaborator から CRCカードと呼ばれています．
CRCカードセッションのやり方
情報カードを用意し，規模が大きな場合は，開発者全員，小さい場合はペアで行います．そして，みんなでブレインストーミングしながら次の手順でカードに書きこんでいきます．
- 必要なクラスの候補を洗い出して，カードにクラス名を書きこむ
- ある機能についてのシナリオを用意する
- シナリオを実行しながら，どのクラスがどの役割を担当するか考える
- クラスの役割をカードの左側に書く
- そのとき必要となるクラスを右側に書く
- 必要な場合は，新しいカードを追加して新しいクラスを作る
- さらに別のシナリオを実行してCRCカードを洗練させていく
必要に応じて，カードの裏にクラスの概要，注意点などのメモを書いてもいいでしょう．また，オブジェクト指向の初心者が多い場合は，CRCカードを配り，配られた人がそのクラスの担当になってシナリオを実行していくというロールプレイングを行うのもいいと思います．
CRCカードで見積もり
たまった CRCカードがそれぞれどれぐらいで実装できるか見積もります．XPでは，本来タスクカードと呼ばれる各機能を数日程度でできるタスクにブレークダウンするのですが，僕のチームでは，CRCカードで代用しています．各カードに，何ペア日でできるか予想し，後から実工数書きこみます．最初の見積もりと実工数を比べてより正確な見積もりができるようにします．（注：この方法はしばらく実行してみたのですがいまいちうまく機能していません．もう少しいい方法がないか検討中です．）
さらにXP のルールを取り入れよう
Collective Ownership
開発者の誰もがどのソースを修正してよい，というルール．人を入れ替えながらペアプログラミングをしていくと，だんだんソースコードの所有権の感覚がなくなってきます．CVS などのバージョン管理ツールを使いながら，Collective Ownership を実行するといいでしょう．
Coding Standard
誰もがどのソースを修正してよい，となると，人によってソースの書き方が違うと編集するのがだんだんわずらわしくなってきます．そこで，みんなでコーディングルールを決め，守るようにします．細かいですが，タブ文字は何文字にするかとか，括弧の位置も決めておいた方がいいでしょう．クラスやメソッド名のつけ方については，次の本を参考にして決めるとよいと思います．
- Kent Beck, Smalltalk Best Practice Patterns, Prentice-Hall, 1996 ISBN 013476904X
- Jeff Langr, Essential Java Style, Prentice-Hall, 1999 ISBN: 0130850861
これらは，コーディングパターンについて書かれた本で，二番目の本は Kent Beck の本を Java に焼きなおしたものです．ぜひこの本の Ruby 版がほしいところです．
Ruby と XP
XP との親和性は高い
Ruby の基本思想として，「楽しいプログラミング」ということが挙げられると思いますが，これは XP と同じ考え方だと思います．Ruby でペアプログラミングを行えば，楽しいプログラミングがより楽しいプログラミングになるでしょう．また，XP のテストとコーディングのサイクルが，インタープリタである Ruby を使うことでよりスピーディに，よりスムーズに行くものと思います．
さらに，RubyUnit は他の Testing Framework と比べてもかなり使いやすいものになっています．Ruby というプログラミング言語自体が優れていることもありますし，RubyUnit の作者（助田君）がより完成度の高いものに洗練してくれたおかげだと思います．
Ruby による大規模開発に向けて
今までは，規模の大きい開発には C++ や Java などの静的型付け言語が用いられてきました．しかし，XP の Unit Test によって静的型付け言語の優位性は薄らいできています．Unit Test を実践すれば，コンパイラによる型チェック等は，バグを見つける手段としてそれほど重要ではなくなってきます．動的型付け言語のランタイムエラーは，Unit Test によって捕捉できます．むしろ，動的型付け言語の方がこれからは主流になってくるかもしれません．
Ruby は，言語仕様として大規模な開発にも向いているといえます．そのときに，XP を開発方法論として取り入れ 10人ぐらいで開発を行うとかなりのことができるようになるのではないでしょうか？