TDD, DDD, BDD... 「DD」が多すぎる問題を整理する
ソフトウェア開発の文脈では、DD がつく略語をよく見かけます。
- TDD
- DDD
- BDD
- ATDD
- FDD
- そして文脈によって意味が揺れる SDD
最初は「結局どれが何なのか分かりにくい」と感じやすいですが、実はそれぞれが見ているレイヤーと重視しているものが少しずつ違います。
この記事では、よく使われる DD 系の用語をピックアップして、
- 何を重視するのか
- どういう場面で使うのか
- 何と混同しやすいのか
をざっくり整理します。
まず結論
ざっくり言うと、DD 系は次のように分けて考えると理解しやすいです。
| 略語 | 何の略 | 主に見る対象 | よく使う場面 |
|---|---|---|---|
| TDD | Test-Driven Development | 実装とテスト | 実装の品質を上げたいとき |
| DDD | Domain-Driven Design | 業務知識とモデル | 複雑な業務ロジックを整理したいとき |
| BDD | Behavior-Driven Development | 振る舞い | 仕様を会話しながら固めたいとき |
| ATDD | Acceptance Test-Driven Development | 受け入れ条件 | 開発者と業務側の認識を揃えたいとき |
| FDD | Feature-Driven Development | 機能単位の進行 | 機能追加を着実に進めたいとき |
| SDD | 文脈依存 | 設計文書や仕様 | チームや会社の定義次第 |
DD は「Development なのか Design なのか」「Test なのか Behavior なのか」で意味が変わるので、略語だけを覚えるより、何を中心にしているかで覚えるほうが実務では役立ちます。
TDD: Test-Driven Development
TDD は テストを先に書いてから実装する 開発手法です。
特徴
- 先に失敗するテストを書く
- テストを通す最小限の実装を書く
- リファクタリングする
- このサイクルを短く回す
何がうれしいのか
- 実装の意図が明確になる
- 仕様漏れに気づきやすい
- 変更に強いコードになりやすい
どんな場面で使うか
- ロジックが複雑で、仕様を固めながら実装したいとき
- バグを早めに見つけたいとき
- 関数やクラスの振る舞いをきちんと定義したいとき
向いているもの
- ドメインロジック
- 金額計算
- バリデーション
- 状態遷移
注意点
TDD は「全部をテスト駆動にする」ことが目的ではありません。
UI の細かい見た目や、外部サービス依存が強い処理まで無理に TDD にすると、逆にしんどくなることがあります。
DDD: Domain-Driven Design
DDD は 業務の中心にあるドメインをきちんとモデル化する ための設計思想です。
特徴
- ビジネス上の概念をコードに反映する
- ユビキタス言語を使ってチームの認識を揃える
- エンティティ、値オブジェクト、集約などを使って境界を作る
何がうれしいのか
- 複雑な業務ルールを整理しやすい
- 言葉のズレを減らせる
- 「システムの都合」ではなく「業務の都合」で設計できる
どんな場面で使うか
- 業務ルールが複雑なサービス
- 変更が多く、仕様が言葉で表現される領域
- 金融、受発注、在庫、請求などの業務システム
向いているもの
- 複雑な状態管理
- 業務ルールの多いシステム
- 外部システムとの境界設計
注意点
DDD は「とにかくエンティティを増やすこと」ではありません。
業務上の意味がある単位で境界を引き、モデルを守るのが本質です。
BDD: Behavior-Driven Development
BDD は 振る舞いを中心に、仕様を人間が読める形で定義する 考え方です。
特徴
- 「何をするか」を自然言語に近い形で表現する
- Given / When / Then のような構造がよく使われる
- テストというより、仕様の会話の土台に近い
何がうれしいのか
- 開発者と非開発者の会話がしやすい
- 受け入れ条件を具体化しやすい
- 実装前に期待値を揃えやすい
どんな場面で使うか
- 仕様をチームでレビューしたいとき
- 業務側との認識合わせが重要なとき
- E2E や受け入れテストを設計したいとき
向いているもの
- ユーザー操作に近い流れ
- 画面やAPIの振る舞い
- 受け入れ条件の確認
注意点
BDD は「テストケースの名前を丁寧にすること」だけではありません。
本来は、振る舞いを共通言語で表現すること に価値があります。
ATDD: Acceptance Test-Driven Development
ATDD は 受け入れテストを先に考える ことで、開発者と業務側の認識を揃えるやり方です。
特徴
- 実装より先に受け入れ条件を定義する
- 仕様の抜け漏れを減らしやすい
- BDD と似ているが、より「受け入れ」に寄る
どんな場面で使うか
- 顧客や業務担当者と合意を取りながら進めたいとき
- 仕様変更の多いプロジェクト
- 受け入れ条件が明確な案件
BDD との違い
BDD は「振る舞いの表現」に重心があります。
ATDD は「受け入れ条件の確認」に重心があります。
実務ではかなり近い文脈で使われるので、厳密な言葉の違いより、誰と何を合意したいのか で考えると分かりやすいです。
FDD: Feature-Driven Development
FDD は 機能単位で設計・計画・実装を進める ことに重きを置く開発手法です。
特徴
- 機能を小さく分けて進める
- 進捗が見えやすい
- 比較的管理しやすい
どんな場面で使うか
- 機能追加が多いプロジェクト
- 進捗管理を明確にしたいとき
- 大きめのチームで開発を進めるとき
向いているもの
- 機能ベースの計画
- 反復的な開発
- 進捗の可視化
SDD: 文脈で意味が揺れる略語
SDD は少しやっかいです。文脈によって意味が変わります。
よく見かけるのはたとえば次のようなものです。
- Software Design Document
- Security-Driven Development
- Specification-Driven Development
- Service Design / System Design の略として使われるケース
つまり、SDD は 「これが唯一の正解」という略語ではない ことが多いです。
会話の中で出てきたら、まず「その場では何を指しているのか」を確認したほうが安全です。
どんな場面で使うか
- 設計書の話をしているとき
- セキュリティを中心に置いた開発の話をしているとき
- 仕様を先に固める開発フローを指しているとき
どう使い分けるか
迷ったときは、次の軸で考えると整理しやすいです。
| 何を重視するか | 代表例 | 覚え方 |
|---|---|---|
| 実装の正しさ | TDD | テストを先に書く |
| 業務の正しさ | DDD | ドメインを中心に置く |
| 振る舞いの分かりやすさ | BDD | 人が読める仕様にする |
| 受け入れ条件の一致 | ATDD | 合意を先に作る |
| 機能の進めやすさ | FDD | 機能単位で進める |
現場でのおすすめ
実務では、1つだけを使うより、組み合わせることが多いです。
たとえば、
- ドメインが複雑なら DDD を軸にする
- 実装の細かいロジックは TDD で詰める
- 仕様の合意は BDD や ATDD で揃える
という使い方が自然です。
つまり、
- DDD は設計の軸
- TDD は実装の進め方
- BDD / ATDD は仕様の合意の仕方
と分けると、混乱がかなり減ります。
まとめ
DD 系の略語は多いですが、慌てて丸暗記しなくても大丈夫です。
大事なのは、
- 何を中心に置く考え方か
- 誰と何を揃えたいのか
- どの開発フェーズで効くのか
を押さえることです。
ざっくり言えば、
- TDD は「テストから実装を組み立てる」
- DDD は「業務の意味をモデルに落とす」
- BDD は「振る舞いを共通言語で表す」
- ATDD は「受け入れ条件を先に合意する」
- FDD は「機能単位で着実に進める」
- SDD は「文脈を確認してから使う」
という整理で覚えておくと、会話でも設計でもかなり楽になります。
必要なら次に、この記事をベースにして
- 図を追加した版
- もっとやわらかい口調の版
- 初学者向けにさらに噛み砕いた版
のどれかに整えます。