システム開発の検収・納品ガイド｜検収基準の決め方とトラブル防止策

検収・納品はシステム開発の「最重要関門」

システム開発において、検収（けんしゅう）は「発注者が成果物を確認し、合格・不合格を判定するプロセス」です。検収が完了すると、受注者は代金を請求でき、発注者は成果物を正式に受け取ったことになります。

つまり検収は、お金と責任が動く「最重要関門」です。にもかかわらず、多くのプロジェクトで検収基準が曖昧なまま開発が進み、最終段階で「思っていたものと違う」「これでは検収できない」というトラブルが発生します。

この記事では、検収トラブルを防ぐための基準の決め方から、受入テストの進め方、検収書の書き方までを解説します。

検収の基本的な流れ

一般的なシステム開発の検収フローは以下のとおりです。

1. 納品 — 受注者がシステム・ドキュメントを発注者に引き渡す
2. 受入テスト（UAT） — 発注者が検収基準に基づいてテストを実施
3. 不具合報告 — テストで発見した不具合を受注者に報告
4. 修正・再テスト — 受注者が修正し、発注者が再確認
5. 検収合格 — 検収基準を満たしたことを確認し、検収書に署名
6. 代金支払い — 検収完了後、契約条件に従って支払い

検収期間は契約で定めるのが一般的で、中小規模のプロジェクトでは2週間〜1ヶ月程度が目安です。

検収基準の決め方

検収トラブルの最大の原因は「検収基準が曖昧」であることです。「ちゃんと動くこと」のような基準では、何をもって合格とするかで揉めます。

検収基準に含めるべき項目

• 機能要件の充足 — 要件定義書に記載された機能がすべて実装されているか
• 非機能要件の充足 — 性能（レスポンス3秒以内等）、可用性（稼働率99.5%等）、セキュリティ要件
• 不具合の許容範囲 — 重大バグ0件、中程度バグ3件以内、軽微バグ10件以内、など
• ドキュメントの納品 — 設計書、操作マニュアル、テスト結果報告書の提出
• テスト結果 — 受注者側のテスト結果報告書で一定のカバレッジ・合格率を達成

不具合の重要度分類

検収基準で不具合の許容範囲を定める際は、重要度を分類して基準を設定します。

契約書への盛り込み方

検収基準は要件定義書や契約書の別紙として定めるのが一般的です。以下の点を明記しましょう。

• 検収期間（納品後○営業日以内）
• 検収基準（上記の項目）
• 不具合発見時の対応フロー
• 検収に合格しなかった場合の取り扱い（再修正の回数上限、契約解除条件）
• 「みなし検収」条項 — 検収期間内に発注者が異議を述べない場合、検収合格とみなす

受入テスト（UAT）の進め方

UAT（User Acceptance Test）は、発注者が実際にシステムを操作して、業務で使えるかを確認するテストです。受注者側の結合テスト・総合テストとは異なり、「業務目線で使えるか」を確認するのがポイントです。

UATの準備

• テストシナリオの作成 — 実際の業務フローに沿ったテストケースを作成。日常業務だけでなく、例外処理（エラー時・取消時等）も含める
• テスト環境の準備 — 本番に近い環境（テストデータ含む）を用意。受注者に依頼して準備してもらう
• テスト担当者のアサイン — 実際にシステムを使う業務担当者が参加するのが理想。IT部門だけでテストすると業務的な問題を見落とす
• 不具合報告のルール — 報告フォーマット、連絡先、重要度の判定基準を事前に決める

UATで確認すべきポイント

• 正常系 — 主要な業務フローが正しく動作するか
• 異常系 — エラー入力、不正操作、同時アクセス時の動作
• データ移行 — 旧システムから移行したデータが正しく表示されるか
• 帳票・レポート — 出力される帳票の内容・レイアウトが正しいか
• 権限制御 — ユーザーの役割に応じてアクセス制限が正しく機能するか
• 性能 — 大量データ時のレスポンス、一覧画面の表示速度
• 操作性 — 業務担当者が迷わず操作できるか

検収書の書き方と法的な意味

検収書に記載すべき事項

• 発注者名（会社名・代表者名）
• 受注者名（会社名・代表者名）
• プロジェクト名・契約書番号
• 納品物の一覧（システム名、ドキュメント名、データ等）
• 検収日
• 検収結果（合格・条件付き合格・不合格）
• 条件付き合格の場合の条件（残存不具合の修正期限等）
• 双方の署名・押印

検収の法的な効果

検収書に署名すると、法的には以下の効果があります。

• 代金支払い義務の発生 — 検収合格をもって、発注者に支払い義務が確定
• 危険負担の移転 — 検収後にシステムに問題が生じた場合、原則として発注者の管理責任
• 契約不適合責任の起算点 — 民法改正後は「契約不適合責任」となり、検収後に発見された不具合は一定期間内（契約で定めた期間、なければ1年）に通知すれば修補請求可能

だからこそ、検収は「なんとなく合格」にしてはいけません。不明点や懸念事項は検収前に解決するか、条件付き検収として残存課題を明記しましょう。

検収トラブルの事例と防止策

トラブル①：「思っていたものと違う」

状況：完成したシステムのUIや動きが、発注者のイメージと異なる

原因：要件定義が抽象的で、具体的な画面イメージを共有していなかった

防止策：プロトタイプやワイヤーフレームで早期に画面イメージを確認。中間成果物のレビューポイントを設ける

トラブル②：検収が延々と終わらない

状況：不具合を直すたびに新しい要望が出て、検収が進まない

原因：検収基準が曖昧で、スコープが膨らんでいる（スコープクリープ）

防止策：検収基準を事前に明確化。要件定義にない機能は「追加開発」として別契約に切り分け

トラブル③：軽微な不具合を理由に検収拒否

状況：致命的な不具合はないが、細かい不具合を理由に検収を拒否される

原因：不具合の重要度分類と許容範囲が定められていない

防止策：不具合の重要度分類を契約時に合意。「条件付き検収」（軽微な不具合は検収後に修正）の仕組みを導入

トラブル④：納品物が不足している

状況：ソースコードは納品されたが、設計書やマニュアルがない

原因：納品物の範囲が契約書に明記されていない

防止策：契約書に納品物一覧を別紙として添付。ドキュメントの種類・粒度・フォーマットまで指定

あわせて読みたい

• システム開発の契約ガイド｜請負・準委任・SESの違いと注意点
• システム開発のNDA（秘密保持契約）｜テンプレートと締結時の注意点
• システム開発トラブルの法的対応｜瑕疵担保・損害賠償・契約解除
• 要件定義のやり方｜システム開発を成功させる最初のステップ
• 【2026年版】システム開発の費用相場まとめ｜種類別・規模別に徹底解説

まとめ

• 検収はお金と責任が動く最重要関門。曖昧な基準では必ず揉める
• 検収基準は開発前に決める。要件定義と一緒に合意するのがベスト
• 不具合の重要度分類を設定。致命的・重大は0件必須、軽微は検収後修正OK
• UATは業務担当者が参加。IT部門だけでなく実際のユーザーがテストする
• 検収書には法的効果がある。安易に署名せず、懸念事項は検収前に解決
• 「みなし検収」条項を契約に入れ、検収が無期限に延びるリスクを防ぐ

システム開発の契約・検収でお困りの方は、お問い合わせからご相談ください。FUNBREWでは、要件定義から検収まで、透明性の高いプロジェクト運営をサポートしています。