システム開発における検収とは、開発会社から納品された成果物が契約で取り決めた仕様・機能・品質を満たしているかを、発注者が確認して合格・不合格を判定する工程です。発注者がすることは、大きく分けて「約束した内容と納品物を突き合わせて確認する」「合否を書面などの記録に残る形で通知する」「合格ならサイン（検収書の発行）をして支払いに進む」の3つです。
「納品が完了しましたので、検収をお願いします」と連絡を受けて手が止まっている方も、見積書や契約書にある「検収」の条項の意味を確認したい方も、まずはこの定義と役割を押さえれば、次に何をすればよいかが見えてきます。
ただし、検収は用語の意味を知るだけでは不十分です。検収期間をどう設定するか、みなし検収の条項をどう扱うか、支払いをいつ確定させるか、検収後の不具合の責任をどこまで求められるか。これらはすべて、見積・契約・保守といった場面で発注者が下す判断につながります。本記事では、検収の定義から検収完了までの5ステップ、各段階で発注者がすることを整理したうえで、それが発注の判断にどう結び付くのかまで、非エンジニアの発注担当者に向けて順を追って解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
検収とは｜定義と発注者がすること
検収とは、納品された成果物を発注者が確認し、契約どおりであれば受け取る（合格）、そうでなければ受け取らない（不合格）と意思表示する、契約上の意味を持った行為です。単に「画面が表示されるか」「ボタンが押せるか」を見る動作確認とは異なり、検収は「契約どおりに作られているか」を判定し、その結果を相手に伝えるところまでを含みます。
検収を行う主体は、開発会社ではなく発注者です。開発会社が「テストをして問題ありませんでした」と報告することはありますが、納品物を受け取って合否を判定するのは発注者の役割です。専任のエンジニアがいなくても心配はいりません。検収で問われるのは高度な技術検証ではなく、「自分たちが発注した内容どおりにできているか」という業務目線での確認が中心です。
発注者が検収でする主なことは、次の3つです。
- 確認する：要件定義書・仕様書・見積書など「何を作る約束だったか」を手元に置き、納品物と突き合わせます。
- 合否を通知する：合格か不合格かを、メールや検収書など記録に残る形で開発会社に伝えます。不合格の場合は、どこがどの仕様に対して不足しているかを具体的に示します。
- 合格ならサインして支払いに進む：検収書などを発行し、契約で定めた報酬の支払いに進みます。
検収の意味や3ステップ、合否の判断基準をさらに詳しく知りたい場合は、システム開発の検収とは？発注者が実施すべき3ステップと合否判断基準で解説しています。本記事は、検収が納品から完了までどう進み、その各場面で発注者がどう判断するのかに焦点を当てます。
検収完了とは｜合格が確定し、支払いと引き渡しが進む時点
検収完了とは、発注者が納品物を合格と判定し、納品が契約どおりに完了したものとして扱われる時点を指します。実務では、発注者が開発会社に検収書や受領書を発行したタイミングが検収完了の合図になることが一般的です。
検収完了によって何が変わるかを先に整理しておきます。
- 契約で定めた報酬（残額）の支払い義務が発生します。
- 成果物の引き渡しが完了したものとして扱われます。
- 以後の追加要望は、契約範囲を超えるものであれば有償対応になりやすくなります。
- 一方で、検収時に気づけなかった契約不適合（約束した仕様を満たしていない欠陥）については、開発会社に責任を求められる余地が残ります。
つまり検収完了は、「動作確認の終わり」であると同時に、支払いと責任の分かれ目となる節目です。この節目の意味を契約の前から理解しておくことが、発注判断に直結します。詳しくは後の章で説明します。
検収の流れ｜納品から検収完了までの5ステップ
検収の全体像を「いつ・何を・どの順で進むのか」という流れとして整理します。流れが見えると、今自分がどの位置にいるのかが分かり、落ち着いて対応できます。
検収の5ステップ｜納品から検収完了まで
一般的なシステム開発の検収は、おおむね次の5つのステップで進みます。
- 納品：開発会社が完成したシステムと、必要なドキュメント（操作マニュアル、テスト結果など）を引き渡します。ここから検収のプロセスが始まります。
- 検収期間の開始：納品を起点に、発注者が確認を行うための期間（検収期間）が始まります。多くの場合、契約書でこの期間が定められています。
- 確認作業（検収テスト）：発注者が、仕様書・要件定義と照らし合わせながら、システムが約束どおりに動くかを確認します。発注者にとって実質的にもっとも作業量が多いステップです。
- 合格通知または不合格通知：確認の結果、問題がなければ合格として検収書などを発行します。不備があれば、その内容を具体的に示して不合格（修正依頼）として通知します。
- 検収完了（または再納品）：合格すれば検収完了となり、報酬の支払いと引き渡しが確定します。不合格の場合は、開発会社が修正して再納品し、再び確認するという流れに戻ります（ベリーベスト法律事務所「IT業界における検収とは？」）。
このうち、発注者が主体的に関わるのは主にステップ3（確認作業）とステップ4（合否の通知）です。次の章で、各ステップで発注者が具体的に何をすればよいのかを掘り下げます。
検収期間の目安｜一般的な長さと、見積・契約で決めておくこと
5ステップのうちステップ2の「検収期間」は、流れ全体を左右する重要な概念です。検収期間とは、納品後に発注者が検収を行うべき期限として契約で定められる期間のことです。
検収期間の長さはシステムの規模や複雑さによって異なりますが、一般的にはおおよそ2週間程度、規模が大きければ1か月程度に設定されるケースが多いとされています（システム幹事「システム開発の検収トラブルを防ぐには？」）。これはあくまで目安です。自社の体制で無理なく確認しきれる長さになっているかを、契約の前に確認することが発注者の判断ポイントになります。
検収期間を決める際は、次の点を見積・契約の段階で開発会社とすり合わせておくと安心です。
- 確認作業に使える社内の担当者と、確認にかかる日数の見込み
- 期間の起算日（納品日か、ドキュメントを含む納品物一式を受け取った日か）
- 期間内に確認が終わらない場合の延長の手続き
みなし検収｜通知しないと合格扱いになる条項
流れの中の落とし穴として注意したいのが「みなし検収」です。みなし検収とは、納品から一定期間が過ぎても発注者から合否の通知がない場合、検収に合格したものとみなすという契約条項です（システム幹事「システム開発の検収トラブルを防ぐには？」）。検収の長期化を防ぐために設けられるもので、開発会社側を保護する意味合いがあります。
発注者の立場では、「忙しくて確認が後回しになっているうちに、自動的に合格扱いになってしまった」という事態が起こり得ます。契約書にみなし検収の条項がある場合は、その期間内に確認を終えられる体制を整えておきましょう。確認が間に合わない見込みがあるなら、期限が来る前に開発会社へ相談し、期間の延長を申し入れることが大切です。
各ステップで発注者がすること｜確認の観点
発注者が主体的に動くステップ3（確認作業）とステップ4（合否通知）について、具体的に何をすればよいかを整理します。
確認作業のステップ｜仕様・要件定義との突合
ステップ3でもっとも基本となるのは、「最初に約束した内容どおりにできているか」を照らし合わせることです。要件定義書・仕様書・見積書といった「何を作ってもらう約束だったか」が書かれた資料を手元に置き、納品されたシステムを一つずつ突き合わせます。
確認の代表的な観点は次のとおりです。
- 要件・仕様との一致：要件定義で求めた機能がすべて実装されているか。仕様書に書かれた画面・項目・処理が抜けなく揃っているか。
- 主要な業務フローの動作：実際の業務で使う一連の操作（たとえば「データを登録して、検索して、出力する」といった流れ）が、想定どおりに完了するか。
- データの保存・出力：入力したデータが正しく保存されるか。帳票やCSVなどの出力結果が、求めた形式・内容になっているか。
- 異常時の挙動：想定外の入力（空欄のまま登録、極端に大きな数値など）をしたときに、システムが不自然に止まったり誤作動したりしないか。
技術的な内部構造を見るのではなく、「業務目線で約束どおりか」を確認するのが発注者の検収です。確認結果は記録に残しておくと、合否の判断やトラブル時の証拠として役立ちます。具体的なテスト手順とチェックリストは、システム開発の検収・受け入れテストの進め方で詳しく解説しています。
合否を通知するステップ｜受け入れ基準を判断の軸にする
ステップ4では、確認の結果をもとに合格か不合格かを通知します。判断の軸になるのが、「どこまで満たせば合格とするか」という受け入れ基準（合格条件）です。できれば検収の前、理想的には契約や要件定義の段階で取り決めておきます。
受け入れ基準があいまいなまま合否を判断しようとすると、「この程度の不具合は合格としてよいのか」「ここは仕様の範囲内か、欠陥か」といった迷いが生じ、開発会社との認識のズレからトラブルに発展しがちです。合格条件を事前に文書で共有しておけば、合否の通知は「基準を満たしているかどうか」を確認する作業になり、判断の負担が大きく減ります。
すでに契約段階を過ぎていて基準が定まっていない場合でも、合否を通知する前に開発会社と「何をもって合格とするか」をすり合わせておくだけで、判断はずっと楽になります。不具合の重大度の分類や許容範囲の決め方は、システム開発の検収とは？発注者が実施すべき3ステップと合否判断基準で整理しています。
不合格として通知する場合は、「どの部分が、どの仕様に対して、どう不足しているか」を具体的に書面で伝えます。口頭だけで済ませると「言った・言わない」のトラブルにつながります。差し戻しの具体的な手順は、検収を拒否する手順5ステップで解説しています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
検収にサインすると確定すること｜支払い・契約上の意味
検収を不安に感じる最大の理由は、「サインによって何が確定するのか」が見えないことにあります。確定するポイントをここで明確にしておきましょう。
検収合格（ステップ5）で支払い義務が発生する
システム開発の多くは「請負契約」という形で結ばれます。請負契約は、成果物を完成させて引き渡すことに対して報酬を支払う契約です。合格・検収完了に至ると、納品が完了したものとして扱われ、契約で定めた報酬（残額）の支払い義務が発生します（ベリーベスト法律事務所「IT業界における検収とは？」）。
合格の証として、発注者が開発会社に「検収書」や「受領書」を発行するケースもあります。この書面にサインや押印をすることが、実務上の「検収完了」の合図です。検収にサインするとは、「納品物を契約どおりのものとして受け取りました。約束した報酬をお支払いします」という意思表示をすることでもあります。
検収後の追加要望は原則として有償になりやすい
検収が完了するということは、「契約で約束した範囲のものは、契約どおりに納品された」と確定することを意味します。そのため、検収後に「ここも直してほしい」「この機能も追加したい」と依頼すると、それが当初の契約範囲を超える要望である場合、追加費用が発生する有償対応になりやすくなります。
検収前であれば、契約で約束した内容に足りない部分は開発会社が無償で修正する対象です。検収を通すと「契約どおりだった」という前提で扱われるため、後からの注文は新しい依頼になりやすい点に注意してください。
ただし、「サインしたら一切対応してもらえない」わけではありません。検収後に発覚した契約不適合については、開発会社に責任が残る場合があります。この点は後の章で説明します。
検収の知識を発注判断につなげる｜見積・契約・保守で確認したい4点
検収の意味と流れが分かったら、次は発注者としてどの場面で何を決めるかです。検収の条項は、見積・契約・保守のそれぞれの場面で発注者の負担やリスクを左右します。
場面 | 確認したいこと | 検収との関係 |
|---|---|---|
見積・要件定義 | 受け入れ基準（合格条件）と、確認作業に必要な社内の工数 | 基準が曖昧だと合否判断の迷いやトラブルの原因になる |
契約書 | 検収期間の長さと起算日、みなし検収の有無、延長の手続き | 期間内に確認できる体制がないと、意図せず合格扱いになり得る |
契約書・支払条件 | 報酬の支払いが検収完了に連動しているか、支払い時期 | 検収完了が支払い義務の発生点になる |
保守・運用 | 検収後の不具合の対応範囲、保証期間、保守契約との線引き | 契約不適合と追加要望の区別が、無償か有償かを分ける |
見積・契約の段階で決めておくこと
見積や契約の段階では、検収期間を自社の体制で無理なく確認しきれる長さにできているかを確認します。みなし検収の条項があるなら、その期間内に確認作業を終えられるかを逆算してください。また、受け入れ基準を要件定義の段階で文書にしておけば、検収の場面で「何をもって合格か」を議論せずに済みます。
支払条件との結び付きを確認する
検収完了は報酬の支払い義務が発生する節目です。契約書の支払条件が検収完了に連動しているかを確認しておくと、「確認が終わらないうちに支払い期日が来る」といった行き違いを避けられます。サインをする権限者を誰にするか、社内の決裁ルールをどう通すかも、あらかじめ決めておくと安心です。
保守契約との線引きを決めておく
検収後の不具合対応は、契約不適合として無償で求められるものと、契約範囲外の追加要望として有償になるものに分かれます。この線引きは、保守契約や保証期間の定めによっても変わります。検収の前に、検収後の対応範囲と費用の考え方を契約書や保守契約で確認しておくことが、後々の費用トラブルを防ぎます。
検収後に不具合が出たら？｜契約不適合責任との関係
「サインした後で不具合が見つかったら、泣き寝入りするしかないのでは」。この不安は、多くの発注者が検収の最終段階でためらう理由です。結論からいえば、検収にサインしたからといって、開発会社の責任がすべて消えるわけではありません。
なお、契約や責任に関する内容は個別の契約書の文言や状況によって結論が変わります。以下は一般的な考え方の説明であり、実際の対応にあたっては契約書を確認し、必要に応じて弁護士などの専門家に相談してください。
契約不適合責任とは｜検収後も残るベンダーの義務
検収が完了した後でも、納品されたシステムに「契約で約束した内容を満たしていない欠陥（契約不適合）」が見つかった場合、開発会社（受注者）はその責任を負うことがあります。これを契約不適合責任といいます。
契約不適合責任は、2020年の民法改正より前は「瑕疵担保責任（かしたんぽせきにん）」と呼ばれていたものに相当します（発注ラウンジ「瑕疵担保責任とは何か？」）。簡単にいえば、「納品物に契約どおりでない不備があったときに、修補（直すこと）や代金の減額、損害賠償などを請求できる」という、発注者を守るための仕組みです。検収時には気づけなかった隠れた不具合については、開発会社に対応を求められる余地が残っています。
検収サイン＝全責任放棄ではない｜ただし証拠と通知が重要
契約不適合責任を追及するうえで押さえたいのが「通知の期限」です。民法では、請負契約において契約不適合を知ったときから1年以内にその旨を相手方に通知すれば、責任を追及できるとされています（クラフトマン法律事務所「納入後の瑕疵（契約不適合）」）。不具合に気づいたら放置せず、できるだけ早く、書面など記録に残る形で開発会社へ伝えることが重要です。
何が契約不適合（直してもらえる欠陥）にあたり、何が契約範囲外の追加要望（有償対応）にあたるかは、ケースによって判断が分かれます。だからこそ、「何を約束していたか（要件定義・仕様書）」と「何を確認し、どう判断したか（検収の記録）」を残しておくことが、後から契約不適合を主張する際の有力な証拠になります。
契約書に「検収完了から○年間は無償で対応する」といった保証期間を別途定めているケースや、保守契約で対応範囲を取り決めているケースもあります。検収後の不具合への備えとして、こうした条項も確認しておきましょう。
検収トラブルを防ぐポイントと完了確認チェックリスト
最後に、検収をスムーズに進めるための事前の取り決めと、検収を「通すか差し戻すか」を判断するためのチェックリストをまとめます。
トラブルを防ぐ事前の取り決め
検収をめぐるトラブルの多くは、検収そのものよりも「事前の取り決めの不足」から生まれます。次のポイントを契約・準備の段階で押さえておくと、検収はずっとスムーズになります。
- 検収期間を契約で明確にする：確認に必要な期間を、自社の体制で無理なくこなせる長さで契約に定めます。みなし検収の条項がある場合は、その期間内に確認を終えられるかを必ず確認します。
- 受け入れ基準（合格条件）を文書化する：「何をもって合格とするか」を、できれば要件定義の段階で具体的に取り決め、開発会社と共有します。
- 確認結果を記録に残す：何を確認し、どこに問題があり、どう判断したかを記録します。合否の判断材料になるだけでなく、検収後に契約不適合を主張する際の証拠にもなります。
- 不合格通知は書面で具体的に行う：「どの部分が、どの仕様に対して、どう不足しているか」を具体的に書面で伝えます。
完了確認チェックリスト｜合否判断の観点
目の前の検収を「合格として通してよいか、差し戻すべきか」を判断するためのチェックリストです。詳細なテスト実施手順ではなく、合否を判断するための観点に絞っています。
- 要件・仕様との一致：要件定義・仕様書で約束した機能や項目が、抜けなく実装されているか。
- 主要業務フローの完遂：実際の業務で使う一連の操作が、最初から最後まで想定どおりに完了するか。
- データの保存・出力：入力したデータが正しく保存され、帳票やCSVなどの出力が求めた形式・内容になっているか。
- 異常時の挙動：想定外の入力をしても、システムが不自然に止まったり誤作動したりしないか。
- 受け入れ基準の充足：事前に取り決めた合格条件を満たしているか。基準を決めていない場合は、今からでも開発会社とすり合わせたか。
- ドキュメントの受領：操作マニュアルやテスト結果など、運用に必要なドキュメントを受け取っているか。
- 記録の保存：確認した内容と判断を、後から見返せる形で記録に残したか。
- 検収期間の確認：契約上の検収期間（みなし検収の有無を含む）を把握し、その範囲内で判断しているか。
項目を一つずつ満たせていれば、自信を持って合格を判定できます。満たせていない項目があるときは、無理に検収を通さず、その点を具体的に開発会社へ伝えて差し戻すのが適切な判断です。具体的な確認手順はシステム開発の検収・受け入れテストの進め方、不合格として差し戻す手順は検収を拒否する手順5ステップで解説しています。
まとめ
検収とは、納品された成果物が契約どおりかを発注者が確認し、合否を判定する工程です。発注者がすることは、確認する、合否を記録に残る形で通知する、合格ならサインして支払いに進む、の3つです。流れは「納品→検収期間の開始→確認作業→合格または不合格の通知→検収完了（または再納品）」の5ステップで進みます。
検収完了は、報酬の支払い義務が発生し、追加要望が有償になりやすくなる節目です。一方で、検収後に見つかった契約不適合については、開発会社に責任を求められる余地が残ります。検収期間は一般的に2週間から1か月程度が目安とされますが、みなし検収の条項と合わせて、自社の体制で確認しきれるかを契約の前に確認しておくことが重要です。
検収の知識は、用語として覚えるよりも、見積・契約・保守の判断に使ってこそ役に立ちます。受け入れ基準の文書化、検収期間とみなし検収の確認、支払条件との連動、保守契約との線引き。この4点を押さえて、目の前の検収にも落ち着いて向き合ってください。実際の確認作業はシステム開発の検収・受け入れテストの進め方、合否の判断基準づくりはシステム開発の検収とは？発注者が実施すべき3ステップと合否判断基準で確認できます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 検収期間内に確認が終わりそうにない場合はどうすればよいですか？
期限が来る前に開発会社へ連絡し、検収期間の延長を書面やメールで申し入れてください。みなし検収の条項がある場合、放置すると自動的に合格扱いになるため、間に合わない見込みが立った時点で早めに相談することが重要です。
- 口頭で「問題なさそうです」と伝えただけでも検収に合格したことになりますか？
なり得ます。明確な合格通知でなくても、合格とみなせる言動や、みなし検収の期間経過によって検収完了と扱われる場合があります。合否の意思表示は、合格・不合格いずれもメールや検収書など記録に残る形で行ってください。
- 一部の機能だけ不具合がある場合、その部分だけ不合格にできますか？
契約や開発会社との取り決め次第ですが、不具合箇所を指摘して修正・再納品を求めるのが基本です。全体を不合格として差し戻すか、軽微な不具合を残したまま条件付きで合格とするかは、不具合の重大度と業務への影響をもとに開発会社とすり合わせて決めます。
- 検収書へのサインは誰がすべきですか？社内の承認は必要ですか？
検収書へのサイン・押印は支払い義務を確定させる行為のため、契約上の発注者（多くは決裁権を持つ責任者）が行うべきです。担当者が確認した上で、サインの前に社内の決裁ルールに沿った承認を得ておくと、後のトラブルを防げます。
- 検収と受け入れテストは何が違うのですか？
受け入れテストは「仕様どおり動くか」を確認する作業そのもので、検収はその結果をもとに合格・不合格を判定し受け取りを意思表示する契約上の工程です。受け入れテストは検収の中の確認作業（ステップ3）にあたり、その判定が検収全体の結論になります。
