特集 「テスト駆動開発」はプログラマのストレスを軽減するか？ 株式会社ピーデー 川俣　晶 2003/11/08

---

新しいソフトウェア開発技法へチャレンジできるか？

　ソフトウェア開発の世界にも日々の進歩がある。そしてその中には、使えばさまざまな恩恵を受けられる技法もある。しかし、それらを現場ですぐに活用できるとは限らない。例えば、1990年代末に生まれ、1つのブームを形成したエクストリーム・プログラミング（XP）という開発技法がある。これは、とても優れた開発技法だと思うのだが、開発プロジェクト単位で、顧客まで巻き込んだ形で使われることが前提となっている。しかし、顧客ぐるみでまったく新しい方法にチャレンジできるかといえば、できないことの方が圧倒的に多いだろう。では、エクストリーム・プログラミングの技法を全部使おうとせず、使うことができる部分だけを取り出して試みることができるかというと、そういうわけにもいかない。エクストリーム・プログラミングは、いくつかのプラクティスと呼ばれる項目から成り立っているのだが、これらは相互にの弱点を補完し合う関係にあるため、特定の1つだけを取り出して使ってもうまく機能しないのである。

　例えば、エクストリーム・プログラミングのプラクティスの1つに、「リファクタリング」というものがある。これは、あるルールに従って、ソース・コードを書き換え、重複を取り除き、より分かりやすい形に変えていくものである。リファクタリングを行うと、ソース・コードが分かりやすくなり、改変やメンテナンスが容易になるというメリットがあるとされる。だが、普通の開発プロジェクトでいきなりリファクタリングをやろうとしてもうまくいかない。通常は、「動いているソース・コードを変えてはならない」という常識がプロジェクトを支配していることが多く、ソース・コードを書き換える行為は強く戒められている。実際に、ただ単にリファクタリングを行って、いかにソース・コードが分かりやすくなったとしても、プログラムの信頼性が落ちるため、それがよいことだとはいえない。エクストリーム・プログラミングの一部としてリファクタリングを行う場合は、別のプラクティスによってもたらされる自動化された単体テストが、リファクタリングによる信頼性低下を防止する役割を担う。これでも完全な信頼性が保証されるわけではないが、信頼性への残された小さな不安よりも、ソース・コードを分かりやすく改善する方が大きなメリットを生む。

　もう1つ、リファクタリングを行う場合には、エクストリーム・プログラミングのプラクティスの1つである「コードの共同所有」が不可欠である。もし、ソース・コードの部分ごとに担当者が決まっていて、彼／彼女以外は書き換えてはならない、ということになると、リファクタリングはとてもやりにくいものになる。例えば、あるメソッドが別のクラスに属しているべきだと判断された場合、双方のクラスのソース・コード担当者に話を通して書き直してもらう必要がある。このような手間をかけていては、とても効率の良い作業とはいえない。

　このように見てみると、エクストリーム・プログラミングは、プロジェクトに所属する開発者の1人だけが試みることを決意しても無意味であることが分かるだろう。プロジェクト全体で、新しい技法に挑戦する場合はよいのだが、そのような例は多くはない。むしろ、プロジェクト内の少数派が、新しい方法にチャレンジする必要性を感じながら、それが実行できず、もんもんとすることの方が多いのではないかと思う。

　そのような場合でも、比較的個人レベルでもチャレンジしやすいものとして、「テスト・ファースト」という技法がある。これもエクストリーム・プログラミングの一部を構成するものだが、比較的単独で使いやすい。これについては、すでにNUnit入門 Test Firstのススメ ［NUnit 2.0対応版］という記事で解説している。

　そして、テスト・ファーストのより洗練された、進化形ともいえる「テスト駆動開発（Test-Driven Development。以下TDD)」というものが提唱されている。これは、プログラマ個人レベルで、試みることが可能な技法である。例えば、大規模プロジェクトのメンバーとして、たった1つのメソッドの開発だけを命じられた場合でも、（事細かに開発の手順を指示されているのでなければ）そのメソッドを開発するために試みることができる。つまり、1990年代的な古い開発スタイルから、より新しい世界を体験する第1歩として、TDDは使えるかもしれない可能性を持っているわけである。

　本稿の目的は、実際の開発に携わるプログラマの視点から、TDDを検証してみることにある。具体的には、『テスト駆動開発入門』（ケント・ベック著 ピアソン・エデュケーション刊）への筆者なりの感想と、実際にTDDを試みた結果を基に構成している。あくまで筆者の解釈によるTDD解説なので、よりオリジナルの形のTDDを知るには、この書籍を読むことをお勧めする。

TDDはテスト・ファーストとどこが違うのか

　TDDは、テスト駆動開発という名前のとおり、「テスト」により「開発」が「駆動」される開発技法である。開発技法であって、テスト技法ではないことに注意が必要である。もちろん、テストとしての側面は持っているが、あくまで主テーマは「テスト」ではなく「開発」にある。

　TDDでは、まず、テストを書き、そのテストをパスするように目的のコードを記述する。テストの実行には、NUnitのようなテスティング・フレームワークを使う。これらの特徴は、テスト・ファーストと何ら変わることはない。そこまでの手順は、既出のNUnit入門 Test Firstのススメ ［NUnit 2.0対応版］で説明しているので、ここでは繰り返さない。

　では、テスト・ファーストとTDDの違いは何か。

　それは筆者としては、以下の2点に要約できると感じている。

• レッド／グリーン／リファクタリングのリズムで開発を行う
• このリズムを短く繰り返す

　この2つは、どちらも開発の「リズム」に関する話であるように見える。とすれば、ただ単にリズムを変えただけにすぎない、ということもできる。しかし、リズムを変えるだけで、何かが改善されたりするのだろうか。

　その話に進む前に、まず、レッド／グリーン／リファクタリングについて説明しよう。

INDEX
	［特集］「テスト駆動開発」はプログラマのストレスを軽減するか？
	1．新しいソフトウェア開発技法へチャレンジできるか？
	2．レッド／グリーン／リファクタリングの三拍子
	3．再びレッドとグリーン、そしてリファクタリング
	4．どんなときにテスト駆動開発を採用すべきか

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）