TDD（テスト駆動開発）とは？アジャイルで重視される理由と「安心して変更できる状態」のつくり方

「TDDは何から始めればいいのか」

「テストを先に書くことに、どんな意味があるのか」

こうした疑問を抱えている方もいるのではないでしょうか。

TDD（テスト駆動開発）は「テストを先に書く手順」ではなく、変更を怖がらずに進められる状態をつくり、アジャイルの「小さく試し、学びながら変える」進め方を支える土台です。

この記事では、TDDの基本的な考え方と、なぜアジャイルで重視されるのか、メリットとデメリット、そして生成AIにテストを書かせた現場の所感までを整理します。

「TDDを始めたいが何から手をつけるべきか分からない」という方や「テストを書く意味を改めて整理したい」という方にも役立つ内容を解説します。

TDD（テスト駆動開発）とは？テストを先に書く開発手法のこと

TDD（テスト駆動開発）は、実装の前にテストを書く開発手法です。

ここでは、基本のサイクルと、その本当の価値を次の2つから見ていきます。

1. TDDは「レッド・グリーン・リファクタリング」を繰り返す
2. TDDの価値は、手順そのものではなく「安心して変更できる状態」にある

まずは手順の全体像を押さえてから、その本質を整理していきます。

1. TDDは「レッド・グリーン・リファクタリング」を繰り返す

TDDは、次の3つのステップを繰り返すサイクルです。

1. レッド：失敗するテストを先に書く
2. グリーン：そのテストを通す最小限のコードを書く
3. リファクタリング：動きを変えないまま、コードの中身を整理し直す

たとえば、買い物の合計金額を計算する機能をつくるとします。

まず「1,000円の商品なら、送料込みで1,100円になる」という、期待する結果を書いたテストを用意します。まだ計算を書いていないので、この時点ではテストは失敗します（レッド）。

次に、そのテストが通るだけの計算を書きます（グリーン）。最後に、読みやすく整理し直します（リファクタリング）。

この小さな往復を繰り返しながら、少しずつ機能を完成させていきます。TDDが生まれた目的は、テストを増やすことではありません。先に「正しい状態」を決めておくと、コードを書いたあとに毎回それを確かめられるため、変更のたびに不安を抱えずに済みます。

2. TDDの価値は、手順そのものではなく「安心して変更できる状態」にある

TDDは、この3つのサイクルを回す手順として語られがちですが、現場で見ているとTDDは「テストを書く順番」の話だけではありません。

システムが大きくなるほど、開発の現場では「どこに影響するか分からない」「壊すのが怖い」という感覚が生まれます。すると、なるべく触りたくない、直したくない、という気持ちが働き、チームの動きは少しずつ遅くなっていきます。

ここで効いてくるのがテストです。テストがあると、「影響が広がるかもしれない」という不安を抱えたままでも、少し変えて試してみるハードルが下がります。

重要なのは、手順を厳格に守ることではなく、このサイクルを通じて「いつでも安心して変更できる状態」をコードとチームにもたらすことなのです。

なぜアジャイル開発でTDDが重視されるのか

アジャイル開発のコアにある考え方と、TDDは深くつながっています。

ここでは、2つの側面から整理します。

1. 変化を前提とするアジャイルでは「あとで変えられる」ことが重要になる
2. TDDは「何を保証したいか」を整理する対話にもなる

まず変化への対応力から見ていき、次に対話の側面を取り上げます。

1. 変化を前提とするアジャイルでは「あとで変えられる」ことが重要になる

アジャイル開発は、最初からすべてを完璧に決めきることを前提にしていません。実際の現場では、やってみたら違った、利用者の反応が想定と違った、優先順位が変わった、ということが普通に起きます。

だからこそ、つくったものを「あとで変えられること」が重要になります。もし変更のたびに、壊れるのが怖い、直すのに何週間もかかる、という状態だと、小さく試すこと自体が難しくなります。

これは、変化を前提とするアジャイルとは相性のよくない状態です。TDDがあると、変更したあとにテストを動かすだけで、どこかが壊れていないかをすぐに確かめられます。「変更しても大丈夫そうだ」という感覚は、チームが変化に対応する力を大きく引き上げます。

この「安心して変更できる」性質は、アジャイルの進め方とそのまま重なります。一気に完成させるのではなく、まず一部だけをつくって動かし、反応を見て次を決める。前につくった部分が壊れないと分かっていれば、次の一歩に安心して進めます。

2. TDDは「何を保証したいか」を整理する対話にもなる

TDDでは、実装の前に「何を期待するのか」「どうなったら正しいのか」を考えます。

これは、あとで確認するのではなく、先に意図を整理する動きに近くなります。「設計をしなくていい」という意味ではありません。むしろ逆で、何をつくりたいのか、どこまでを正しいと保証したいのかを、最初に言葉にしておく作業です。

この「何が正しいか」を考えることは、一人の作業にとどまりません。「この機能は本当に必要か」「どこまでを自分たちの責任とするか」を整理する場にもなります。何を正しいとするかがテストという具体的な形で残るため、コードを見るだけでは伝わりにくい意図も共有しやすくなります。

つまりTDDは、何をつくろうとしているのかをチームで揃えていく行為でもあります。この特徴は、対話や共通理解を大切にするアジャイルの考え方と相性のよい部分です。

【現場の所感】生成AIにテストを書かせると何が起きるか

最近は、テストコードそのものを生成AIに書かせる場面が増えています。実際に試してみると、生成AIにテストを書かせることは、使い方しだいで結果が大きく変わると分かってきました。

ここで取り上げるのは、次の3つです。

1. 同じ生成AIにテストも書かせると、テストが実装をなぞるだけになる
2. 生成AIとTDDを安定させる4つの使い方
3. 生成AIは「何を確かめるか」が決まっているテストが得意

まずは注意点から見ていき、対策と活用法を順に整理します。

1. 同じ生成AIにテストも書かせると、テストが実装をなぞるだけになる

本来テストは、コードが「正しく動くか」を、実装とは別の視点から確かめるためのものです。TDDでテストを先に書くのも、「何が正しいか」を先に決めてから実装するためです。

ところが、実装したのと同じ生成AIにテストも書かせると、「正しさの基準」であるテストも、それを満たすコードも、同じAIの想定からつくられます。テストを先に書いても、その想定そのものが間違っていれば、テストは間違いごと「正しい」としてしまいます。

これは、問題も模範解答も自分でつくって、自分で解くようなものです。手元ではすべて一致しますが、本当に正しいかは確かめられていません。その結果、テストはすべてグリーン（成功）なのに、実際にプロダクトを触るとバグだらけ、ということが起きます。

生成AIは、与えられたコードや指示の範囲ではよく動きますが、「この機能で本当に守りたいことは何か」という問いや「ここも守っていた方がよいのでは」という経験値に基づく先回りには、まだ十分に対応できません。

たとえば、金額の計算で「マイナスの値が入ってきたらどうするか」といった、仕様に書かれていない条件は、人が気づいて指示しなければ抜けたままになりがちです。ここで見えてくるのは、「テストが通る」と「安心して変更できる」は同じではない、ということです。

テストがすべて通っていても、意図がずれていたり、将来の変更に弱かったりすることは起こります。では、生成AIとどう付き合えばよいのでしょうか。

2. 生成AIとTDDを安定させる4つの使い方

生成AIに任せきりにするのではなく、現場で安定するのは、次のような使い方です。

• 何を保証したいのかは、人が考える
• 実装を担当する生成AIと、テストを担当する生成AI（または人）を分ける
• 「グリーンになった」を、そのまま完了の条件にしない
• 最後は人が意図を確認する

生成AIは、テストを「書く」ハードルを大きく下げてくれます。ただ、「何を保証したいのか」を考えるのは、今のところ人の仕事です。そしてこの「何を保証するか」は、チームで「何をもって完成とするか」を揃える話ともつながっていきます。

3. 生成AIは「何を確かめるか」が決まっているテストが得意

生成AIには、はっきり得意なことがあります。すでに動いているコードの動きを読み取り、そのままテストにする作業では力を発揮します。

たとえば、誰が書いたか分からない古いコードに手を入れるとします。直す前に「この入力なら、いまはこの結果が返る」という現在の動きをテストにしておきます。こうしておくと、直したあとに同じテストを流すだけで、直したいところ以外がうっかり変わっていないかを確かめられます。

「入力の境目になる値で確かめて」「条件の組み合わせを整理して」のように、確かめ方を具体的に指示すると、生成AIは筋の通ったテスト設計もある程度できます。つまり、何を確かめたいかがはっきりしているほど、生成AIは速く、正確にテストを書いてくれるのです。

TDDを導入するメリット・デメリット（注意点）

TDDには、メリットと、始めるうえで知っておきたい注意点の両面があります。

ここでは、次の2つに分けて整理します。

1. 【メリット】設計と意図が整理され、問題にも早く気づける
2. 【デメリット・注意点】始めたばかりは、手間と慣れがハードルになる

まず得られる効果から見ていき、次に注意点を確認します。

【メリット】設計と意図が整理され、問題にも早く気づける

TDDで得られるメリットは、バグが減ることだけではありません。

一つ目は、整理された設計に近づきやすいことです。テストを先に書くには、コードがテストしやすい形になっている必要があります。結果として、複雑な依存が減り、シンプルな構造に向かいやすくなります。

2つ目は、コードの意図が分かりやすくなることです。テストには「このコードに何を期待しているか」が書かれているため、あとから入ったメンバーでも、テストを読めば動きの意図をつかみやすくなります。

さらに、問題に早く気づけます。短いサイクルで確かめながら進めるため、どこで間違えたのかをその場で見つけられます。

【デメリット・注意点】始めたばかりは、手間と慣れがハードルになる

TDDを始めたばかりの頃は、コードの前にテストを書くため、進みが遅くなったように感じます。

また、テストそのものを保守し続ける負担も生まれます。本体のコードを変えれば、テストも直す必要があるためです。

ただ、これはTDDの欠陥というより、「変更しやすさを優先する」という選び方から生まれるトレードオフです。最初に手間を払うことで、あとで変えやすい状態を手に入れます。

TDDが向いている開発と向きにくい開発

TDDは万能ではありません。向く開発と向きにくい開発があります。

TDDが効くのは、入力と出力がはっきり決まっている開発です。たとえば、業務ルールが複雑な処理や、計算、データの変換などでは、恩恵が大きくなります。

一方で、効きにくい場面もあります。画面の見た目の調整のように、好みに左右される部分は、テストを自動化する手間に見合わないことが多くあります。使い捨て前提の試作のように、変更があまりに激しい段階でも、厳密なTDDは足かせになることがあります。

向いているかどうかは、これからどれだけ変更が起きそうかで考えると判断しやすくなります。

TDDで陥りやすいアンチパターンと改善策

TDDを始めたばかりのチームには、つまずきやすいパターンがあります。

ここでは、代表的な2つのポイントを整理します。

1. テストの保守そのものに時間を取られてしまう
2. 内部の作りに依存して、少しの変更でも壊れる

それぞれの課題と、そこから抜け出す向き合い方を見ていきます。

1. テストの保守そのものに時間を取られてしまう

テストの保守には一定の手間がかかりますが、これが必要以上に重くなることがあります。本体のコードよりテストのほうが複雑になり、直すこと自体に時間を取られてしまう状態です。

テストも本体と同じように整理し、シンプルに保ち続けることが改善につながります。テストは「保証したいこと」を確かめるためのものだと、立ち返るとよいでしょう。

2. 内部の作りに依存して、少しの変更でも壊れる

「この関数が呼ばれたか」のように、内部の細かい手順に依存したテストを書くと、コードを少し変えただけで大量のテストが壊れます。中の作りを変えただけで、結果は同じなのにテストが落ちてしまうからです。

そうではなく「この入力なら、この結果になる」という、外から見える結果を確かめるようにします。たとえば「1,000円の商品なら、送料込みで1,100円になる」を確かめておけば、計算の中身をどう書き換えても、結果さえ合っていればテストは通り続けます。

こうすると、変更に強いテストになります。

TDDに関するよくある質問

TDDに関するよくある質問をQ&A形式で整理しました。

まとめ

TDDは、単にテストを先に書くという技術ではありません。変更を怖がらずに進められる状態をつくり、アジャイルの「小さく試し、学びながら変える」進め方を支える土台です。

重要なのは、テストがすべて通ることではなく、「何を保証したいのか」を考え続けることです。生成AIで”書く”ことが速くなったいまも、ここはむしろ重みを増しています。

最初から完璧なテストをそろえる必要はありません。まずは、いま関わっている機能の一部について、「こう動けば正しい」という期待をチームで揃える会話から始めてみてください。