ATDD
エーティーディーディー
ATDD（Acceptance Test-Driven Development）とは、開発着手前に受け入れテストの基準をチーム全体で定義し、そのテストを自動化してから実装を進める開発手法である。
TDD との違い
TDD が開発者のコード設計を駆動するのに対し、ATDD はビジネス要件の理解をチーム全体で揃えることを目的とする。TDD のサイクルが「RED→GREEN→Refactor」であるように、ATDD にも明確なサイクルがある。
- Discuss（議論）: プロダクトオーナー・開発者・QA が要件を議論し、受け入れ基準を具体例で合意する
- Distill（蒸留）: 合意した基準を Given-When-Then 等の構造化フォーマットに落とす
- Develop（開発）: 受け入れテストを自動化し、テストが RED の状態から実装を開始する
- Demo（デモ）: テストが GREEN になったらステークホルダーにデモする
三者協議（Three Amigos）
ATDD の核心は、実装前の「三者協議」にある。ビジネス担当・開発者・テスターの3つの視点で受け入れ基準を議論することで、仕様の曖昧さや認識のズレを早期に解消する。コードを書き始めてから「そういう意味じゃなかった」という手戻りを防ぐ効果が大きい。
導入のハードル
ATDD は開発プロセス全体に影響するため、ツールを入れれば始められるものではない。チーム全員が受け入れ基準の書き方に慣れる必要があり、プロダクトオーナーの積極的な関与も不可欠だ。まずは1つのユーザーストーリーで試し、効果を実感してから範囲を広げるのが現実的なアプローチになる。
この用語を扱う記事
- ATDD（受け入れテスト駆動開発）の実装ステップ：BDD・TDDとの違いと導入パターンATDDの実装ステップを解説。BDD・TDDとの使い分け、導入パターン、チームへの段階的な導入方法まで、QAエンジニア向けの実践ガイド。
- PoC失敗の原因と事例から学ぶ防止策：AI導入を仕様駆動開発（SDD）と受け入れテスト駆動開発（ATDD）で設計するAI導入のPoCが失敗する原因は、出力が一定しない・性能がデータで決まる・合否の線がないというAI特有の性質を企画段階で扱わないことにあります。よくある失敗事例のパターンと、仕様駆動開発（SDD）で検証範囲を固定し、受け入れテスト駆動開発（ATDD）で合否を着手前にテストにする方法、着手前のチェックリストを解説します。
- Eval-Driven Development（EDD）とは？評価ファーストで作るAI開発プロセス勘に頼らず評価指標をサイクル全体に組み込むEDDの考え方と、プロンプト・パラメータを自動調整する実践手順を解説します。
関連用語
E2Eテスト
E2E テスト（End-to-End テスト）とは、ユーザーの操作を起点にブラウザや API を通じてシステム全体を通過させ、期待どおりの結果が得られるかを検証するテスト手法である。
受け入れテスト
受け入れテスト（アクセプタンステスト）とは、開発した機能がビジネス要件やユーザーストーリーを満たしているかを、プロダクトオーナーやステークホルダーの視点で検証するテスト手法である。
SSM（AWS Systems Manager）
AWS Systems Manager（SSM）とは、EC2 インスタンスやオンプレミスサーバーをまとめて運用・管理するための AWS マネージドサービスである。パッチ適用、コマンド実行、パラメータ管
N+1クエリ問題
N+1クエリ問題とは、一覧データを1回のクエリで取得した後、各レコードの関連データを1件ずつ個別にクエリする結果、合計 N+1 回のデータベースアクセスが発生してしまうパフォーマンス上のアンチパターン