監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
受け入れテストは、開発したシステムが発注側の業務要件を満たしているかを、発注側の視点で確認する最終段階のテスト工程です。ユーザー受け入れテスト（UAT）とも呼ばれます。開発側のテストが「仕様どおり作れたか」を見るのに対し、受け入れテストは「実際の業務で使えるか」「契約で約束した範囲を満たすか」を検証し、検収と本番移行の判断材料にします。
受け入れテストは、ウォーターフォール型の開発であれば結合テスト・システムテストの後、本番リリースの直前に置かれる工程です。目的は大きく二つに分かれます。
開発側が行うシステムテストは「要件定義書どおりに作れたか」を問う工程でした。受け入れテストはそこから視点を移し、要件定義では書ききれなかった業務の実態に照らして使えるかを問います。PMにとっては、ここを通過できないとプロジェクトが完了扱いにならないため、スケジュール上の重要な関門になります。
受け入れテストは、発注側の業務担当者が主役になる点がほかのテストと大きく違います。進め方はおおむね次の順で進みます。
PMの役割は、発注側と開発側の間で基準と優先順位をすり合わせ、判定が感覚ではなく記録に基づいて進むよう整えることにあります。
テスト工程は似た名前が並ぶため、混同されがちです。ここでは「誰が」「何を基準に」「何を見るか」という軸で整理します。
この三つは段階的に視点が広がっていくと捉えると整理しやすくなります。結合テストが部品同士のつながり、システムテストが製品全体の動き、受け入れテストが業務の中での使い勝手、という順です。PMは、どの工程でどこまで確認済みかを把握しておくと、受け入れテストで出た指摘が本当に新規のものか、前工程で拾えたはずのものかを切り分けやすくなります。
受け入れテストは工程の終盤にあるため、ここでの手戻りはスケジュール全体に響きます。起こりやすいつまずきを挙げます。
受け入れテストは、PMが発注側と開発側の利害を調整する力を試される工程です。合格基準のすり合わせ、不具合と要望の切り分け、担当者の工数確保といった調整は、技術知識だけでは進みません。業務を理解したうえで関係者の合意を形にする経験は、プロジェクト全体をまとめる力として評価されやすい部分です。
転職を検討する場面でも、受け入れテストをどう設計し、どんな課題をどう収束させたかは具体的に語りやすい実績になります。テストの合否を記録に基づいて判断し、検収まで導いた経験は、進捗管理や品質管理と並んでPMの実務力を示す材料になります。前工程の品質を見極める視点を持てると、終盤の手戻りを減らす提案にもつなげられます。
受け入れテストは誰が行うのですか。
原則として発注側の業務担当者が主役になります。実際にそのシステムを使う現場の人が、普段の業務手順に沿って操作し、業務で使えるかを確認します。開発側のPMやテスト担当は、シナリオ作成の支援や環境準備、不具合の受け付けといった後方支援の役割を担うことが多いです。
受け入れテストとシステムテストはどう違いますか。
システムテストは開発側が要件定義書を基準に、システム全体が仕様どおり動くかを確認する工程です。受け入れテストは発注側が業務要件や契約を基準に、実際の業務で使えるかを確認します。基準と担当者、見る視点が異なり、受け入れテストのほうが業務の実態に近い観点で判定します。
受け入れテストで不具合が多く出たらどうしますか。
まず重要度で分類し、リリース前に直すものと運用でカバーできるものに振り分けます。あわせて、それが本当に不具合か、仕様変更の要望かを切り分けます。前工程で拾えたはずの不具合が多い場合は、システムテストの進め方を見直す判断材料にもなります。基準に沿った記録を残すことが判断の支えになります。