TDD・SDD・DDDの違いとは？3つの開発手法を比較解説

「TDD、SDD、DDD——略語が似ていて、正直どれがどれだか整理しきれない」と感じたことはないでしょうか。私自身、開発現場でこれらの手法に触れるたびに、それぞれの境界線が曖昧になり混乱した経験があります。本記事では、3つの開発手法の違いを比較表とともに整理し、実務での使い分けを解説します。

TDD・SDD・DDDそれぞれの基本概念

まず、3つの手法を端的に定義します。

TDD（Test-Driven Development：テスト駆動開発） は、実装コードを書く前にテストコードを先に書く開発手法です。Kent Beckが提唱した「Red → Green → Refactor」のサイクルが基本で、失敗するテストを書き、最小限の実装で通し、リファクタリングするという流れを繰り返します。

SDD（Spec-Driven Development：仕様駆動開発） は、仕様（Specification）を最初に定義し、その仕様を「信頼できる唯一の情報源（Single Source of Truth）」として開発を進める手法です。ここでいう仕様とは、OpenAPI（Swagger）やGraphQLスキーマ、Protocol Buffers、JSON Schemaなど、機械可読な形式で記述されたインターフェース定義を指します。仕様を起点にコード生成・バリデーション・ドキュメント作成を自動化し、フロントエンド・バックエンドの並行開発を可能にするのが大きな特徴です。

DDD（Domain-Driven Design：ドメイン駆動設計） は、Eric Evansが提唱した設計手法で、ビジネスドメインの知識をソフトウェア設計の中心に据えます。ユビキタス言語、境界づけられたコンテキスト、集約といった概念を用いて、ビジネスロジックの複雑さに対処するのが特徴です。

最初は「どれも設計の話でしょう」と大雑把に捉えていたのですが、実際にはそれぞれの焦点がまったく異なることに気づかされました。

TDD——「Red → Green → Refactor」の具体的な流れ

TDDの概念は理解していても、実際にどう進めるのかイメージしにくいという声をよく聞きます。ここでは、ECサイトの「カート合計金額を計算する」という機能を例に、TDDのサイクルを具体的に見てみましょう。

ステップ1：Red（失敗するテストを書く）

まず、まだ存在しない関数に対してテストを書きます。

// cart.test.js
test("商品が1つのとき、その商品の価格×数量が合計になる", () => {
  const items = [{ name: "Tシャツ", price: 2000, quantity: 3 }];
  expect(calculateTotal(items)).toBe(6000);
});

この時点では calculateTotal 関数は存在しないため、テストは当然失敗します。これが「Red」の状態です。

ステップ2：Green（最小限の実装でテストを通す）

次に、テストを通すために最小限の実装を書きます。

// cart.js
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

テストが通り「Green」の状態になりました。ここで重要なのは、この段階では「きれいなコード」を目指さないことです。まずテストを通すことだけに集中します。

ステップ3：Refactor（テストを維持しながら改善する）

Greenの状態を保ったまま、コードの構造を改善します。たとえば、割引ロジックの追加が見込まれる場合は、計算処理を拡張しやすい構造に整理するかもしれません。テストが通り続けている限り、安心してリファクタリングできます。

サイクルを回す

続けて、新しいテストケースを追加していきます。

test("複数商品のとき、各商品の小計の合計が返る", () => {
  const items = [
    { name: "Tシャツ", price: 2000, quantity: 3 },
    { name: "マグカップ", price: 800, quantity: 1 },
  ];
  expect(calculateTotal(items)).toBe(6800);
});

test("カートが空のとき、0が返る", () => {
  expect(calculateTotal([])).toBe(0);
});

このように、小さなテストを積み重ねることで、仕様を網羅しながら堅牢な実装が出来上がっていきます。

私がTDDを実践して最も価値を感じたのは、「テストが設計を導いてくれる」という点でした。テストを先に書くことで、関数のインターフェースを利用者の視点から考えるようになり、結果として使いやすいAPIが自然と生まれるのです。一方で、UIの表示ロジックやデータベースとの結合部分など、入出力が曖昧な箇所では無理にTDDを適用しようとして手が止まることもありました。万能ではないからこそ、得意な領域を見極めることが大切です。

SDD——仕様ファーストで開発を回す具体例

SDDの核心は「まず仕様を書き、仕様からすべてを生成する」という考え方にあります。APIの仕様をOpenAPIで定義するケースを例に、具体的な開発フローを見てみましょう。

ステップ1：OpenAPIで仕様を定義する

たとえば、ユーザー情報を取得するAPIの仕様を以下のように記述します。

# openapi.yaml
openapi: 3.0.3
info:
  title: User API
  version: 1.0.0
paths:
  /users/{userId}:
    get:
      summary: ユーザー情報を取得する
      parameters:
        - name: userId
          in: path
          required: true
          schema:
            type: string
            format: uuid
      responses:
        "200":
          description: 成功
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/User"
        "404":
          description: ユーザーが見つからない
components:
  schemas:
    User:
      type: object
      required: [id, name, email]
      properties:
        id:
          type: string
          format: uuid
        name:
          type: string
          example: "田中太郎"
        email:
          type: string
          format: email

このYAMLファイルが、チーム全体の「契約書」になります。

ステップ2：仕様から自動生成する

仕様が定まったら、さまざまな成果物を自動生成します。

TypeScriptの型定義： openapi-typescript などのツールでリクエスト・レスポンスの型を生成し、フロントエンドとバックエンドの両方で利用する
モックサーバー： Prism などを使い、仕様に準拠したモックAPIを即座に立ち上げる。フロントエンドチームはバックエンドの実装完了を待たずに開発を開始できる
APIドキュメント： Swagger UI や Redoc で、常に仕様と同期したドキュメントを公開する
バリデーション： リクエスト・レスポンスが仕様に適合しているかをミドルウェアで自動検証する

ステップ3：仕様を軸に並行開発する

ここがSDDの真骨頂です。仕様という共通言語があることで、フロントエンドチームとバックエンドチームが同時に動き出せます。

フロントエンド： モックサーバーに対して画面を開発する。型定義が生成済みなので、APIの構造を推測する必要がない
バックエンド： 仕様に定義されたエンドポイントを実装する。バリデーションミドルウェアが仕様との乖離を検出してくれる
QA： 仕様からテストケースの骨格を生成し、エッジケースの検証を進める

仕様変更が発生したら？

SDDでは「仕様ファイルを変更する → 再生成する → 差分を確認する」という流れで変更を管理します。たとえば、Userスキーマに phoneNumber フィールドを追加する場合、仕様を更新して再生成すれば、型定義・ドキュメント・バリデーションがすべて追従します。コードと仕様が乖離するリスクを構造的に排除できるのです。

私がSDDの価値を痛感したのは、あるプロジェクトでフロントエンドとバックエンドのチームが「APIのレスポンスにこのフィールドは含まれるのか」で揉めた経験がきっかけでした。Slackでの口頭合意やConfluenceのドキュメントでは、どうしても認識のズレが生じます。機械可読な仕様を一つ置くだけで、こうした摩擦の大部分が解消されました。

DDD——ビジネスの言葉でコードを書く

DDDは3つの手法の中で最も学習コストが高いと言われますが、その分、複雑なビジネスロジックを扱うプロジェクトでは絶大な効果を発揮します。「オンライン予約システム」を例に、DDDの考え方がどのようにコードに反映されるかを見てみましょう。

ユビキタス言語の確立

DDDでは、開発者とドメインエキスパート（業務担当者）が共通の言葉を使うことを重視します。たとえば、宿泊予約システムであれば以下のような用語を定義します。

予約（Reservation）： ゲストが宿泊日と部屋を指定して行う申し込み
空室（Availability）： 特定の日付に予約可能な部屋の状態
キャンセルポリシー（CancellationPolicy）： 予約取り消し時の料金規定

重要なのは、コード上の変数名やクラス名にもこの用語をそのまま使うことです。「data」や「info」といった汎用的な命名を避け、ビジネスの言葉でコードを書く。これにより、コードを読むだけでビジネスルールが理解できる状態を目指します。

集約でビジネスルールを守る

DDDの「集約（Aggregate）」は、データの整合性を保つ単位です。予約システムでは、Reservationを集約ルートとして設計するかもしれません。

class Reservation {
  private status: ReservationStatus;
  private checkIn: Date;
  private cancellationPolicy: CancellationPolicy;

  cancel(currentDate: Date): void {
    if (this.status !== "confirmed") {
      throw new Error("確定済みの予約のみキャンセルできます");
    }
    // キャンセルポリシーに基づいて料金を計算
    const fee = this.cancellationPolicy.calculateFee(
      this.checkIn, currentDate
    );
    this.status = "cancelled";
    this.addDomainEvent(new ReservationCancelled(this.id, fee));
  }
}

「確定済みの予約のみキャンセルできる」「キャンセル料はポリシーに基づいて算出する」といったビジネスルールが、集約の中に凝集しています。このルールがサービス層やコントローラーに散らばっていると、変更時に影響範囲が把握しにくくなります。DDDでは、こうしたビジネスルールをドメインオブジェクトに閉じ込めることで、変更に強い設計を実現します。

境界づけられたコンテキスト

システムが大きくなると、同じ「ユーザー」という概念でも、文脈によって意味が異なるケースが出てきます。予約コンテキストでは「ゲスト」、決済コンテキストでは「支払者」、マーケティングコンテキストでは「リード」というように。DDDでは、これらを無理に統一するのではなく、「境界づけられたコンテキスト」として分離し、コンテキスト間の変換ルールを明示的に定義します。

私がDDDに取り組み始めた頃は、概念の多さに圧倒されて「全部を最初から完璧にやらなければ」と構えてしまい、なかなか前に進めませんでした。実際には、ユビキタス言語の整理だけでもチーム内のコミュニケーションが目に見えて改善します。すべてを一度に導入する必要はなく、効果の高い部分から段階的に取り入れるのが現実的です。

3つの手法を比較する——観点別の整理

同じように「違いがわかりにくい」と感じている方のために、主要な観点で比較表を作成しました。

観点	TDD	SDD	DDD
主な関心事	コードの正しさ・品質	インターフェースの契約	ビジネスロジックの構造
起点となる成果物	テストコード	仕様定義ファイル（OpenAPI等）	ドメインモデル
適用フェーズ	実装フェーズ	API・インターフェース設計フェーズ	要件定義・設計フェーズ
主な効果	回帰バグの防止、設計改善	チーム間の並行開発促進	ビジネスと実装の一致
代表的ツール	Jest, pytest, RSpec	OpenAPI, GraphQL, Protobuf	EventStorming, Context Map
学習コスト	中程度	低〜中程度	高い
チーム規模との相性	規模を問わない	複数チーム並行開発向き	中〜大規模向き

この表を作る過程で改めて実感したのは、3つの手法は競合関係ではなく、それぞれ異なるレイヤーの課題を解決しているという点です。TDDは「実装が正しいか」、SDDは「チーム間の認識が揃っているか」、DDDは「ビジネスの本質を捉えているか」に答えます。

なぜ「レイヤーが違う」と言えるのか

もう少し掘り下げると、3つの手法は意思決定のタイミングと対象が異なります。

DDD はプロジェクトの最上流で「何を作るか」「ビジネスの構造をどうモデリングするか」を決める
SDD は設計フェーズで「コンポーネント間のやり取りをどう定義するか」を決める
TDD は実装フェーズで「個々の関数やクラスが正しく動くか」を検証する

上流から下流に向かって適用範囲が絞り込まれていくイメージです。だからこそ、互いに排他的ではなく、組み合わせて使うことに大きな意味があります。

実務での使い分け——プロジェクト特性に応じた選択基準

「結局どれを使えばいいのか」という疑問に対して、私が実務で得た感覚をもとに整理します。一概には言えない部分もありますが、以下のような判断基準が参考になるかもしれません。

TDDが特に効果を発揮する場面：

計算ロジックやバリデーションなど、入出力が明確な処理が多い
既存コードのリファクタリングを安全に進めたい
長期運用でバグの再発を防ぎたい

SDDが特に効果を発揮する場面：

フロントエンドとバックエンドを別チームが開発している
マイクロサービス間の連携が多い
APIファーストで外部公開を前提としたサービス

DDDが特に効果を発揮する場面：

ビジネスルールが複雑で、単純なCRUDでは表現しきれない
ドメインエキスパート（業務に詳しい人）との協業が必要
システムが成長するにつれてコードの見通しが悪くなっている

振り返ると、私自身も「とりあえずTDDを導入すれば品質は上がるだろう」と考えていた時期がありました。しかし、ビジネスロジックの構造自体が整理されていない状態でテストを書いても、テストコードがビジネスの変更に追従できず、かえってメンテナンスコストが増えてしまったのです。DDDでドメインモデルを整理してからTDDでテストを書くという順序に変えたことで、状況が大きく改善されました。

導入時によくある落とし穴

手法の選択だけでなく、導入の進め方にも注意が必要です。私が見てきたプロジェクトで陥りがちだったパターンをいくつか共有します。

TDDの落とし穴：カバレッジ至上主義 テストカバレッジの数値を追い求めるあまり、意味の薄いテストが量産されるケースがあります。getter/setterのテストや、フレームワークの内部挙動を検証するようなテストは、メンテナンスコストに対してバグ検出の効果がほとんどありません。「このテストが失敗したら、本当にバグがあると言えるか」を常に自問することが大切です。

SDDの落とし穴：仕様と実装の乖離を放置する 仕様を最初に定義しても、開発が進むにつれて「仕様を更新せずにコードだけ変える」という状況が生まれがちです。こうなると仕様の信頼性が失われ、SDDの意味がなくなります。CIパイプラインに仕様とコードの整合性チェックを組み込み、乖離が発生したらビルドを失敗させる仕組みが有効です。

DDDの落とし穴：過度な抽象化 DDDの概念に忠実であろうとするあまり、小規模なCRUDアプリケーションにまで集約・リポジトリ・ドメインサービスといった構造を持ち込んでしまうケースです。ビジネスロジックがほとんどないのにDDDのフル装備を適用すると、構造だけが複雑になり、かえって開発速度が落ちます。DDDは「複雑さに対処する手法」なので、複雑さがないところには不要です。

3つの手法を組み合わせるアプローチ

実際のプロジェクトでは、これらの手法を単独で使うよりも組み合わせるケースが多いのではないでしょうか。以下に、実践的な組み合わせパターンを示します。

パターン1：DDD + TDD（ドメイン中心の堅牢な開発）

DDDで境界づけられたコンテキストと集約を設計し、各集約のビジネスルールをTDDで実装します。ドメイン層のテストが充実するため、ビジネスロジックの変更に強い構造になります。

EventStormingでドメインイベントを洗い出す
集約・エンティティ・値オブジェクトを設計する
ドメインオブジェクトの振る舞いをTDDで実装する
Red → Green → Refactorを繰り返す

たとえば、先ほどの予約システムであれば、Reservation.cancel() のビジネスルール（キャンセル期限の判定、キャンセル料の計算）をTDDで一つずつテストしながら実装していきます。ビジネスルールが明確にテストコードに表現されるため、半年後に仕様変更が入った際にも「どのテストが影響を受けるか」がすぐにわかります。

パターン2：SDD + TDD（API品質を担保する開発）

OpenAPIなどで仕様を先に定義し、その仕様からテストケースを生成してTDDのサイクルに組み込みます。契約テスト（Contract Testing）の考え方と親和性が高い組み合わせです。

OpenAPIでAPI仕様を定義する
仕様からモック・型定義・テスト雛形を自動生成する
生成されたテストをベースにTDDで実装を進める
フロントエンドはモックを使って並行開発する

この組み合わせの強みは、「仕様に書かれたレスポンス構造と実装が一致しているか」を自動テストで継続的に検証できる点です。仕様変更の際にも、まず仕様ファイルを更新し、テストが失敗する（Red）のを確認してから実装を修正する（Green）という、SDDとTDDの自然な融合が生まれます。

パターン3：DDD + SDD + TDD（フルスタックでの適用）

大規模なシステムでは、3つすべてを段階的に適用するアプローチも有効です。DDDで全体の構造を設計し、SDDでサービス間の契約を定義し、TDDで各サービスの実装品質を担保します。

具体的な流れとしては、DDDのEventStormingで洗い出した境界づけられたコンテキストがマイクロサービスの境界となり、コンテキスト間のやり取りをOpenAPIやProtocol Buffersで仕様化し、各サービス内のドメインロジックをTDDで実装するという形です。最初からすべてを完璧に適用しようとすると負荷が大きいので、段階的に導入するのが現実的でしょう。

まとめ——手法の選択は目的から逆算する

TDD・SDD・DDDは、それぞれ「コード品質」「チーム間連携」「ビジネス構造」という異なる課題に対するアプローチです。重要なのは、手法そのものに固執するのではなく、自分たちのプロジェクトが抱える課題を見極め、最も効果的な手法を選択することだと感じています。

私の経験では、まず現在のプロジェクトで最も痛みを感じている部分を特定し、そこに対応する手法から導入するのが成功率の高い進め方でした。チーム間の認識齟齬が多ければSDD、バグの再発に悩んでいればTDD、ビジネスロジックの複雑さに押しつぶされそうならDDDという具合です。

そして、一つの手法で効果を実感できたら、足りない部分を補う形で別の手法を組み合わせていく。この「小さく始めて、段階的に広げる」というアプローチが、現場に無理なく定着させるコツだと私は考えています。

開発手法の選定や技術戦略についてお悩みの方は、こちらからお気軽にご相談ください。プロジェクトの状況に応じた最適なアプローチを一緒に考えさせていただきます。