【開発管理】ユーザーの「欲しい」をテストで定義！「ATDD（受け入れテスト駆動開発）」｜情報処理問題1000本ノック
アジャイル開発において、チーム全員が「同じゴール」を向くための管理手法。要望の定義と同時にテストの合格条件を決めてしまう、ATDDを攻略しましょう。
1. 【 問題 】：アジャイル開発のマネジメントプラクティス
【 問題 】 アジャイル開発において、顧客、ビジネスアナリスト、開発者、テスターが協力し、ユーザーストーリー（機能要求）の作成と同時に、その機能の完了条件となる「受け入れテスト」を明確に定義して開発を進める手法はどれでしょうか？
① TDD (Test-Driven Development)
② BDD (Behavior-Driven Development)
③ ATDD (Acceptance Test-Driven Development)
④ FDD (Feature-Driven Development)
2. 正解：
正解： ③ ATDD（Acceptance Test-Driven Development / 受け入れテスト駆動開発）
3. 解説：「できた！」の基準を最初に握る
ATDDは、開発をスタートする前に「何を作れば顧客が満足して受け入れてくれるか」というゴール（受け入れテスト）を全員で合意し、それを道標にして開発を“駆動（リード）”していく管理手法です。
ATDDでは、ビジネス・開発・テストの3つの視点（3アミーゴ）で話し合います。
1. 議論 (Discuss)：顧客が「こんな機能（ユーザーストーリー）が欲しい」と提案する。
2. 抽出 (Distill)：全員で話し合い、「じゃあ、〇〇の条件でボタンを押したら、××の画面になる。これで合格（受け入れ）ですね？」と、具体的なテスト例を同時に定義する。 ← ココが問題の正解！
3. 実装 (Develop)：そのテストをパスすることだけを目指して、開発者がコードを書く。
4. デモ (Demo)：作った機能でテストを走らせ、顧客に確認してもらう。
★ ①：TDDは、開発者がプログラムの最小単位（関数など）に対して、コードを書く前に単体テストを書く「実装テクニック（開発技術）」です。顧客視点の受け入れテストを対象とするATDDとは規模や目的が異なります。
★ ②：BDDは、TDDやATDDをさらに「システムの振る舞い（ユーザーの行動）」に焦点を当て、「Given（前提）-When（もし）-Then（ならば）」という自然言語に近い文章で記述する手法です。
1. 理解のコツ: 「友達への誕生日プレゼント」に例えてみましょう。「何かいい感じの服が欲しい（ユーザーストーリー）」と言われて勝手に選ぶと、好みが合わずに失敗するリスクがあります。そうではなく、最初に「青色で、サイズはMで、普段着として洗えるパーカー（受け入れテスト）」と、合格ラインを具体的に約束してからお店に買いに行く。これがATDDです。絶対にハズレ（手戻り）が起きません。
2. 試験対策の視点: 「ユーザーストーリーの作成と同時」「受け入れテスト（または受け入れ基準）を定義」「顧客やテスターと協力」という管理・コミュニケーション重視の記述があればATDDです。先述の「Wモデル」や「シフトレフト」の思想を、アジャイル開発のチーム運営に落とし込んだ手法として出題されます。
4. まとめ
「要求定義（ユーザーストーリー）と受け入れテストをセットで作り、開発のブレをなくす管理手法」。これがATDDです。ビジネス側と開発側の『言った・言わない』の不毛な衝突を完全に防ぎ、無駄なコードを1行も書かずに最短ルートで顧客が本当に欲しいシステムを届けるための強力なプラクティスです。