移行プロジェクトのテスト・受け入れ検証（UAT）の進め方

「開発会社からは『テストは完了しています』と報告を受けたが、本当に現場の業務で使えるのか不安が残る」——システム移行プロジェクトの終盤で、こうした感覚を持つ担当者は少なくありません。開発側の単体テスト・結合テストが通っていても、それは仕様通りに動くことの確認であり、実際の業務フローで問題なく使えるかどうかとは別の話です。この「業務で使えるか」を確認する最後の工程が、受け入れ検証（UAT：User Acceptance Test）です。

UATを形だけの儀式にしてしまうと、本番稼働後に「この画面ではこの業務ができない」「この項目が必須なのに入力できない」といった問題が次々と発覚し、現場の混乱と開発会社への問い合わせ対応に追われることになります。この記事では、移行プロジェクトにおけるUATの進め方を、シナリオ設計から判定基準の決め方まで解説します。

この記事の要点（30秒でわかるまとめ）

• UATは**「仕様通りか」ではなく「業務で使えるか」を現場目線で確認する工程**である
• テストシナリオは実際の業務の流れに沿って作成することが重要
• 合格・不合格の判定基準をテスト開始前に明文化しておく必要がある
• 例外パターン・繁忙期のイレギュラー対応もシナリオに含めておくことが望ましい

UATと開発側テストの違いを理解する

結論：開発会社が行う単体テスト・結合テストは仕様通りに動作するかの確認であり、UATは実際の業務担当者が日常業務の流れに沿って操作し、業務が問題なく回るかを確認する工程です。

この違いを曖昧にしたまま「テストは開発会社に任せておけば大丈夫」と考えてしまうと、仕様書通りには動いているものの現場の実態と合っていないシステムが、そのまま本番稼働してしまうリスクがあります。UATは発注側の業務担当者が主体となって実施するテストであるという前提を、プロジェクトの早い段階で関係者全員と共有しておくことが重要です。移行プロジェクト全体のスケジュール感については、システム移行の期間はどれくらい？規模別の目安と短縮のポイントもあわせて参考にしてください。

テストシナリオは業務の流れに沿って作る

結論：UATのテストシナリオは、画面や機能の単位ではなく、実際の業務がどのような順序で発生するかという流れに沿って作成することで、実務上の不備を発見しやすくなります。

例えば見積作成の業務であれば、「見積書を1件作成する」という単発のテストだけでなく、「問い合わせを受ける→見積を作成する→社内承認を得る→顧客に送付する→修正依頼を受けて再作成する」といった一連の流れを通してテストすることで、単独の機能テストでは見つからない不備に気づけます。テストシナリオの作成は、要件定義の段階で洗い出した業務フローをベースにすると効率的です。要件定義の進め方については、現場を巻き込む要件定義のやり方で解説しています。

例外パターン・繁忙期のイレギュラーも含める

結論：正常な業務フローだけでなく、入力ミスの修正や承認差し戻しといった例外パターン、繁忙期に発生しやすいイレギュラーな操作もシナリオに含めておくことをおすすめします。

日常的に発生する例外的な操作ほど、開発時の想定から漏れやすい傾向があります。現場の担当者にヒアリングし、「実際によくあるが仕様書には書かれていない」操作をシナリオに反映しておくことで、本番稼働後のトラブルを減らせます。

判定基準をテスト開始前に決めておく

結論：「何をもって合格とするか」という判定基準を、UATを開始する前に関係者間で明文化しておくことが、後々の認識齟齬を防ぐうえで欠かせません。

判定基準が曖昧なまま進めると、「軽微な不具合だから許容範囲」と考える人と「業務に支障が出るので修正必須」と考える人の間で意見が割れ、リリース判断が難航することがあります。以下のように不具合の重要度を事前に分類しておくと、判定がスムーズになります。

不具合が見つかった際の対応方針は、新旧システムの並行稼働計画とも関わってきます。切り戻し計画の立て方については、新旧システムの並行稼働と切り戻し計画の立て方を参考にしてください。

誰がUATを実施すべきか

結論：UATは、実際にそのシステムを日常的に使う現場の担当者が実施することが望ましく、IT部門やプロジェクト事務局だけで完結させないことが重要です。

管理部門の担当者だけでテストを行うと、現場特有の使い方や細かな業務ルールが反映されず、本番稼働後に「聞いていなかった使い方」が次々と出てくることがあります。複数部署が関わる移行プロジェクトでは、各部署から最低1名はUATの実施者を選出しておくと、部署ごとの業務の違いを漏れなく確認できます。移行プロジェクトの社内体制づくりについては、移行プロジェクトの社内体制づくり：担当者は何をすべきかで詳しく解説しています。

よくある質問（FAQ）

Q. UATにはどれくらいの期間を見込めばよいですか？ A. システムの規模やシナリオ数によって異なるため一概には言えませんが、致命的な不具合が見つかった場合の修正・再テストの期間も見込んでおくことをおすすめします。

Q. UATで見つかった不具合はすべて修正してからリリースすべきですか？ A. 重要度に応じた判定基準をあらかじめ決めておき、致命的・重要な不具合は修正、軽微な不具合はリリース後の改善対応とするなど、優先順位をつけて判断するのが現実的です。

Q. 現場の担当者がテストに時間を割けない場合はどうすればよいですか？ A. UATの重要性を事前に説明し、業務時間内に一定のテスト時間を確保できるよう、経営層やマネジメント層の協力を得ることをおすすめします。

Q. UATで問題がなければ、本番稼働後は何もチェックしなくてよいですか？ A. UATはあくまで限られたシナリオでの検証であるため、本番稼働直後も一定期間は運用状況を注視し、想定外の問題がないか確認することをおすすめします。

まとめ

UATは、仕様通りに動くかではなく、実際の業務で使えるかを確認する重要な工程です。業務の流れに沿ったシナリオ設計、例外パターンの網羅、そして判定基準の事前明文化という3点を押さえることで、本番稼働後のトラブルを大きく減らすことができます。

Irwin&co株式会社では、開発の初期段階から動くデモをお見せしながら要件を具体化していくため、UATの段階で大きな認識齟齬が発覚するリスクを抑えられることが特徴です。移行プロジェクトのテスト設計でお悩みの場合は、お問い合わせからご相談ください。開発事例はこちらでもご紹介しています。