先に要点
受託開発やWeb制作で、納品後に意外と揉めやすいのが検収です。
作る側は 仕様どおり作った と思っていても、発注側は まだ確認したいことがある と感じていることがあります。
問題は、どちらかが悪いというより、検収 の意味が曖昧なまま進むことです。
納品、確認、不具合修正、仕様変更、追加開発が混ざると、終盤でかなり苦しくなります。
この記事では、検収とは何か、納品と何が違うのか、納品後に揉めにくくする確認項目と進め方を、受託開発やWebシステムの実務に寄せて整理します。
保守契約との違いまで見たい場合は、Webサイト保守の月額費用に含める範囲は？受託開発の保守費用と契約の決め方 もつながりやすいです。
この記事では、2026年4月22日時点でIPAの「情報システム・モデル取引・契約書（第二版）」「情報システム・モデル取引・契約書（アジャイル開発版）」「『情報システム・モデル取引・契約書』からの見直しのポイント」を確認しながら整理しています。IPAは、契約のタイミングで仕様、プロジェクト管理方法、検収方法などについて、共通理解のもとで対話を深めることを重視しています。ここでは法的助言ではなく、受託開発で揉めにくくするための実務上の考え方としてまとめます。
結論：検収は「感想をもらう場」ではなく「完了条件を確認する場」
検収を一言でいうと、納品された成果物が、合意済みの条件を満たしているかを確認して受け入れる工程 です。
大事なのは、確認の基準が先にあることです。
逆に、基準がないまま 使ってみて気になった点を全部出す 形になると、次のものが混ざります。
- 合意済み仕様どおりに動かない不具合
- 想像と違ったが、仕様としては決まっていなかった点
- あとから足したくなった改善要望
- 納品対象外だった作業
ここが混ざると、発注側は まだ終わっていない と感じ、受注側は 追加対応が増えている と感じやすくなります。
納品と検収の違い
納品と検収は似ていますが、見ている場所が違います。
| 項目 | 意味 | 実務でのポイント |
|---|---|---|
| 納品 | 成果物を引き渡せる状態にすること | ファイル、ソースコード、公開環境、操作説明、納品物一覧などを渡す |
| 検収 | 納品物が合意内容どおりか確認すること | 確認者、確認環境、確認項目、期限、修正範囲を決めて進める |
つまり、納品は 渡す 側の行為で、検収は 受け入れるか判断する 側の工程です。
ただし実務では、両者が一緒に確認する場面も多いので、役割と手順を先にそろえておく方が安全です。
検収で最低限決めたい確認項目
検収で一番大事なのは、確認する観点が事前にそろっていることです。
最低限、次のような項目は決めておきたいです。
- 何を確認対象にするか
画面、フォーム、CSV、帳票、通知メール、権限、外部連携、管理画面、ドキュメントなど。 - どの環境で確認するか
ステージングか本番か、テストデータを使うか、本番データ移行後に見るか。 - 誰が確認者か
現場担当、決裁者、運用担当、情シス、外部委託先のうち誰が一次確認するか。 - 何をもって完了とするか
重大不具合がないこと、主要シナリオが通ること、操作説明を受けたことなど。 - 修正をどこまで検収内に含めるか
誤字修正、表示崩れ、軽微な調整まで含めるのか、追加要望は別にするのか。
納品後に揉めやすいポイント
1. 確認項目がふわっとしている
一通り見てください だけだと、確認の深さが人によって変わります。
現場担当は業務フローを細かく見ますが、管理職は見た目と大枠しか見ないこともあります。
そのため、主要シナリオ、入力例、期待結果を簡単でもよいのでそろえておく方が安全です。
全部を詳細テスト仕様書にしなくても、この3画面、この2帳票、この通知、この権限 のように絞るだけでかなり違います。
2. 不具合修正と仕様変更が混ざる
受託開発でかなり多いのがここです。
合意済み仕様どおりに動いていないなら不具合修正ですが、合意後に やはりこうしたい と変えるなら仕様変更です。
たとえば、次のように分けると整理しやすいです。
- 仕様書で必須だった入力チェックが動かない: 不具合修正
- 一覧の並び順が決まっていなかったが、あとから変更したい: 要望、または仕様変更
- CSV出力自体は合意済みだが、列を追加したい: 追加開発または仕様変更
ここを曖昧にすると、検収期間が 追加要望の受付期間 になりやすいです。
3. 確認者が実際に触れない
現場担当が忙しくて見られない、確認者が決裁者しかいない、運用担当へ引き継がれていない。こういう状態もかなり多いです。
結果として、期限だけ過ぎて、あとから そこは見ていなかった が起きます。
検収は、確認する人と時間を確保できて初めて機能します。
要件定義やスケジュール調整の時点で、誰がいつ触るかまで置いておく方が現実的です。
4. 本番でしか分からないことを検収条件に入れていない
メール送信、外部決済、DNS、権限、添付ファイル、CSV文字化け、印刷、スマホ表示などは、本番や本番相当環境でないと見えにくいことがあります。
そこを検収条件に入れていないと、納品後すぐに追加調整が出やすいです。
実務で使いやすい検収チェックリスト
小規模案件でも、次の観点があるとかなり進めやすいです。
| 観点 | 確認例 | 見落としやすい点 |
|---|---|---|
| 主要業務フロー | 登録、検索、更新、承認、出力、通知が通るか | 正常系だけ見て、差し戻しや取消を見ていない |
| 権限 | 一般ユーザー、管理者、閲覧専用で見える範囲が違うか | 管理者アカウントだけで確認してしまう |
| 入出力 | CSV、帳票、メール、添付ファイルが期待どおりか | 文字コード、改行、件名、差出人、ファイル名 |
| 外部連携 | API、決済、地図、メール配信、Webhook が動くか | テスト環境では通っても本番設定が違う |
| 運用開始条件 | 初期設定、管理者アカウント、バックアップ、マニュアルがそろっているか | 使い始める準備が抜けている |
検収期間で先に決めたいこと
検収そのものだけでなく、期間の扱いも重要です。
少なくとも次は決めておいた方が安全です。
- 検収開始日はいつか
- 検収期間は何営業日か
- 指摘はどの手段で出すか
- 指摘の整理責任は誰が持つか
- 軽微修正後に再確認する範囲はどこまでか
ここが曖昧だと、チャット、口頭、メール、会議で指摘が散って、どれが正式な指摘か分からなくなります。
チケット、スプレッドシート、議事録でもよいので、検収指摘の置き場 を一つに寄せる方が実務ではかなり効きます。
アジャイルでも検収が不要になるわけではない
アジャイル開発だと、最後にまとめて検収しないから楽 と思われることがあります。
ただ実際には、受け入れ条件の確認が不要になるわけではありません。
IPAのアジャイル開発版でも、進め方指針を通じて開発プロセスの共通認識を確立・維持することが重視されています。
つまり、ウォーターフォールより細かく分けるとしても、何を確認して受け入れるか を曖昧にしない方が大事です。
アジャイルでは、スプリント単位の受け入れ確認、小さな完了条件、バックログ上の受け入れ基準に分けて置く方が扱いやすいです。
アジャイルだから柔軟 を理由に、完了条件をぼかすとむしろ揉めやすくなります。
よくある失敗
検収を、納品後に出た気になる点を全部拾う期間だと思ってしまうことです。これだと、不具合修正、改善要望、追加開発、仕様変更が混ざり、終盤の期待値が崩れやすくなります。
ほかにも次の失敗はかなり多いです。
- 検収条件を要件定義で決めていない
- 現場担当が触る時間を確保していない
- 本番設定やメール送信確認を検収に含めていない
- 指摘の置き場が複数に散っている
- 軽微修正の範囲が決まっていない
まとめ
検収 は、納品後に何となく触って感想を集める工程ではありません。
合意済みの条件に照らして、受け入れるかを確認する工程です。
受託開発で納品後に揉めにくくするには、確認項目、確認者、検収期間、指摘の置き場、軽微修正の範囲、不具合修正と仕様変更の線引きを先にそろえておくことが大事です。
特に小規模案件ほど、最後にまとめて調整するのではなく、要件定義の時点で 何をもって完了とするか を置いておく方がかなり効きます。