「検収」とは?納品時に確認すべきこと — 動作確認・データ・引き渡し物
「検収」の意味と重要性、納品時に確認すべき動作確認・実データ・権限・引き渡し物のチェックリスト、検収期間の目安、不具合発見時の伝え方を中立的に解説します。
「検収」とは何か
「検収」(けんしゅう)とは、発注者がシステムやソフトウェアの納品物を検査し、契約や仕様書で合意した内容通りに完成しているかを確認したうえで、正式に受け入れる手続きを指します。システム開発の実務では、検収が完了した時点で「納品が完了した」という区切りになるのが一般的で、それ以降に見つかった不具合は「契約不適合」として別途対応を求める形になることが多く、検収前の指摘とは扱いが変わってきます。そのため検収は単なる形式的な手続きではなく、発注者にとって「何を確認し、何を確認しないまま受け入れてしまうか」を左右する重要な工程です。発注の全体像についてはシステム開発発注ガイドでも整理していますが、本記事では検収そのものに焦点を当てて解説します。
なぜ検収が重要なのか(背景)
検収が重要視される背景には、システム開発が「形のない成果物」を扱う取引であるという特性があります。建物や機械であれば納品時に目視で状態を確認しやすい一方、ソフトウェアは外見だけでは動作の正しさを判断できません。画面は表示されていても、特定の条件で計算結果がずれていたり、実データを入れた途端に処理が止まったりするケースは珍しくありません。また検収は「支払いのタイミング」とも密接に関わっています。多くの契約では、検収完了をもって残代金の支払い義務が発生する、あるいは請求書の発行条件になっているため、検収を急いで終わらせてしまうと、後から見つかった不具合の交渉材料を失いやすくなります。逆に検収基準が曖昧なまま契約を進めてしまうと、発注者・開発会社の双方が「どこまで確認すれば完了とみなせるのか」で認識がずれ、トラブルの火種になります。
検収を曖昧にすると起きる問題(課題の構造)
検収の課題は大きく3つの構造に分けられます。1つ目は「確認範囲の曖昧さ」で、契約書や仕様書に検収基準が明記されておらず、発注者側の担当者の主観で合否を判断してしまうケースです。2つ目は「確認体制の偏り」で、情報システム部門やプロジェクト担当者だけで検収を完結させてしまい、実際にシステムを使う現場の意見が反映されないまま受け入れてしまうケースです。3つ目は「時間的な制約」で、検収期間が短く設定されている、あるいは業務都合で確認が後回しになり、契約上の検収期間を過ぎて「みなし検収」(一定期間内に異議を申し立てなければ検収完了とみなす条項)が成立してしまうケースです。これらはいずれも、検収を「受け入れる側の権利」として十分に活用できていない状態と言えます。追加費用トラブルの多くも検収時の確認不足が発端になっていることがあり、追加費用トラブルを防ぐ方法と合わせて把握しておくと、発注全体のリスクを下げやすくなります。
仮検収と本検収の違い(中立比較)
| 項目 | 仮検収 | 本検収 |
|---|---|---|
| タイミング | システム稼働直後・試験運用期間中に実施することが多い | 一定の運用期間を経て、問題がないことを確認したうえで実施することが多い |
| 目的 | 明らかな不具合や仕様漏れの有無を早期に洗い出す | 契約内容通りに完成しているかを最終確認し、正式に受け入れる |
| 支払いとの関係 | 契約によっては一部支払いのトリガーになる場合がある | 残代金の支払い義務が発生する契約が多い |
| 見つかった不具合の扱い | 修正を前提に本検収へ進むことが多い | 契約不適合責任の対象として別途協議になることが多い |
検収チェックリスト
検収時に確認すべき項目は契約や仕様書の内容によって異なりますが、中小企業がシステムを発注する際に共通して押さえておきたい項目を整理すると、次のようになります。
- 主要機能の動作確認: 仕様書・要件定義書に記載された機能が、記載通りの手順・条件で動作するかを一通り確認する
- 実データでの確認: サンプルデータではなく、実際の業務データ(またはそれに近いデータ量・形式)を使って処理速度やエラーの有無を確認する
- 権限・セキュリティの確認: ユーザーごとの権限設定が仕様通りに機能しているか、想定外のユーザーが操作できてしまう箇所がないかを確認する
- 異常系の確認: 誤った入力や想定外の操作をした場合に、エラーメッセージが適切に表示されるか、システムが停止しないかを確認する
- 引き渡し物一式の確認: ソースコード、設計書・マニュアル類、各種アカウント(サーバー・ドメイン・外部サービスの管理権限など)が契約通りに引き渡されているかを確認する
- 運用・保守条件の確認: 検収後の保守対応の範囲や条件が契約書・保守費用の考え方と齟齬がないかを確認する
検収期間の目安と社内の回し方
検収期間は契約によって異なりますが、1〜2週間程度に設定されるケースが一般的です。ただしこれはあくまで目安であり、システムの規模や業務への影響度によって、双方合意のうえで調整することが可能です。重要なのは、検収を情報システム部門や特定の担当者だけで完結させず、実際にそのシステムを日常的に使う現場の担当者に触ってもらう機会を設けることです。現場でしか気づけない「使いにくさ」や「業務フローとのズレ」は、開発側の視点だけでは見落とされがちです。検収期間内に現場確認のスケジュールを組み込み、指摘事項を整理して開発会社に伝える体制を、契約前の段階からある程度想定しておくと、検収がスムーズに進みやすくなります。
不具合を見つけたときの伝え方
検収中に不具合や仕様との相違を見つけた場合は、感覚的な印象ではなく、再現手順を明確にして伝えることが重要です。「いつ・どの画面で・どのような操作をしたら・何が起きたか(期待していた結果と実際の結果の違い)」を整理し、可能であればスクリーンショットや操作動画を添えて開発会社に共有すると、修正対応がスムーズに進みます。また指摘事項は口頭のやり取りだけで終わらせず、メールやチケット管理ツールなど記録に残る形で伝えることも大切です。検収期間内に指摘した内容と、その後の対応状況を一覧化しておくと、検収完了の判断材料としても、後日の認識合わせの材料としても役立ちます。
よくある質問
検収後に不具合が見つかった場合、もう対応してもらえないのですか?
契約内容によりますが、多くの契約には契約不適合責任に関する条項があり、検収後に見つかった不具合であっても、一定期間・一定条件のもとで無償修正を求められる場合があります。ただし対応範囲や期間は契約書の記載によって異なるため、契約書の該当条項を確認することが重要です。
検収期間中に確認が終わらなかった場合はどうなりますか?
契約に「みなし検収」の条項がある場合、定められた期間内に異議を申し立てなければ、自動的に検収完了とみなされることがあります。確認に時間がかかりそうな場合は、期限内に開発会社へ延長を相談することが望ましいです。
検収は誰が担当するべきですか?
プロジェクトの発注担当者だけでなく、実際にシステムを使用する現場の担当者を含めて確認する体制が望ましいとされています。役割分担や最終的な合否判断者は、社内であらかじめ決めておくとスムーズです。
まとめ
検収は、システム開発における「納品の区切り」であると同時に、発注者が最後にシステムの品質を確認できる重要な機会でもあります。チェックリストを事前に用意し、実データでの確認や現場担当者の参加を組み込むことで、検収後に「こんなはずではなかった」という事態を避けやすくなります。検収基準や検収後の対応については契約書の記載内容によって扱いが異なるため、疑問点がある場合は契約書を確認し、必要に応じて開発会社や専門家に相談しながら進めることをおすすめします。
お気軽にご相談ください
お問い合わせ