表１ ●ＸＰの１２の実践項目（プラクティス）

No	実践項目	概要
１	計画ゲーム（The Planning Game）	ビジネスの優先度と技術的判断から､次回リリースの計画を立てること
２	短期リリース（Small Releases）	小さなシステムでいいから、新バージョンのソフトウェアを短期間にリリースすること
３	メタファ（比ゆ）（Metaphor)	ソフトウェアの動きや仕組みを、何らかのたとえとしてメンバー間で共有すること
４	シンプルな設計（Simple Design）	本当に必要な機能だけを設計すること
５	テスティング（Testing)	単体テストと機能テストを繰り返し行うこと
６	リファクタリング（Refactoring)	ソフトウェアの動作を変えることなく、コードをきれいにすること
７	ペア・プログラミング（Pair Programming)	二人のプログラマが１台のマシンを使ってコーディングすること
８	共有所有（Collective Ownership)	開発メンバーの誰もがコードを変更できるようにすること
９	継続的な結合（Contｉnuous Ｉｎｔｅｇｒａｔｉｏｎ）	１日に最低１回でも結合（ビルド）を行い、テストを必ずパスさせること
１０	週４０時間労働（Ｆｏｒｔｙ Ｈｏｕｒ Ｗｅｅｋ）	開発にかかる労働時間は、一週間に４０時間とすること
１１	オンサイト顧客（Ｏｎ-ｓｉｔｅ Ｃｕｓｔｏｍｅｒ）	ユーザー（顧客）を開発にフルタイムで参加させること
１２	コーディングの標準化（Ｃｏｄｉｎｇ Ｓｔａｎｄａｒｄｓ）	コーディングのルールを定めること

その１	その３	Ｎｏ Ｌｉｎｋ	Ｎｏ Ｌｉｎｋ	Ｎｏ Ｌｉｎｋ

ますが、実際にやってみると、プログラミング作業が賑やかになって楽しくなるなど、さまざまなメリットが得られるようです。中でも大きいのは、コード品質の向上とコミュニケーションが円滑になることです。
　ペア・プログラミングでは、会話主体で作業が進みます。二人のプログラマのスキルがまったく同じということはないでしょうから、ベテランと新人が組めば教育的効果があるでしょう。逆にベテラン同士または新人同士が組めば、互いに切磋琢磨する効果があります。その結果、一人で黙々とプログラミングするのに比べて、バグを見つけやすくなり、結果的にソフトウェアの品質は向上する、というわけです。また、ペアで作業するということからコミュニケーションが円滑になり、メンバー間の士気が高まる、という効果もあります。Ｋｅｎｔ Ｂｅｃｋは「最初は一時的に生産性は落ちるかもしれないが、トータルで見ると生産性/品質とも向上する」とそのメリットを説明します。
　とはいえお互い人間。一人のほうが生産性は高いというプログラマもいれば^＊１０、相性もあります。その場合は「無理にペアにすることはない」というのがＸＰの考え方です。要は、無理なく適度な緊張感を持ってコーディングできればいいわけです。すると、意外に「厳しさ」より「楽しさ」のほうが体験できるようです。

■「ＸＰが普及するかどうかは、見積もり方法の確立とプログラマの努力しだい」

　これからは、ソフトウェアの開発プロジェクトがもっと少人数になってくると思います。大きなプロジェクトだったとしても、小さな単位に分割されることが多くなるでしょう。そのほうがネットワークを軽くでき､技術や世の中の変化に柔軟に対応できるからです。メンバー間のコミュニケーションも良くなりますしね。その意味で、少人数で最大結果を出そうというＸＰは、いいタイミングで出てきた手法だと思います。
　ＸＰが普及するかどうかは､ＸＰだとどれくらいの納期やコストになるのかを見積もれるかどうかにかかっているでしょう。今の段階では、まだわからないことばかりですが、それがある程度予測できるようになれば、もっと事例が増えてくると思います。
　ただし、ＸＰはけっして簡単な手法ではありません。テスティングやリファクタリングを実践するには、それなりのスキルが必要です。その意味では、一人ひとりのプログラマがもっと勉強しないとＸＰは普及しないかもしれませんね。
（日本ＸＰユーザーグループの代表（暫定）者の意見）

　ここまで読んでみて「面白そうだ。ぜひＸＰを実践してみたい」と思った方もいるかもしれません。実は、すでに国内でＸＰを使った事例があります。この事例では、わずか２ヶ月間でインターネット・ベースのＢ２Ｂ（企業間電子取引）システムを完成させることに成功しています（別掲記事「たった２ヶ月で開発完了！ＸＰの威力を実感した」参照）。ＸＰは、けっして机上の空論ではないわけです。
　それでも、ＸＰを本格的に実践するには、さまざまな課題があるでしょう。実際には、できるところからやってみるしかありません。例えば開発プロジェクトが大きな場合は、１０人以下の小さなプロジェクトに分割する、というカスタマイズも必要です。ペア・プログラミングも試行錯誤するしかないでしょう。しかしやってみるだけの価値はありそうです。
　特集の冒頭で、ソフトウェア開発に「スピードと変化」の波が来ていると述べました。この「スピードと変化」に対応する最大の武器は、ＸＰで語られた「コミュニケーション」です。プログラマ同士、またはユーザーとの会話など、これからますます良いコミュニケーションが必要になってくるでしょう。良いコミュニケーションなしに、良いソフトウェアは作れないからです。その意味でＸＰは、ソフトウェア開発を見直す、いいキッカケになるはずです。

●ＸＰでソフトウェア開発のやり方を考え直そう

　ソフトウェアのを開発するとき、行き当たりばったりの思いつきで作業を進めることは、ほとんどないでしょう。それが趣味のプログラミングであったとしても、「どのような機能が必要なのか」という作業（いわゆる分析/設計）の後で、実際にプログラミングをスタートし、ある程度プログラムができたら、テストを実施して機能やバグをチェックしリリースします。この一連の流れは（きちんと守るかどうかは別として）ソフトウェアの種類や大小にかかわらず共通しています。
　しかし、ビジネスとしてソフトウェアを開発するとなると、決めなくてはならないことが格段に増えます。ユーザーとの契約で納期も厳しく決められます。したがって、「どのような手順でソフトウェアを開発するのか」「スケジュールはどうなるのか」「どのような役割のメンバーが必要か」「各メンバーが行う作業は何か」「成果物として残すべきドキュメントは何か」・・・といったことをあらかじめ決めて、進めていく必要があります。
　このような開発のやり方を、建築や機械製造などのエンジニアリング手法をヒントに、体系化してまとめたものが「ソフトウェアの開発手法」です。これまで、さまざまな開発手法が考え出され、実際の開発プロジェクトで利用されてきました。

　ここでは、日経ソフトウェア２００１年７月号に掲載されていた『これがプログラミングの”新常識”だ！の第三部』真島馨氏の文書から抜粋したものを掲載します。通常、マイコン制御プログラム開発などを行っている方からすれば、ウォーターフォール型開発をしていることと思いますが、オープン系などの開発において開発状況・環境等の条件から、開発方式を模索していることがわかります。それが提案の一部であることを認識して潮流を感じることができれば良いのではないかと思います。

プログラマの多くは、開発手法というと「コンサルタントや管理者の考えるべきこと」と思いがちです。でも、それは大きな間違い。ソフトウェアを実際にコーディングするのはプログラマです。それなら、プログラマの仕事のやり方は、プログラマ自らが考えてみるべきだと思いませんか？ここでは、従来の開発手法と比較して、よりライトな（軽量な）開発手法として注目を浴びている「ＸＰ（Ｅｘｔｒｅｍｅ　Ｐｒｏｇｒａｍｍｉｎｇ）」を紹介しましょう。

●ライトな開発手法を身につけよう！

　しかし、最近、従来の開発手法にほころびが出始めています．その原因が”開発のスピード化”と”要求仕様の頻繁な変更”です。
　開発手法の多くは、ソフトウェア開発プロジェクトがもっとも大規模で、開発期間も１年以上かかる時代に考えられたものです。開発工程は、分析/設計、プログラミング、テスト、運用と明確に分けられ、順番に開発を進めていく「ウォーターフォール型開発」が主流でした（図１の（ａ））。さらに、これらの各工程は、たっぷり時間がとれることを前提にしていました。高いところから流した水は、けっして上に逆流することなく低いところへ流れていくように、ウォーターフォール型開発では、原則として前工程への後戻りはありません。ユーザーの要求しようはスケジュールの早い段階で完全に固定化する、というのが前提になります。
　しかしＩＴ技術の急速な進歩と、企業経営のスピード化が、ウォーターフォール型開発の問題点を一気に表面化させました。最近の開発プロジェクトの開発期間は、１年どころか３〜６ヶ月あるいは１ヶ月というのも珍しくありません。この短いサイクルの中で、ウォーターフォール型開発手法通りの作業を進めることは、工数的に見てかなり無理があることがわかってきたのです。また、最近のソフトウェア開発では、途中でユーザーの要求が変わったり、機能の変更や追加を頻繁に行ったりすることがよくあります。開発の早い段階でユーザーの要求仕様を固定化してしまうウォーターフォール型開発では、その後の変化に追従するのが非常に難しくなります。その結果、「完成したときには、もうそのシステムや機能は必要とされない」という状況すら発生するようになっています。

●従来の開発手法ではスピードや変化についていけない

*1　ＲＡＤ（Ｒａｐｉｄ Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｖｅｌｏｐｍｅｎｔ）　ツールは、プログラマがアプリケーションの完成イメージ（ＧＵＩ）を把握しながら開発できるツール。

　そこで新たに考え出されたのが、ウォーターフォール型の開発サイクルをもっと短くし、Ｖｉｓｕａｌ Ｂａｓｉｃ（ＶＢ）やＤｅｌｐｈｉなどのＲＡＤツール^*1を駆使して生産性を高める「繰り返し（スパイラル）型開発」です（図１の（ｂ））。「繰り返し型開発」では、短期間の開発に対応するため、一気にすべての機能を開発しようとはしません。機能を絞り込んだプロトタイプ（準完成品）をユーザーに提供し、ユーザーから性能や使い勝手などのフィードバックを得て、何度も設計〜プログラミング〜テスト〜リリースを繰り返します。こうして、少しずつ機能を変更したり追加していけば、ウォーターフォールで陥りがちな、ユーザーのニーズを見失うリスクを回避できるというわけです。繰り返し型開発は、ウォーターフォール型開発に代わる効果的な手法として、１９９０年代後半からさまざまなソフトウェア開発で行われるようになりました。
　しかし、現実に繰り返し型開発を実践するのは、それほど簡単ではありません。中途半端な「形だけ」の繰り返しは、かえって問題を複雑にします（図２）。例えば、ウォーターフォール型開発での作業量を変えずに開発期間を短縮されただけでは、開発者への負荷を高めてしまいます。また、１回あたりの開発期間はどれくらいか、繰り返しは何回行うのか、などをきちんと決めておかないと、全体として無計画なプロジェクトになってしまう危険もあります。さらに、十分な機能や性能を持っていないプロトタイプをリリースしても、ユーザーからはいつまでもＯＫが出ませんし、的確なフィードバックが得られません。結局、最終的なソフトウェアの品質は低下します。

●繰り返せばいいってものではない

*2　米国では、ＸＰのようなライトな開発手法は「Ａｇｉｌｅ Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ」と呼ばれ、ほかにもいくつか登場している。例えば、Ｃｏｃｋｂｕｒｎ’ｓ Ｃｒｙｓｔａｌ Ｆａｍｉｌｙ，ＳＣＲＵＭ，ＦＤＤ （Ｆｅａｔｕｒｅ−Ｄｒｉｖｅｎ Ｄｅｖｅｌｏｐｍｅｎｔ）などが挙げられる。これらは、米国のソフトウェア技術者Ｍａｒｔｉｎ Ｆｏｗｌｅｒ氏による論文「Ｔｈｅ Ｎｅｗ Ｍｅｔｈｏｄｏｌｏｇｙ」で詳しく分析されている（同論文は、http://www03.u-page.so-net.ne.jp/dc4/tnaka/fowler/new-Methodology_j.htmlで日本語版が読める）。
*3　http://www.xp.medinfo.m.ehime-u.ac.jp/
*4　「ＸＰエクストリーム・プログラミング入門」（Ｋｅｎｔ Ｂｅｃｋ著、永田渉、飯塚麻里香 訳、長瀬嘉秀監訳、ピアソン・エデュケーション発行）、「ＸＰエクストリーム・プログラミング実行計画」（Ｋｅｎｔ Ｂｅｃｋ、Ｍａｒｔｉｎ Ｆｏｗｌｅｒ 著、飯塚麻里香 訳、長瀬嘉秀監訳、ピアソン・エデュケーション発行）などの書籍もある。

　そこで、繰り返し型開発のメリットを生かしつつ、より実践的な開発手法として登場したのが、「ＸＰ（Ｅｘｔｒｅｍｅ Ｐｒｏｇｒａｍｍｉｎｇ：エクストリーム・プログラミング）」です。ウォーターフォールに代表される従来の開発手法が、開発手順を細かく規定したり、大量のドキュメント作成を要求するのに対し、ＸＰは実践項目も単純で、ドキュメントもほとんど作りません。また、後述するように、比較的少人数向けの開発手法のため、「ライトな（軽量な）手法」と呼ばれることもあります^＊２。
　ＸＰは、オブジェクト指向言語Ｓｍａｌｌｔａｌｋのプログラマとして有名な、Ｋｅｎｔ Beck氏らが中心になって考案した開発手法です（別載記事「ＸＰを実践すれば、よいプログラマになれる」参照）。日本でも２０００年ごろからオブジェクト指向開発を行っている開発者たちに知られるようになり、今年に入って「日本ＸＰユーザーグループ（ＸＰＪＵＧ）」^＊３も発足しました。４月には提唱者のＫｅｎｔ Ｂｅｃｋを招いたセミナーが開催されるなど、ちょっとしたブームになっています^＊４。
　どうしてＸＰは注目を集めるのでしょうか。それはＸＰに、ソフトウェア開発者を引きつけるさまざまな魅力があるからです。
　その一つは、ＸＰが特定のツール・ベンダーやコンサルタント会社の「製品」ではない点でしょう。有志によるユーザー・グループではあっても、特定の権利団体はなく、後述するＸＰの実践項目（プラクティス）を行ったところで、だれかに使用料を払う必要はありません。従来の開発手法の多くが「製品」で、ベンダーが主催する有料のセミナーや講習を必要とするのとは大違いです。その意味でＸＰは、手法というより「ソフトウェア開発者が共有すべきノウハウのかたまり」と言ったほうがいいかもしれません。
　ＸＰのもう一つの魅力は、「Ｅｍｂｒａｃｅ Ｃｈａｎｇｅ（変化を抱擁せよ）」という精神です。ウォーターフォール型が最初に仕様をきっちり決めて、後はその実現に向かってまっしぐらに進むという開発スタイルであったのに対し、ＸＰはざっくりと目標を定めるだけで、後は右へ左へフラフラと進むスタイルをとります。一見イイカゲンに見えますが、ＸＰでは「ソフトウェア開発に変化はつきもの。ユーザーのニーズも変わるし、機能やコードの変更も当然。問題は、いかにその変化に対応するかである」と説きます。これは過去の開発手法とは１８０度違う発想です。従来「仕様が決まってからの変化や変更」は”悪”でした。「変更すればするほど、後工程の変更コストは上昇する」ので、早期に設計を固定化させて「変更コストを抑える」ことが重要と考えられていたからです。しかし、ＸＰの発想は逆です。第１部で解説したオブジェクト指向プログラミングや、後述するさまざまな実践項目（プラクティス）を究極的に（Ｅｘｔｒｅｍｅ）実践すれば、「変更のコストは時間とともに上昇しない場合がある」と考えるわけです。
　その考え方を実現するためにＸＰでは、　『　●コミュニケーション　　●シンプル　　●フィードバック　　●勇気　』
の四つの価値を重視します。「開発者同士または開発者とユーザー間の風通しを良くし（コミュニケーション）、余計な開発は行わず（シンプル）、ユーザー・ニーズやコード変更などの情報を頻繁に交換し（フィードバック）、ニーズの変化やコードの変更を恐れなければ（勇気）、変化に柔軟に耐えられる」というわけです。
　「何だか宗教みたいだな」と思われる方もいるかもしれません。確かにそんなところはあります。しかし、従来の開発手法の多くが、ち密な決まりごとで開発者の行動をきっちり統制したのに比べ、ＸＰは開発者、特にプログラマの自主性を尊重するなど、もっと自由な雰囲気があります。この点がＸＰが人気を集める最大のポイントかもしれません。

●変化に柔軟に対応するライトな開発手法「ＸＰ」

◆ＸＰは、どんな分野のソフトウェア開発に向いていると思いますか。
　ＸＰはどんなソフトウェア開発でも使えると思います。業務アプリケーションの開発でも、組み込み機器の開発でも関係ありません。なぜならＸＰは、コミュニケーション、つまり人間関係に注目しているからです。実際、米国でも、金融システムの開発から医療機器のような組み込み機器開発まで、さまざまな分野でＸＰの取り組みが始まっています。
◆ＸＰはオブジェクト指向開発に限られた手法なのでしょうか？
　そんなことはありません。基本的にＸＰの実践項目（プラクティス）は、プログラミング技術や言語に依存しないと考えています。私は、父がアセンブリ言語でソフトウェアを開発する様子を見てＸＰのヒントを得ました。テストを繰り返したりプログラミングを見直したりすることは、プログラミングの方法や言語とは関係ないと思います。ただし、オブジェクト指向言語を使ってプログラミングを行った方が、設計やコードの変更コストをより低く抑えられる、ということは言えるでしょう。ＣＯＢＯＬやＶｉｓｕａｌ Ｂａｓｉｃ（ＶＢ）のような非オブジェクト指向言語でもＸＰはできますが、工夫は必要だと思います。
◆ＸＰを実践する上で難しいところは何でしょうか？
　プログラマにとって、もっとも問題になるのはペア・プログラミングでしょう。約２週間で一つの開発（イテレーション）を行う、というのも工数的に不安かもしれません。でも、やってみるしかありません。それには勇気が必要です。ＸＰを実践していけば、プログラマは「良いテスター」「良いリファクター（リファクタリングできる人）」「良い設計者」になれます。そのためには、別にコンピュータ・サイエンスの学位や才能が必要なわけではありません。実践しながら学んでいけばいいのです。
◆ＸＰはこれからソフトウェア開発手法として広まると思いますか？
　テスティング・フレームワークの整備など、課題はいろいろあるでしょう。それに、従来のソフトウェア開発手法に慣れた人は、好きになれないかもしれません。しかし、新しい世代のプログラマなら、それほど抵抗なくＸＰになじんでいくと思います。そうすれば、自然とＸＰは広がっていくでしょう。

■「ＸＰを実践すれば、良いプログラマになれる」　----　ＸＰの提唱者Ｋｅｎｔ Ｂｅｃｋ氏に聞く

*5　熱心なＸＰ信者の中には、これらすべてを実践できなくてはＸＰと呼べない､という人もいる。
*6　ストーリー・カードにフォーマットはないが、紙のカードを用いることが多い。後述するタスク・カードも同様で、ＣＡＳＥツールのようなソフトウェアは使わない。
*7　これは決まっているわけではない。経験的に、１〜３週間程度が適切と考えられている。
*8　ＸＰでは、「変更が必要になったときにプログラムを変更するコストのほうが、今日のうちにプログラムを変更して、結局使われないコストより低い」と考える。

　ＸＰには前述の四つの価値をベースに、具体的な実践項目（プラクティス）が１２個用意されています（表１）。「ＸＰを実践する」ということはこれらすべて、もしくはいくつかを実践することを意味します^＊５。
　最初の「計画ゲーム」では、ユーザー（顧客）が「ソフトウェアにどのような機能が必要か」を”ストーリー・カード”^＊６に書きます。このときプログラマも参加し、ビジネスの優先度や技術的見地から、計画達成の日程を決めます。システムの全体像は「メタファ」を考えて、そのイメージをメンバーで共有し、ストーリーは、より具体的な作業単位として”タスク・カード”（だれがどんなプログラムを作成するか）に分割して記述します。
　開発作業はタスク・カードに従って行われ、繰り返し「短期リリース」します。ＸＰではだいたい２週間程度が一つのリリースを出荷するまでの時間と考えられています^＊７。１回あたりの開発（イテレーションと呼ぶ）で重要なのは、たとえ後で必要になることがわかっていても、最初に決めた以外の機能は設計しない「シンプルな設計」です^＊８。また、コードはメンバー全員で「共同所有」できるようにし、だれのコードを見ても理解可能なように、インデントの文字数やコメントの書き方など「コーディングの標準化」を行います。
　プログラミングは二人でチームを組んで一つのマシンを共有する「ペア・プログラミング」を実施します。作成したプログラムに対しては、単体テスト（プログラムの動作チェック）や機能テスト（ユーザーの必要とする機能があるかどうかのチェック）などの「テスティング」を徹底して行い、テストを徹底させるため､ユーザー（顧客）は「オンサイト顧客」として、フルタイムで開発に参加します。
　プログラムは、テストを通過すればＯＫではありません。"よりわかりやすく､より修正しやすく”するため「リファクタリング」も頻繁に行います。このようにして作成したプログラムは「継続的な結合」によって、毎日最低１回は結合（ビルド）し、テストを必ずパスさせるようにします。ただし開発作業を延々と続けても能率は上がらないので、働く時間は「週４０時間労働」を目安にします。
----以上が、ＸＰを実践してみたときの開発の流れです。皆さんはどう思われましたか？

●ＸＰを支える１２の実践項目

*9　ＣＡＳＥ（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ）　ツールは、ソフトウェア開発の主に設計工程を支援するツール
*10　そもそも一人で仕事をしたがるタイプの人間がプログラマには多いのではないだろうか。

　さまざまな意見があるかもしれませんが、１２のプラクティスすべてを忠実に実践するのは、結構難しそうですね。それにコミュニケーションに価値を置くといっても、開発メンバーが多くなれば、全員の意思疎通を図るのは容易なことではありません。実際、ＸＰは「２から１０人以下の少人数の開発プロジェクトに適した方法で、それ以上だと失敗する可能性が高い」と提唱者のＫｅｎｔ Ｂｅｃｋは述べています。
　しかし、それでもＸＰには従来の開発手法にはない魅力があります。例えば、ＸＰを実践するのに､高価なＣＡＳＥツール^＊９は必要ありません。ドキュメントと言っても、ストーリー・カードやタスク・カードなどの紙のカード程度で、仕様を作らないというのが根本姿勢です。そこには、「仕様書や設計書ではソフトウェアは動かない。コードこそ最良の設計書である」という思想があります。
　また、従来の開発では当然であったＳＥ（設計者）とプログラマという明確な区別も、ＸＰにはありません。プロジェクト・メンバーには最低、ユーザー（顧客）、プログラマ、テスター、トラッカ（進捗管理者）、コーチ（アドバイザ）の役割があればいいのです。これは､システム分析者､設計者・・・などと３０種類以上の役割を用意する米 Ｒａｔｉｏｎａｌ Ｓｏｆｔｗａｒｅの開発手法 ＲＵＰ（Ｒａｔｉｏｎａｌ Ｕｎｉｆｉｅｄ Ｐｒｏｃｅｓｓ）とは大きく異なるところです。（別掲記事「ＲＵＰとはどういうものか？」参照）。
　ＸＰがほかの開発手法と決定的に違うのは、「ソフトウェアを作るのは機械ではない、人間だ」という精神にあふれていることでしょう。コミュニケーションや勇気などにこだわるのもそのためです。しかし、けっして、理想を追い求めただけの精神論ではありません。その実現には、技術的な裏付けがあります。それが、「ペア・プログラミング」「テスティング」「リファクタリング」です。

●ソフトウェアを作るのは人間だ

　ＸＰを支える最も技術的な要素と言えば、「テスティング」と「リファクタリング」です。
　テストに対するＸＰの姿勢は、かなり厳しいものがあります。従来の開発手法では､テストはプログラミングの後にまとめて実施するのが普通でした。しかしＸＰは逆です。まずテスト用のプログラムを作成し、それから本体のプログラムを作るのです。そして、本地プログラムができたら、すぐにその場でテストします。これがポイントです。
　テスト用プログラムのコードは､プログラマ自らが書きます。こうすることで、「どんなプログラムを作るべきか」ということが明確になるからです。プログラマが作成するテストは「単体（Ｕｎｉｔ）テスト」と呼ばれ､作成したプログラム（オブジェクト指向言語ならクラス）が、エラーなく動作するかどうかをチェックします。
　しかし､テスト作業がプログラミングの工数を奪うようでは本末転倒です。そこでＸＰは、できるだけテストを簡略化かつ自動化させるためのツールとして、「テスティング・フレームワーク（テスト環境）」を使うことを推奨しています。テスティング・フレームワークは、ＸＰの支持者によって開発され、Ｊａｖａ、C/C++、VB、Perlなどプログラミング言語別に無償で入手することができます。
（http://www.xprogramming.com/software.htm）。
　テストには「単体テスト」のほかに、ユーザー（顧客）が作成する「機能テスト」もあります。「システム全体が、ユーザーの指定したストーリー通りに機能するかどうか」をチェックするものです。といってもユーザーが自らテスト・コードを書くことは通常できませんから、実質的には専任のテスターがユーザーの意見を聞きながら機能テストを作り上げ、テストを実施します。このようにＸＰでは、小さな「単体テスト」とシステム全体の「機能テスト」を頻繁に繰り返し、徹底的な品質の向上を図るわけです。

●単体テストと機能テストでソフトウェア品質を上げる

*11　リファクタリングの手法は「リファクタリング：プログラミングの体質改善テクニック」（Ｍａｒｔｉｎ Ｆｏｗｌｅｒ著、児玉公信、友野品夫、平澤章、梅澤真史 訳、ピアソン・エデュケーション発行）に詳しい。

　さらに重要なのが「リファクタリング」です。リファクタリングは「システムの振る舞いを変更せずに”理解や修正が簡単になるように”内部構造を変化させること」を意味します。要は、一度書いたプログラム（それもテストを通過したもの）をもう一度見直しすること､と考えればいいでしょう。これは､プログラムの実行速度を向上させるパフォーマンス・チューニングとは意味が違います。チューニングは速度向上のためならトリッキーなコードでも許しますが、リファクタリングは性能より「わかりやすさ、保守しやすさ」を優先するからです。
　通常､テストを通過したプログラムは一応完成品ですから､できることならコードをいじりたくはありません。「きちんと動いているのだから、そっとしておいてよ」というのがプログラマの本音でしょう。それでもリファクタリングを実施するのは、
●重複したコードを削除できるなど、コード設計が向上する
●プログラムの中身が理解しやすくする
●バグが見つけやすくなる
といったメリットがあるからです。
　リファクタリングは、単なる"メンテナンスのススメ”とは違います。プログラムを修正することで新たなバグが生まれたら元も子もありませんから、「サブクラスの抽出」「引数の追加」など７０種類以上の”リファクタリングの仕方”が体系化され、メンテナンス手順が具体的にルール化されています^＊１１。例えば､クラス１にあるメソッド１をクラス２に移動させたい場合は、図４のような手順で行うことが決められています。この手順に従えば､メンテナンスをしたことによる新たなバグ発生を防げるからです。
　このように､テスティングとリファクタリングは、単なる「繰り返し型開発手法」とＸＰとの違いを明確に分けるものです。逆に､この実践項目（プラクティス）を実施できなければ、ＸＰのメリットは得られない､と言ってもいいかもしれません。「変化を柔軟に受け入れる」という姿勢から､ＸＰのことを無計画でいいかげんな手法だと批判する人たちもいますが、Ｋｅｎｔ Ｂｅｃｋは「常にテストやリファクタリングの可能性を考えながら作業を進めるＸＰは、むしろきわめて慎重な開発手法である」と述べています。

●リファクタリングは性能チューニングとは違う