本番稼働から1週間。ある製造業の経営者から届いたのは、悲鳴に近い電話だった。新しく導入した受発注システムが、繁忙期の受注データを正しく処理できず、出荷指示が二重に発行される。現場は混乱し、得意先への納品が半日遅れる。原因を辿ると、検収時に確認していなかった「同一顧客からの複数注文が同日に届いた場合の処理」というテストケースが、そもそもテストシナリオに存在していなかった。開発会社に問い合わせると、契約書には「検収完了をもって納品完了とする」の一文があり、追加対応は有償の見積もりからのスタートだった。
これは特別な失敗談ではない。中小企業のシステム導入現場では、驚くほど頻繁に起きている。検収というのは、地味で、後回しにされやすく、しかし取り返しがつかない意思決定の瞬間だ。サインした後に「やっぱり動かない」と言っても、契約上はもう遅い。だからこそ、検収前にどれだけ本気で確認したかが、その後の何年もの業務を左右する。
この記事では、システム導入担当者が検収前に必ず押さえるべき受け入れテスト(UAT)の考え方と、明日から使える実践的なチェックリストを示す。エンジニアではない経営者や担当者でも、自社の業務を守るために何を確認すればいいかが分かるように書いた。
UAT(受け入れテスト)とは何か、開発側のテストと何が違うのか
UATとは User Acceptance Testing、日本語では受け入れテストと呼ばれる。システム開発の最終工程で、発注者側が「このシステムは実際の業務で使えるかどうか」を自らの目で確認する工程を指す。
開発会社は納品前に、単体テスト、結合テスト、システムテストという複数の段階を経てバグを潰していく。これらは「仕様書通りに動くか」を検証するテストだ。プログラムが設計図通りに機能しているかを、開発側の視点でチェックする。
一方でUATは視点がまったく違う。「仕様書通りに動くか」ではなく「自社の業務が実際に回るか」を確認する工程だ。この違いを理解していないまま検収に臨む担当者が非常に多い。開発会社のテストレポートに「全項目パス」と書かれていても、それは仕様書に書かれた範囲の話でしかない。仕様書に書かれていない、現場だけが知っている例外処理やイレギュラー対応は、開発側のテストでは検証されようがないのだ。
つまりUATは、開発会社の仕事の続きではない。発注者にしかできない、発注者の責任で行う工程だ。ここを他人任せにした瞬間、システムは「動くけれど、使えない」ものになるリスクを抱える。
検収前に確認すべき7つのチェック項目
UATで何を見るべきか、抽象論ではなく具体的な確認項目として整理する。以下は多くの導入現場で実際に問題が発生してきたポイントだ。
1. 実際の業務フロー通りに一気通貫で動くか
個別の画面や機能が動くことと、業務が最初から最後まで通ることはまったく別物だ。受注入力から始まり、在庫引当、出荷指示、請求書発行、入金消込までを、実際の担当者が普段の手順で最初から最後まで一度通してみる。途中で1つでも手作業の迂回が必要になったら、それは未完成のサインだ。
2. 異常系・エッジケースへの対応
正常な入力に対してシステムが動くのは当たり前だ。確認すべきは、ありえないはずの入力、想定外の操作に対する挙動だ。数量にマイナスを入れたらどうなるか、必須項目を空欄のまま送信したらどうなるか、同じ処理を二重にクリックしたらどうなるか。冒頭の事例のように「同日に同じ顧客から複数注文が来る」といった、頻度は低いが必ず発生するケースを、自社の業務履歴を1年分振り返って洗い出しておく。
3. 権限設定とアクセス制御
誰が何を見られて、何を編集できるかは、業務のガバナンスそのものだ。パート従業員が単価や粗利を見られる状態になっていないか、退職予定者のアカウントが適切に無効化される設計になっているか、承認権限を持つべき役職者に承認ボタンが実際に表示されるか。役職ごとにログインし直して、画面に表示される項目とボタンを一つずつ突き合わせる。
4. データ移行の整合性
旧システムからのデータ移行は、UATの中でも最も見落とされやすく、最も痛手が大きい領域だ。移行後の顧客マスタの件数が旧システムと一致しているか、過去の取引履歴が金額まで一致しているか、文字化けや桁落ちが起きていないか。全件は無理でも、金額が大きい取引先トップ20件は必ず手作業で照合する。ここで1円でもずれがあれば、本番稼働後に会計処理全体の信頼性が揺らぐ。
5. パフォーマンスと同時アクセス
担当者1人がテストする分には快適でも、月末の締め処理で全社員が同時にアクセスした瞬間に固まるシステムは珍しくない。可能であれば、繁忙期を想定した人数で同時にログインし、重い処理(月次集計、大量データの検索など)を同時に走らせてみる。開発会社に本番相当の負荷テストを依頼できるか、事前に契約時点で確認しておくべき項目だ。
6. 帳票・出力物の実務適合性
画面上の動作が正しくても、印刷される請求書や納品書のレイアウトが取引先の要求に合わなければ意味がない。振込先情報が正しいか、消費税の端数処理が自社のルール通りか、実際に紙に印刷して既存の帳票と並べて確認する。PDF出力とプリンター印刷でレイアウトが崩れるケースもあるため、両方で確認する。
7. 外部システムとの連携
会計ソフト、勤怠管理、ECサイトなど、既存の外部システムとのデータ連携がある場合、そのAPIやCSV連携が実データで正しく動くかを確認する。連携が想定より遅延する、文字コードが合わずに文字化けする、といった問題は本番でしか発覚しないことが多いため、UATの段階で本番に近いデータ量を使って一度は流してみる。
UATを実施する体制の作り方
UATが機能するかどうかは、テストを誰がやるかで9割決まる。情報システム部門やプロジェクト担当者だけで完結させてはいけない。実際にそのシステムで毎日仕事をする現場の担当者を、必ずテストの実行者として巻き込む。
現場を巻き込む具体的な方法は、テストシナリオを「機能一覧」ではなく「一日の業務の流れ」で作ることだ。「受注登録機能のテスト」ではなく、「朝一で届いたFAX注文を10件入力し、昼にキャンセル連絡が来た1件を取り消し、夕方に出荷確定処理を行う」というように、現場の一日をそのままシナリオ化する。この形式であれば、非エンジニアの現場担当者でも迷わずテストを実行でき、かつ実際の業務で起きうる問題を自然に拾い上げられる。
テストシナリオを作る際は、次の3種類を必ず用意する。日常的に発生する典型的な業務パターン、月末月初など特定タイミングでしか発生しない業務パターン、そして自社が過去に経験したイレギュラー対応のパターンだ。過去の受注台帳やクレーム記録を見返せば、3つ目のパターンは自然と集まってくる。
そして、テスト結果は必ず記録に残す。誰が、いつ、何を確認し、結果がどうだったかを一覧表にする。口頭で「大丈夫でした」と済ませてしまうと、後で問題が起きたときに何を確認済みで何を確認していなかったのかが分からなくなる。この記録は、検収書にサインする根拠にもなる。
よくある失敗パターン
現場を巻き込まず、情シス担当者や経営者一人だけで画面をひと通り触って「動いているから大丈夫」と判断し、検収書にサインしてしまうケースは非常に多い。本番稼働後、現場から「これじゃ普段の仕事のやり方に合わない」という声が噴出し、結局エクセルとの二重管理に戻ってしまう。システムは導入されたのに、誰も使わない状態になる。これが最も多い、そして最も悲しい失敗パターンだ。
もう一つ多いのが、納期のプレッシャーに負けて確認を打ち切ってしまうケースだ。「予定していた稼働日が近いから」という理由で、チェックリストの後半を「後で確認すればいい」と流してしまい、そのままサインしてしまう。契約上、検収完了後の修正は追加費用が発生することが多く、結果的に稼働日を守るために将来のコストを前借りすることになる。
また、開発会社から渡されたテスト項目書をそのまま使い、自社独自のチェック項目を追加しないケースもよく見られる。開発会社のテスト項目書は、あくまで仕様書に基づいた一般的な項目だ。自社の業務特有のイレギュラーは、発注者自身が追加しない限り、誰もテストしてくれない。
検収書にサインする前の最終確認ポイント
検収書にサインするという行為は、単なる事務手続きではない。「このシステムを、今の状態のまま、自社の業務基盤として受け入れる」という経営判断だ。サインする直前に、次の点を必ず確認する。
- 洗い出したチェック項目のうち、未確認・未解決の項目が残っていないか。残っている場合は、検収書に「留保事項」として明記し、対応期限と担当を書面で合意する。
- 不具合として報告した項目のうち、修正されたと聞いているものを、実際に自分の目でもう一度動かして確認したか。
- 検収後の保守・サポート体制と、対応時間、追加開発費用の発生条件を契約書で確認したか。
- 操作マニュアルやFAQが、現場担当者が実際に読んで理解できる内容になっているか。
- 本番データへの切り替え後、旧システムに戻す判断基準と手順(ロールバック計画)が用意されているか。
1つでも曖昧な点が残っているなら、サインを1日待ってもらう勇気を持つ。開発会社にとっても、検収後にトラブルが起きて信頼を失うより、検収前に洗い出してもらうほうがずっと望ましい。誠実な開発会社であれば、その延期要求を歓迎するはずだ。
まとめ
検収は、システム導入プロジェクトの最後に置かれた地味な事務作業ではない。これから何年も自社の業務を支える基盤を、自分たちの目で確かめる最後にして最大のチャンスだ。派手さはないが、この工程に向き合った担当者だけが、本番稼働後の静かな安心を手に入れる。
UATは、開発会社の仕事を疑うための作業ではない。自社の業務を、自社の言葉で、自社の責任で守るための作業だ。今日紹介した7つのチェック項目と、現場を巻き込む体制づくりを、次の検収で一つでも実践してほしい。地道な確認の積み重ねが、稼働後のトラブルを未然に防ぎ、システムを本当の意味で「使えるもの」に変えていく。壁を越えて働くというのは、こういう見えない仕事に手を抜かないことでもある。