受け入れテスト（UAT）とV字モデルの対応関係
V字モデルでは受け入れテスト（User Acceptance Test / UAT）は要求定義と対応します。V字モデルの最右端に位置するこのフェーズは、技術者ではなくビジネスオーナー・エンドユーザーがシステムを「業務で実際に使えるか」を判定する最終関門です。
システムテストが「技術的な仕様を満たしているか」を確認するのに対し、受け入れテストは「ビジネスゴールを達成できるか」「ユーザーが違和感なく使えるか」を確認します。受け入れテストを通過することがリリース承認の条件になるため、テスト仕様書の作成には発注者側（ユーザー）の積極的な関与が必要です。
INPUTドキュメント — 何を読んでテストを設計するか
| INPUTドキュメント | 参照目的 | 確認箇所 |
|---|---|---|
| 要求仕様書 | 受け入れテストシナリオの源泉。ビジネス要件ごとにテストケースを導出する | ビジネス機能・ユーザーストーリー・受け入れ基準（Acceptance Criteria） |
| 業務フロー図 | 実際の業務手順に沿ったテストシナリオを設計する | 業務フローのステップ・担当者・判断条件・例外フロー |
| ユーザーストーリー | 誰が・何のために・どうしたいかを基点にシナリオを構成する | ペルソナ・目的・受け入れ基準（BDD の Given-When-Then） |
| 画面設計書・業務マニュアル（案） | ユーザーが実際に操作する手順とシステムの挙動を突き合わせる | 操作手順・表示項目・入力ルール・エラーメッセージ |
💡 受け入れ基準（Acceptance Criteria）の明確化
受け入れテストで最もトラブルが起きやすいのは「合格・不合格の判断基準が曖昧なこと」です。要件定義フェーズでユーザーストーリーに受け入れ基準を Gherkin（Given-When-Then）形式で記述しておくことで、開発者・テスター・ユーザーが同じ言語で合否を議論できます。
作成ドキュメントの構成
① 受け入れテスト仕様書（テストシナリオ集）
受け入れテスト仕様書はビジネスシナリオ単位でテストを構成します。技術的な詳細よりも「誰が・どのような状況で・何をしたか・どうなるべきか」という業務視点の記述が重要です。
| 記載項目 | 内容 | 例 |
|---|---|---|
| テストシナリオID | 一意の識別子 | UAT-ORDER-001 |
| 対応要件ID | 要求仕様書の機能ID・ユーザーストーリーID | US-023「顧客が商品を注文できる」 |
| テスト対象業務 | どの業務プロセスを検証するか | 新規注文 → 在庫確認 → 決済 → 確認メール送信 |
| テスト実施者 | ユーザー・業務担当者・テスター | 営業部門の担当者（非エンジニア） |
| 前提条件 | テスト開始時のシステム状態・データ | 商品マスタに商品A（在庫10個）が登録済み |
| 操作手順 | ステップごとの操作内容（業務マニュアルに近い形式） | ①ログイン ②商品検索 ③数量入力 ④注文確認 ⑤注文確定 |
| 期待結果 | 業務観点での期待するアウトカム | 注文完了画面表示・確認メール受信・在庫が9個に減少 |
| 合否判定 | OK / NG / 保留 + コメント | NG: 確認メールが届かない（担当：開発チーム） |
② チェックリスト（非機能観点）
受け入れテストでは機能確認に加えて、業務観点での使いやすさ・帳票の見やすさ・エラーメッセージのわかりやすさなど、ユーザー体験の観点も確認します。これらはチェックリスト形式でユーザーが評価するのが実践的です。
Gherkin（Given-When-Then）によるシナリオ記述
BDD（振る舞い駆動開発）で使われる Gherkin は、テストシナリオを自然言語に近い形式で記述する言語です。Feature・Scenario・Given・When・Then のキーワードを使い、ビジネス関係者と開発者が共通の言語でテストシナリオを表現します。
Gherkin で記述されたシナリオは Cucumber（Java/Ruby）・Behave（Python）・SpecFlow（C#）などのフレームワークを使ってテストコードと紐付けることで自動化できます。ビジネスシナリオとテストコードを連動させることで、仕様変更時の追従漏れを防げます。
確認ポイント
| 観点 | 確認内容 | 優先度 |
|---|---|---|
| ビジネス要件の充足 | 全ユーザーストーリーの受け入れ基準が満たされていること | 必須 |
| 業務シナリオの全体フロー | 業務フロー図の全経路（正常系・例外処理）が実際に動作すること | 必須 |
| データの業務整合性 | 業務操作後のデータが業務ルール通りに更新されること（在庫・残高・ステータスなど） | 必須 |
| ユーザー体験（UX） | エラーメッセージが業務担当者に分かりやすい言葉で表示されること | 必須 |
| 帳票・レポートの正確性 | 出力される帳票・CSV の値・レイアウトが業務で使える水準であること | 推奨 |
| 移行データの確認 | 旧システムから移行したデータが正しく引き継がれ、業務に支障がないこと | 推奨 |
| 業務マニュアルとの整合性 | 業務マニュアル（案）の手順通りにシステムが操作できること | 推奨 |
利用ツール — Cucumber / Allure Report / Autify / Jira
Allure Report によるエビデンス管理
受け入れテストでは、テスト結果の「エビデンス」として画面キャプチャ・ログ・操作録画を保管することが求められます。Allure Report は Cucumber や JUnit と連携し、テストステップごとのスクリーンショットを自動取得してHTMLレポートに埋め込みます。これにより、手動でスクリーンショットを撮って Excel に貼り付けるという非効率な作業を排除できます。
Jira + Xray（テスト管理・バグ管理）
Jira のプラグイン「Xray」を使うと、テストケースをJiraチケットとして管理し、実行結果と不具合チケットを一元管理できます。ユーザーが発見した不具合を Jira に起票し、開発チームが修正して再テストするサイクルを効率化します。
よくある落とし穴と対策
⚠️ ユーザーがテストに参加しない
「開発チームが全部やってくれる」というスタンスで受け入れテストに臨むと、リリース後に「使い方が違う」「業務フローが合っていない」という問題が発覚します。受け入れテストは主体的にユーザーが実施するものです。プロジェクト計画段階からユーザーのスケジュールを確保してください。
⚠️ 受け入れ基準が事前に定義されていない
「なんとなく動いているからいいか」という曖昧な合否判定は後で大きなトラブルになります。受け入れ基準は要件定義フェーズで開発側とユーザー側が合意した形で文書化しておく必要があります。Gherkin（Given-When-Then）で記述すると、曖昧さが排除されます。
⚠️ テスト環境が本番と乖離している
受け入れテストは「本番と同等の環境」で実施することが前提です。データ量・外部連携先・マスタデータが本番と大きく異なる環境でテストすると、本番移行後に予期せぬ問題が発生します。本番移行手順の確認も受け入れテストのスコープに含めることを推奨します。
まとめ
受け入れテストフェーズで定義すべき3つのポイントを整理します。
- INPUT：要求仕様書・業務フロー図・ユーザーストーリー（受け入れ基準）・業務マニュアル案
- 作成ドキュメント：受け入れテスト仕様書（シナリオ・Gherkin形式の受け入れ基準）＋チェックリスト（UX・帳票）
- 確認ポイント：ビジネス要件の充足・業務シナリオ全体フロー・データ整合性・UX・エビデンス保管
受け入れテストは V字モデルの集大成であり、全フェーズのドキュメント品質が問われます。Gherkin で受け入れ基準を明文化し、Cucumber/Behave で自動化、Allure Report でエビデンスを整備することで、リリース判定の根拠となる品質証跡を効率的に作成できます。ノーコードツール（Autify・MagicPod）を活用すれば、非エンジニアのユーザーが自らテストを実行・管理できる体制も実現できます。
✅ V字モデル テスト仕様書シリーズ
このシリーズでは V字モデルの4フェーズに対応するテスト仕様書を解説しました。単体テスト仕様書（詳細設計対応）→結合テスト仕様書（基本設計対応）→システムテスト仕様書（要件定義対応）→受け入れテスト仕様書（要求定義対応）の順で読むと体系的に理解できます。