ATDDで素早く安定した デリバリを実現しよう！

RSGT2025での登壇資料です。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2025/proposal/21072/atdd

いざ開発して機能が完成した後になって、機能の詳細部分で「あれ、その振る舞いはそういう仕様のつもりじゃなかったんだけどな」と関係者間で捉え方が違っていて、それによって開発の手戻りが発生してしまうということはありませんか？

受け入れテスト駆動開発(Acceptance Test Driven Development: ATDD)とは、具体的な仕様を書き起こした受け入れテストを作成することで、実装の着手前に関係者間でユーザーストーリーの共通理解を促進する手法です。
関係者間で事前に実装する中身の認識を合わせることで仕様を確認しながら実装を進めることができ、手戻りのリスクを減らすことが期待できます。

本セッションでは実際にATDDをチームに導入して得た知見を、実際の開発プロセスを交えながら、導入の効果やつまづきポイント、改善のために工夫したポイントなどを踏まえてお話します。

Transcript

1. ATDDで素早く安定した デリバリを実現しよう！ 導入の効果・躓きポイントから改善の工夫
2. 自己紹介 KDDIアジャイル開発センター株式会社 高崎　和成 ソフトウェアエンジニア グループ会社向け契約管理基盤開発 内製開発支援 2 / 39 KDDIアジャイル開発センター株式会社 政野　博紀 ソフトウェアエンジニア ATDD導入期のチームに後発参画、その拡大に従事
3. KDDIアジャイル開発センターについて 3 / 39
4. 本日おはなしすること • ATDDの概要 • 導入してみた際の課題 • 感じた良し悪し • 導入効果 • 今から導入する人に向けたアドバイス 私たちのチームの経験談でお話しします。 よりよい開発のヒントになれば幸いです。 4 / 39
5. KDDI Agile Development Center Corporation 受け入れテスト駆動開発 (ATDD) とは
6. 受け入れテスト駆動開発 (ATDD)とは 具体的な仕様を表した受 け入れテストを書く (この時点では失敗する) ユニットテストを書く (この時点では失敗する) テストを 通るようにする リファクタリング 受け入れテストが通る 開発着手前に受け入れテスト(具体的な仕様)を書き出す手法 ここはTDD ATDD 6 / 39
7. 受け入れテスト駆動開発 (ATDD)とは 具体的な仕様を表した受 け入れテストを書く (この時点では失敗する) 受け入れテストが通る ここはTDD ATDD ここが肝 開発着手前に受け入れテスト(具体的な仕様)を書き出す手法 ユニットテストを書く (この時点では失敗する) テストを 通るようにする リファクタリング 7 / 39
8. ATDD の 3 steps テストを自動化する 自然言語のテストとして書き出す 具体的な仕様を話し合う Step 1. 発見 Step 2. 定式化 Step 3. 自動化 8 / 39
9. アジャイルテストの四象限 チームの支援 製品の批評 ビジネス面 技術面 機能性に対するテスト ユーザー受け入れテスト 非機能要求に対するテスト 技術的なテスト ユーザーストーリーテスト 機能テスト 単体テスト コンポーネントテスト 静的解析 探索的テスト ユーザー受け入れテスト セキュリティテスト パフォーマンステスト 9 / 39
10. アジャイルテストの四象限 チームの支援 製品の批評 ビジネス面 技術面 機能性に対するテスト ユーザー受け入れテスト 非機能要求に対するテスト 技術的なテスト ユーザーストーリーテスト 機能テスト 単体テスト コンポーネントテスト 静的解析 探索的テスト ユーザー受け入れテスト セキュリティテスト パフォーマンステスト ATDDはここ 10 / 39
11. シフトレフト https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf 30 15 10 5 1 要件定義 コーディング 単体テスト 統合テスト ストーリーテスト 初期顧客の フィードバック 製品リリース後 ソフトウェア開発の各段階で発見された欠陥の修復にかかるコストの相対比 欠陥の発見が遅れるほど、修復コストは膨れる 11 / 39
12. シフトレフト https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf 30 15 10 5 1 要件定義 コーディング 単体テスト 統合テスト ストーリーテスト 初期顧客の フィードバック 製品リリース後 ソフトウェア開発の各段階で発見された欠陥の修復にかかるコストの相対比 欠陥の発見が遅れるほど、修復コストは膨れる ATDDはここ 早い段階で欠陥を見つける 12 / 39
13. ATDD の恩恵 素早く安定したデリバリを実現 手戻りやバグ修正の頻度を減らし 素早いデリバリを実現 安定して品質の高い プロダクトコードを担保 認識齟齬、考慮漏れによる 手戻りの減少 考慮漏れによる バグ発生の抑制 シナリオテスト自動実行によるデ グレ確認 13 / 39
14. KDDI Agile Development Center Corporation ATDD導入の背景
15. 社内で受けたアジャイルテスティング研修で ATDDを知った https://scruminc.jp/training/agile-testing/ アジャイルテストとは アジャイル開発における品質保証の取り組み • アジャイルテストの四象限 • テストマニフェスト • 探索的テスト • 受け入れテスト駆動開発 (ATDD) 15 / 39
16. まずは試してみることにした 開発着手 テスト実装 手動のシナリオテスト PO受け入れテスト まずはやってみよう 私達のチームでも手戻りは発生していた 手戻り ATDDに興味があった 16 / 39
17. KDDI Agile Development Center Corporation ATDDはじめてみました
18. 既存の開発サイクルをベースに ATDDのプロセスを追加 バックログ作 成 リファインメン ト プランニング シナリオ 作成 （定式化） POレビュー 自動化 テストが通る コードを書く UTを書く リファクタ リリース 開発 実装 18 / 39
19. 既存の開発サイクルをベースに ATDDのプロセスを追加 バックログ作 成 リファインメン ト プランニング シナリオ 作成 （定式化） POレビュー 自動化 テストが通る コードを書く UTを書く リファクタ リリース 開発 実装 19 / 39
20. 既存の開発サイクルをベースに ATDDのプロセスを追加 バックログ作 成 リファインメン ト プランニング シナリオ 作成 （定式化） POレビュー 自動化 テストが通る コードを書く UTを書く リファクタ リリース 開発 実装 20 / 39
21. 実際に始めて見えてきた課題 課題１ 導入と メンテナンスが大変 課題２ テスト⇔実装の 細かいサイクルを 回すのが大変 課題３ 開発目線が先行し，ビ ジネスフレンドリでな かった 21 / 39
22. 課題① — 導入とメンテナンスが大変 〜ATDD導入前の理想と現実〜 スナップショットテスト （自動） シナリオテスト （手動で補完） ATDD導入前 E2E 結合テスト 単体テスト 理想的なテストピラミッド 現実 22 / 39 毎週のリリースにあたり、手動テストの手間を要する
23. 課題① — 導入とメンテナンスが大変 〜ATDD導入前の理想と現実〜 スナップショットテスト （自動） シナリオテスト （手動で補完） ATDD導入前 E2E 結合テスト 単体テスト 解決したい領域 23 / 39 毎週のリリースにあたり、手動テストの手間を要する → ATDD導入するなら，完全自動化しつつ不足領域を補いたい！
24. 課題① — 導入とメンテナンスが大変 〜ATDDによる自動化の光と影～ スナップショットテスト （自動） ATDD with 自動化 ATDD導入後 理想形とはギャップがある 結合テスト 単体テスト E2E 24 / 39 • 実際やってみると、テストケースはたくさん作る傾向 • 開発者の安心感は増したが、割高感はあり • 重複テストの見直しや、慣れによって回るように
25. 課題② — テスト⇔実装の細かいサイクルを回すのが大変 RED GREEN Refactor 阻害要因 • 実行準備で色々立ち上げる必要（サーバ, API, DB, etc…） • 外部システム連携があって複雑 • CI上で実行時間が長い → せめてローカル環境で気軽に試せるようにしよう！ 25 / 39 ATDDも小さくサイクルを回すのが大事
26. 課題② — テスト⇔実装の細かいサイクルを回すのが大変 ～楽なテストの工夫～ + GitHub Actions（CI）or ローカルPC backendコンテナ DBコンテナ 外部サービス モックコンテナ いつでも誰でも同時でも１コマンドで実行可能な状態がオススメ 26 / 39 コンテナベースでのE2Eテスト環境の構築 E2Eテスト用コンテナ
27. 課題③ — 開発目線が先行し，ビジネスフレンドリでなかった 気づき 統一されたシナリオファイル テストデータファイル for開発者 27 / 39 • シナリオにアクセスしやすい，見やすいことは大事 • 開発者のみで進めると，視点が偏りがち • ビジネス側でF/Bを受けやすい状態にして、開発前に気づきを得られる 表面的なシナリオファイル
28. KDDI Agile Development Center Corporation 今だから感じる ATDDの良い点・大変な点
29. ATDDの良い点 事前に認識を 合わせる癖がつく 生きているドキュメントが出 来上がる チームが共通言語で 話すことができる 一方で・・・ 29 / 39
30. ATDDの大変な点 ―テストピラミッドと「さじ加減」 IT E2E UT E2E IT UT E2E IT UT Static テストの理想形や落としどころ → 見極めが難しい 30 / 39 • 高コストで時間がかかることを最初やる • 開発者主導でホワイトボックス視点が入りがち • つい上位レイヤで品質を担保したくなる → 「さじ加減」を覚え，一旦サイクルを回し，適宜棚卸しもやる
31. KDDI Agile Development Center Corporation 自分たちのチームにとって 導入効果はあったか？
32. ATDD導入前後のコスト比較 : 一見すると … 導入前のコスト 導入後のコスト スナップ ショットE2E テストの実 装 手動の シナリオ テスト実施 シナリオテスト自 動化 単純な実装時のコストはATDD導入後の方が大きい シナリオ 書き出し シナリ オ書き 出し 32 / 39
33. ATDD導入前後のコスト比較 : 実際は 導入前のコスト 導入後のコスト スナップ ショットE2E テストの実 装 手動の シナリオ テスト実施 シナリオテスト自 動化 ATDD導入により未導入時の隠れたコストが明らかになった シナリオ 書き出し シナリ オ書き 出し 認識齟齬 による 手戻り バグ発見 の遅延 後々の 仕様確認 の手間 開発時の 手動確認 の手間 33 / 39
34. ATDD導入前後のコスト比較 導入前のコスト 導入後のコスト スナップ ショットE2E テストの実 装 手動の シナリオ テスト実施 シナリオテスト自 動化 ATDD導入により未導入時の隠れたコストが明らかになった シナリオ 書き出し シナリ オ書き 出し 認識齟齬 による 手戻り バグ発見 の遅延 後々の 仕様確認 の手間 開発時の 手動確認 の手間 ATDD導入により トータルのコストが減少 34 / 39
35. 導入した効果 : 経験から言えること • シナリオテスト自動化の実装やメンテナンスはそれなりに大変 • メリットは手戻り解消だけではない ◦ 早期のバグ発見 ◦ リグレッションテストの充実 ◦ 開発中にE2Eテストをこまめに実行できる ◦ 後からの仕様確認に役立つ • ATDD導入は、コストはかかるが後々救われる 35 / 39
36. KDDI Agile Development Center Corporation 結論
37. 素早く安定したデリバリを実現できる ATDD導入により実装の品質が向上する 結論 37 / 39
38. KDDI Agile Development Center Corporation これから始めるなら
39. 導入のすゝめ 導入時期 • プロジェクトの早めの段階，身軽なうち • 人の入れ替わりや引継ぎタイミング 導入方法 • 具体例を書き起こして，シナリオだけからでもOK • 自動化は具体例やシナリオに慣れてきたら，早めに その他 • 「とりあえず」ではなく，少し学んでからがお勧め 39 / 39
40. Be a Change Leader. アジャイルに力を与え
 共に成長し続ける社会を創る