受入テスト（UAT）の進め方と検収のチェックポイント
「開発会社から『受入テストをお願いします』と言われたが、何をどこまで確認すればいいのかわからない」「検収書にサインした後で不具合が見つかったらどうなるのか」。受入テストは発注者が主体となって行う数少ない工程ですが、進め方がわからないまま形だけで終わってしまうケースも見られます。
この記事では、受入テスト（UAT）の意味と開発会社のテストとの違い、準備から検収までの進め方、テストケースの作り方、検収前に確認すべきチェックポイントを解説します。稼働後のトラブルを防ぐために、発注者が押さえておくべき実務のポイントをまとめました。
- 受入テストとは、発注者が要件どおりに動き、業務で使えるかを確認するテストです。
- 開発会社のテストが「仕様どおりか」を見るのに対し、受入テストは実際の業務の流れと実データで確認します。
- 進め方は計画→テストケース作成→実施→不具合対応→検収の5段階が基本です。
- 検収後の不具合は契約不適合責任の範囲で対応されますが、期間と範囲を契約で確認しておくことが重要です。
目次
受入テスト（UAT）とは？
受入テストとは、システム開発の最終段階で、発注者が納品されるシステムを実際の業務の観点から確認し、受け入れてよいかを判断するためのテストです。英語ではUser Acceptance Testing（UAT）と呼ばれ、「ユーザー受入テスト」「受け入れ試験」ともいいます。受入テストの結果をもとに、発注者は検収（納品物を確認し、受け取ったことを認める手続き）を行います。
検収が完了すると、請負契約では代金の支払い義務が確定するのが一般的です。つまり受入テストは、発注者が支払いの前に品質を確かめる最後の機会でもあります。
開発会社のテストとの違い
| テスト | 実施者 | 確認すること |
|---|---|---|
| 単体テスト | 開発会社 | 機能や部品が個別に正しく動くか |
| 結合テスト | 開発会社 | 機能同士をつないだときに正しく動くか |
| 総合テスト | 開発会社 | システム全体が設計・要件どおりに動くか |
| 受入テスト | 発注者 | 実際の業務で使えるか、要件を満たしているか |
開発会社のテストは設計書や仕様書に照らして正しく動くかを確認しますが、業務の実態を完全に知っているわけではありません。「仕様どおりだが業務では使いにくい」「月末の特殊な処理ができない」といった問題は、業務を知る発注者でなければ見つけられません。
受入テストの進め方5ステップ
- テスト計画を立てる範囲、期間、担当者、環境、合格基準を決めます。開発会社と早めに相談しましょう。
- テストケースを作る実際の業務シナリオに沿って、確認する操作と期待する結果を一覧にします。
- テストデータを準備する過去の実データや、例外パターンを含むデータを用意します。個人情報の扱いにも注意します。
- テストを実施し、不具合を報告する結果を記録し、不具合は再現手順と画面をつけて開発会社に伝えます。
- 修正を確認し、検収する修正内容を再テストし、合格基準を満たしたら検収書を発行します。
受入テストの期間と体制の目安
受入テストの期間は、中規模の業務システムで2〜4週間程度、基幹システムでは1〜2か月程度を見込むことが多いです。実施するのは実際にシステムを使う部署の担当者が中心で、窓口担当者が結果を取りまとめます。繁忙期と重なると十分な時間が取れないため、開発スケジュールを組む段階で時期を調整しておきましょう。
テストケースの作り方
テストケースは、機能ごとではなく業務の流れ（シナリオ）ごとに作るのがポイントです。たとえば「受注登録画面のテスト」ではなく、「電話で受けた注文を登録し、在庫を引き当て、出荷指示を出して請求書を発行する」という一連の流れで確認します。
| No. | 業務シナリオ | 操作 | 期待する結果 | 結果 |
|---|---|---|---|---|
| 1 | 通常の受注 | 得意先・商品・数量を入力して登録 | 単価が自動表示され、在庫が引き当てられる | OK／NG |
| 2 | 在庫不足の受注 | 在庫を超える数量で登録 | 警告が表示され、残数が確認できる | OK／NG |
| 3 | 月末締め | 締め処理を実行 | 得意先別の請求額が正しく集計される | OK／NG |
通常の業務だけでなく、キャンセル、返品、締め日をまたぐ処理、入力ミスの訂正など、例外的な業務を必ず含めましょう。要件定義書や業務フロー図をもとに作ると漏れを防げます。
検収前のチェックポイント
- 要件の充足：要件定義書に記載した機能がすべて実装されている。
- 業務シナリオ：主要な業務と例外処理が最後まで通る。
- データの正確さ：集計、計算、帳票の数値が旧システムや手計算と一致する。
- 性能：実際のデータ量で、画面の表示や処理に実用上問題のない速度が出る。
- 権限：利用者ごとに見られる情報・操作できる機能が正しく制限されている。
- 移行データ：旧システムから移したデータの件数と内容に漏れがない。
- 納品物：マニュアル、設計書、ソースコードなど契約上の納品物がそろっている。
- 未解決事項：残っている不具合や課題の対応方針と期限が合意されている。
受入テストでよくある失敗
うまくいく受入テスト
- 現場担当者が実データで操作する
- 業務シナリオと例外処理を網羅する
- 不具合を再現手順つきで記録する
- 合格基準を事前に決めている
失敗しやすい受入テスト
- 窓口担当者だけが画面を少し触って終わる
- 通常の処理しか確認しない
- 口頭で不具合を伝え、記録が残らない
- 稼働日に間に合わせるため検収を急ぐ
受入テストで見つかった指摘が「不具合」なのか「仕様変更」なのかで揉めることもあります。判断の拠り所になるのは要件定義書と設計書です。合意した内容を文書に残しておくことが、ここで効いてきます。
不具合の報告の仕方
受入テストで見つけた不具合は、開発会社が再現して原因を特定できるように報告することが大切です。「動かない」「おかしい」だけでは調査に時間がかかり、修正が遅れます。次の項目を記録して一覧で共有しましょう。
| 項目 | 記入例 |
|---|---|
| 発生日時・画面 | 10月5日14時、受注登録画面 |
| 操作手順 | 得意先A社を選択し、商品Bを数量10で登録ボタンを押した |
| 期待した結果 | 単価1,200円が表示される |
| 実際の結果 | 単価が0円で表示された（画面の画像を添付） |
| 重要度 | 高（業務が止まる）／中（回避策あり）／低（表示の軽微な問題） |
重要度をつけておくと、修正の優先順位を開発会社と合意しやすくなります。また、報告内容が不具合なのか要望なのかを区別して記録しておくと、後の費用の協議もスムーズです。
よくある質問
- 受入テストは開発会社に代行してもらえますか？
- テスト計画やテストケース作成の支援は依頼できますが、業務で使えるかの最終判断は発注者が行う必要があります。実際に操作するのは、システムを使う部署の担当者が望ましいでしょう。
- 受入テストで不具合がゼロでないと検収してはいけませんか？
- 業務に支障のない軽微な不具合が残っていても、対応方針と期限を合意したうえで検収することは一般的です。業務が止まる重大な不具合がある場合は、修正を確認してから検収しましょう。
- 受入テストにはどれくらいの期間が必要ですか？
- 中規模の業務システムで2〜4週間程度、基幹システムで1〜2か月程度が目安です。不具合の修正と再テストの期間も含めて計画しておきましょう。
まとめ
受入テストは、発注者が実際の業務の流れと実データでシステムを確認し、受け入れてよいかを判断する工程です。業務シナリオに沿ったテストケースを作り、現場担当者を巻き込んで十分な期間を確保すること、検収前にチェックポイントと契約上の保証範囲を確認することが、稼働後のトラブルを防ぐ鍵になります。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
