Webシステム発注初心者ガイド
第8話
テストと検収―「動く」と「使える」は違う
「完成しました」連絡が来た
開発開始から4ヶ月後、C社のPM木村さんから連絡が入った。
「システムの開発が完了しました。テスト環境をご用意しましたので、ご確認をお願いします」
いよいよだ。と思いながら、テスト環境のURLを開いた。
ちょっと待ってね。「動く」と「使える」は別物なんだよ。
開発会社がやる単体テスト・結合テストは「機能が正しく動くか」を確認するもの。でも「実際の業務で使えるか」を確認するのは発注者側のテストの仕事なんだ。
これをUAT（User Acceptance Testing：受入テスト）と呼ぶよ。「開発会社が想定した動き」ではなく、「自社の業務フローに合っているか」を検証する大切なステップだね。
テストケースを作る
UATでは、事前にテストケースを作っておくことが重要だ。
「なんとなく触ってみる」では重要な問題を見落とす。
見積書作成のテストケース（例）
| No | テスト内容 | 期待する結果 | 結果 |
|---|---|---|---|
| 1 | A社（掛率85%）を選択して品目を追加 | 単価が定価×0.85で自動計算される | ✅ |
| 2 | 品目を50行追加する | エラーなく追加できる | ✅ |
| 3 | 100万円未満の見積を申請 | 営業リーダーを飛ばして部長へ直送 | ❌ |
| 4 | 承認者が不在の場合に申請 | 代理承認者に通知が届く | 未確認 |
| 5 | PDF出力してメール送信 | 添付ファイルが正しく届く | ✅ |
そう、これはバグだね。承認フローの条件分岐が正しく動いていない。
でもこれがUATをやる意義だよ。開発会社側のテストで「承認フローが動く」ことは確認されていても、「100万円未満でリーダーをスキップする」という自社固有のルールが正しく実装されているかは、発注者が確認しないと見つけられないんだ。
見つけたバグは必ずリストにして、C社に報告しよう。
バグ報告の仕方
バグは口頭で伝えるのではなく、再現手順とともに文書で報告する。
バグ報告の書き方
【バグNo.】 BUG-003
【発見日】 2026-08-15
【重要度】 高（業務フローに直接影響）
【画面】 見積書申請画面
【再現手順】
1. 見積金額が80万円の見積書を作成
2. 「申請」ボタンを押す
3. 承認フロー画面を確認する
【期待する結果】
営業リーダーを飛ばして営業部長へ直送されること
【実際の結果】
営業リーダーへの承認依頼が送られてしまう
【スクリーンショット】
（添付）要件定義書に明記されていた仕様のバグなら、追加費用なしで修正してもらえるのが基本だよ。
ただし「要件定義書に書いていなかった機能の追加」は、バグではなく「仕様変更」として追加費用になる可能性があるから気をつけてね。
だから要件定義書をしっかり作っておくことが、このタイミングで効いてくるんだ。「書いてある通りに動いていない」は明らかにバグ。「書いていなかったけど欲しい」は変更依頼、という区別を意識しよう。
再テストと検収
バグ修正後、再度テストを実施した。今度はバグリストの全項目が✅になった。
いよいよ検収（けんしゅう）だ。
検収とは「納品物を確認し、合格と判断してOKを出す」こと。検収完了のサインをした時点で、残金の支払いが発生する。
通常は検収書という書類をC社が用意してくれるよ。内容は「何を検収したか」「合格の判断基準は何か」「検収完了日はいつか」が書いてあるもの。
発注者がサインして返送すれば検収完了だね。
一度サインしたら後から「やっぱりここが違う」は通りにくくなるから、テストで問題ないことを確認してからサインしてね。急かされても、焦ってサインしないようにしよう。
次回：リリースと振り返り →