開発会社から「納品しました。検収をお願いします」と連絡が来た。ただ、社内に検収をやったことがある人がいない。動かしてみると気になる点がいくつかあるけれど、これを不合格にしてよいのかも分からない。そういう状態でこの記事にたどり着いた方に向けて書きます。

検収でつまずく原因の多くは、確認のやり方ではなく、決めておくべきことを決めていないことにあります。しかも発注側が「当然できる」と思っている対応の中には、法律で禁止されているものが混ざっています。この記事では、何をどこまで確認するのかと、発注側ができること・できないことの線引きを整理します。受け取る納品物の一覧や契約書全般は別の記事に譲ります。

この記事のポイント

  1. 検収基準は納品後に考えるものではなく、発注時に決めておくもの
  2. 検収が終わっていなくても、支払期日は法律で受領日から60日以内と決まっている
  3. 発注時の書面に「検査を完了する期日」を書く義務がある
  4. 不合格にできるのは相手に明らかな責任がある場合に限られる。気に入らないから直させるのは禁止行為
目次
  1. システム開発の検収は何をどこまで確認するか
  2. 検収は責任が移る分岐点
  3. 検収基準は納品後ではなく発注時に決める
  4. 確認するのは4つの観点
  5. 検収期間の目安と決め方
  6. システム開発の検収で発注側が守るべきルール
  7. 検収が終わらなくても支払期日は動かせない
  8. 発注時の書面に検査完了日を書く義務がある
  9. 不合格にできるのはどこまでか
  10. みなし検収の条項をどう扱うか
  11. システム開発の検収についてよくある質問
  12. 総括:システム開発の検収で押さえる判断軸

システム開発の検収は何をどこまで確認するか

明るいオフィスで40代男性の現場担当者が画面を操作しながら、手元の紙資料と見比べて実際の業務が回るかを確認している寄りの場面
画面が動くかではなく、その業務が回るかを見る

まず確認の中身からです。ここを間違えると、動作を眺めただけで合格を出してしまい、あとから使えないことに気づくことになります。

検収は責任が移る分岐点

検収に合格を出すと、そこから先の責任は発注側に移ります。「まだ確認しきれていないけれど、とりあえず合格にしておく」をやると、後から見つかった問題を相手の負担で直してもらいにくくなります。

逆に言えば、検収は発注側にとって最後の交渉機会です。支払いを済ませたあとで「実は業務で使えない」と分かっても、追加費用の話になります。時間を取って確認する価値があるのはこのためです。

ただし、時間を取ればよいという話でもありません。あとで触れるとおり、確認に時間をかけすぎると別の問題が起きます。

検収基準は納品後ではなく発注時に決める

検収でもめる会社に共通しているのは、何をもって合格とするかを納品後に考え始めていることです。基準がないので、担当者の主観で「なんとなく気になる」という指摘になり、相手も納得できません。

基準は発注時に決めます。そして多くの場合、新しく作る必要はありません。要件定義書がそのまま検収基準になるからです。要件定義書に「受注登録後、承認者が確認し、確定後に管理部門へ通知する」と書いてあるなら、そのとおり動くかを確認すればよい、ということになります。

裏を返すと、要件定義書が曖昧だと検収も曖昧になります。「使いやすくする」としか書いていなければ、使いやすいかどうかで揉めます。検収の質は要件定義の時点でほぼ決まっているので、これから発注する段階の方は、要件定義書のサンプルと作り方は?記入例と手順を実務目線で解説を先に確認してください。

確認するのは4つの観点

実際の確認は、次の4つに分けると漏れが減ります。

観点 確認すること 誰が見るか
要件どおりか 要件定義書の各項目が実装されているか システム担当
業務が回るか 実際の伝票や取引先データで1日分を流せるか 使う部署
止まらないか 同時利用、繁忙期の件数、夜間処理の所要時間 システム担当
引き渡し物 設計書、操作手順書、アカウント、ソースコード システム担当

とくに2つ目を軽視しないでください。画面が仕様どおり動くことと、その業務が実際に回ることは別です。テスト用の当たり障りのないデータではなく、実際に処理に困っている取引先や、例外的な処理が必要な伝票を流してみると、要件の抜けが表に出ます。

4つ目の引き渡し物は、検収の場で確認しないと後から出てきません。設計書、操作手順書、管理者アカウント、ソースコードの受け渡し方法まで、その場で揃っているかを見てください。何を受け取るべきかの一覧は、この記事の後半で触れる別記事にまとめています。

検収期間の目安と決め方

検収期間は、一般的には2週間から1か月程度が目安として挙げられます。ただしこの数字をそのまま採用する前に、2つ確認してください。

ひとつは、使う部署が動ける時期かどうかです。月末月初や決算期に検収期間を重ねると、現場が確認に参加できず、システム担当だけで形式的に流すことになります。それでは業務が回るかを見られません。契約を結ぶ段階で、繁忙期を外した期間を確保しておくべきです。

もうひとつは、次に触れる支払期日との関係です。検収期間を長く取れば安全というわけではなく、上限があります。

システム開発の検収で発注側が守るべきルール

受領日の位置から60日目までを帯で示したカレンダー状の升目を並べ、支払期日の上限を表したフラットイラスト
検査の有無にかかわらず、支払期日には上限がある

ここからは、発注側が知らずに違反しやすい部分です。相手が同意していても、こちらに違法性の意識がなくても違反になる、と明記されている点なので注意してください。

検収が終わらなくても支払期日は動かせない

「検収が終わっていないから支払わない」。これは発注側では当然のように行われていますが、条件によっては法律違反になります。

公正取引委員会が示している委託事業者の義務には、支払期日を定める義務として「委託事業者が中小受託事業者の給付の内容について検査するかどうかを問わず」、物品等を受領した日から起算して60日以内でできる限り短い期間内に定めること、と書かれています。

ポイントは「検査するかどうかを問わず」という部分です。検収の進み具合は支払期日の理由になりません。さらに支払いが遅れた場合は、受領日から60日を経過した日から実際に支払う日までの日数に応じて、未払金額に年率14.6%を乗じた遅延利息を支払う義務があります。

この法律は2026年1月に下請法から中小受託取引適正化法へと改称され、あわせて呼び方も親事業者が委託事業者、下請事業者が中小受託事業者に変わりました。古い記事や社内の資料は旧称のままのことがあるので、調べるときは注意してください。なお、この法律は資本金の区分など適用条件がある取引に適用されるもので、すべての発注が対象になるわけではありません。自社の取引が当たるかは契約担当か顧問弁護士に確認してください。

発注時の書面に検査完了日を書く義務がある

先ほど「検収基準は発注時に決める」と書きましたが、これは実務上の推奨にとどまりません。

同じ資料の発注内容等の明示義務では、発注の際に交付する書面の記載事項として「給付の内容について検査をする場合は、その検査を完了する期日」が挙げられています。つまり検収をするなら、いつまでに終えるかを発注時点で書いておく必要があるということです。

加えて、書類の作成・保存義務では、検査をした場合はその検査を完了した日、検査の結果、検査に合格しなかった給付の取扱いを記録し、2年間保存することが求められています。検収の結果を口頭で済ませず、書面に残しておくべき理由がここにあります。

不合格にできるのはどこまでか

では、気になる点があったときにどこまで突き返せるのか。公正取引委員会は委託事業者の禁止行為として11項目を挙げており、そのうち検収に直結するのが次の4つです。

禁止行為 内容 発注側がやりがちなこと
受領拒否 相手に責任がないのに受領を拒む 納期に間に合ったが社内都合で受け取らない
支払遅延 受領日から60日以内に定めた支払期日までに全額支払わない 検収が終わるまで支払いを止める
返品 受領後に返品する あとから気が変わって突き返す
不当なやり直し 費用を負担せずに受領後にやり直しをさせる 検収の指摘として仕様外の変更を求める

いちばん起きやすいのが4つ目です。検収で確認していると、要件定義書に書いていないけれど直したい点が必ず出てきます。それを「検収の指摘」として無償で直させると、不当なやり直しに当たる可能性があります。要件どおりでない箇所と、要件には無いが直したい箇所は、分けて扱ってください。後者は追加の依頼として費用を含めて相談するのが筋です。

一方で、明らかに相手に責任がある不良品を受領後すみやかに返品することは問題ないとされています。要件どおり動かない箇所を指摘して直してもらうのは正当な対応です。線引きは「要件に照らして不足があるか」に置いてください。

みなし検収の条項をどう扱うか

契約書に「納品後◯日以内に発注者から異議がない場合は検収に合格したものとみなす」という条項が入っていることがあります。いわゆるみなし検収です。

これ自体は当事者間の取り決めであり、直ちに問題になるものではありません。困るのは、発注側が期間内に確認しきれず、気づかないうちに合格になってしまうケースです。とくに現場の繁忙期と重なると起こりやすくなります。

本記事で扱うのは、契約段階で交渉すべき1点です。それは起算日をいつにするか。起算日が「納品日」になっていると、設計書や操作手順書が後から届く場合に、実質的な確認期間が削られます。「必要な引き渡し物がすべて揃った日」を起算日にしておくと、この目減りを防げます。あわせて、前に触れた支払期日の起算日とも整合しているかを見てください。

もう一方の「期間内に確認しきれる体制をどう組むか」は運用側の話なので、受託開発の納品物と成果物は?発注者が受け取る一覧と検収を解説にまとめています。チェックリストの準備や担当者の時間確保はそちらを参照してください。契約書全体で確認すべき点は、受託開発の契約で発注者が確認すべきこと(著作権・ソースコード)で整理しています。

検収の前に確認しておくこと

  • 検収基準(要件定義書のどの項目を見るか)が発注時に決まっているか
  • 検査を完了する期日が発注書面に書かれているか
  • 検収期間が使う部署の繁忙期と重なっていないか
  • みなし検収の条項と、その起算日がいつか
  • 不合格だった場合の再納品と再検収の手順
  • 支払期日が受領日から何日後に設定されているか

この中で見落とされやすいのが1つ目です。検収基準は要件定義書がそのまま使えますが、その要件定義書に抜けがあると検収でも判定できません。実際に何を見て合否を判断するかは、検収・受入テスト確認シートの6カテゴリ45項目が目安になります。

システム開発の検収についてよくある質問

Q. 検収が終わるまで支払いを止めてもよいですか?
A. 条件によっては法律違反になります。公正取引委員会は支払期日について「検査するかどうかを問わず」受領日から起算して60日以内に定めることとしており、検収の進み具合は支払期日の理由になりません。遅延した場合は年率14.6%の遅延利息の支払義務もあります。
Q. 検収期間はどれくらい取ればよいですか?
A. 一般的には2週間から1か月程度が目安として挙げられます。ただし長く取れば安全というわけではなく、支払期日の上限があります。それよりも、使う部署の繁忙期を外して実際に確認できる時期に設定するほうが重要です。
Q. 気になる点があれば不合格にできますか?
A. 要件に照らして不足がある場合は指摘して直してもらえます。ただし要件定義書に書いていない改善要望を「検収の指摘」として無償で直させるのは、不当なやり直しに当たる可能性があります。要件どおりでない箇所と、要件には無いが直したい箇所は分けて扱ってください。
Q. みなし検収の条項は受け入れてよいですか?
A. 条項自体が問題になるわけではありません。確認しきれずに合格扱いになるのが問題なので、期間を自社の体制に合う長さにすること、起算日を必要な引き渡し物が揃った日にすること、の2点を契約段階で交渉してください。
Q. 検収の結果は書面に残す必要がありますか?
A. 残してください。委託事業者には、検査を完了した日・検査の結果・検査に合格しなかった給付の取扱いを記録し2年間保存する義務があります。口頭で合格を伝えるだけの運用は避けるべきです。