受入テストとは？ビジネス要件の充足を確認する最終検証手法

受入テストとは

受入テスト（UAT: User Acceptance Testing）とは、システムやプロダクトがビジネス要件を満たしていることを、実際のユーザーまたは発注者が確認する最終段階のテスト活動です。開発チームによる機能検証（システムテスト）が「仕様通りに動くか」を確認するのに対し、受入テストは「ビジネスの目的を達成できるか」を確認します。

PMBOKでは受入テストをプロジェクトのスコープ検証プロセスの一部として位置づけています。受入テストの合格がプロジェクトの成果物の正式な受入（Acceptance）につながり、契約上の完了条件を満たす根拠となります。

受入テストは技術的なテストとは異なり、業務プロセスの観点で実施します。実際の業務シナリオに沿ってシステムを操作し、日常業務が問題なく遂行できることを確認する点が特徴です。

:::box-point 受入テストはPMBOKのスコープ検証プロセスに位置づけられ、「仕様通りに動くか」ではなく「ビジネス目的を達成できるか」をユーザー視点で最終確認する活動です。合格がプロジェクト成果物の正式な受入根拠となります。 :::

構成要素

受入テストの種類

種類	目的	実施者
ユーザー受入テスト（UAT）	業務要件の充足をエンドユーザーが確認	エンドユーザー、業務部門
運用受入テスト（OAT）	運用・保守の観点での受入可否を確認	運用チーム、インフラチーム
契約受入テスト	契約上の要件がすべて満たされていることを確認	発注者、検収担当
規制受入テスト	法規制やコンプライアンス要件への適合を確認	品質保証部門、監査担当

受入テストの3つの構成要素

• テストシナリオ: 実際の業務フローに基づくシナリオ。「顧客から注文を受けてから出荷指示を出すまで」のような業務の流れ全体を通しで検証する
• 合否判定基準: 何をもって合格とするかの明確な基準。主観的な判断を避け、可能な限り定量的に定義する
• テスト環境・データ: 本番に近い環境とリアルに近いテストデータ。本番データのマスキングコピーが理想的

実践的な使い方

ステップ1: 受入テスト計画を策定する

プロジェクトの早い段階で受入テスト計画を策定します。テスト計画はシステムテスト計画とは別に、業務部門の主導で作成します。

• テストの目的と範囲を定義する
• テスト参加者（テスター）を業務部門から選定する。業務に精通した担当者が最適
• テスト期間とスケジュールを確保する。業務繁忙期との重複を避ける
• 合否判定基準と不合格時の対応手順を事前に合意する
• テスト環境の準備とテストデータの要件を定義する

ステップ2: テストシナリオを設計する

業務プロセスに基づいたテストシナリオを設計します。

• 主要な業務フロー（ハッピーパス）をシナリオ化する
• 例外処理やエラーケースも含める（注文取消、返品処理、権限不足のケースなど）
• 各シナリオに期待結果を明記し、合否の判断基準を具体化する
• シナリオの優先度を設定し、重要度の高い業務から順にテストする
• テストシナリオは技術的な用語ではなく、業務用語で記述する

ステップ3: テストを実行し結果を記録する

計画に基づいてテストを実行します。

• テスターへの事前説明会を開き、テストの目的・手順・記録方法を共有する
• 各シナリオの実行結果を合格/不合格で記録する
• 不合格の場合は問題の内容と再現手順を詳細に記録する
• 発見された問題を重大度で分類し、修正の優先度を判断する
• 修正後の再テスト（確認テスト）を実施する

ステップ4: 受入判定を行う

テスト結果を集約し、受入の可否を判定します。

• 全テストシナリオの消化率と合格率を集計する
• 未解決の問題の一覧と、それぞれの対応方針（修正する/回避策で対応する/次期対応に先送り）を整理する
• 合否判定基準に照らして、受入可否を判断する
• 条件付き受入（一部の問題を残しつつ、期限を定めて修正する）の場合は、条件と期限を文書化する

活用場面

• 基幹システムの刷新: ERPや会計システムの入替で、全業務プロセスの動作を業務担当者が確認します。マスタデータの移行結果の確認も受入テストの重要な対象です
• 外部委託開発の検収: 受託開発の成果物を受け入れる際の検収テストとして実施します。契約上の要件がすべて満たされていることを確認する根拠となります
• パッケージ導入: SaaSやパッケージソフトウェアの導入時に、カスタマイズ箇所と業務フローの適合性を確認します

注意点

:::box-warning 受入テストでは、テスター確保の難しさと要件の曖昧さが重大な問題になりがちです。計画段階からテスターの業務負荷を考慮し、合否判定基準を早期に合意しておくことが成功の鍵です。 :::

テスターの業務負荷

受入テストのテスターは通常業務と兼務するため、テスト期間中の業務負荷が増大します。テスト期間中は通常業務の一部を他のメンバーに委譲するなど、テスターが集中できる環境を整えることが重要です。

要件の曖昧さが露呈する場

受入テストの段階で「これは要件に含まれていたのか」という議論が発生することがあります。要件定義の段階で合意が不十分だった部分が、受入テストで顕在化するパターンです。この問題を最小化するには、要件定義時にステークホルダーとの合意を入念に行い、受入テストの合否判定基準も早期に合意しておく必要があります。

形式的なテストの回避

テストシナリオを「ただ消化する」だけでは、実際の業務で発生する問題を見逃します。テスターが実際の業務のつもりでシステムを操作し、想定外の操作やデータも試す余地を残すことが重要です。

まとめ

受入テストは、システムがビジネス要件を満たしていることをユーザー視点で最終確認する活動です。業務シナリオに基づくテスト設計、明確な合否判定基準、テスターの確保と環境整備が成功の鍵であり、受入テストの合格がプロジェクトの成果物の正式な受入根拠となります。