受入テスト（UAT）の進め方｜発注者が確認すべきこと

開発会社から「テストは完了しました」と言われても、それで発注者の確認が終わるわけではありません。受入テスト（UAT：User Acceptance Testing）は、発注者が自分たちの業務で使えるかを確かめる最後の工程です。この記事では、受入テストの進め方を、テスト工程の全体像と発注者の担当範囲、シナリオの作り方、現場の巻き込み方、不具合の報告と再テストの順に説明します。

受入テストの進め方の前に：4つのテスト工程と発注者の担当範囲

システム開発のテストは、一般に次の4段階で進みます。前の3段階は開発会社が主に担当し、最後の受入テストを発注者が主に担当します。

開発会社のテストは「設計書どおりに作れているか」を確かめるものです。一方、受入テストは「その設計で本当に業務が回るか」を確かめます。設計書どおりに動いていても、実際の業務の流れに当てはめると使えない、ということは起こり得ます。

受入テストは発注者の責任で行うものですが、すべてを自力でやる必要はありません。テスト計画づくりやテスト環境の準備、テストデータの作成などは開発会社に支援を依頼できます。その場合は見積の段階で、受入支援の工数が入っているかを確認してください。

受入テストに合格したあとに検収（納品物を確認して受け取る手続き）に進みます。検収の判断基準は検収の進め方と注意点で説明しています。

受入テストのシナリオの作り方

受入テストでは、画面の項目を一つずつ確認するより、業務の流れに沿った「シナリオ」で確認する方が、実際の問題を見つけやすくなります。

シナリオは次の手順で作ります。

1. 対象の業務を書き出す: 「問い合わせを受けて見積を出す」「月末に売上を集計する」など、システムを使う業務を一覧にします。
2. 業務ごとに流れを書く: 誰が、どの画面で、何を入力し、どんな結果になれば正しいかを順に書きます。
3. 例外のケースを足す: 入力ミス、途中でのキャンセル、権限のない人の操作、データが0件のときなど、普段と違う場面を加えます。
4. 合格の基準を書く: 「金額が既存の帳票と一致する」「3秒以内に表示される」など、誰が見ても判断できる形にします。

シナリオの例を挙げます。

合格の基準を事前に決めておくことが、受入テストで最も大切な点です。基準があいまいだと、不具合なのか仕様なのかで開発会社と意見が分かれやすくなります。要件定義の段階で受入の基準まで話しておくと、後の工程が楽になります（要件定義で発注者がやること）。

テストの環境とデータを準備する

受入テストは、本番とは別のテスト用の環境で行うのが基本です。本番の環境で試すと、テストの操作で実際のデータを書き換えたり、顧客にメールが届いてしまったりするおそれがあります。

テストに使うデータも事前に準備します。実際の顧客情報をそのまま使うのではなく、個人が特定できない形に加工したデータや、テスト用に作ったデータを使ってください。件数の多いデータでの動作も確認したい場合は、本番に近い件数のテストデータを開発会社に用意してもらうよう依頼します。

テストの期間も、開発の計画段階で確保しておきます。開発が遅れると受入テストの期間が削られがちですが、ここを短くすると本番で問題が見つかることになります。

現場の担当者を巻き込む方法

受入テストは、情報システム担当や発注窓口だけで行うと、実際の使い勝手の問題を見落としがちです。普段その業務をしている現場の担当者に参加してもらいましょう。

現場を巻き込むときのポイントは次のとおりです。

• 早めに日程を押さえる: 繁忙期と重なると参加できません。テスト期間は開発の計画段階で決め、現場の上長にも了解をもらっておきます。
• 操作説明を短く行う: 最初に15〜30分程度の説明会を開き、テストの目的と記録の仕方を伝えます。
• 「いつもの仕事」をしてもらう: シナリオに加えて、普段の業務を一通り試してもらう時間を取ると、想定外の使い方が見つかります。
• 感想と不具合を分けて記録する: 「使いにくい」という感想と「動かない」という不具合は、扱いが違います。記録の欄を分けておくと整理しやすくなります。

現場から出た「使いにくい」という声は、すべてを今回の範囲で直す必要はありません。契約の範囲内で直すもの、次の改修に回すものを、発注者が優先順位をつけて判断します。追加の要望の扱いは仕様変更と追加費用も参考にしてください。

不具合を見つけたときの報告と再テスト

不具合を見つけたら、開発会社が再現できる形で報告することが大切です。次の項目をそろえると、修正が早くなります。

報告はメールや口頭ではなく、課題管理表などの一か所にまとめます。修正されたら、その箇所だけでなく、関係する周辺の機能も再テストしてください。一か所の修正が別の機能に影響することがあるためです。

重要度の高い不具合が残っている状態で本番の利用を始めるかどうかは、発注者が判断します。回避策があり業務が止まらないなら先に進める、という判断もあり得ます。その場合は、いつまでに直すかを書面で残しておきましょう。

受託開発の現場から

受託開発の現場で実践されている受入テスト・本番投入の進め方から、発注者にも役立つものを紹介します。

• 受入テストの担当を見積で明確にする: 受入テストは発注者が主担当、開発会社は支援という分担を提案書に明記し、テストや受入支援の工数を見積に計上しています。誰がやるのかがあいまいなまま本番を迎えないためです。
• 決済はテストモードで最後まで確かめる: 決済まわりの検証では、決済サービスのテストモードを使い、実際には課金せずに返金の処理まで確かめます。
• 新旧の数字が一致するまで確認する: システムを置き換えるときは、新旧の帳票の数値が一致するまで確認します。あわせて、検証環境でデータベースの復元や切り戻しを実際に1〜2回試しておきます。
• 小さく始めて広げる: 多店舗で使うシステムでは、まず数店舗で使ってもらい、問題がなければ中規模、全店と段階的に広げています。AIの認識精度のように環境で結果が変わるものは、試験導入で測った実測値をもとに受入の基準を合意します。

まとめ

• 受入テストは、発注者が「業務で使えるか」を確かめる最後のテストです。
• シナリオは業務の流れに沿って作り、例外のケースと合格の基準まで書きます。
• 現場の担当者に早めに参加してもらい、感想と不具合を分けて記録します。
• 不具合は再現できる形で一か所にまとめて報告し、修正後は周辺も再テストします。

受入テストでどこまで確認すべきかは、案件の規模や業務によって変わります。FastProposal の無料AI相談では、案件の内容を整理し、開発の範囲や費用の目安を数分で確認できます。発注前の準備にお役立てください。