監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
受入テストは、開発側が納めた成果物を発注側（利用部門やユーザー企業）が自分たちの業務目線で確認し、検収して本番へ移してよいかを判断する工程です。要件どおりに動くかだけでなく、実際の業務が回るかを見る点が特徴で、合否が支払いや稼働開始日に直結します。UATと略されることもあります。
受入テストの軸は「開発側の内部品質」ではなく「発注側が業務を任せられるか」です。システムテストまでで動作の正しさは開発側が確認済みという前提に立ち、その上で発注側が最終判断を下します。ここで確認したいのは、要件定義書に書いた要求が本当に満たされているか、そして日々の業務手順にそのまま乗せられるか、の二つです。
典型的には、利用部門の担当者が実際の業務シナリオに沿って操作します。たとえば受注入力から在庫引き当て、出荷指示までを一連で流し、途中で例外的な入力があっても業務が止まらないかを見ます。開発側の視点では正常でも、現場の運用ルールに合わなければ受け入れられないことがあり、その差を洗い出すのがこの工程の役割です。
成果物としては、受入テスト計画書、テストシナリオと判定基準、実施記録、そして検収書が並びます。PMは、これらの判定基準を要件定義の段階から発注側と握っておくと、合否の解釈がぶれにくくなります。
進め方は、準備・実施・判定の三段に分けて考えると整理しやすくなります。まず準備段階では、発注側の業務担当者を中心にテストシナリオを作ります。ここで「どの業務の、どの操作を、どの結果になれば合格とするか」を明文化します。開発側は、本番に近いデータと環境を用意し、操作手順やテスト用アカウントを渡します。
実施段階では、発注側の担当者がシナリオに沿って操作し、期待どおりの結果になるかを記録します。不具合や要望が出たら、それが契約範囲内の欠陥なのか、仕様変更にあたる追加要望なのかを切り分けます。この切り分けを曖昧にすると、受入テストが延々と終わらなくなります。
PMの役割は、この三段が滞りなく進むよう日程と関係者を調整し、指摘の対応方針を発注側・開発側の間で合意させることにあります。
受入テストでよく起きるのは、合格の基準が事前に定まっていないまま実施に入ってしまうことです。判定基準が曖昧だと、担当者ごとに「使いにくい」「思っていたのと違う」といった主観的な指摘が積み上がり、どこまで直せば検収できるのかが見えなくなります。要件定義の時点で判定基準を言語化しておくことが予防策になります。
次に多いのが、テスト用データが本番の業務実態とかけ離れているケースです。件数が極端に少なかったり、例外パターンを含まないデータで確認すると、稼働後に想定外の入力でつまずきます。可能な範囲で本番に近いデータを使い、繁忙期の量や異常系も含めておくと安心です。
もう一つは、指摘への対応が仕様変更へ滑り込んでいく問題です。「ついでに直してほしい」という要望が欠陥対応に紛れ込むと、日程も費用も膨らみます。指摘を欠陥と変更要望に仕分け、変更にあたるものは変更管理の手続きに載せる運用を、テスト開始前に発注側と共有しておくと混乱を抑えられます。加えて、発注側の担当者が本業と兼務で時間を取れず、テストが後ろ倒しになることも珍しくないため、稼働日から逆算した日程確保もPMの守備範囲です。
テスト工程は、確認する主体と観点という軸で並べると違いが見えてきます。結合テストは、複数のモジュールをつないだときにデータの受け渡しが正しく行われるかを開発側が確認する工程です。システムテストは、システム全体が要件どおりに動くかを、性能や負荷も含めて開発側が総合的に確かめます。いずれも作り手側の視点が中心です。
これに対して受入テストは、確認する主体が発注側に移り、観点も「業務が回るか」へと変わります。同じ機能を触っていても、開発側が「仕様どおり動く」と判断したものを、発注側が「この手順で業務に使える」と納得できるかを見る点が異なります。工程の順序としては、結合テスト、システムテスト、受入テストと進むのが一般的な流れです。
アジャイル開発では、これらの区切りが明確な段階として現れないこともあります。スプリントごとにプロダクトオーナーが成果物を確認する形が、受入テストに相当する役割を担う場合があります。いずれの進め方でも、発注側が業務目線で受け入れ可否を判断するという受入テストの本質は変わりません。
受入テストは、PMが発注側と開発側の間に立って合意を作る力が試される工程です。判定基準を要件定義から握り、指摘を欠陥と変更要望に仕分け、稼働日から逆算して日程と要員を調整する。この一連をさばけると、検収と稼働をつまずかせないPMとして評価につながりやすくなります。転職を考える際も、受入テストを主導した経験は、単にテストを回した実績ではなく、ステークホルダー間の期待値をそろえて着地させた実績として語れます。品質管理や変更管理と組み合わせて説明できると、上流から検収までを一貫して見られる人材という印象を持ってもらいやすくなります。
受入テストは誰が主体で行いますか
発注側の利用部門やユーザー企業が主体となります。実際に業務を担う担当者が業務シナリオに沿って操作し、検収の可否を判断します。開発側はテスト環境やデータの準備、操作手順の提供といった支援に回るのが一般的な役割分担です。
システムテストと受入テストはどう違いますか
システムテストは開発側がシステム全体を要件どおりか総合的に確認する工程です。受入テストは主体が発注側に移り、業務が実際に回るかという観点で確認します。同じ機能でも見る視点が作り手側か使い手側かで異なる点が主な違いです。
受入テストが終わらないときはどうすればよいですか
多くの場合、合格基準の曖昧さと指摘の仕分け不足が原因です。要件定義の段階で判定基準を明文化し、出てきた指摘を欠陥と仕様変更に分けて、変更にあたるものは変更管理の手続きに載せると、対応範囲が定まり収束しやすくなります。