受入テスト（UAT）とは？発注者が主体になる理由と進め方・観点

受入テスト（UAT）を任されたものの、「ベンダーのテスト完了報告があれば十分ではないか」「限られた時間でどこまで確認するべきか」と迷う発注者側の担当者は少なくありません。Webサービスやスマホアプリでは、画面や機能が動くことに加え、自社の権限、データ、部門間の受け渡し、外部連携を含めて業務が完了するかを確認する必要があります。

この記事では、UATの位置付けから、範囲の優先付け、業務シナリオの作成、体制・日程、課題管理、受入可否、外部支援の判断までを解説します。読後には、自社の受入範囲・役割・判断条件を具体化できるようになります。

UATはベンダー試験の完了報告を確認しつつ、発注者・利用部門が自社業務への適合性を確かめ、受入判断の根拠を整える工程です。検収との接続方法は契約条件や受入基準に沿って確認します。

01Section受入テスト（UAT）とは：ベンダー試験・検収との違い

受入テスト（User Acceptance Test：UAT）は、システムが自社の業務やサービスで意図したとおりに使え、実運用へ移せる状態かを確認する工程です。発注者・利用部門が判断の主体となりますが、発注者だけですべてのテスト作業を担うという意味ではありません。ベンダーの試験結果を確認しながら、業務適合性と受入可否の根拠を整える工程と捉えると、役割を分けやすくなります。

単体・結合・システムテストとUATの役割分担

テスト工程の名称や分け方は、開発手法や契約内容によって異なります。一般的には、ベンダー側の試験が技術的・仕様上の品質確認を中心とするのに対し、UATでは発注者側が実際の業務や利用条件に照らして確認します。工程全体の関係は、結合テストの解説も参照してください。

ベンダーのシステムテスト完了報告は、UATを始めるための重要な材料です。ただし、それだけで「自社の担当者が必要な権限で操作できるか」「移行後のデータで後続業務まで進められるか」といった業務上の確認を一律に代替できるわけではありません。

UATと検収は同じではない

UATは業務適合性を確認する工程であり、検収は契約や要求仕様で定めた成果物を受け取る手続きです。両者は実務上連続しますが、同義ではありません。デジタル庁の標準ガイドライン解説書でも、受入テストを通じた修補などを行い、合否判定基準を満たすことを確認して検収へ進む考え方が示されています。

検収の詳細は検収の進め方を確認し、契約条件や受入条件はシステム開発契約での確認ポイントも踏まえて整理しましょう。情報システム取引のモデル文書は、経済産業省の情報システム・モデル取引・契約書を参照できます。ただし、モデル文書は個別案件の契約解釈や法的な結論を代替するものではありません。

UAT開始前に確認する根拠文書と承認者

開始後に「何を満たせば受け入れるのか」を議論し直すと、課題の優先順位や日程が揺れます。受入条件と責任者を、先に対応付けておくことが重要です。

02Section受入テストの範囲は、業務シナリオとリスクで決める

UATは、全機能を同じ深さで再試験する工程ではありません。限られた体制で受入判断に必要な確認を行うため、まず「止まると困る業務」から範囲を決めます。利用頻度だけでなく、問題が起きたときに回避できるか、重要データや権限に影響するかも判断材料です。

優先度を上げる業務・機能の条件

次の条件が重なる業務は、必須シナリオとして優先しやすい領域です。

• 利用頻度が高く、停止すると日常業務へ直ちに影響する
• 金額、契約、顧客情報など重要データの正確性に関わる
• 承認、閲覧制限、個人情報など権限管理に関わる
• 外部システム連携やデータ移行があり、失敗時に重複・欠損が起こり得る
• 複数部門で受け渡しがあり、手作業での回避が難しい

要件を3つの対応先へ分ける

要件定義書、業務フロー、画面・帳票一覧、権限一覧、連携仕様、移行計画、非機能要件を並べ、各項目を次のいずれかに対応付けます。

1. 1UATケースで確認する：発注者環境・利用部門の操作で、業務適合性を確認すべき項目。
2. 2ベンダー試験資料を確認する：技術的な試験結果を主な根拠とし、必要に応じて発注者側で結果を確認する項目。
3. 3対象外理由を記録する：今回のUATでは確認しない理由、代替する確認方法、確認責任者を残す項目。

対象外にした項目を無記録にすると、受入後に確認漏れなのか、意図的な除外なのかを説明できません。特に外部連携や移行では、相手先都合で試験が難しい場合もあるため、代替確認の方法と残るリスクを記録します。

非機能要件は一律に再試験しない

性能、可用性、セキュリティ、ログ、端末・ブラウザ対応、アクセシビリティなどの非機能要件は、すべてをUATで再試験するものではありません。受入基準に含まれるか、業務影響が大きいか、発注者の実利用環境で確認する必要があるかで決めます。

IPAの非機能要求グレードは、重要項目から要求レベルを整理し、受発注者間の認識差を抑える考え方の参考になります。アクセシビリティ要件があるWebサービスでは、利用者が業務を遂行できるかの確認と、規格に沿った試験は目的が異なります。WAICのユーザが参加したウェブサイトの検証を参照し、必要に応じて別の試験・確認方法を計画してください。

03Section業務シナリオ型のテストケースを作る

機能一覧に沿って「登録できた」「画面が開いた」と確認するだけでは、実運用での詰まりを見つけにくいことがあります。UATでは、業務の開始から完了までを追い、誰が何を判断し、次の担当者や外部システムへどう引き継がれるかを確認します。

優先するシナリオを選ぶ

最初に、主要業務、高頻度業務、失敗時の影響が大きい業務、例外が起こりやすい業務を挙げます。例えば「申請から承認、後続処理まで」のように、複数の役割や処理をまたぐ一連の業務を1本のシナリオにします。

外部連携がある場合は、通常の送受信だけでなく、連携失敗を検知できるか、再実行時に重複や欠損が発生しないか、担当者へ必要な通知が届くかまで確認対象を広げます。移行がある場合は、移行後データで主要業務を完了できるかを確認します。

テストケースに記入する項目

テストケースは操作手順だけでなく、担当者・権限、期待する業務結果、例外時の確認、証跡まで結び付けると、受入判断に必要な情報を残しやすくなります。

期待結果は「問題なく動く」ではなく、何を見て合否を決めるかまで書きます。画面表示だけでなく、登録データ、通知、帳票、連携結果、履歴、後続処理のうち、業務上必要な結果を明記してください。

正常系だけでは足りない理由

現場では、入力不備による差し戻し、担当変更、取消、権限不足、通知未達などが起こります。正常系だけを確認しても、例外時にデータの状態や後続処理が不整合になると、利用開始後に業務が止まる可能性があります。

例外をすべて網羅する必要はありません。業務影響、発生しやすさ、回避手順の有無を踏まえ、必須ケースへ組み込む例外を選びます。業界固有の規制や社内規程がある場合は、汎用テンプレートに追加して受入条件へ反映します。

04SectionUATを止めない体制・準備・日程を組む

UATは、準備、実施・課題管理、再テスト・受入判断の3段階に分けると計画しやすくなります。実施する人と受入を承認する人を分けることで、実施率だけで受入判断をしてしまうリスクを抑えられます。

役割を分けて、判断経路を明確にする

発注者側責任者は範囲、優先順位、進捗、論点のエスカレーションを担います。業務テスターは実際の業務シナリオを実施し、操作性や運用上の問題を記録します。結果確認者は、証跡と期待結果を確認します。

受入承認者は、必須ケースの結果、残課題、契約・社内条件を踏まえて受入判断を担います。情報システム部門は環境、アカウント、権限、ログ、連携の確認を支援し、ベンダー窓口は問い合わせ、原因調査、修正計画、修正版の提供を担います。役割の兼任は可能ですが、少なくとも実施結果の確認と最終承認の視点は分けることが望ましいでしょう。

日程はケース数と確保可能時間から逆算する

日程は必須ケースと担当者が確保できる時間から組み立て、修補・再テスト・承認・検収手続きを初回実施と別枠で確保します。

「UATは何週間」と固定するのではなく、必須ケースの作業量と担当者が確保できる時間から計画します。UAT前後を含む開発工程の全体像は、システム開発の流れで確認できます。

IPAのソフトウェアテスト見積りガイドブックは、テスト量、品質目標、進捗に応じて計画前提を見直す考え方の参考になります。標準的な期間や人日を示す資料ではないため、案件のケース数、稼働、修正状況に合わせて更新します。

日程には、環境・データ・権限をそろえる準備、シナリオを実行する実施、修補と回帰確認を行う再テスト、結果集計と承認・検収手続きを行う判断・手続きの枠を分けて置きます。テスト最終日と受入・検収の完了日を同じ日に置かないことが重要です。

05Section課題を管理し、受入可否を契約条件に沿って判断する

UATで見つかった事象をすべて「不具合」として扱うと、対応方針が曖昧になります。合意済みの要件や仕様との差異なのか、仕様が不明確なのか、新しい要望なのか、教育や運用で解決できる課題なのかを切り分けます。

課題票に残すべき情報

課題は、不具合、仕様確認、要件変更、教育・運用課題に分類します。そのうえで、再現・影響評価・再テストに必要な情報を記録します。

重大度は業務影響で決める

重大度は、画面上の見え方だけで決めません。主要業務を停止させるか、重要データや金額・契約情報の正確性を損なうかを確認します。次に、個人情報、権限、セキュリティ、法令・社内規程への影響を見ます。最後に、安全に実行できる回避策があるか、修正が周辺業務や連携へ及ぼす影響はどこまでかを確認します。

修正版が提供されたら、報告した事象だけでなく、変更の影響を受け得る周辺機能、連携、移行データも再確認します。再テスト範囲と結果を残すことで、受入判断の説明可能性が高まります。

受入可・条件付き受入の検討・保留を分ける

受入可否は実施率だけでなく、必須ケースの結果、合否基準、重大課題、残課題への対応、証跡と承認記録を合わせて確認します。具体的な判断は契約条件と受入基準に沿って行います。

受入可否は、テスト実施率だけでは決められません。必須ケース、合否基準、重大課題、残課題、再テスト、証跡、承認記録を一体で見ます。

06Section自社で進めるか、外部支援を使うかを判断する

対象業務や部門が限定的で、業務知識を持つテスター、受入基準、環境、データを確保できる場合は、自社主体で進めやすいでしょう。一方、多部門・多数利用者、複数連携、データ移行、短い準備期間、テスト経験や進行管理の不足がある場合は、外部支援を検討する余地があります。

ただし、外部支援を利用しても、受入基準、優先順位、残課題を許容するかどうか、最終受入承認は発注者側に残します。外部支援は、計画レビュー、観点整理、ケース作成、実行補助、進行管理、第三者レビュー、教育など、不足する部分に限定すると責任分界を明確にしやすくなります。

内製・外部支援を分ける判断順

1. 1業務判断者を確保できるかを確認します。確保できない場合は、まず発注者側の受入責任者、利用部門、承認者を定めます。
2. 2不足を分類します。業務知識、テスト設計の方法論、実行人員、進行管理、第三者レビュー、連携・移行・セキュリティの専門性に分けます。
3. 3不足部分だけを委託範囲にします。計画レビューのみ、ケース作成支援まで、実行補助を含む、と段階を分けます。
4. 4情報管理と責任分界を文書化します。アクセス、成果物、課題のエスカレーション、最終クローズ者、追加作業時の扱いを明確にします。

比較見積では前提をそろえる

費用は、対象業務、ケース数、連携・移行、支援範囲、期間、成果物、データ取扱い、追加作業条件によって変わります。総額だけを比較せず、同じ前提で個別見積を確認してください。

UATで重要なのは、テストを多く実施することではなく、自社が受け入れるために必要な業務確認と判断記録をそろえることです。受入基準、必須シナリオ、役割、日程、残課題の扱いを開始前に合意し、ベンダー試験資料とUAT結果を組み合わせて受入可否を判断しましょう。

受入テストの設計・実行支援を検討する場合

多部門での実施、複数システム連携、データ移行、短い準備期間などで体制に不足がある場合は、テスト観点の整理、ケース作成、実行補助、進行管理、第三者レビューといった必要な範囲に絞って支援先を比較できます。受入基準と最終承認の責任分界は、事前に明確にしましょう。

QA・第三者検証670社掲載

QA・第三者検証の支援先を探す