User Acceptance Test — 業務担当者がシステムを「業務として使えるか」判定する最終段階のテスト。仕様通りでも業務に合わなければ NG とする視点。
概要
UAT は開発者ではなく 業務担当者 が「業務として OK か」を判定するテスト。仕様書通りに動いても、現場の業務フローに合わなければ受入は通らない。リリース前の最後の関門。
| 観点 | UAT の特徴 |
|---|---|
| 主体 | 業務担当者・現場ユーザー |
| 視点 | 業務フロー全体・実運用での使いやすさ |
| 検出するバグ | 仕様と業務のズレ・運用上の不便・例外フロー |
| 自動化 | 基本は人手、補助的にスクリプト |
UAT を設計する 3 つの型
1. シナリオベース
業務フロー単位で受入条件を作る：
シナリオ: 注文受付 〜 決済完了まで
前提: ログイン済み・カートに商品あり
手順: 1) 配送先入力 2) 決済方法選択 3) 注文確定
結果: 確定メール受信、在庫が引き当てられている2. ユーザーストーリー（Given / When / Then）
Given 在庫 5 個の商品がカートに入っている
When 数量を 6 個に変更しようとする
Then 「在庫不足」エラーが表示される3. 受入条件チェックリスト
[ ] 注文確定後、在庫が即座に減る
[ ] 確定メールが 1 分以内に届く
[ ] キャンセル時に在庫が戻る
[ ] 決済失敗時に注文が確定しないUAT を「最後に押し付ける」失敗
リリース直前に業務担当者にチェックを依頼し、根本的な認識ずれが発覚 → 大量手戻り、というパターンは典型的な失敗。
| 失敗 | 是正 |
|---|---|
| UAT を最後に依頼 | 要件定義時点で UAT シナリオを作成 |
| 受入条件が曖昧 | Given/When/Then で具体化 |
| 業務担当者が UAT に来ない | 開発初期から業務担当者を巻き込む |
AI 駆動開発との関係
UAT 自体は AI に任せられない （業務担当者の判断が必要）。ただし、 UAT シナリオを要件定義時に書いておく ことで、AI 駆動開発のスピードを生かせる。
ステアリング駆動開発 の requirements.md に 受入テストシナリオ を Given/When/Then で書いておけば、AI に実装を任せても受入条件を満たすか自動的に検証できる。
| 段階 | やること |
|---|---|
| 壁打ち | 業務担当者から受入条件をヒアリング |
| ステアリング作成 | requirements.md に受入シナリオ記載 |
| 実装 | AI に実装させながら、受入条件をテストとして埋め込む |
| UAT 実施 | 業務担当者が受入条件チェックリストで判定 |
関連記事
- 開発手法ガイド：テスト技法編 — UAT の位置づけ
- ステアリング駆動開発 — UAT を要件定義に組み込むワークフロー
- 壁打ち・規模判定編 — 業務担当者から受入条件を引き出す
関連用語
- E2E テスト — UAT より下位、自動化された業務フロー検証
- ビジネスケイパビリティ — UAT シナリオの単位となる業務能力
- MVP — 受入条件を最小限に絞る考え方
- ADR — UAT で出た判断を残す