「先方から『完成しました』と連絡が来たので、画面をひととおり触ってみました。特に問題なさそうだったので、検収ということで進めます」——発注したシステムの受け取りについて、こうした進め方をよく聞きます。悪気はまったくありません。ただ、ここには一つ落とし穴があります。
検収を通した瞬間から、見つかった不具合の扱いが変わるのです。検収前なら「納品物が要件を満たしていない」として修正の対象ですが、検収後は「追加の改修」として費用と納期の相談になりがちです。契約の書き方にもよりますが、この線引きが実務上とても重く効きます。だからこそ、受け取る側にも確認の作法があります。専門知識がなくてもできることは意外に多いので、順番に整理します。
検収は「動くかどうか」を見る場ではない
まず考え方から。検収でよくある失敗は、画面を触って「動いた・動かない」だけを見てしまうことです。動くのは当たり前で、確認すべきなのは発注時に決めたことが、そのとおりに満たされているかです。
つまり検収の基準は、要件定義の内容です。要件が曖昧なまま進んだ案件は、検収の段階で必ず揉めます。「言ったはずだ」「聞いていない」の水掛け論になるのは、たいてい検収の問題ではなく、その手前の要件の問題です。この土台の固め方は要件定義の三層設計の記事、契約形態を含めた発注全体の進め方はシステム開発の外注で失敗しない発注ガイドにまとめています。
発注者でも確認できる4つのこと
技術的な中身は分からなくても、次の4点は発注者の立場で確認できます。しかも、抜けると後で確実に困るものばかりです。
- 要件の一覧と突き合わせる — 発注時の要件書を横に置き、一項目ずつ「これは満たされているか」を確認する
- 普段の業務の流れで通してみる — 機能を単体で触るのではなく、実際の仕事の順番どおりに一連の操作をやってみる
- 異常なケースを試す — 空欄のまま送信する、想定外の文字を入れる、途中で戻る。エラーが親切に出るか
- 引き渡されるものを確認する — ソースコード、管理画面のアカウント、設計や操作の資料、外部サービスの契約名義
とくに2番目が効きます。機能ごとのチェックでは通るのに、業務の流れで通すと「この画面からあの画面に戻れない」といった実用上の問題が見つかることが本当に多いのです。
引き渡し物の確認を軽く見ない
4番目の「引き渡されるもの」は、その場では困らないのに、後からいちばん響きます。
| 引き渡し物 | 抜けていると起きること |
|---|---|
| ソースコード一式 | 別の会社に引き継げず、実質的に囲い込まれる |
| 管理者アカウント・権限 | 自社で設定変更ができない |
| 外部サービスの契約名義 | 開発会社名義のままで、解約や支払いを握られる |
| 操作・運用の資料 | 担当者が代わった瞬間に運用が止まる |
三つ目は見落とされがちですが、サーバーやドメイン、各種SaaSの契約が開発会社名義のままだと、関係が切れたときに身動きが取れなくなります。この構造的なリスクはベンダーロックインを避ける発注の仕方で詳しく扱っています。検収は、これを確認する最後のタイミングです。
検収は「終わり」ではなく「運用の始まり」
もう一点。検収が通った後、システムは動かし続けることになります。検収の場で「この後の保守はどうなりますか」を確認しておくと、引き継ぎがなめらかになります。毎月かかる費用の内訳は業務システムの保守費用の記事、契約で握るべき範囲は保守・運用契約で発注者が見るべきことの記事が参考になります。
押す前に、要件書をもう一度開く
検収は、専門知識の勝負ではありません。発注時に決めたことと突き合わせる——やることはこれに尽きます。画面を触った感触ではなく、要件の一覧を一つずつ確認する。業務の流れで通してみる。引き渡されるものを揃える。この三つをやるだけで、後から「話が違う」となる事態はかなり防げます。次に「完成しました」の連絡を受け取ったら、検収印を押す前に、発注時の要件書をもう一度開いてください。
システムの検収をどう進めればよいか分からない、提示された納品物が妥当か第三者に見てほしい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談からお気軽にお問い合わせください。発注者側に立った検収の伴走も承ります。
