TDD（テスト駆動開発）とは｜進め方・向く場面と現場で続けるコツ

TDDとは｜テストを先に書いて設計を決める開発手法

TDDは、実装の前にテストを書くことで、コードの使われ方を先に固定する開発手法です。 1990年代後半にKent Beckがエクストリームプログラミングの実践の一つとして提唱しました。

Martin Fowlerは自身の解説で、TDDを「自己テスト可能なコードを得るための技術」と位置づけています。単にバグを減らす仕組みではなく、テストから書くことでインターフェースの設計が改善される点を重視する立場です（Martin Fowler「Test Driven Development」）。

Red・Green・Refactorの3ステップ

サイクルは3つに分かれます。

Greenの段階では、ベタ書きでも定数を返すだけでも構いません。設計を整えるのはRefactorの役割です。ここを分けずに「きれいなコードを一発で書こう」とすると、サイクルが長くなって破綻します。

TDDと「テストを後で書く」開発の違い

実装してからテストを書く進め方は、テスト自動化ではあってもTDDではありません。違いは、テストが設計への入力になっているか、実装の検算になっているかです。

後追いで書いたテストは、すでに存在する実装をなぞる形になりやすく、実装のミスをそのまま追認してしまうことがあります。先に書いた場合は、まだ存在しないコードをどう呼び出したいかを書くので、引数の順序や戻り値の形といったインターフェースの違和感が早い段階で出ます。

自動テストの整備とTDDは目的が違う

混同されやすい点なので分けておきます。

• 自動テストの整備：既存コードに保護網を張る。目的はリグレッション検知

• TDD：これから書くコードの設計を決める。目的は設計と仕様の明確化

どちらも自動テストを使いますが、入る順番も、書くテストの粒度も違います。既存コードに後から網を張る話は技術的負債とは｜リファクタリング案件の合意形成と単価への影響、生成AIでテストを起こす話はAIテスト自動化の実務｜生成AIで単体・E2Eテストを作る手順と限界で扱っています。

ミニFAQ：TDDをやるとテスト設計は不要になりますか？

なりません。TDDで書くのは主に開発者が設計のために書くテストで、境界値・異常系・非機能の観点を体系的に洗い出す作業は別に必要です。その領域はQAエンジニアとは｜仕事内容・年収・テストエンジニアとの違いをフリーランス視点で解説の守備範囲になります。

TDDの進め方｜1サイクルを短く保つ手順

結論として、TDDが回るかどうかは「1サイクルの長さ」に大きく左右されます。 数分から10分程度という目安が紹介されることが多く、これを大きく超え始めたらテストの粒度が大きすぎるサインと考えられます。ただし固定のルールではありません。ビルドやテスト実行に時間がかかる環境では、この範囲に収まらないこともあります。

実際の手順

1. 作る振る舞いを1文で書く。 コメントでも紙でも構いません。「金額が0円のとき、送料は無料にならない」程度の粒度にします。

2. その1文をテストコードに落とす。 まだ存在しない関数やクラスを呼びます。当然コンパイルも通りません。

3. 失敗を確認する。 ここを飛ばさないでください。テストが失敗しない理由で失敗している（タイポ、モックの設定ミス）ケースは珍しくありません。

4. 通す最小限を書く。 汚くて構いません。

5. Refactorする。 重複、長すぎる関数、意味の伝わらない名前を直します。テストは緑のままにします。

6. 次の1文に移る。

Kent Beck自身が後年、この手順を改めて整理しています（Kent Beck「Canon TDD」）。テストリストを先に作り、そこから1つずつ取り出すという書き方が明示されていて、我流との差分を確認するのに使えます。

サイクルが伸びたときの立て直し

10分を超えても緑にならないときは、実装を進めるのではなく、いったん戻します。

• 書いたテストが大きすぎないか。1つのテストで複数の振る舞いを検証していないか

• 実装対象が外部I/Oに直接触れていないか。触れているなら、その境界を切り出す

• そもそもテストで表現しづらい仕様なら、TDDに向かない領域かもしれません

書いたコードを捨てて小さいテストから書き直すほうが、結果的に早いことが多いです。

TDDの効果と限界｜研究データで確認できること

効果は出ますが、初期工数の増加とセットです。 ここを曖昧にしたまま導入を提案すると、現場で「思ったより遅い」と言われて続きません。

参照できる実証研究

Microsoftの3チームとIBMの1チームを対象にした事例研究では、TDDを採用しなかった類似プロジェクトと比べて、リリース前の欠陥密度が40〜90%低下したと報告されています。一方で、同じチームで初期の開発時間は15〜35%増加しています（Nagappan et al. "Realizing quality improvement through test driven development" (2008)）。

この数字を扱うときの注意点を挙げておきます。

• 対象は4チームで、業種も規模も限られます。あらゆる現場に当てはまる係数ではありません

• 2008年の発表です。当時と現在では、CI環境やテストフレームワークの整備状況が違います

• 「欠陥密度の低下」はリリース前の測定値で、運用フェーズまで追った数字ではありません

それでも、品質が上がる方向・初期工数が増える方向という向きは、実務の感覚とも一致します。提案の場では「早くなる」ではなく「後工程の手戻りが減る代わりに、最初は時間がかかる」と説明するほうが通りやすいです。

効果が出にくい領域

• 画面の見た目やレイアウト。期待値をコードで書きづらい

• 仕様が固まっていない探索的な試作。テストを書いた端から捨てることになります

• 外部APIやミドルウェアに強く依存する層。モックを積み上げると、テストが実装の写し鏡になります

この最後の点は実務で最も詰まります。Fowlerのテストピラミッドの議論が参考になります（Martin Fowler「The Practical Test Pyramid」）。

ミニFAQ：カバレッジは何%を目指せばいいですか？

TDDの文脈では目標値を決めない運用が現実的です。TDDで書いていれば結果としてカバレッジは上がりますが、逆に数値目標を先に置くと、通すだけのテストが増えて設計が良くなりません。数値を報告する必要がある現場では、全体の率ではなく「変更した範囲のカバレッジ」を見るほうが会話が噛み合います。

TDDを入れる・入れないの判断｜3軸で切り分ける

判断は「対象コードの性質」「参画期間」「現場のテスト文化」の3軸で決まります。 どれか1つが欠けても、部分的な適用には持ち込めます。

参画期間も掛け合わせます。3か月程度の短期参画なら、チーム全体への導入提案は現実的ではありません。自分の成果物の品質を担保する範囲に留めるほうが、結果として信頼を得やすいです。1年以上の長期参画で、かつ既存のテストがある程度動いている現場なら、チームの進め方に踏み込む余地があります。

レガシーコードに持ち込むときの順番

テストがない既存コードに、いきなりTDDを持ち込むことはできません。 テストを書ける形になっていないからです。

順番は次のようになります。

1. 特性テストを置く。 現在の振る舞いを、正しいかどうかは問わずそのまま固定するテストです。仕様書ではなく現状を写し取ります

2. テストが緑のまま、構造を切り出す。 外部I/Oと計算ロジックを分離します

3. 切り出せた内側で、新しい振る舞いからTDDを始める。

この1と2を飛ばして「まずテストから書きましょう」と言うと、テストが書けない設計に対してモックを大量に積む羽目になります。切り出しの手順や合意形成は技術的負債とは｜リファクタリング案件の合意形成と単価への影響、レイヤの分け方はクリーンアーキテクチャとは｜4層構造とDDDの関係を実務目線で解説とドメイン駆動設計（DDD）とは｜戦略設計と戦術設計の使いどころが参考になります。

フリーランスが現場に定着させる4段階

外部から入った立場でTDDを広げるなら、段階を踏みます。飛ばすと「外の人が持ち込んだやり方」として扱われて終わります。

段階1：自分の手元だけで回す（参画してしばらく経ってから）

参画直後は既存のやり方に合わせてください。 目安として最初の2〜4週間ほどは、コードベースの癖とレビュー文化を掴む期間に充てると動きやすくなります。この期間はチーム規模やオンボーディングの手厚さで変わるため、固定の日数として捉える必要はありません。慣れないうちにTDDを持ち出すと、成果が出る前に進め方の話になってしまいます。

手元でTDDを回す分には、誰の合意も要りません。コミットの粒度もテストの有無も自由です。

段階2：PRにテストを添える

自分のPRに、対応するテストを必ず付けます。説明を足さないのがコツです。 「TDDで書きました」と書かずに、テストが付いた読みやすいPRを出し続けます。

レビューでの伝え方そのものはコードレビューの作法｜指摘の書き方・受け方と信頼される進め方で整理しています。

段階3：チームで合意を取る

バグ修正のPRで「このバグを再現するテストを先に足してから直しました」という形を何度か見せると、話が通りやすくなります。再現テストから入る進め方は、TDDという言葉を使わずにTDDの価値を説明できる数少ない入り口です。

このタイミングで、適用範囲を明示的に決めます。全部に入れようとしないでください。ロジック層だけ、あるいは新規モジュールだけ、という線引きにします。

段階4：CIに載せる

テストがローカルでしか動かない状態だと、数か月で腐ります。CIで自動実行されるところまで持っていって、ようやく定着です。設定の実務はGitHub Actionsとは？CI/CDの仕組み・基本ワークフロー・案件単価をフリーランス視点で解説を参照してください。

アジャイル系の現場ではスプリントの進め方と噛み合わせる必要があります。前提はアジャイル開発とは｜仕組み・スクラム・ウォーターフォールとの違いにまとめています。

ミニFAQ：ペアで作業する機会がない現場でも広げられますか？

広げられます。段階2のPRを積み重ねる方法は、非同期のレビュー文化でも機能します。ただし段階3の合意形成には時間がかかるため、参画期間が短いなら段階2で止める判断も妥当です。

見積もり・契約でテスト工数をどう扱うか

テストコードを書く時間は、実装の一部として見積もりに含めるのが基本です。 別項目に切り出すと、削られる対象になります。

準委任と請負での違い

準委任契約では、成果物ではなく稼働を提供する形が基本になるため、進め方の裁量は受託側に比較的委ねられるケースが多くなります。テストを書くかどうかで単価が変わる性質のものではありません。

請負契約の場合は、テストコードが納品物に含まれるかを契約書で確認してください。 納品物の範囲や著作権の帰属は契約書の定めによって決まり、案件ごとに扱いが異なります。検収の対象になるのか、自分の作業資産として残せるのかは、契約前に個別に確認する必要があります。ここが曖昧なまま進むと、納品後の保守で認識が食い違う原因になります。判断に迷う条項があれば、契約前に弁護士等の専門家に確認するのが確実です。

見積もりの作り方そのものは工数見積もりのやり方｜手法4種・根拠の作り方とバッファ設計・失敗パターンで扱っています。

単価交渉での位置づけ

TDDの経験そのものに単価が付くわけではありません。評価されるのは、「テストがない領域に保護網を張って安全に変更できる状態にした」という結果のほうです。商談では手法名ではなく、担当範囲・変更頻度・障害の減り方といった事実で話すほうが伝わります。

設計側のスキルとして整理する場合はエンジニアの設計力・上流スキルの磨き方｜段階別ロードマップと単価アップが参考になります。自分の経験で今どのくらいの単価帯を狙えるか確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？に整理しています。

言語・フレームワーク別の入り口

TDDの考え方は言語に依存しませんが、実際に回すにはテストフレームワークの作法を押さえる必要があります。担当言語に応じて次を参照してください。

E2Eテストは実行時間が長く、TDDのサイクルには乗りません。E2Eは回帰検知の道具として別枠で考えてください。単体テストの定義そのものが現場で揺れている点については、Martin Fowler「UnitTest」の整理が役に立ちます。

よくある失敗と対策

Refactorを飛ばす

最も多い失敗です。Fowlerも3番目のステップを怠ることを典型的な失敗として挙げています。Greenで止めると、通るだけの汚いコードが積み上がります。サイクルの終わりを「テストが通ったとき」ではなく「構造を直したとき」に置いてください。

テストが実装の写経になる

実装の内部構造をそのまま検証するテストは、リファクタのたびに壊れます。壊れるたびにテストを直すので、テストが変更の足かせになります。検証するのは外から見える振る舞いに限定します。

モックを積み上げすぎる

モックが増えるのは、対象が外部依存に直接触れている合図です。モックを足すのではなく、依存を境界に追い出す設計に変えるほうが早いです。自己テスト可能なコードの考え方はMartin Fowler「SelfTestingCode」にまとまっています。

カバレッジを目的にする

数値目標が先に立つと、アサーションのないテストや、通すだけのテストが増えます。カバレッジは結果を見る指標であって、達成目標には向きません。

全部に適用しようとする

UIも設定ファイルも試作コードも、という進め方は続きません。適用範囲を明示的に絞ることが、続けるための条件です。

実践チェックリスト

参画先でTDDを始める前に、次を確認してください。

• [ ] 担当範囲のうち、ロジックが独立して切り出せる部分がどこか把握したか

• [ ] テストがローカルで実行できるか（依存サービスの起動方法を含めて）

• [ ] CIが動いているか。動いていない場合、誰が管理しているか

• [ ] 既存テストの成功率を確認したか（常に赤いテストが放置されていないか）

• [ ] 参画から2〜4週間、既存の進め方を観察したか

• [ ] 契約が請負の場合、テストコードが納品物に含まれるか確認したか

• [ ] 1サイクルが10分以内に収まる粒度でテストを書けているか

• [ ] Refactorのステップを毎回実行しているか

• [ ] 適用範囲を「ロジック層のみ」等に絞って宣言したか

• [ ] バグ修正時に、再現テストを先に書く運用にしたか

まとめ

TDDは、テストを先に書くことで設計を決める手法であり、適用範囲を絞って初めて続きます。 全面導入を目指すと失敗し、ロジック層に限定すると定着します。

• Red・Green・Refactorの1サイクルは10分以内。超えたらテストの粒度を疑う

• 研究報告では欠陥密度40〜90%減・初期開発時間15〜35%増（4チームの事例、2008年）。品質と初期工数のトレードオフとして説明する

• 向くのはロジック層。UI・試作・外部依存の濃い層には持ち込まない

• レガシーコードには特性テスト→構造の切り出し→TDDの順で入る

• 外部から入った立場では、手元→PR→チーム合意→CIの4段階で広げる。参画直後の2〜4週間は既存のやり方を観察する

• 請負契約では、テストコードが納品物に含まれるかを契約時に確認する

次のステップとしては、担当している機能のうちロジックが独立している箇所を1つ選び、次のバグ修正で再現テストから書いてみてください。そこが最も抵抗の少ない入り口になります。

参照した一次情報は次のとおりです。

• Martin Fowler「Test Driven Development」

• Martin Fowler「SelfTestingCode」

• Martin Fowler「UnitTest」

• Martin Fowler「The Practical Test Pyramid」

• Kent Beck「Canon TDD」

• Nagappan et al. "Realizing quality improvement through test driven development" (2008)