ATDD

TDD との違い

TDD が開発者のコード設計を駆動するのに対し、ATDD はビジネス要件の理解をチーム全体で揃えることを目的とする。TDD のサイクルが「RED→GREEN→Refactor」であるように、ATDD にも明確なサイクルがある。

1. Discuss（議論）: プロダクトオーナー・開発者・QA が要件を議論し、受け入れ基準を具体例で合意する
2. Distill（蒸留）: 合意した基準を Given-When-Then 等の構造化フォーマットに落とす
3. Develop（開発）: 受け入れテストを自動化し、テストが RED の状態から実装を開始する
4. Demo（デモ）: テストが GREEN になったらステークホルダーにデモする

三者協議（Three Amigos）

ATDD の核心は、実装前の「三者協議」にある。ビジネス担当・開発者・テスターの3つの視点で受け入れ基準を議論することで、仕様の曖昧さや認識のズレを早期に解消する。コードを書き始めてから「そういう意味じゃなかった」という手戻りを防ぐ効果が大きい。

導入のハードル

ATDD は開発プロセス全体に影響するため、ツールを入れれば始められるものではない。チーム全員が受け入れ基準の書き方に慣れる必要があり、プロダクトオーナーの積極的な関与も不可欠だ。まずは1つのユーザーストーリーで試し、効果を実感してから範囲を広げるのが現実的なアプローチになる。