受入テストの観点チェックリストとUATシナリオの書き方

受入テスト（UAT：User Acceptance Test）とは、発注側（システムを使う側）が、納められたシステムで自分たちの業務が回るかを確かめ、受け取ってよいかを判断するテストです。 画面の項目を1つずつ調べるのではなく、業務の流れに沿って最初から最後まで通して確認します。

この記事では、観点チェックリスト、UATシナリオのテンプレートと記入例、合否判定の基準表、検収書の項目一覧を、そのまま使える形で載せます。題材は架空の受注管理システムです。

この記事の結論

• 確認するのは発注側、単位は業務の流れです。 「受注を登録して出荷指示を出し、請求書を出すまで」を1本のシナリオにします。
• 合否の基準はテストを始める前に合意します。 終わってから決めると、同じ結果でも判断が分かれます。
• 合否は「不具合の重要度ごとの残件数」で決めます。 例：重要度Aが0件、Bが0件または回避手順と修正日に合意済み。
• 不具合と要望を分けます。 合意した仕様どおりに動かないものが不具合、仕様に無いものは要望（変更依頼）です。
• 証跡を残します。 画面の写しや出力した帳票が、検収の根拠になります。

確認環境：掲載したチェックリストとテンプレートは、タブ区切りの列数がそろっていること、項目数が本文の記載と一致すること、合否判定の例の集計を Python 3.11.15 で点検しています。確認日 2026-10-05。

受入テストの早見表

受入テストの進め方（6つの手順）

受入テストの観点チェックリスト（7分類35項目）

各分類5項目です。自分のシステムに無い項目は「対象外」と書いて残すと、確認漏れではないことが後から分かります。

表計算ソフトに貼れるタブ区切り版

セルA1に貼り付けると、結果と確認日を書き込める表になります。

No  分類  確認する観点  確認の方法   結果  確認者 確認日 備考
1   業務フロー   日次の業務を最初から最後まで通せる   業務シナリオを通しで実施                
2   業務フロー   月次・年次の締め処理を通せる  日付を進めたデータで実施                
3   業務フロー   取消・訂正・差し戻しの流れを通せる   例外のシナリオを実施              
4   業務フロー   部門をまたぐ引き継ぎが途切れない    担当者を替えて続きを実施                
5   業務フロー   前後のシステムとのデータの受け渡しができる   連携ファイルを相手側で取り込む             
6   帳票  帳票の項目・並び順・改ページが様式どおり    出力して現行の帳票と見比べる              
7   帳票  合計・小計・端数処理が手計算と一致する 3件以上を手計算と照合             
8   帳票  件数が多いとき、0件のときも出力できる 最大件数と0件で出力              
9   帳票  印刷・PDF・CSVの出力が利用者の端末でできる    利用者の端末とプリンターで出力             
10  帳票  宛名・日付・社名などの固定の文言が正しい    出力物を読み合わせる              
11  権限  役割ごとに、使える機能だけがメニューに出る   役割別のアカウントでログイン              
12  権限  他部門のデータが見えない・変更できない 他部門のデータを検索、URLを直接入力             
13  権限  承認者だけが承認できる 一般の利用者で承認を試す                
14  権限  異動・退職を想定した権限の変更ができる 管理者画面で変更して再ログイン             
15  権限  操作の記録が残り、誰がいつ行ったか追える    操作後に記録を確認               
16  データ移行   移行前後で件数が一致する    現行と新システムの件数を比べる             
17  データ移行   金額・数量の合計が一致する   合計値を比べる             
18  データ移行   抜き取ったデータの内容が一致する    30件ほどを項目単位で照合               
19  データ移行   途中の状態のデータを新システムで続けられる   処理の途中のデータで続きを実施             
20  データ移行   文字（旧字体、記号、長い名称）が正しく表示される    該当するデータを画面と帳票で確認                
21  性能  よく使う画面が合意した時間内に表示される    本番に近い件数で時間を計る               
22  性能  利用が集中する時間帯の人数で操作できる 複数人で同時に操作               
23  性能  夜間の処理が翌朝の業務開始までに終わる 本番に近い件数で実行時間を計る             
24  性能  大きな帳票・CSVの出力が待てる時間で終わる  最大件数で出力             
25  性能  利用者の端末・回線で支障なく動く    拠点の端末から操作               
26  運用  利用者の追加・変更・停止が手順書どおりにできる 管理者が手順書を見て実施                
27  運用  マスタの変更が業務に反映される 変更後にシナリオを実施             
28  運用  障害時の連絡先と手順が決まっている   手順書を読み合わせる              
29  運用  バックアップからデータを戻せる 検証環境で戻す手順を実施                
30  運用  問い合わせの受付から回答までの流れが決まっている    模擬の問い合わせで流れを確認              
31  マニュアル   手引きだけで基本の操作を完了できる   初めての人が手引きを見て操作              
32  マニュアル   画面の写しと文言が納品された版と一致する    画面と見比べる             
33  マニュアル   エラーが出たときの対処が載っている   表示されるメッセージで引く               
34  マニュアル   管理者向けの手順が載っている  管理者が手順どおりに実施                
35  マニュアル   用語が業務で使っている言葉と一致する  業務担当者が読み合わせる                

UATシナリオの書き方

シナリオを起こす手順

1. 業務フローの「開始」と「終了」を決める。 例：受注の連絡を受ける〜請求書を出す。
2. 流れを基本・例外・周期の3種類に分ける。 基本（いつもの流れ）、例外（取消・訂正・在庫不足）、周期（月次の締め）。
3. 登場する役割を書き出す。 営業担当、承認者、出荷担当など。役割ごとにアカウントを用意します。
4. 手順を「誰が・どの画面で・何を入力して・何を押すか」で書く。
5. 期待結果を、見て判断できる形で書く。「正しく登録される」ではなく「受注一覧に状態『承認待ち』で1行表示される」。
6. 使うデータを決めて書く。 取引先、商品、数量、日付を具体的な値にします。

シナリオの本数の目安は、基本の流れ1本につき例外2〜3本です。全部の組み合わせを試すのは開発側のテストの役割で、受入テストは「業務でよくある流れ」と「起きたら困る流れ」に絞ります。

UATシナリオのテンプレート

# UATシナリオ

| 項目 | 内容 |
|---|---|
| シナリオID | |
| シナリオ名 | |
| 業務 | |
| 種類 | 基本／例外／周期 |
| 優先度 | 高／中／低 |
| 実施者（役割） | |
| 実施日 | |

## 前提
- 使うアカウント：
- 使うデータ：
- 事前の状態：

## 手順と結果
| No | 役割 | 手順 | 期待結果 | 実際の結果 | 判定 | 証跡 |
|---|---|---|---|---|---|---|
| 1 | | | | | | |
| 2 | | | | | | |

## 判定
| 項目 | 内容 |
|---|---|
| シナリオの判定 | 合格／不合格／保留 |
| 不具合票の番号 | |
| 確認者 | |
| 確認日 | |

判定の欄には、合格・不合格のほかに「保留」（データや環境の都合で実施できなかった）と「対象外」を使います。空欄のままにしないことで、実施していないのか、実施して問題なかったのかを区別できます。

記入例：架空の受注業務（受注登録から請求書の出力まで）

# UATシナリオ

| 項目 | 内容 |
|---|---|
| シナリオID | UAT-ORD-001 |
| シナリオ名 | 受注登録から請求書の出力まで（基本の流れ） |
| 業務 | 受注業務 |
| 種類 | 基本 |
| 優先度 | 高 |
| 実施者（役割） | 営業担当：田中、承認者：中村、出荷担当：小林 |
| 実施日 | 2026-11-10 |

## 前提
- 使うアカウント：tanaka（営業）、nakamura（営業課長）、kobayashi（出荷）
- 使うデータ：取引先「青空商事」、商品「事務用いす A-100」単価12,000円、在庫20脚
- 事前の状態：青空商事に未出荷の受注が無い

## 手順と結果
| No | 役割 | 手順 | 期待結果 | 実際の結果 | 判定 | 証跡 |
|---|---|---|---|---|---|---|
| 1 | 営業 | 受注登録画面で取引先に「青空商事」、商品に「A-100」、数量に5、納期に11月20日を入力し「登録」を押す | 受注番号が表示され、受注一覧に状態「承認待ち」で1行表示される。金額は60,000円 | 受注番号 R-000123。状態「承認待ち」、金額60,000円 | 合格 | 画面の写し 001-01 |
| 2 | 承認者 | 承認待ち一覧から R-000123 を開き「承認」を押す | 状態が「承認済み」に変わり、営業担当に通知メールが届く | 状態は「承認済み」。メールは3分後に届いた | 合格 | 画面の写し 001-02、メール |
| 3 | 出荷 | 出荷指示一覧で R-000123 を選び「出荷指示書を出力」を押す | 出荷指示書のPDFが出力され、品名・数量5・納期が受注と一致する | 一致 | 合格 | PDF 001-03 |
| 4 | 出荷 | 出荷登録画面で出荷日に11月18日を入力し「出荷済みにする」を押す | 状態が「出荷済み」に変わり、A-100の在庫が15脚になる | 状態は「出荷済み」。在庫は15脚 | 合格 | 画面の写し 001-04 |
| 5 | 営業 | 請求書出力画面で青空商事・11月分を指定し「出力」を押す | 請求書に R-000123 が1行載り、税抜60,000円、消費税6,000円、合計66,000円 | 合計は66,000円。宛名の敬称「御中」が抜けている | 不合格 | PDF 001-05 |

## 判定
| 項目 | 内容 |
|---|---|
| シナリオの判定 | 不合格（手順5） |
| 不具合票の番号 | B-014（重要度C） |
| 確認者 | 田中 |
| 確認日 | 2026-11-10 |

記入例のポイントです。

• 期待結果に数字が入っている。 60,000円、15脚、66,000円と書いてあるので、誰が見ても同じ判定になります。
• 実際の結果は「一致」だけでなく、見えた値を書く。 手順2の「3分後に届いた」のように、後で基準と比べられる情報を残します。
• 不合格の手順があっても、最後まで進める。 手順5の不具合は重要度Cなので、後述の判定表では合格の範囲に収まります。

シナリオ一覧のタブ区切り版

シナリオが増えたら、一覧で進み具合を管理します。

シナリオID  シナリオ名   種類  優先度 実施者 実施日 判定  不具合票    備考
UAT-ORD-001 受注登録から請求書の出力まで  基本  高   田中  2026-11-10  不合格 B-014   宛名の敬称
UAT-ORD-002 承認者が差し戻し、修正して再申請    例外  高   田中  2026-11-10  合格      
UAT-ORD-003 在庫が足りない数量で受注を登録 例外  高   田中  2026-11-11  合格      
UAT-ORD-004 出荷前の受注を取り消す 例外  中   小林  2026-11-11  合格      
UAT-ORD-005 月次の締めと請求書の一括出力  周期  高   中村  2026-11-12  保留      月末のデータを準備中

合否判定の基準表（不具合の重要度別）

重要度の決め方

重要度は「直すのが難しいか」ではなく、業務への影響で決めます。発注側が付け、開発側と読み合わせて確定します。

合否の判定表

数字は例です。プロジェクトごとに決め、受入テスト計画に書いてテストを始める前に合意します。

判定の例です。シナリオ40本のうち39本を実施し（優先度「高」は18本すべて実施）、不具合が次のとおり残ったとします。

消化率は 39÷40＝97.5% で95%以上、Aは0件、Bは1件で回避の手順あり。判定は条件付き合格です。要望の4件は不具合の数に入れず、変更依頼として別に扱います。

不具合か要望かを分ける質問

受入テスト・システムテスト・運用テスト・検収の違い

受入テストは「確かめる作業」、検収は「受け取りを認める手続き」です。 受入テストの結果が、検収の判断材料になります。検収の期限や、期限までに連絡が無い場合の扱いは契約書の定めによるので、計画を立てるときに契約書を読み、受入テストの期間をその中に収めます。

どれを行うかの判断基準です。

小さなシステムでは、運用テストを受入テストの一部として行うこともあります。その場合は、チェックリストの「運用」の5項目が運用テストに当たります。

検収書に書く項目一覧

検収書は、納品物を受け取ったことを発注側が書面で伝える文書です。一般的な項目の例を挙げます。様式や必須の項目は契約書の定めに従ってください。

受入テストをなめらかに進めるコツ

確かめて分かったこと

• チェックリストは7分類が各5項目、合計35項目でそろえました。 分類ごとの件数を数えると、厚い分類と薄い分類の偏りが見えます。自分用に項目を足すときも、分類別の件数を出すと偏りに気づけます。
• タブ区切りの表は、空欄の列もタブを残す必要があります。 末尾のタブが落ちると、貼り付けた後に列がずれた行と区別が付きにくくなります。掲載した表は全行が同じ列数であることを点検しています。
• 消化率の条件は、全体と優先度別で結果が変わります。 判定の例は全体97.5%で条件を満たしますが、実施できなかった1本が優先度「高」なら不合格の側になります。条件は2段で書くのが確実です。
• 要望を不具合の件数に入れると、判定が変わります。 例の残件は、要望を含めると8件、含めないと4件です。種別を分けて数えることが判定の前提になります。

よくある質問

Q. 受入テストとは何ですか？ A. 発注側が、納められたシステムで業務が回るかを確かめ、受け取ってよいかを判断するテストです。UAT（ユーザー受入テスト）とも呼びます。

Q. 受入テストとシステムテストの違いは何ですか？ A. 実施者と目的が違います。システムテストは開発側が仕様どおりかを確かめ、受入テストは発注側が業務で使えるかを確かめます。

Q. 受入テストと検収の違いは何ですか？ A. 受入テストは確かめる作業、検収は受け取りを正式に認める手続きです。受入テストの結果が検収の判断材料になります。

Q. 受入テストのシナリオは何本くらい作ればよいですか？ A. 業務の基本の流れ1本につき例外2〜3本が目安です。業務が5つなら15〜20本ほどから始め、優先度を付けて高いものから実施します。

Q. 不具合が残っていても合格にできますか？ A. 事前に合意した基準の範囲ならできます。重要度Aが0件で、残るBとCに回避の手順と修正日の合意があれば、条件付き合格として検収書に条件を書きます。

まとめ

• 受入テストは発注側が、業務の流れで確認します。
• 観点は業務フロー・帳票・権限・データ移行・性能・運用・マニュアルの7分類です。
• シナリオは前提・手順・期待結果・実際の結果・判定・証跡で書き、期待結果には具体的な値を入れます。
• 合否は、始める前に合意した判定基準と、不具合の重要度別の残件数で決めます。
• 不具合と要望を分け、要望は変更依頼として扱います。
• 受入テストの結果を根拠に、検収書で受け取りを伝えます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。