SDDとTDDの違い｜併用する5つの接点

はじめに

「SDDとTDDは、どちらを選べばよいのか」。AIコーディングや仕様駆動開発を調べると、よく出る疑問です。

結論から言えば、二者択一ではありません。SDD（仕様駆動開発）は「何を、なぜ、どの条件で作るか」をそろえ、TDD（テスト駆動開発）は「次の小さな振る舞いをどう実装し、設計を改善するか」を短いループで確かめます。 対象と時間軸が違うため、同じ案件で併用できます。

ただし、仕様書を書いた後にテストを書けば自動的に併用できるわけではありません。仕様の項目を、実行可能なテストへどう渡し、変更時にどう戻すかを決める必要があります。本記事では両者の違いと、実務で接続する5つのポイントを整理します。

SDDとTDDの違いは「駆動する成果物」にある

SDDという言葉の使い方は、ツールや組織によって少し異なります。GitHubのSpec Kit公式ドキュメントでは、基本の流れを「Specify → Plan → Tasks → Implement → Converge」とし、仕様を計画、実装、収束まで持ち運ぶプロセスとして説明しています。

一方、Martin FowlerのTDD解説では、次に追加したい機能のテストを書き、通るまで実装し、その後にコードとテストをリファクタリングする3段階を繰り返すとしています。一般にRed、Green、Refactorと呼ばれる短い反復です。

SDDは上流だけ、TDDは下流だけという分け方も正確ではありません。SDDでは実装後に仕様へ収束させる確認があり、TDDで書くテストはインターフェースや設計にも影響します。違いは工程ではなく、開発判断を前へ進める中心的な成果物にあります。

仕様だけでは、コードが期待通り動く証明にはなりません。テストがすべて通っても、そもそも必要な要件を漏らしていれば正しい製品にはなりません。両者は別の失敗を防ぎます。

SDDとTDDを併用する5つの接点

1. 仕様の受け入れ条件をテストケースの入口にする

最初の接点は、仕様にある受け入れ条件です。「パスワードを再設定できる」のような機能名だけでは、TDDのテストへ落とせません。

たとえば、仕様を次のように具体化します。

• 再設定リンクは発行から30分で失効する
• 一度使ったリンクは再利用できない
• 対象外の利用者情報を画面へ表示しない
• 失敗時は理由に応じた結果を返す

TDDでは、このうち一つを選び、「31分後のリンクは拒否される」という失敗テストから始められます。仕様はテストケースの候補を供給し、テストは仕様の曖昧さを見つけます。

大切なのは、仕様の文章をそのままテスト名へコピーすることではありません。入力、事前状態、操作、期待結果を分け、観測可能な条件へ変換します。AIテスト自動化は受け入れ条件から始めるで整理した通り、テスト可能性は仕様品質を測る一つの物差しになります。

2. 受け入れテストと単体テストの役割を分ける

仕様から直接作る受け入れテストと、TDDで増やす単体テストは同じものではありません。

受け入れテストは、利用者から見た振る舞いが成立するかを確認します。単体テストは、実装を小さく進め、設計を改善するための速いフィードバックを担います。すべての仕様文を単体テストに押し込むと、内部実装に強く依存し、変更しにくくなります。

上位のテストが「何を守るか」を示し、下位のテストが「安全にどう作るか」を支えます。この層分けがあると、AIが大量にテストを生成しても、同じ条件の重複や重要な条件の空白を見つけやすくなります。

3. 仕様IDとテストを追跡できるようにする

併用で最も起きやすい失敗は、仕様とテストが別々に増えることです。仕様変更後も古いテストが通り続ければ、成功表示が誤解を生みます。

各仕様に短いIDを付け、受け入れ条件、実装タスク、代表テストを関連付けます。

すべての単体テストに仕様IDを付ける必要はありません。要件を代表するテストだけをひも付け、細かな実装テストはコード構造に沿って管理します。

仕様変更では「仕様を直す→影響するテストを特定する→テストを先に変更して失敗を確認する→実装する→仕様と結果を収束させる」という順番にします。仕様駆動開発の基本で扱った仕様の更新と、TDDの短いループをここで接続できます。

4. AIへ渡すコンテキストを役割別に分ける

AIコーディングでは、仕様、設計、既存コード、テストを一度に渡すだけでは不十分です。資料同士が矛盾していると、AIはどれを正本にすべきか判断できません。

実装タスクごとに、次の順でコンテキストを渡します。

1. 変更対象の仕様IDと受け入れ条件
2. 対象範囲と対象外
3. 既存の設計制約とインターフェース
4. 最初に失敗させるテスト
5. 実行する検証コマンド
6. 更新が必要な仕様・記録

ここでAIへ「実装して」とだけ頼まず、まずテスト案と仕様の不明点を出させます。不明点が業務判断に関わるなら、人が仕様を更新してから実装へ進みます。実装方法の局所的な判断なら、TDDのループ内で設計を改善できます。

AIがテストを通すためだけに仕様を狭く解釈していないか、テスト対象外のエラー処理を削っていないかも確認します。テスト成功は必要条件ですが、仕様への適合を単独では保証しません。

5. 完了条件を「仕様・テスト・実装」の三点でそろえる

最後の接点は完了条件です。コードが動く、テストが通る、仕様書がある、のどれか一つで完了にしません。

最低限、次をレビューします。

• 対象仕様に未決定の条件が残っていない
• 重要な受け入れ条件に代表テストがある
• 新しいテストが変更前に失敗したことを確認した
• 実装後に対象テストと回帰テストが通った
• リファクタリング後も同じ振る舞いを保っている
• 実装中に得た制約や例外を仕様へ戻した
• 対象外へ変更が広がっていない

TDDではGreenで止めず、Refactorまで行うことが重要です。SDDでも実装して終わらず、成果物間の矛盾を解消して収束させます。両者を併用するときの完了は、テスト結果だけでなく、仕様と実装が同じ状態を説明できることです。

SDDだけ、TDDだけで進めやすい場面

すべての変更に同じ重さのプロセスは不要です。

既知の不具合を小さく直し、期待結果が明確なら、再現テストから始めるTDDが中心になります。反対に、新規サービスの目的、利用者、権限、外部連携が未確定なら、テストを書く前にSDDで境界をそろえる必要があります。

方法論の名称を導入すること自体を目的にしないでください。仕様の曖昧さが主なリスクならSDDを厚くし、局所的な設計劣化や回帰が主なリスクならTDDのループを厚くします。

併用を始めるための最小テンプレート

最初から全要件と全テストをひも付ける必要はありません。次の一枚から始められます。

• 仕様ID：何を識別するか
• 目的：なぜ必要か
• 対象／対象外：どこまで変えるか
• 受け入れ条件：観測できる結果は何か
• 代表テスト：最初に何を失敗させるか
• 実装タスク：どの順で進めるか
• 検証：何を実行し、誰が確認するか
• 変更記録：実装中に何が分かったか

SDDとTDDの違いは競合関係ではありません。SDDは意図と境界を開発の中心に置き、TDDは小さな振る舞いとフィードバックを実装の中心に置きます。仕様から代表テストを作り、テストで見つけた曖昧さを仕様へ戻す。この往復ができれば、AIによる実装速度を上げても、何を作るはずだったかを見失いにくくなります。

既存の議事録や要求メモを、AI実装とテストへ渡せる仕様に整理したい場合は、株式会社Atsumellへご相談ください。要件、受け入れ条件、検証手順がつながる開発プロセスづくりを支援します。