ユーザー受け入れテスト（UAT）

ユーザー受け入れテスト（UAT）は、システムを開発したチームではなく、システムを使う人や所有する人が行うテストです。業務ユーザーが本番相当の環境で現実的な作業を行い、そのソフトウェアが自分たちに必要な仕事をこなせるかを判断します。UAT が成功すると正式な承認（サインオフ）で締めくくられ、多くの場合それがリリースのゲート、あるいはベンダーからの契約上の受け入れの条件になります。

例

ある銀行が融資申込システムを刷新します。本番稼働の前に、融資担当者が 1 週間 UAT 環境で現実的な申込を処理します。標準的な個人ローン、連帯申込、収入が不規則な自営業者の申込、そして正しい通知書を生成しなければならない否決案件です。担当者は、ワークフローが実際の業務の進め方に合っているか、レポートが管理者の必要とする内容になっているか、手作業での回避策を強いられる部分がないかを確認します。問題は記録され、プロジェクトチームとトリアージされ、承認の前に修正されるか、受け入れられます。

UAT とシステムテストの違い

	システムテスト	ユーザー受け入れテスト
実施者	QA チーム	業務ユーザー、顧客、プロダクトオーナー
問い	システムは仕様を満たしているか？	実際のニーズを満たしているか？
根拠	要件と設計	業務プロセスと受け入れ基準
焦点	欠陥、エッジケース、非機能面の確認	目的への適合性、実際の文脈での使いやすさ

システムテストにすべて合格しても、UAT で不合格になることはありえます。仕様そのものが間違っていたり不完全だったりするためです。だからこそ UAT は、検証（verification）（「製品を正しく作っているか？」）ではなく妥当性確認（validation）（「正しい製品を作っているか？」）の典型例とされています。

受け入れテストの種類

• アルファテスト: 社内のユーザーが開発元の拠点でテストします。
• ベータテスト: 限られた外部ユーザーが自分たちの環境でテストします。
• 運用受け入れテスト（OAT）: 運用チームがバックアップ、フェイルオーバー、モニタリング、デプロイを確認します。
• 契約・規制の受け入れテスト: 合意した契約条件や法的要件を満たしているかを確認します。

よくある間違い

• UAT で基本的なバグを見つけようとする。 ユーザーがクラッシュに遭遇するなら、システムテストが終わっていなかったということです。UAT は QA が検出すべきだった欠陥ではなく、適合性に集中すべきです。
• シナリオやデータが準備されていない。 業務ユーザーには現実的なデータと明確なシナリオが必要であり、テスターがその作成を手伝うことがよくあります。
• 後回しにしすぎる。 リリース直前の数日に詰め込まれた UAT は、たいてい形だけの承認になってしまいます。