受入テスト（UAT）の進め方｜計画・シナリオ・判定基準の実践手順

2026年9月17日 2026年9月17日株式会社 SunSunTech

株式会社 SunSunTech

受入テスト（UAT）を任されたものの、「結合テストと何が違うのか」「どこまで確認すれば合格にできるのか」と迷っていないでしょうか。受入テストは、機能が仕様書どおりに動くことだけでなく、利用部門が実際の業務を完遂できるかを確かめる工程です。本記事では、業務担当者、PM、開発リーダーに向けて、計画、シナリオ作成、実施、不具合管理、合否判定までの進め方を実務で使える形に整理します。

受入テスト（UAT）の目的と他のテストとの違い
計画段階で決めるべき項目
業務シナリオとテストケースの作り方
実施・不具合管理・合否判定の進め方
受入テストに関するよくある質問
まとめ
- - 投稿者プロフィール
    - 最新の投稿

受入テスト（UAT）の目的と他のテストとの違い

UATはUser Acceptance Testの略で、システムを受け入れて業務利用を開始できるかを利用者側の視点で判断するテストです。開発チームが行う単体テストや結合テストは、プログラムや機能間連携が設計どおりに動くかを主に確認します。一方、受入テストでは「注文受付から請求まで処理できる」「担当者交代後も権限に応じて作業できる」といった業務の成立を確認します。

したがって、画面ごとの正常動作を繰り返すだけでは不十分です。実データに近い条件、担当者の役割、締め時間、承認、例外処理、外部システムとの連携まで含めて評価します。最終的な成果物はテスト結果そのものではなく、残存リスクを把握したうえで「利用開始できる」と説明できる判断材料です。

開始時には、責任範囲も明確にします。業務部門はシナリオと期待結果、開発側は環境・データ準備と障害解析、PMは日程・課題・判定会議を担当するのが基本です。合否の決裁者を決めずに始めると、テストが終わっても誰も受入可否を決められません。

計画段階で決めるべき項目

最初に、対象業務、対象機能、対象外、実施期間、参加者、環境、データ、完了条件を一枚の計画にまとめます。機能一覧だけで範囲を決めるのではなく、業務フロー単位で線を引くことが重要です。たとえば「受注登録」は対象でも、その後の在庫引当や請求連携が対象外なら、どこまでを確認し、何を別工程で保証するのかを記載します。

合否基準は開始前に数値と条件で定義します。単純に「全ケース消化」だけでは、重大障害が残っていても完了扱いになりかねません。次の観点を組み合わせると判断しやすくなります。

重要業務シナリオがすべて実行済みである
業務停止につながる重大不具合が0件である
未解決不具合に回避策、対応期限、責任者がある
権限、帳票、データ連携など重点項目の確認が完了している
操作手順書や問い合わせ窓口など運用準備が整っている

テスト環境とデータの準備も計画に含めます。本番相当の権限設定、マスタ、日付条件、外部連携先が用意できなければ、正しいシナリオでも検証できません。個人情報や機密情報を使う場合は、マスキングやアクセス制御、テスト後の削除方法も事前に決めます。

業務シナリオとテストケースの作り方

シナリオは「利用者が達成したい業務」から逆算します。画面Aで入力、画面Bで検索という機能の羅列ではなく、「営業担当が新規注文を登録し、上長が承認し、在庫担当が出荷を確定する」のように、開始条件から完了状態までを一本につなげます。担当者、前提データ、操作、期待結果、確認する証跡をセットで記述してください。

正常系だけでなく、現場で起きる例外を優先します。入力ミス、重複登録、承認却下、権限不足、締め日越え、連携遅延、途中保存、取消・再処理などです。すべてを網羅しようとすると件数が膨らむため、発生頻度と業務影響で優先順位を付けます。「頻度は低いが、発生すると請求を誤る」ケースは重点対象です。

期待結果には、画面表示だけでなく後続への影響を書きます。データベースに正しく保存されたか、承認者へ通知されたか、帳票や集計に反映されたか、外部システムへ一度だけ送信されたかまで確認します。金額、件数、ステータス、処理時刻など、合否を客観的に判断できる値にすると担当者によるばらつきを減らせます。

実施・不具合管理・合否判定の進め方

実施前に短い説明会を開き、テストの目的、操作手順、証跡の残し方、不具合の登録方法、質問窓口を共有します。進捗はケース消化率だけでなく、未実施理由、再テスト待ち、環境停止時間も分けて管理します。消化率が高くても重要シナリオが未実施なら、受入判断の材料にはなりません。

不具合票には、再現手順、入力データ、期待結果、実際の結果、発生日時、利用者・権限、画面やログの証跡を残します。重大度は技術的な直しやすさではなく業務影響で判断します。「業務を継続できない」「回避策はあるが負担が大きい」「表示上の問題に限定される」など、共通の基準を使いましょう。

よくある失敗は、テスト中に仕様確認と不具合判定が混ざり、対応が止まることです。質問、仕様差異、不具合、改善要望を分類し、誰がいつ判断するかを決めます。変更要望をすべて受入条件にすると終了できないため、今回のリリースに必須か、次回改善に回せるかを切り分けます。

判定会議では、完了条件の達成状況、重大不具合、未実施ケース、回避策、運用準備、リリース後の監視項目を確認します。結論は「合格・不合格」だけでなく、条件付き合格も選択肢です。ただし条件付き合格にする場合は、残課題の責任者、期限、影響範囲、問題発生時の切り戻しや連絡経路を明記します。

受入テストに関するよくある質問

Q1. 受入テストは誰が実施すべきですか？

実際の業務と判断基準を理解している利用部門が中心です。開発担当者だけで実施すると、機能確認に偏りやすくなります。開発側は環境準備、データ作成、調査、修正を支援し、業務側が最終的な受入可否を判断できる体制にします。

Q2. テストケースはどこまで細かく作ればよいですか？

初めて操作する担当者が、同じ前提データで実施して同じ合否を判断できる粒度が目安です。全クリックを説明するより、業務上重要な入力値、分岐、期待結果、証跡を明確にします。操作に不慣れな参加者が多い場合は、手順書へのリンクを併記します。

Q3. 不具合が残っていてもリリースできますか？

重大度、発生条件、回避策、影響範囲を評価し、事前に決めた合否基準を満たすなら条件付きで判断できます。ただし、重大障害を件数だけで平均化してはいけません。業務停止や誤請求、情報漏えいにつながる問題は、原則として解消と再テストを優先します。

まとめ

受入テストを成功させる鍵は、機能の動作確認ではなく、重要な業務を利用者が完遂できるかを評価することです。まず対象業務、役割、環境、完了条件を計画し、業務フローと例外処理をシナリオに落とし込みます。実施中は業務影響に基づいて不具合を管理し、最後に残存リスクと運用準備を含めて受入可否を判断します。

次の行動として、最も重要な業務を一つ選び、「開始条件・担当者・操作・期待結果・証跡・例外」の6項目でシナリオを書いてみてください。その一本を業務担当者と開発担当者でレビューすると、曖昧な範囲や不足データが早い段階で見つかり、実行できる受入テスト計画へ近づきます。

投稿者プロフィール

株式会社 SunSunTech: はじめまして。
株式会社SunSunTech代表取締役の鈴木と申します。

SunSunTechは、エンジニアが納得できるキャリアと報酬を得られるSES企業を目指して設立しました。

私は元々、エンジニアとして複数のSES現場で経験を積んできました。
その中で、「スキルに見合った評価が得られない」「給与の仕組みが不透明」といった業界特有の課題に何度も直面してきました。

こうした状況を変えるために、SunSunTechでは、透明性のある評価制度の導入、エンジニアファーストな案件選定など、"エンジニアが報われる仕組み"を徹底しています。

SES企業様とのパートナー連携においても、スピード・誠実・精度を大切にし、長期的に信頼される関係構築を目指しております。

エンジニアの未来を、本気で変えていく。
その想いに共感してくださる方、ぜひ一度お気軽にお声がけください。