以下の担当名は仕事上の役割を示します。専任部署の設置を前提とせず、兼務や外部支援を含めて、内容を判断する人と実行する人を決めてください。
システム開発の受け入れテスト（UAT）は、顧客や業務担当者が実際の業務シナリオでシステムが要件どおりに機能するかを検証する重要な工程です。テストをスムーズに完了させるには、事前に「何を決め、誰が何を確認するか」を明確にしておくことが不可欠です。本稿では、受け入れテストの準備段階で必要な判断基準、関係者のチェック項目、実務で使える手順例を示します。
1. 受け入れテスト実施の前提条件と判断基準
- テスト対象の範囲：要件定義書・機能仕様書で合意された機能、非機能要件（性能・セキュリティ等）を対象にするかを明示。
- テスト実施環境：本番に近い構成（OS・ミドルウェア・ネットワーク）を用意し、環境差異がテスト結果に影響しないようにする。
- テスト実施者の権限：業務担当者が実際に操作できる権限設定が完了していること。
- 合意されたテスト完了基準（受入基準）：不具合の許容範囲やクリティカル度合いの定義を事前に決め、関係者全員が共有。
2. 受け入れテストに関わる主要な担当者と役割
| 担当者 | 主な役割 | 確認すべき項目 |
|---|---|---|
| プロジェクトマネージャー（PM） | テスト全体の進捗管理・リスク対応 | テストスケジュール、リソース確保、合意された受入基準の有無 |
| 業務担当者（UAT実施者） | 実際の業務シナリオで操作・検証 | テストケースの実行結果、業務上の不具合報告、操作性の評価 |
| 開発リーダー／テストエンジニア | 不具合の再現・修正、テストデータの提供 | 不具合の再現性確認、修正完了の報告、テスト環境の整備状況 |
| 品質保証（QA）担当 | テスト結果の客観的評価・記録 | テスト記録の整合性、受入基準の適合性チェック、最終承認手続き |
| 情報セキュリティ担当 | テストデータの取り扱い・アクセス制御 | テストデータのマスキング状況、アクセスログの取得設定 |
3. 受け入れテスト計画書に必ず記載すべき項目
- テスト目的と対象範囲（機能・非機能）
- テスト実施日程とマイルストーン
- テスト環境の構成情報（ハード・ソフト）
- テストケース一覧（シナリオ別・担当者別）
- テストデータの作成方針と取得元
- 不具合報告フローと優先度分類基準
- 受入基準（合格ライン）と承認手続き
- リスクと緊急時の対応策（環境復旧・ロールバック）
4. テストデータ作成の実務手順
テストデータは、実際の業務データに近い形で用意することが重要です。以下の手順で作成・確認を行います。
- データ項目の抽出：要件定義書から対象機能に必要なマスタ・トランザクション項目をリスト化。
- データソースの選定：本番データのサンプル、もしくはテスト用に生成したダミーデータを選択。
- 個人情報等のマスキング：実データの必要性を確認し、利用を認める条件に従って情報を除外・置換。加工後も識別につながる情報が残っていないか確認。
- シナリオ別データセット作成：業務フローごとに必要な状態遷移を網羅するデータを作成。
- データ検証チェックリスト：項目の必須/参照整合性・重複有無・フォーマットを確認。
- 担当者レビュー：業務担当者がデータ内容を確認し、実務上問題がないか承認。
5. テスト実施時の具体的な作業フロー
- テスト開始前に環境・データの最終確認（PMがチェックリストで承認）
- 業務担当者がテストケースを実行し、結果を記録シートに記入
- 不具合が発生した場合は、即座に不具合管理ツールに登録し、優先度を設定
- 開発リーダーが不具合の再現確認と修正作業を実施
- 修正後、同一テストケースで再テスト（リテスト）を行い、結果を更新
- 結果と残課題を、業務上の受け入れを判断する人へ提示。QAなどの確認役は結果を整理し、受け入れの権限を持つ人が完了を判断
6. よくある失敗とその対処法
- テストケースが不足している：業務フローを洗い出す段階で、例外処理やエッジケースを抜け落としがちです。
対策は、業務担当者と開発者が共同で「フローチャート＋例外シナリオ」表を作成し、レビューを重ねること。 - テストデータの品質が低い：実データと乖離していると不具合が見逃されます。
対策は、データ抽出サンプルを業務担当者に確認してもらい、マスキング後も業務ロジックが成立するか検証する。 - 不具合報告が曖昧：再現手順が不明確だと修正が遅れます。
対策は、報告テンプレートに「再現手順・期待結果・実際の結果・スクリーンショット」項目を必須化する。 - 受入基準が不明確：合格ラインが曖昧だと承認が遅れます。
対策は、受入基準を数値的・定性的に分け、各項目に合格/不合格の判定基準を明記する。
7. 想定例：受け入れテスト準備チェックリスト（実務で使える項目）
※以下は「想定例」として示すチェックリストです。実際のプロジェクトに合わせて項目を追加・削除してください。
| 項目カテゴリ | 具体的項目名 | 判断基準・確認内容 | 担当者 |
|---|---|---|---|
| テスト範囲 | 対象機能一覧 | 要件定義書と照合し、除外項目がないか確認 | PM |
| テスト環境 | サーバ構成・ミドルウェアバージョン | 本番との差分と、確認できない事項を記録 | インフラ担当 |
| テストデータ | データマスキング実施状況 | 個人情報が匿名化され、業務ロジックが保持されているか | 情報セキュリティ担当 |
| テストケース | シナリオカバレッジ | 主要業務フロー＋例外フローが網羅されているか | 業務担当・開発リーダー |
| 不具合管理 | 報告テンプレートの使用 | 必須項目が全て入力されているか | 全テスト実施者 |
| 受入基準 | 合格ラインの明示 | クリティカル不具合が0件、非クリティカルは許容範囲内か | PM／QA担当 |
8. 短いQ&A（よくある質問）
- Q: テスト環境が本番と完全に同一でなくても受け入れテストは実施できるか？
A: 原則は同一が望ましいですが、差異がある場合は差分リストを作成し、テスト結果への影響を評価したうえで実施可否を判断します。 - Q: テストデータに実際の顧客情報を使用しても問題ないか？
A: 実データの利用は、目的、契約、社内方針、権限を確認して判断します。検証用データで代替できるなら優先し、実データが必要な場合は情報管理の判断者へ確認します。伏せ字だけで安全とは限りません。 - Q: 受入基準に合格しないテストが1件だけ残っている場合、リリースは可能か？
A: クリティカル度合いと業務影響度を評価し、リスクが許容範囲内であれば例外承認手続きを経てリリース可能です。ただし、例外は文書化し、後続の改善策を計画します。
受け入れテストは、システムが実務に適合するかを最終的に確認する重要なフェーズです。上記のチェックリストと手順を活用し、関係者全員が「何を決め、誰が何を確認するか」を共有すれば、テストの抜け漏れや遅延を最小限に抑えることができます。
関連サービスと基礎資料
システム・アプリ開発の対象範囲もご確認いただけます。
本記事の手順・確認項目は一般的な検討のための提案です。AIを使って草案を作成し、構成・表現の点検を行っています。個別の契約・運用条件は実際の環境に合わせて確認してください。