受け入れ条件を E2E テストにしてから実装する Outside-In 開発フローと、その運用

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackA-7

1. 受け入れ条件を E2E テストにしてから 実装する Outside-In 開発フローと、 その運用 グリーエックス株式会社 ソフトウェアエンジニア 松井 寛太
2. 松井寛太 グリーエックス社 ソフトウェアエンジニア 2017年よりゲーム・Webの両領域でエンジニアと してキャリアを積み、2022年よりグリーエックス 株式会社に所属。 フロントエンドからインフラまで一貫して開発を 担当している。 2
3. アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 3
4. AI で実装は速くなったが、確認が追いつかない 動作確認待ち 仕様 AI 人が仕様を渡す 画面・機能がすぐできる 中身をよく知らないまま 動作確認だけする 作るより、確かめるほうに時間がかかる 4
5. 確認の判断と責任は人が持つ 人が決める 何を満たすか・どう確かめるか・受け入れるか 機械に任せる 記録に残す 毎回同じ手順で繰り返せる確認 自動も人の確認も、何をいつ確認したか 何を確認したのか、後から説明できる状態を作る 5
6. 仕様書や実装から E2E を生成する仕組み 仕様書 E2E テスト 期待する動き 実装 AI 動作と確認箇所 用意する手間は大きく減った 6
7. 画面が真っ白でもテストが通っていた 確認していたのは「詳細画面の項目が出ない」ことだけ example.com/items/2 このデータは 表示できません テスト成功 正しい拒否 example.com/items/2 example.com/items/2 エラーが発生しました 時間をおいて再度お試しください テスト成功 テスト成功 想定外のエラー 白画面 本当は失敗すべき 本当は失敗すべき テストの成功だけでは、完成と判断できない 7
8. 仕様・実装・E2E の対応を記録する 変更 仕様 何を満たすか 対応関係とハッシュ値を記録 見直す 見直す 実装 E2E どう動かすか 満たしたかを確かめる ずれを見つけたら、AI が仕様に合わせて直し、人が差分を確認する 8
9. アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 9
10. 受け入れ条件を実装の前にテストにする 受け入れ条件＝クライアントと合意した、完成かどうかの判断基準 今回：先に E2E にする 条件に合意 判断基準を、最後から最初へ これまで：最後に確かめる 実装 受け入れ判断 合意した条件の E2E を、実装中も繰り返し実行する 最後の受け入れ判断は、これまでどおり行う 10
11. 受け入れ条件を E2E にしてから実装する 案件での基本フロー ① 受け入れ条件 残したい改善は 次の受け入れ条件に 人 ⑤ 継続検証 触って改善 自動テスト・人 ② E2E 作成 失敗の確認 Outside-In AI・自動テスト 利用者から見える動きを先に決め そこから実装へ進む ④ レビュー マージ 人 ③ 実装・PR 作成 AI 参考：Gojko Adzic『Specification by Example』Manning, 2011 11
12. 受け入れ条件を .feature にまとめる 受け入れ条件 他社のデータの詳細は 表示されない Gherkin で書く 日本語で書けるので、 PM やクライアントも読める company-data.feature # language: ja 機能: 他社のデータの詳細表示 @AC-001 @red-contract シナリオ: 他社のデータの詳細は見えない 前提 A 社・B 社のデータがある かつ A 社の利用者でログイン済み もし B 社のデータの詳細ページを開く ならば 拒否のメッセージが表示される かつ B 社のデータの項目は表示されない 前提 操作 期待結果 12
13. 見えないことに加えて、拒否も確かめる example.com/items/2 example.com/items/2 example.com/items/2 このデータは 表示できません エラーが発生しました 正しい拒否 想定外のエラー 白画面 見えないことだけ確認 成功 成功（見逃し） 成功（見逃し） 拒否画面も確認 成功 失敗（気づける） 失敗（気づける） 前のページの company-data.feature より ならば 拒否のメッセージが表示される かつ B 社のデータの項目は表示されない ← 追加した確認 ← もともとあった確認 13
14. 実装前に、テストが正しく失敗するか確かめる 環境の問題なら、先に直す 機能がない Red 機能がなく 失敗する 原因を確認 実装 Green 条件を満たして 成功する 機能がないから失敗している → 実装へ 期待値は、実装ではなく受け入れ条件から決める 14
15. タグは 2 種類：進み具合と、合否の決め方 状態タグ：進み具合。完了したら外す @draft @red-contract 草案：まだ実行しない 実装待ち：テストは失敗 状態タグなし 完了と宣言 成功は実行結果で確かめる 判定タイプのタグ：何で合否を決めるか。条件の ID（@AC-001 など）と同じく、完了後も残す 画面 タグなし（既定） 数値・記録 @oracle:data 人間 @human E2E だけで確かめる E2E ＋ 人 人だけで確認 表示・遷移・権限など ローカルの E2E で値を確かめ、 検証環境の値は人が確認。両方 そろって確認済み E2E の実行から外し、人が確認 して記録を残す。例：外部シス テムへの反映 15
16. AI が書いた条件をツールが点検する 人がレビューする前に 3 つ点検する 点検 こう書いてあると ツールが出す案 否定だけの確認 「表示されない」「遷移しない」 だけ 拒否のメッセージなど、 正しく起きたことを肯定で確かめる行を足す 期待する値を 書いていない 「件数が表示される」だけで、 何件なら正しいかが無い 前提でデータを固定し、期待する値を具体的に書く。 値は仕様から取り、無ければ仕様への加筆を頼む テストで 用意できない前提 外部システムの状態、 共有データ、実際の時刻に依存 環境を限るタグ、 または @human（人が確かめて記録を残す） 点検は提案だけ。条件そのものは書き換えず、取り入れるかどうかは人が決める 16
17. .feature の書き方は機械でチェックする 自作ツールが警告として出す（AI は使わない） 確認（ならば）の無いシナリオ 前提・操作・確認の順番が逆の手順 同じ手順のシナリオの重複 前提と操作が同じで確認だけ違う（矛盾の候補） 理由コメントの無い @out-of-scope テストを止めるタグ（@skip など） 中身の判断は人、書き方のチェックは機械 警告として出し、設定で CI を失敗させることもできる 17
18. 自動確認と人の確認を分担した 受託 Web サービス 1 案件の受け入れ条件 100 件超 約6割 約2割 約2割 E2E だけ E2E ＋ 人 人 表示・権限 作成・編集・削除 集計値・件数 監査ログ 外部表示・反映時間 旧システムとの一致 確認方法を先に分けたので、人の確認を必要なところに絞れた 18
19. アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 19
20. 壊れていないか E2E で確かめながら改善した 通知・ エラーメッセージ 操作の流れ E2E 初回の実装 見やすさ・文言 E2E E2E 約2週間 同じ動作確認を人がやり直さずに、次の改善へ進めた 20
21. 残したい改善は受け入れ条件に追加した 受け入れ条件 触ってみて 必要だと判断 最初 クライアントと合意した条件 追加 送信済みのものを複製して、新しく作れる 追加 詳細画面から、宛先を指定して送れる 追加 更新したときは、必ず通知し直す 次の変更でも確かめるので、改善を失いにくい 21
22. 守りと攻めの両方で、品質を上げられた 守り 攻め リグレッションを出さない 使いやすさを上げる 差し戻しなし 約2週間の改善 改善を重ねても、前にできていたことを 壊さずに受け入れ確認を通過 操作の流れ、通知・エラーメッセージ、 見やすさ・文言を改善 E2E で確かめ続ける 人が触って改善する 22
23. 守りを E2E に任せて、攻めに時間を使えた 攻め：一元的品質・魅力的品質 使いやすさや価値を高める 例：操作の流れを改善する 人が改善する 同じ確認に使っていた時間を回す 守り：当たり前品質 欠けると強い不満になる 例：他社のデータは見えない E2E で守る 狩野モデル：品質を「当たり前品質」「一元的品質」「魅力的品質」などに分けて考える枠組み 参考：狩野ほか「魅力的品質と当り前品質」品質 14巻2号, 1984 23
24. 合意した品質は守り、使いやすさを良くしたい 時間の使い方（イメージ） これまで 実装：AI 守り：人が毎回触って確かめる 攻め 実装は AI で短くなったが、人の確認の時間は変わらない。むしろ増えることもある 目指す姿 実装：AI 守り：E2E 攻め：使いやすさや体験を良くする 橙 = 人の時間 青 = AI・機械 そのために、確認を機械に任せる仕組みを作っている 24
25. 進捗は、確認できた受け入れ条件の数で見る 条件の一覧 E2E の実行結果 成功・失敗・未実行 人の確認記録 確認済み・未確認 二つを合わせた判定 条件 種類 E2E 人 判定 AC-001 画面 成功 ― 確認済み AC-014 数値 成功 未確認 未確認 AC-031 人だけ ― 確認済み 確認済み AC-042 画面 未実行 ― 未確認 確認済み 2 件 / 4 件（表示例） 25
26. 毎日の結果を見て、次の作業を決める 例: 平日 17:30 に Slack へ自動で投稿 E2E 定期実行 17:30 読み取って、次の作業を決める 受け入れ条件の確認状況 受け入れ条件 48 件（E2E 37 人 11） 48 件 → 仕様の増え方も見る E2E：成功 30 失敗 1 実装待ち 6 失敗 1 → 失敗した条件を調べる 人の確認：OK 8 NG 0 未確認 3 未確認 3 → 人の確認を進める 期日の見通し：順調 順調 → 件数から出した参考の判定 スレッド：要対応の条件の一覧 数値は表示例 26
27. アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 27
28. 受け入れ条件を満たすまで AI に実装させる 自動化の検証フロー ① 受け入れ条件 人 ⑤ 継続検証 触って改善 自動テスト・人 ②〜④ に人の手は入らない ② E2E 作成 実装 AI・自動テスト 人は ① で条件を決め ⑤ で結果を見る ④ レビュー マージ 自動 ③ PR 作成 AI 検証用アプリで試行中。受託案件での無人運用はまだ試していない 28
29. テストが通るまで AI が実装を繰り返す 自動化の検証フロー ② の中身 ② E2E作成 実装 ① 受け入れ条件 E2E テスト すべて成功 AI が実装 E2E を実行 人が確認済み ③ PR 作成 AI 失敗したら修正して、もう一度 AI・自動テストのみ 29
30. AI がテストを書き換えられないようにする 3 つを組み合わせて固定を守る 固定する 受け入れ 条件 E2E 人が確認した基準 AI は書き換えない 書き込み権限を絞る AI が書く 作業後の差分を確認 実装 ハッシュ値を照合 テストが通るまで 実装を直す 検知したら止めて、人の判断に戻す 条件やテストを変えたいときも、人の判断に戻す 30
31. 気づいたことを次の条件とテストに追加する AI が画面を探索 気づきを記録して渡す 人が触って確かめる 人が振り分ける 受け入れ条件に追加 E2E と実装へ 不具合／条件の漏れ／ 問題なし 残すと決めたものだけ 次の変更でも確かめ る 使った感想・気づき 先ほどの案件で、複製や通知の改善を条件に加えた流れと同じ 残すかどうかは人が決めて、受け入れ条件に追加する 31
32. AI に画面を探索させて、条件の漏れを探す AI が画面を探索 人が振り分け 境界 0 件・ちょうど収まる件数・1 件あふれる 不具合 受け入れ 条件 ここから観点を 少しずらす 権限 未ログイン・権限のない人が URL を開く 事実を 記録 操作・画面 動画 条件の漏れ 問題なし 状態の組合せ 期限切れ・退会済みが混ざる 32
33. 触り心地や楽しさは人が判断する AI が手伝う 人が判断する 探索して、気づいたことを記録して人に渡す 触り心地や楽しさ、使い続けたいか 条件の漏れ 機械で確かめやすい 状態の組合せ 連打・同時操作 触り心地 使って楽しいか 使い続けたいか 最終的に人が判断する 33
34. アジェンダ 01 確認のボトルネック 02 受け入れ条件から始める開発 03 確認結果の活用：改善と進捗の把握 04 実装とフィードバックの自動化 05 自作ツールの全体像 34
35. 自作ツールの 4 つの機能 受け入れ条件 4 つの機能の共通の基準 AI で生成 17:30 投稿 気づき 仕様 E2E 実装 Green E2E 生成 ＋ 関連管理 確認状況 進捗の可視化 自動実装 ループ 探索 フィードバック支援 仕様と実装から E2E を 作り、変更を検知する 実行結果と人の記録から 毎日の現在地を投稿 固定した条件に 合格するまで実装 AI が画面を探索し 気づきを人に渡す 35
36. まとめ 受け入れ条件を軸に、合意した品質を守り、改善に時間を使う 課題 解決策 受け入れ条件を、実装の前に E2E テストにする AI で作るのは速いが 確認が追いつかない 自動と人の確認を分け、結果を改善と進捗の把握に使う 実装とフィードバックの自動化へ広げる 36
37. ご清聴ありがとうございました 公開ツール specproof github.com/Pound79/specproof E2E 生成・関連管理 条件の点検 書き方のチェック 参考：Gojko Adzic『Specification by Example』Manning, 2011 狩野ほか「魅力的品質と当り前品質」品質 14巻2号, 1984 37