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つのユーザーストーリーで試し、効果を実感してから範囲を広げるのが現実的なアプローチになる。