ATDD（受け入れテスト駆動開発）の実装ステップ：BDD・TDDとの違いと導入パターン

ATDD（受け入れテスト駆動開発）は、ビジネス要件から逆算して受け入れテストを先に定義し、要件漏れを防ぎながら開発を進める手法ですが、BDD・TDDと組み合わせ、チームの習熟度に応じて段階的にツールと運用を整えて初めて効果を発揮します。本記事は QA エンジニアやテスト自動化担当者、アジャイル開発チームのリードを対象に、ATDDの実装ステップ、BDD・TDDとの違いと使い分け、プロジェクト規模別の導入パターンを解説します。読み終えれば、既存プロジェクトへATDDを後付けする際の判断基準と、自チームに合ったツール選定・導入手順を組み立てられるようになります。

ATDDは、顧客・開発者・テスターの三者（トライアド）が実装前に受け入れテストを協働で定義する手法で、テストは顧客に読める形で記述され、自動化は必須ではありません。要件そのものをテストとして固定する点が、TDD・BDDとの位置づけの違いを生みます。

ATDDの循環は次の5ステップで進みます。

1. トライアドで要件から具体例を出し合う（「ログイン失敗が3回続いたらロックする」など）
2. 具体例を受け入れ基準として文章化する
3. 受け入れ基準をGherkin記法や表形式に落とし、実行可能な受け入れテストへ変換する
4. テストが通るように開発者が実装する
5. CIでテストを回し、次のストーリーの要件定義に戻る

Gherkin記法で書く場合、受け入れテストは次のような形になります。

Feature: ログインロック
  Scenario: 3回連続で失敗するとロックされる
    Given ユーザーが存在する
    When パスワードを3回連続で間違える
    Then アカウントがロックされる

このステップ3で作った受け入れテストは、テストであると同時に要件仕様書として機能します。実装が完了した後もテストコードとして残るため、要件がドキュメントとコードの両方で同期した状態を保てます。TDDの単体テストが実装の内部ロジックを検証するのに対し、ATDDのこの循環は「ビジネス要件が満たされているか」を毎イテレーションで検証する点が異なります。自動化のタイミングは必須ではなく、まず手動確認で合意形成し、後から自動化する進め方も可能です。

従来のテスト手法は、実装が完了した後にテスターが仕様書を読んで手動または自動でテストケースを作成します。この順序では、仕様書の記述漏れや解釈のズレがテスト設計の段階で初めて発覚し、修正コストが実装後にかかります。ATDDは受け入れテストを実装前に確定させるため、要件の曖昧さや矛盾がコーディング開始前の合意形成の場で表面化します。

対象範囲の違いも明確です。従来の機能テストはUI操作や画面遷移といった実装済みの振る舞いを外部から検証するのに対し、ATDDの受け入れテストは「ビジネス要件を満たしているか」を検証基準として先に固定します。テスト対象が同じ画面や機能であっても、テストが実装の結果ではなく実装の目的そのものを表現している点が異なります。

チーム構成にも差があります。従来のテストはテスターが単独で設計・実行することが多く、開発者や顧客の関与は仕様書のレビュー程度にとどまります。ATDDでは顧客・開発者・テスターのトライアドが同じ受け入れ基準を最初から共有するため、テストケースが「仕様の合意結果」として実装前から存在し続けます。この違いが、要件漏れを実装後ではなく着手前に防ぐという ATDD 特有の効果につながります。

実装の内部品質を担保したいならTDD、チームの合意形成を「振る舞い」の言葉で揃えたいならBDD、ビジネス要件そのものを実装前の受け入れ基準として固定したいならATDDを選びます。三者は排他的ではなく、対象範囲が異なる階層として併用できます。

TDDは受け入れテストの内側で単体テストを書く形で共存でき、BDDはATDDが定義した受け入れ基準をGherkin記法などで記述する手段として機能します。したがって「ATDDかBDDか」という二択ではなく、ATDDで要件を確定し、BDDの記法で実行可能な形に落とし、TDDで内部実装を固める、という重ね方が実務的です。選択を誤りやすいのは、単体テストの充実度だけを見てATDDが不要と判断するケースで、その場合は受け入れレベルの要件漏れがテスト工程を通過してしまいます。

各手法が実装ライフサイクルのどの時点で価値を発揮するかは、テスト対象の粒度と直結しています。TDDの単体テストは実装コードと1対1で対応するため、関数を書く数分から数十分前に用意し、レッドグリーンリファクタのサイクルを1タスク内で何度も繰り返します。粒度が最も細かい分、実装が変わればテストも即座に書き直す前提です。

BDDのシナリオは画面遷移や機能単位の振る舞いを対象にするため、ストーリー着手後、実装と並行して育てていく形になります。開発者がコードを書きながらシナリオのステップ定義を追加し、テスターがシナリオの網羅性を確認する往復が続きます。TDDより粒度は粗く、1つのシナリオが複数の単体テストをまとめて検証する層になります。

ATDDの受け入れ基準はビジネス要件そのものを対象にするため、実装コードが1行も存在しないストーリー着手前に確定させます。この確定作業がトライアドによる合意形成であり、後段のBDDシナリオやTDDの単体テストは、この受け入れ基準を分解した下位テストとして位置づけられます。実装タイミングが早い順に並べるとATDD、BDD、TDDとなり、対象範囲は狭い順にTDD、BDD、ATDDという逆の関係になります。

導入難度は、チームに求めるスキルの種類と量によって決まります。TDDは開発者がレッドグリーンリファクタのサイクルを個人で回せれば導入できるため、チーム全体の合意形成コストがかからず、単独チームでも着手しやすい手法です。一方でBDDとATDDは、顧客やテスターを含む複数ロールの協働が前提になるため、ミーティング設計やファシリテーションのスキルが不足していると形だけの導入で終わります。

想定例として、開発者5名だけで構成され、プロダクトオーナーが多忙で会議時間を確保しづらいチームを考えます。この場合、トライアドによる要件合意を前提とするATDDをいきなり導入すると、受け入れ基準の確定作業自体が停滞します。まずTDDで単体テストの文化を定着させ、次にBDDのシナリオ記述で開発者とテスターの合意形成に慣れ、プロダクトオーナーの時間確保が可能になった段階でATDDのトライアドワークショップに進む順序が現実的です。

逆に、顧客担当者が要件定義に十分な時間を割け、テスターも自動化スクリプトの記述経験があるチームでは、TDD・BDDを経由せずATDDから直接始めても、受け入れ基準の合意と自動化を同時並行で進められます。選択の基準は手法の優劣ではなく、チームが持つ協働スキルと確保できる合意形成の時間です。

ATDDの循環を実プロジェクトへ適用する際は、要件定義・自動化・実装の3段階に分けて進めると、トライアドの合意形成とスクリプト作成が同時に停滞する事態を避けられます。各段階で担う役割とツールが変わる点が、導入時の判断の分かれ目になります。

要件定義とテストケース設計の段階では、トライアドがユーザーストーリーから具体的な例を出し合い、受け入れ基準として文章化する作業に集中します。この時点ではツールやスクリプトの話を持ち込まず、自然言語での合意形成を優先します。自動化の議論を先に始めると、実装可能な範囲に要件を縮めてしまい、要件漏れを防ぐATDDの目的そのものが崩れます。

具体例を出す際は、正常系だけでなく境界値と異常系を必ず含めます。「ログイン失敗が3回続いたらロックする」という要件であれば、2回失敗の場合、3回目の失敗の直後、ロック中の正しいパスワード入力の3パターンを挙げ、それぞれの期待結果をトライアドで確認します。この段階で顧客が想定していなかった挙動（ロック解除の条件など）が発覚することが多く、実装着手前に修正できます。

受け入れ基準は表形式でまとめ、条件・入力・期待結果の3列に整理すると、後段でGherkin記法へ変換する作業がスムーズになります。この表がステップ2の自動化スクリプト作成の入力になるため、あいまいな表現（「適切に処理する」など）を残さず、判定可能な言葉に置き換えておくことが次段階の停滞を避ける分かれ目になります。

受け入れ基準の表ができたら、条件・入力・期待結果の各列をGherkin記法のステップに機械的に変換します。この変換作業でトライアドの言葉を保ったまま実行可能なテストへ落とし込めるかどうかが、後段の実装フェーズがスムーズに進むかを決めます。

Feature: ログインロック
  Scenario: 2回失敗した時点ではロックされない
    Given ユーザーが存在する
    When パスワードを2回連続で間違える
    Then アカウントはロックされていない

  Scenario: ロック中に正しいパスワードを入力しても解除されない
    Given アカウントがロックされている
    When 正しいパスワードでログインを試みる
    Then ログインは拒否される

ステップ定義（Given・When・Thenと実際の操作コードを結びつける部分）は、この段階では開発者が実装します。ここで重要なのは、シナリオの日本語表現を実装都合で変更しないことです。表現を変えるとトライアドが合意した内容とテストの内容がずれてしまい、後から要件の解釈違いが発覚することになります。

ステップ定義の内部でSelenium等のUI操作ライブラリやAPI呼び出しを使う場合も、Gherkin記法のシナリオ自体は変更せず、実装側だけを差し替えられる構造にしておきます。この構造にしておくと、UIの実装が変わってもシナリオを書き直す必要がなくなり、受け入れ基準がドキュメントとして長く生き続けます。

開発実装のフェーズでは、ステップ2で作成した受け入れテストをレッドの状態からスタートし、実装コードを追加してグリーンに変えていく作業を繰り返します。TDDのサイクルと異なるのは、対象がビジネス要件を表す受け入れテストである点で、開発者は単体テストを内側で書きながら、外側の受け入れテストが通ることを最終確認として使います。

Scenario: 3回連続で失敗するとロックされる
  実行結果: FAIL（未実装）
  → ロック判定ロジックを実装
  実行結果: PASS

実装が1つのシナリオを満たしたら、次のシナリオに進む前にCIパイプラインへ受け入れテストを組み込みます。ローカルで通ったテストがCI環境で失敗するケースは、テスト用データベースの初期化順序やタイムゾーン設定の違いが原因になることが多く、CI統合を後回しにするとこの種の不整合が実装完了後にまとめて発覚します。

継続的なテスト実行では、受け入れテストを毎回のプルリクエストで全件回し、失敗したシナリオがあれば実装を疑う前にシナリオ自体の記述漏れを確認します。トライアドが合意した受け入れ基準は実装後も資産として残るため、次のストーリーの要件定義（ステップ1）に戻った際、既存の受け入れテスト群が回帰確認の土台になります。

ATDDの導入方法はチーム人数やリリース頻度によって最適解が変わり、同じ受け入れ基準の合意プロセスでも、扱うツールと自動化の範囲を規模に応じて調整する必要があります。小規模・中規模・大規模のいずれも、トライアドの合意形成という土台は共通しています。

小規模チームでATDDを始める場合、開発者3〜5名程度の構成であれば、Cucumberと既存のテストランナーだけで受け入れテストの循環を回せます。専用の管理基盤やCI環境を新設する必要はなく、既にTDDで使っているJUnitやRSpec等のテストランナーにGherkin記法のシナリオを追加する形で導入できます。

ツール構成は次の3点に絞ります。

このステップ2の自動化スクリプト作成で示したステップ定義の書き方をそのまま使えば、追加のインフラ投資は不要です。テスト管理ツールやダッシュボードの導入は、シナリオ数が増えて手動での網羅性確認が難しくなった時点で検討すれば十分です。小規模チームでは、ツールを増やすことよりトライアドの合意形成の時間を確保することが導入成功の分かれ目になります。

中規模プロジェクトでは、開発者10〜20名程度、複数チームが並行してリリースを進める体制になるため、小規模チーム向けのCucumberと既存テストランナーだけの構成では、シナリオ数の増加に管理が追いつかなくなります。段階的な自動化とは、すべてのシナリオを一度に自動化するのではなく、優先度の高いシナリオから順に自動化の対象を広げていく進め方を指します。

進め方は次の順序が実務的です。

1. 既存の受け入れ基準を「回帰確認が必須」「1回限りの確認で十分」の2つに分類する
2. 回帰確認が必須なシナリオだけをCucumberで自動化し、CIに組み込む
3. 1回限りの確認で十分なシナリオは手動確認のまま残す
4. リリースを重ねるごとに、手動確認から自動化への移行対象を見直す

この分類作業は、複数チームがシナリオを持ち寄る場になるため、テスト管理ツール（TestRailやZephyr等）を導入してシナリオの一覧性を確保する判断がここで初めて必要になります。小規模チームでは不要だったこの一覧管理が、チーム間でシナリオの重複や矛盾を防ぐ役割を担います。

自動化の優先順位は、変更頻度が高い機能ほど回帰確認の価値が高いため、リリースごとに変更が入る決済フローや認証機能を先に自動化し、変更が少ない管理画面は後回しにする基準で判断します。

大規模エンタープライズでは、開発者50名以上、複数のプロダクトチームが同じCI/CDパイプラインを共有する体制になるため、中規模プロジェクト向けの分類・優先順位付けだけでは、シナリオの実行時間そのものがボトルネックになります。CI/CDパイプライン統合とは、受け入れテストをリリース工程の各段階（プルリクエスト時・統合ブランチへのマージ時・本番リリース前）に振り分け、実行タイミングごとに対象範囲を絞り込む設計を指します。

振り分けの基準は次のとおりです。

この振り分けを機能させるには、受け入れテストの結果を一元的に可視化するダッシュボードが必要になり、シナリオがどの機能・チームに属するかをタグ付けして管理します。タグ付けが漏れると、変更範囲に無関係なシナリオまでプルリクエスト時に実行され、開発者の待ち時間が延びる形で不整合が表面化します。

ATDDで使うツールは、シナリオ記述層と実行基盤層で分けて選定します。シナリオ記述層の代表例はCucumberとFitNesseで、前者はGherkin記法でシナリオを書き自然言語に近い形でトライアドが読める点が強みです。後者は表形式のWikiページで受け入れ基準を管理でき、Gherkin記法の記述に抵抗があるチームや、顧客がテキストエディタよりスプレッドシート的な表を好む現場に向いています。

実行基盤層では、UI操作を伴うシナリオならSelenium、API検証中心ならHTTPクライアントライブラリを組み合わせ、内部の単体テストはJUnit等の既存フレームワークをそのまま使います。選定基準は3つです。

• 既存の開発言語・テストランナーと同じ生態系で動くか
• シナリオの記法がトライアドの顧客にも読めるか
• CIパイプラインへの組み込みが既存の仕組みで完結するか

FitNesseは表ベースで非エンジニアにも扱いやすい一方、Gherkin記法ほど広く普及していないため、他チームとの記法統一を重視する場合はCucumberを優先します。ツールの機能比較よりも、顧客が受け入れ基準を自分で読めるかどうかを選定の起点にすることが、ATDDのツール選びを他の自動化ツール選定と分ける点です。

導入タイミング、既存プロジェクトへの後付け、BDDとの同時導入は、いずれもチームの合意形成コストと既存資産の扱い方次第で判断が変わり、正解が1つに定まらない領域です。

ATDDを始める最適なタイミングは、新しいユーザーストーリーの着手前、要件がまだコードに落ちていない段階です。既存プロジェクトの途中からでも、次のスプリントで扱う未着手のストーリーを対象にすれば導入できます。

判断が分かれるのはプロジェクトのフェーズです。要件がまだ流動的なPoC段階では、受け入れ基準を確定させる作業自体が頻繁な変更で無駄になりやすく、要件がある程度固まった開発初期〜中盤での導入が現実的です。逆にリリース直前の安定化フェーズで導入すると、トライアドの合意形成に時間を取られ、既存の不具合修正が滞ります。したがって、新規プロジェクトなら最初のスプリントから、既存プロジェクトなら次にまとまった要件変更が入るタイミングを起点に始めるのが判断の分かれ目になります。

既存プロジェクトへの後付けは可能です。ただし対象を「これから着手する未実装の機能」に限定する必要があります。すでにリリース済みの機能に遡って受け入れテストを作る作業は、実装から要件を逆算する形になり、ATDDが本来防ぐはずの要件漏れの検証にはなりません。

後付けの手順は次のとおりです。

1. 直近のスプリントで着手予定の未実装ストーリーを1件選びます
2. そのストーリーだけトライアドで受け入れ基準を確定し、Gherkin記法に変換します
3. 既存の単体テスト・機能テストはそのまま残し、置き換えません
4. 1〜2ストーリー分の実績ができた時点で、次のストーリーに対象を広げます

既存の仕様書やテストケースを一括でATDD形式に書き換える進め方は、トライアドの合意形成が追いつかず途中で頓挫しやすいため避けます。

ATDDとBDDは競合する手法ではなく、ATDDで確定した受け入れ基準をBDDのGherkin記法で記述する形で自然に重なるため、同時導入は次の順序で進めます。

1. 最初のトライアドワークショップで受け入れ基準を自然言語のまま合意する
2. 合意内容をGherkin記法のシナリオに変換する作業を、開発者とテスターが担当する
3. ステップ定義の実装を進めながら、シナリオの表現がトライアドの合意内容からずれていないかを顧客に確認する

同時導入で起きやすい停滞は、ワークショップの場でGherkin記法の文法に沿った書き方を求めてしまい、顧客が発言をためらうことです。合意形成の段階では自然言語の表を使い、記法への変換は後工程に分離すると、この停滞を避けられます。