検収で何を確かめるか ── 受け入れの確認表を、発注側で作る

「納品しました。ご確認ください」。メールにURLとログイン情報が書いてあります。開いてみると、トップ画面が出て、一覧に何件かのデータが並んでいる。いくつか押してみて、エラーも出ないので「大丈夫そうです」と返す。

検収の場で、これはよく起きます。そして2週間後、実際に使い始めた現場から「締めの処理ができない」「パートさんの画面に単価が出ている」と連絡が来る。確認したはずなのに、確認したことになっていなかった、という話です。

この記事は、検収のときに発注側が何を確かめるかを、確認表の作り方として書きます。検収期間や不具合の対応期間といった契約上の扱いは会社ごとに違うので、そこは契約書で確認してください。読む場所はシステム開発の契約書で、発注側が読むべき5つの場所にまとめています。

「大丈夫そうです」では、検収にならない

検収は、契約で決めたものが決めたとおりに動くかを、発注側が確かめて受け取る手続きです。画面を眺めて印象を伝える場ではありません。

印象で確認すると、見るのはいつも同じ場所になります。ログインして、一覧を開いて、詳細を1件見る。普段の業務で一番よく通る道だけを歩いて、問題がないことを確かめる。ところが、システムが止まるのはたいてい普段通らない道のほうです。

なので、確かめる道を先に紙に書き出しておきます。これが確認表です。1行に1つ、「誰が、どの画面で、何をしたら、何が起きれば合格か」を書きます。最後の「何が起きれば合格か」が書けない行は、確認表の行になっていません。

私たちのように開発中に週1回、動く画面を見ていただく進め方でも、確認表は役に立ちます。週ごとの確認は1画面ずつ見ることが多く、画面と画面をつないだ流れを通しで試すのは、どうしても最後になるからです。

まず、業務の1日を流してみる

確認表の最初の行は、実際の業務の1日から作ります。架空の想定例です。資材の卸で、FAXと電話で来る注文を登録し、倉庫に出荷を指示している会社が、受注のシステムを入れたとします。

時刻	誰が	何をする	合格の条件
9:00	事務	FAXの注文3件を登録する	一覧に3件が「未出荷」で並ぶ
10:30	事務	電話で数量の変更を受け、1件を直す	変更の履歴が残り、出荷指示の数量も変わる
13:00	倉庫	スマホで出荷指示を開き、2件を出荷済みにする	事務の一覧で状態が変わっている
17:00	事務	当日分をCSVで出し、請求用のExcelに貼る	件数と金額の合計が画面と一致する
月末	管理者	締めの処理をする	締めた月の注文が編集できなくなる

ポイントは、時刻と人を入れることです。「注文を登録できること」だけだと、事務の人がPCで1件登録して終わります。時刻と人を入れると、倉庫の人がスマホで同じ注文を見る、という画面をまたぐ確認が自然に入ります。

行の数は、1日の業務で10〜20行くらいになることが多いです。月末や月初にしか起きない処理は、別の行として足しておきます。

例外は、実際にあった日から拾う

次に、例外の行を足します。思いつきで書くと漏れるので、過去の業務から拾います。先月の注文表やメールを見返して、「普通ではなかった日」を探してください。

注文の取り消しが来た。締めたあとに修正が来た。同じ注文を2人が別々に登録してしまった。特別な単価の取引先から注文が来た。入力の途中で電話が鳴って、画面を開いたまま30分離れた。どれも月に何回かは起きているはずです。

例外の行で見るのは、正しく処理できるかどうかに加えて、間違えたときに戻せるかどうかです。間違えて出荷済みにした注文を、未出荷に戻せるか。戻した記録は残るか。例外の処理が画面にないと、現場はその日からExcelに戻ります。この話は作ったのに使われないシステムになる原因にも書きました。

権限ごとに、ログインし直して見る

検収でいちばん見落とされやすいのが、ここです。確認する人はたいてい管理者のアカウントを渡されているので、全部の画面が見えて、全部のボタンが押せる状態で確認しています。

役割の数だけ確認用のアカウントを用意して、1つずつログインし直してください。見るのは2つで、見えるべきものが見えるか、見えてはいけないものが見えないか、です。倉庫の人のアカウントで単価や取引先の連絡先が見えていないか。パートの人のアカウントで、削除のボタンが押せてしまわないか。

スマホで使う役割があるなら、その役割はスマホで確認します。PCの画面で問題がなくても、スマホでは表が横にはみ出して、出荷済みのボタンが画面の外にある、ということがあります。

データを出して、いつもの表と突き合わせる

最後の観点はデータの出力です。CSVを出して、普段使っているExcelで開いてみてください。

文字化けしていないか。日付が「2026/10/28」なのか「2026-10-28」なのか、集計用のExcelが読める形か。件数が画面の一覧と一致しているか。金額の合計が合っているか。消費税の端数の扱いが、いまの請求書と同じか。

確認には、先月1ヶ月分の実際の件数を再現したデータを使うのが一番です。先月の集計表がすでに手元にあるので、システムから出した数字と並べれば、ずれがあればすぐに分かります。データを持ち込むときの注意は既存システムから乗り換えるときに書いています。

誰が確認するか、いつ確認するか

確認表の行ごとに、確認する人を決めます。入力の行は、実際に入力する人に。一覧や集計の行は、それを見て判断する人に。決裁者には、最後に結果の一覧だけ見てもらえば足ります。

管理職ひとりで全行を確認すると、現場の人が毎日通る道を、普段通らない人が歩くことになります。操作に迷うのは慣れていないからなのか、画面が分かりにくいからなのか、区別がつきません。

時間も先に押さえておきます。検収の期間は契約書で決まっていることが多く、担当者が忙しくて触れないまま期間が過ぎるのが、いちばんもったいない形です。確認表の行に担当者の名前が入った時点で、その人の予定に1〜2時間を入れてください。8週間のうち発注側がどこで時間を使うかは発注したあと、自分たちは何をするのかに並べました。

見つけたものを、不具合と要望に分ける

確認していると、いろいろ見つかります。それを全部同じ欄に書くと、検収が終わらなくなります。

分け方は1つだけです。決めたとおりに動かないものは不具合。決めたとおりに動いているが、変えたくなったものは要望。たとえば、決めていた並び順で一覧が出ない、合計が合わない、見えてはいけない画面が見える、は不具合です。並び順を期限順に変えたい、項目をもう1つ足したい、は要望です。

どちらか迷ったら、画面ラフや打ち合わせのメモを見返します。何を決めていたかが書いてあれば、判断はそれほど割れません。決めていなかったことは、たいてい要望の側に入ります。要望がどこから追加費用になるかの線は開発中に「やっぱりこうしたい」が出たときに書きました。

要望が出ること自体は、悪いことではありません。実際に通しで使ってみて初めて分かることのほうが多いからです。ただ、検収の合否には混ぜずに、次に直すものの候補として別の表に移してください。私たちの場合、そうした要望はリリース後12ヶ月の月額の稼働時間の中で、順番を相談しながら対応しています。不具合の対応期間や検収の手続きそのものは、案件ごとの契約書で確認してください。