UATとは？システム開発の最終段階でユーザーが本番同等の環境で行う受入テスト

UATとは？ざっくりと3行で

User Acceptance Testingの略で、システムが発注者・エンドユーザーの要件・業務フローを満たしているかをユーザー自身が本番に近い環境で検証する最終段階のテストのこと。受入テスト・受け入れテストとも呼ばれる
開発側が行うシステムテスト（技術的な動作検証）とは異なり「実際に使う人が実際の業務フローで試して問題なく使えるか」を確認することで本番リリースへのゴーサインを出す最後の検証プロセスだ
UATはアジャイル開発・ウォーターフォール開発どちらにも存在する概念で、UATで合格（Acceptance）することがリリース判断の条件になることが多い

【深掘り】これだけ知ってればOK！
よくある誤解
1. 開発者がテストすればUATは不要だと思っている
2. UATは開発の最後に一度やれば十分だと思っている
会話での使われ方
【まとめ】3つのポイント
よくある質問
【出典】参考URL

【深掘り】これだけ知ってればOK！

UATの実施プロセスを整理しよう。UATシナリオの作成：実際の業務フローに基づいたテストシナリオを発注者・ユーザーと協力して作成する。テスト環境の準備：本番に近いデータ・設定を用意したUAT環境を構築する。UATの実施：実際のエンドユーザーがシナリオに沿って操作してバグ・要件の不適合・使いにくさを報告する。不具合の修正と再テスト：報告された問題を修正して再度確認する。受入承認：発注者がUATの結果に合格のサインをする。

UATのよくある問題と対策を理解しよう。UATで大量のバグが出る：UATはシステムテスト完了後に行うべきで、開発側のテストが不十分なままUATに入ると発注者・ユーザーの工数を無駄に消費する。開発側でのテストを徹底してからUATに入ることが重要だ。UATシナリオが曖昧：要件定義の段階でUATシナリオの原型を作成することでテストの網羅性を確保する。

UATとシステムテストの違いを理解しよう。システムテスト（ST）：開発者・QAエンジニアが技術的な動作要件・性能・セキュリティを検証する。UAT：発注者・エンドユーザーが業務要件の適合性・使いやすさ・実際の業務フローでの動作を検証する。どちらも必要で役割が異なる。

アジャイル開発でのUATの位置付けを理解しよう。スクラムでは各スプリントの終わりにスプリントレビューがあり、プロダクトオーナーが成果物を確認するが、これは毎スプリントの小さなUATとも言える。リリース前の最終UATと組み合わせることで継続的な受入確認ができる。BDD（振る舞い駆動開発）では受入基準（Acceptance Criteria）がUATシナリオの原型になる。

DX推進が進む中でUATのデジタル化が注目されている。従来の紙ベースのテスト結果記録から、TestRail・Zephyr・Jiraなどのテスト管理ツールを使ったUAT管理に移行することで、テスト結果のトレーサビリティ・進捗の可視化・エビデンスの保管が効率化できる。

よくある誤解

開発者がテストすればUATは不要だと思っている

開発者は技術的な動作を検証するが「実際の業務フローで正しく使えるか」という視点はエンドユーザーしか持てない。開発者が正しく動くと確認したシステムでも、実際の業務に合わない機能・UIのわかりにくさが発覚するのはUATで初めて気づくことが多い。

UATは開発の最後に一度やれば十分だと思っている

アジャイル開発では各スプリントに小さなUAT（スプリントレビュー）を実施して早期に問題を発見することが推奨される。最終UATで大量の問題が出てからの修正は手戻りコストが高いため継続的な受入確認が重要だ。

会話での使われ方

システムテストが完了したのでUATに移行します。発注者の業務部門の方に実際の業務シナリオで操作してもらいましょう。

プロジェクトマネージャーがUATフェーズへの移行を指示している場面。

UATでユーザーが「この画面では日次集計がこのデータの順序で出てくるはずなのに違う」という問題を指摘しました。要件定義の段階で見落としていたシナリオです。

QA担当者がUATでユーザーが発見した要件の不一致を報告している場面。

UATの合格基準を事前に合意しておきましょう。「クリティカルな不具合ゼロ・軽微な不具合5件以内で受入承認」という基準を発注者と決めてからテストを開始しましょう。

PMがUATの合格基準を事前に明確化する重要性を説明している場面。

【まとめ】3つのポイント

エンドユーザー・発注者が本番同等環境で業務フローの適合性を最終検証するテスト：開発側のシステムテストとは異なる「実際に使う人が実際の業務で試す」という視点から要件の不適合・UIの使いにくさ・業務フローの不整合を発見する最終品質確認の場だ
UATシナリオは要件定義の段階から作成してテストの網羅性を確保する：要件定義でUATシナリオの原型を作成することでシステム開発全体を通じて「受入基準」が明確になり開発・テスト・リリース判断の基準が統一される
テスト管理ツールでUATのエビデンス・進捗を可視化して承認プロセスを効率化：TestRail・Jiraなどのテスト管理ツールを使うことで紙ベースのUAT管理から脱却してテスト結果のトレーサビリティ・進捗の可視化・受入承認の記録が効率化できる

よくある質問

Q UATと受入テストは同じですか？: A

はい。UAT（User Acceptance Testing）は「受入テスト」「受け入れテスト」とも呼ばれる同義語です。

Q UATで見つかったバグはいつ直すべきですか？: A

クリティカルなバグ（業務が止まる・データが壊れる）はUAT完了前に必ず修正します。軽微なバグは発注者と協議してリリース後の修正対応にすることもあります。

Q アジャイル開発でUATはどこに位置づけられますか？: A

各スプリントのスプリントレビューが小さなUATです。BDD（振る舞い駆動開発）では受入基準（Acceptance Criteria）がUATシナリオと連動します。

Q UATの合格基準はどうやって設定しますか？: A

発注者と合意の上で「クリティカルな不具合ゼロ・重要機能の動作確認100%・軽微な不具合○件以内」などの基準を事前に設定します。

【出典】参考URL

https://www.istqb.org/ ：ISTQB（国際ソフトウェアテスト資格委員会）
https://jstqb.jp/ ：JSTQB（日本ソフトウェアテスト資格委員会）
https://e-words.jp/w/%E5%8F%97%E5%85%A5%E3%82%8C%E3%83%86%E3%82%B9%E3%83%88.html ：IT用語辞典「受入テスト」