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