システム開発の検収期間の目安｜期間の決め方・延長対応・トラブル防止策

検収期間とは？まず基本を整理しよう

検収期間とは、システム開発において発注者が納品物を受け取ってから、合格・不合格を判定するまでの期間のことです。

この期間中に発注者は、システムが要件通りに動作するかを確認し（受入テスト）、問題がなければ検収書を発行します。検収が完了すると、受注者（開発会社）への代金支払いが確定します。

検収期間は「単なるチェック作業の時間」ではなく、責任の所在とお金が動く法的にも重要な期間です。適切に設定・管理しないと、後々のトラブルにつながります。

検収期間の一般的な目安

業界の相場として、システム開発の検収期間は以下が目安です。

ただし、これはあくまで目安です。確認すべき機能の数・複雑さ・社内の担当者リソースによって変わります。

検収期間を決める5つのポイント

「とりあえず2週間」と決めてしまいがちですが、適切な期間を設定するには以下の5点を考慮してください。

1. 確認すべき機能・画面の数

機能数が多いほど確認に時間がかかります。事前に「何を・何人で・どれくらいかけて確認するか」をリストアップしましょう。確認項目が100を超える場合、1週間では現実的に足りないことが多いです。

2. 担当者の稼働状況

検収の実務を担う社内担当者が、検収期間中にどれくらい時間を使えるかを事前に把握してください。「繁忙期と重なる」「担当者が出張中」といった事情があれば、その分の余裕を期間に盛り込みます。

3. 外部連携・決済の動作確認

決済サービスや外部APIとの連携があるシステムは、テスト環境での動作確認に追加の工数がかかります。特に本番環境に近い条件でのテストが必要な場合は、1週間程度の追加バッファを設けると安心です。

4. 社内の承認フロー

経営者の最終確認や複数部門の承認が必要なケースでは、担当者レベルの技術確認が終わっても承認が下りるまで時間がかかります。社内の意思決定スピードを考慮した期間設定が必要です。

5. 不具合修正の往復回数

検収中に不具合が見つかった場合、修正→再確認のサイクルが発生します。開発会社の修正対応スピードにもよりますが、1〜2回の往復を想定した期間を確保しましょう。

契約書への「検収期間」の記載方法

検収期間は必ず契約書に明記してください。曖昧な表現はトラブルの原因になります。

明記すべき4つの項目

特に「期間内に通知がない場合はみなし検収」の条項は、発注者にとって不利に見えますが、開発会社側の資金繰りを保護する合理的な条件です。ただし、検収作業ができなかった「正当な理由」がある場合の例外規定も設けておくと安心です。

検収期間が延長される主な原因

実際のプロジェクトでは、当初設定した検収期間を超えてしまうケースが少なくありません。主な原因は以下の通りです。

発注者側の原因

• 担当者のリソース不足：繁忙期と重なり、確認作業に時間を割けない
• 確認範囲の拡大：「ついでにここも確認してほしい」という追加要望
• 社内合意形成の遅延：部門間の意見が分かれ、承認が下りない
• 仕様認識の齟齬：「思っていたものと違う」という認識のずれが発覚

受注者（開発会社）側の原因

• 不具合の修正対応が遅い：担当者の体制が変わり、修正に時間がかかる
• ドキュメントの不備：操作マニュアルや設計書が不足していて確認できない

検収期間の延長を申請する場合の手順

やむを得ず検収期間の延長が必要になった場合は、以下の手順で対応しましょう。

1. 延長理由の明確化：「不具合が多い」「担当者が不在」など具体的な理由を文書化
2. 必要な追加期間の算出：感覚ではなく、残りの確認タスクから逆算して算出
3. 開発会社への書面での通知：口頭ではなくメール等で記録を残す
4. 双方の合意確認：延長後の新しい検収期限を明記した合意書を取得

「みなし検収」とは？発注者が知るべきリスク

多くのシステム開発契約では、「検収期間内に発注者が合否の通知をしない場合、検収完了（合格）とみなす」という条項が含まれています。これをみなし検収といいます。

みなし検収が成立すると：

• 代金支払い義務が発生する
• その後の不具合は「瑕疵担保責任（契約不適合責任）」の対象外になる可能性がある
• 追加の修正対応は有償扱いになることがある

「忙しくて後回しにしていたら、気づいたら検収完了になっていた」という事態を防ぐため、納品を受けたら速やかに検収スケジュールを組むことが重要です。

検収期間に関するトラブル防止のための事前準備

1. 受入テスト計画を事前に作成する

検収が始まってから「何を確認すればいいか」を考えていては時間がかかりすぎます。要件定義・設計の段階から、どんなシナリオでテストするかを計画しておきましょう。

2. 検収担当者を専任で確保する

「誰でもいいから空いている人が確認する」という体制では、確認の質が下がります。プロジェクトのことをよく知っている担当者を検収期間中に確保してください。

3. 不具合の重要度分類を事前に合意する

すべての不具合が検収NG理由になるわけではありません。「軽微な表示のズレ」と「機能が動かない」では重大度が違います。不具合の重要度（Critical / Major / Minor）の定義と、各レベルの対応方針を事前に合意しておくと、トラブルが減ります。

4. 変更要望と不具合を切り分ける

検収期間中に「やっぱりここを変えたい」という変更要望が出ることがあります。これは不具合ではなく仕様変更なので、追加費用が発生するケースがほとんどです。検収作業と変更要望を混在させると、プロジェクトが終わらなくなります。

まとめ：検収期間は「事前設計」で9割決まる

システム開発の検収期間は、発注時点での「事前設計」が成功を左右します。

• システム規模に応じた適切な検収期間（1〜4週間が目安）を設定する
• 契約書に検収完了条件・期間・みなし検収の条件を明記する
• 検収担当者のリソースを事前に確保する
• 受入テスト計画を要件定義段階から準備する
• 不具合と変更要望を明確に切り分ける

検収の「何を確認するか」については システム開発の検収・納品ガイド を、具体的なチェックリストは システム開発の検収チェックリスト をあわせてご覧ください。