ソフトウェア開発の委託で「テスト済み」と報告されても、受入側には確認したいことが残ります。どの業務を、どのデータで検証し、何をもって正しいと判断したのでしょうか。日本のSIer、CTO、PM、DX推進担当者にとって、ユーザー受入テスト（UAT）の前にテストデータと期待結果をそろえることは、実務的な準備の一つです。
1. 業務上の判断からシナリオを考える
確認する画面を並べるだけでなく、利用者が行う判断を起点にします。どの申請を承認するのか、どの帳票を照合するのか、誰に案件を引き継ぐのか。シナリオごとに実施者、開始時の状態、操作、受入可能な結果を記載します。お客様は業務上の意味を確認し、開発側はその結果がシステム上でどのように表れるかを明確にします。
2. 照合できる共通のテストデータを用意する
両者で、次の項目をまとめたテスト一式を確認することを提案します。
- 識別番号とバージョンを付けた入力データ。
- 合意した権限を持つテスト用アカウント。
- 各シナリオの期待結果と、その業務上の根拠。
- 準備担当者、確認担当者、データを確定する時点。
業務の特徴を再現した架空データを使う方法もあります。実データが必要な場合は、共有する範囲と機微情報の扱いを事前にすり合わせます。それぞれが独自にデータを変更し、条件の異なる結果を比較する状態は避けたいところです。
3. 再確認できる条件を残す
テストの証跡とともに、ソフトウェアのバージョン、環境、抽出条件、実施日時を記録します。状態が変わる業務では、合意した開始状態にテストデータを戻す方法も用意します。差異が出たら、まず条件を照合し、不具合なのか、期待結果が曖昧なのか、データが適切でないのかを確認します。日越のチームが具体的な根拠に基づいて話すための準備です。
4. 架空の例：月次受注レポートの受入確認
ある企業が月次受注レポートを確認するとします。架空データは34件の受注で、うち3件は取消済みです。両者は、受注月を基準に有効な31件のみを集計し、全件を閲覧できるアカウントで確認する、と合意します。
結果が30件だった場合、確認者はシナリオID、データのバージョン、抽出条件、不足している受注の一覧を残します。アカウントの閲覧範囲が一部門に限られているなら、集計不具合と判断する前に権限を確認します。この例は、TECHNESTの実際の案件や成果を示すものではありません。
5. 受入判断の担当者を明確にする
差異ごとに担当者、対応方針、再確認日を決めます。お客様側は業務結果の確認者を、開発側は修正対応の取りまとめ役を定めます。未合意の項目は分けて記録し、チェック表を埋めるために合格扱いにしません。残課題がある場合は、影響、暫定対応、受入可否の判断権限を持つ人を記載し、両者が合意した条件に沿って判断します。
6. TECHNESTと受入判断の根拠を整える
TECHNESTは、日本市場での長年の協業を通じて、業務システムの設計・開発、レガシーシステムの刷新、日本のコンサルティングパートナーとの連携に取り組んできました。その経験を背景に、プロジェクトの終盤を待たず、データ、確認責任、引き渡す証跡を早期に話し合うことを提案します。
DELIVERYサービスをご覧いただくか、貴社のシステムに合うUATの準備についてTECHNESTへご相談ください。
