ユーザー受入テスト（UAT）の進め方｜基幹システムのテストシナリオ例と合否基準

ユーザー受入テスト（UAT）は、「仕様どおりに動くか」ではなく「この仕組みで自社の業務が月末まで回るか」を発注側が確かめるテストです。成否を分けるのは、テストを始める前に合否基準を数字で決めて合意しておくことと、画面単位ではなく「受注から入金まで」の業務の流れでシナリオを書くことの2つです。この記事では、基幹システムのUATの進め方、テストシナリオの例、不具合の重要度と合格ラインの決め方を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

ユーザー受入テスト（UAT）とは：ベンダーのテストと何が違うか

ユーザー受入テスト（UAT：User Acceptance Test）は、新しい基幹システムを実際に使う発注側の担当者が、自社の業務で使えるかを確かめるテストです。受入テスト、受け入れテスト、ユーザーテストとも呼ばれます。

ソフトウェアテストの国際資格ISTQBのシラバス（日本語版はJSTQBが公開）では、受け入れテストを「妥当性確認と、デプロイの準備ができていることの実証」に焦点を当てるテストと位置づけ、想定ユーザーが実施するのが理想としています。主な形式として、ユーザー受け入れテスト（UAT）、運用受け入れテスト、契約・規制による受け入れテストなどが挙げられています。

ベンダーが行うテストとの違いは、何を「正解」とするかです。ベンダーのテストは設計書が正解で、設計書どおりに作れているかを確かめます。UATの正解は自社の業務です。設計書どおりに動いていても、締め日の請求が出せない、現場の入力に倍の時間がかかる、といった問題はUATでしか見つかりません。

UATは、要件定義書に書いた受入基準が満たされたかを確かめる場でもあります。受入基準が要件定義の段階で書かれていないと、UATで「これで合格か」を判断できません。要件定義書側の書き方は要件定義書の書き方で解説しています。

UATで確認すること・ベンダーに任せること

中小企業のUATでよく起きるのは、発注側が画面を1つずつ開いて項目を確かめる「2回目のシステムテスト」になってしまうことです。業務担当者の時間は限られています。UATでは、ベンダーのテストでは確かめられないことに集中します。

※◎：主に確認する、○：確認する、△：必要に応じて、×：確認できない。説明用の例です。

ポイントは、「網羅性」はベンダーの責任、「業務として成り立つか」は発注側の責任と線を引くことです。この線引きをテスト計画書に書いておくと、UATの範囲が膨らみません。

限られた時間をどこに使うかは、リスクの大きさで決めます。重点を置くのは、①アドオン（追加開発）した機能、②会計ソフトやEDIなど外部システムとの連携、③お金と在庫の数字が動く処理の3つです。パッケージの標準機能をそのまま使う部分は、製品として検証されている分だけ優先度を下げられます。アドオンの範囲を確認したいときはERPのアドオンとはも参考にしてください。

ユーザー受入テストの進め方：7つのステップ

UATは、テスト期間そのものより準備で決まります。システムテストの終盤に慌てて準備を始めると、テストデータがない、担当者の予定が押さえられていない、という状態でUATに入ることになります。

1. テスト計画を作る（UAT開始の2〜3か月前）
   範囲、期間、参加者、環境、不具合の管理方法、合否基準を1つの文書にまとめます。合否基準はこの時点でベンダーと合意します。
2. テストシナリオを書く
   業務の流れ単位でシナリオを書き、優先度をつけます。書くのは業務担当者、まとめるのはプロジェクトの事務局です。
3. テストデータを準備する
   移行リハーサルで移したマスタと、実在の取引先・品目を使います。架空のデータだけでは、特殊な締め日や掛率の取引先が漏れます。
4. 参加者に操作説明をする
   テストの前に半日程度の操作説明を行います。操作に迷った時間を不具合と混同しないためです。
5. テストを実施し、結果と不具合を記録する
   シナリオごとに合否と証跡（画面の写し、出力した帳票）を残します。不具合は1件1行で管理表に記録します。
6. 修正の確認と再テストを行う
   修正された不具合を確認し、修正の影響がありそうなシナリオを流し直します。
7. 合否を判定し、結果を報告する
   合否基準に照らして合格・条件付き合格・不合格を判定し、稼働判定の会議に報告します。

IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド 第2版」は、テストの完了基準が曖昧なままだと完了を判断できず、テストを際限なく続けることになると指摘しています。そのうえで、業務継続性を担保できる要件を定量的な基準として定め、テスト実施前に各ステークホルダと合意しておく必要があるとしています。手順1で合否基準を決めるのはこのためです。

UATの結果は、そのまま本番稼働の可否を決める会議の材料になります。稼働判定の基準と進め方は稼働判定と本番切替で詳しく解説しています。

テストシナリオの書き方と記入例

テストシナリオは、画面単位ではなく業務の1サイクル単位で書きます。「受注入力画面のテスト」ではなく、「A社から通常の注文を受け、出荷し、20日締めで請求し、翌月末に入金を消し込む」までを1本にします。こうすると、機能と機能の境目で起きる問題が見つかります。

次の表は、従業員150名、本社工場と物流倉庫の2拠点を持つ製造販売業を例にしたシナリオ一覧の抜粋です。

※説明用の例です。実際のシナリオ数は対象業務の範囲によって変わります。

シナリオ1本の書き方（UAT-01の記入例）

一覧の各行は、実施する人が迷わない粒度の手順に展開します。UAT-01なら次のとおりです。

1. 営業事務が、A社の注文書（標準品3品目、各50個、納期は翌週水曜）を受注登録する。期待：受注番号が採番され、3品目に在庫引当がかかる
2. 倉庫担当が、出荷指示一覧からA社分を選んで出荷登録する。期待：納品書が出力され、在庫が150個減る
3. 経理が、20日締めで請求締めを実行する。期待：A社の請求書に今回の出荷分が載り、金額が現行システムで同じ条件を流した請求書と一致する
4. 経理が、翌月末の入金（振込手数料を差し引いた額）を登録して消し込む。期待：差額が手数料として処理され、A社の売掛残がゼロになる

各手順に「期待」を書くことで、どこで食い違ったかがその場でわかります。振込手数料の差し引きのように、現場では当たり前でも設計書に書かれていない処理は、この粒度で書いて初めて表に出ます。

シナリオを書くときは、次の3種類がそろっているかを確かめます。

• 通常の流れ（UAT-01など）：取引件数の多い、いつもの業務。全体の4〜5割を占めるのが目安です。
• 例外の流れ（UAT-02〜06、12など）：分納、取消、返品、特別単価、締め日またぎ。現行業務で「この取引先だけ」「月末だけ」と言われている処理は、すべてここに入れます。
• 周期の処理（UAT-09、10など）：月次締め、棚卸、期末、年1回の単価改定。日々の業務では出てこないため、意識しないと抜けます。

シナリオの「期待する結果」には、できるだけ照合する相手を書きます。「請求額が正しい」ではなく「現行システムの請求書と一致」と書けば、合否で迷いません。IPAの同ガイドでも、同じ入力で現行システムと新システムの出力が一致するかを確かめる「現新比較テスト」が紹介されています。ただし、現新比較は設計に基づく全ルートのテストではないため網羅性は保証できない、という留意点もあわせて示されています。現行と比べるのは、金額や数量など照合できる項目に絞るのが現実的です。

合否基準の決め方：不具合の重要度と合格ライン

UATの合否は、「不具合がゼロになったら合格」では決まりません。基幹システムでは、稼働時点で軽微な不具合が残ることはよくあります。大事なのは、どの重さの不具合が何件残っていたら稼働できないかを先に決めておくことです。

※説明用の例です。件数の上限や修正期限は、業務の繁閑と取引先への影響で決めます。

合否基準は、不具合の件数だけでなく、次の3つを組み合わせて決めます。

• シナリオの実施率と合格率：例「優先度『高』のシナリオは100％実施・100％合格、全体では95％以上合格」
• 残存不具合：例「重要度Aは0件、Bは回避策と修正計画があるもののみ」
• 照合の結果：例「UAT期間中の売上・仕入・在庫金額が、現行システムの集計と一致」

重要度の判定で揉めたときに備えて、誰が最終的に重要度を決めるかも決めておきます。発注側は重く、ベンダーは軽く見積もる傾向があるため、プロジェクトの責任者や、ステアリングコミッティで判断する形にしておくと停滞しません。会議体の作り方はステアリングコミッティとはを参考にしてください。

UATでよく起きる失敗と防ぎ方

UATの失敗は、テストの技術より段取りで起きます。よく見る3つのパターンを、防ぎ方とあわせて示します。

UATの体制と、社内の工数の見積もり方

UATを実施する発注側の社内工数は、ベンダーの見積もりには入っていません。発注側の作業として、社内で見積もっておく必要があります。役割は次の4つに分けると整理しやすくなります。

• UAT責任者（プロジェクト責任者。管理部長など）：計画の承認、重要度の最終判断、合否判定
• 事務局（情シス担当、PMO）：シナリオのとりまとめ、日程管理、不具合管理表の運用、ベンダーとの窓口
• テスト実施者（営業事務・倉庫・購買・経理の担当者）：シナリオの作成と実施、結果と証跡の記録
• ベンダー（開発・導入会社）：環境の準備、操作の問い合わせ対応、不具合の調査と修正

不具合管理表は、Excelでも専用ツールでも構いません。少なくとも「番号、発見日、シナリオID、発見者、現象（何をしたら、何が起きたか）、期待した結果、重要度、回避策、担当、修正予定日、修正確認日、状態」の12項目を持たせます。「現象」と「期待した結果」を分けて書くと、ベンダーが再現しやすくなり、調査の往復が減ります。状態は「未着手・調査中・修正済み・確認済み・保留（要望へ移管）」の5つ程度に絞ると、日々の集計が楽になります。

社内工数は、シナリオの本数から逆算します。たとえば、シナリオ60本、1本あたり準備と実施で平均2時間、再テストを3割と置くと、60本×2時間×1.3＝約156時間です。テスト実施者が4人なら1人あたり約39時間、1日3時間をUATに充てると約13日かかります。これに事務局の作業と判定会議が加わります。

※説明用の例です。1本あたりの時間は、シナリオの長さと参加者の習熟度で大きく変わります。

外部のPMOに任せられるのは、主に事務局の作業です。シナリオの作成や合否の判断は、業務を知る発注側にしかできません。外部に任せる範囲の決め方はPMOとはで解説しています。

UATは契約上の検収とも関係します。2020年4月施行の改正民法では、請負の目的物が契約内容に適合しない場合、注文者は不適合を知った時から1年以内に請負人へ通知しないと、修補や損害賠償などを請求できなくなると定められました（民法637条）。契約書で検収の期間や合格の扱いを独自に定めていることも多いため、UATの期間と合否基準が契約上の検収とどう対応するかを、契約前に確認しておきます。

UAT開始前の10のチェックポイント

• UATの範囲（対象業務・拠点・帳票）と、範囲外が文書になっている
• 合否基準（シナリオ合格率・残存不具合・照合結果）がベンダーと合意済み
• 不具合の重要度の定義と、重要度を最終判断する人が決まっている
• シナリオに通常・例外・周期（月次締め・棚卸）の3種類がそろっている
• 各シナリオの期待する結果に、照合する相手（現行の帳票など）が書かれている
• テストデータは本番相当のマスタで、実在の取引先の締め日・掛率を含む
• 参加者の予定が繁忙期を避けて押さえられ、上長の承認がある
• 不具合管理表の項目と、登録から修正確認までの流れが決まっている
• 要望を不具合と分けて扱う手続き（変更管理）が決まっている
• UATの期間・合否と、契約上の検収の関係を確認している

よくある質問

まとめ

ユーザー受入テスト（UAT）は、設計書どおりかを確かめるテストではなく、自社の業務が受注から入金、月次締めまで回るかを発注側が確かめるテストです。合否基準をテストの前に数字で決めて合意すること、シナリオを業務の流れ単位で通常・例外・周期の3種類そろえること、参加者の時間を先に確保すること。この3つを押さえれば、終わりの見えないUATは避けられます。

テスト計画や合否基準を自社でどう決めればよいか迷う場合は、無料診断で現在のプロジェクトの状況を整理し、稼働までに決めておくべきことを確認できます。