検収とは？システム開発での意味・進め方とチェックリスト

システム開発の終盤で出てくる「検収（けんしゅう）」。聞き慣れない言葉ですが、発注側にとって重要な最終チェックの工程です。ここを流してしまうと、後から不具合が見つかっても「もう検収を通したのだから」と有償対応になったり、支払いだけ済んで肝心の業務が回らなかったりします。逆に、検収の勘どころを押さえておけば、発注側の立場をしっかり守れます。この記事では、検収とは何か、どんな流れで進むのか、何をチェックすればいいか、検収書の書き方、支払い・責任との関係、そしてトラブルを防ぐ進め方までを、初めての方向けに整理して解説します。

検収とは

検収とは、納品されたシステムが要件どおりに作られているかを確認し、「これで完了」と認める工程です。検収が済むと正式に納品完了となり、支払いや保守フェーズへ移ります。いわば「受け取り確認」の場で、ここで問題を見つければ修正を求められます。

似た言葉に「納品」「検品」「受入テスト」がありますが、意味が少しずつ違います。整理すると次のとおりです。

用語	意味
納品	開発側が完成物（システム・ソースコード・マニュアル等）を引き渡すこと
検収	発注側が納品物を確認し「要件どおり」と認めること
受入テスト	検収の中で発注側が実際に操作して行う確認作業
検収完了	検収に合格し、正式に取引が完了した状態

ポイントは、**検収は「開発側の作業」ではなく「発注側の権利であり責任」**だということです。開発側が「できました」と言っても、発注側が確認して合格を出すまで完了にはなりません。ここが、発注側が主導権を持てる数少ない場面です。裏を返せば、発注側が確認をおろそかにすると、その責任も発注側に返ってきます。

検収の流れ

検収は「受け取って終わり」ではなく、いくつかの段階を踏みます。一般的な流れは次の5ステップです。

1. 受け取り（納品）：開発側からシステム・ドキュメント・ソースコードなどを受け取る。まず「約束したものが揃っているか」を目録で確認する。
2. テスト（受入テスト）：発注側が実際に操作し、決めた機能が動くか、業務データで正しく処理されるかを確認する。
3. 指摘（不具合報告）：見つかった不具合や要件との違いを、一覧にまとめて開発側へ伝える。口頭ではなく書面・チケットで残す。
4. 修正（手直し）：開発側が指摘を修正し、再度納品する。修正箇所だけでなく、周辺機能に影響が出ていないかも再確認する。
5. 合格（検収完了）：すべての指摘が解消され、合格基準を満たしたら検収書を交わして完了する。

この「指摘→修正→再確認」は1回で終わらないこともあります。あらかじめ検収期間を何日確保するか、修正の往復を何回まで見込むかを決めておくと、スケジュールが崩れにくくなります。実務では、初回テストで指摘を洗い出し、修正版で再テスト、という2〜3周を想定しておくと安心です。

検収前にやっておく準備

検収は「その日にいきなり触る」とうまくいきません。事前の準備で精度もスピードも変わります。受け取る前に、次を整えておきましょう。

• テストデータを用意する：本番に近い件数・パターンの業務データを準備する。少量のきれいなデータだけでは、本番で起きる問題を見つけられない。
• 受入テストの観点を書き出す：チェックしたい機能・業務シナリオを一覧にしておく。「注文を登録→在庫が減る→帳票に出る」のように、業務の流れ単位で確認項目を作ると漏れにくい。
• 確認する担当を決める：機能はシステム担当、業務の妥当性は現場担当、というように役割を割り振る。
• 合格基準を再確認する：発注時に決めた基準を手元に出し、それに沿って判定する。

準備の質が、検収の質をほぼ決めます。逆に、準備なしで臨むと「なんとなく動いていそう」で合格を出してしまい、後で困りがちです。受け取ってから慌てて準備を始めると、限られた検収期間を準備で使い切ってしまうため、納品の少し前から準備を進めておくのが理想です。

検収でチェックすべき項目

検収では「動くかどうか」だけでなく、業務で本当に使えるかを多面的に見ます。最低限、次の4カテゴリを押さえましょう。

チェック項目	確認内容
機能	決めた機能がすべて動くか
実データ	実際の業務データで正しく動くか
不具合	エラーや不具合がないか
納品物	マニュアル・ソースコード等が揃っているか

これをさらに具体化した実践チェックリストが以下です。項目ごとに「合格／不合格／保留」を付けていくと、抜け漏れを防げます。

• 機能（要件との一致）
  • 要件定義で決めた機能が、すべて実装されているか
  • 画面の項目・ボタン・メニューが仕様どおりか
  • 権限（管理者／一般ユーザー等）の出し分けが正しいか
• データ（正確性）
  • 実際の業務データを入れて、集計・計算結果が正しいか
  • 登録・編集・削除が想定どおり反映されるか
  • 文字化け・日付のズレ・桁あふれなどが起きないか
  • CSVやExcelの取り込み・書き出しが崩れないか
• 性能（実用に耐えるか）
  • 普段使う件数のデータでも、表示や検索が待たされないか
  • 複数人が同時に使ってもエラーにならないか
  • スマホ（iOS／Android）でも表示・操作できるか
• ドキュメント（引き継ぎ・運用）
  • 操作マニュアル・管理者向け手順が揃っているか
  • ソースコード一式を受け取れるか（権利の所在も確認）
  • 障害時の連絡先・保守条件が書面で示されているか

可能なら、実際に使う現場の人にも触ってもらうと、見落としを防げます。作った人・発注担当者だけで確認すると「本来の使い方」でしか触らず、現場特有の操作でのバグを見逃しがちだからです。

検収書の役割と書き方

検収書とは、検収が完了したことを証明する書類です。検収書を交わすことで「要件どおり納品された」ことが確定します。後の「言った・言わない」を防ぐためにも、検収の記録は大切です。

検収書には主に3つの役割があります。

• 完了の証明：発注側が納品物を確認し、合格と認めたことを示す。
• 支払いの根拠：多くの契約で、検収完了が支払いの条件になっている。
• 責任の起点：検収後に見つかった不具合の扱い（契約不適合責任）を判断する基準になる。

記載しておきたい項目

検収書の書式に決まりはありませんが、最低限、次の項目を入れておくと後で困りません。

記載項目	内容の例
件名・案件名	「○○管理システム開発」など対象を特定できる名称
発注者・受注者	双方の会社名・担当者名
検収日	検収を行い合格と判断した日付
検収対象	納品物の一覧（システム・マニュアル・ソースコード等）
検収結果	合格／条件付き合格／不合格
残課題	条件付き合格の場合、いつまでに何を直すか
署名・押印	双方の確認の証

「条件付き合格」を用意しておくのがコツです。軽微な指摘が残っていても、期限を明記して先に検収を通せば、支払いと残作業を切り分けられます。すべて完璧になるまで検収を出さない、という運用は双方にとって重くなりがちです。

不合格・保留のときの対応

要件を満たさない重大な不具合があれば、無理に合格を出す必要はありません。その場合は次のように進めます。

• 不合格の理由を具体的に書く：「動かない」ではなく「どの機能が、どの条件で、どうなるか」を記録する。開発側が再現・修正しやすくなる。
• 修正の期限を決める：いつまでに直し、いつ再検収するかを合意する。期限がないと、そのまま宙に浮きやすい。
• 支払いの扱いを確認する：検収完了が支払い条件なら、合格が出るまで支払い義務は基本的に生じない。ここを曖昧にしない。

大切なのは、感情的に「受け取らない」と突き放すのではなく、何が満たされれば合格なのかを明文化して返すことです。基準が共有できていれば、修正のゴールもはっきりします。

検収と支払い・契約不適合責任の関係

検収は、お金と責任に直結する工程です。ここを理解しておくと、判断に迷いません。

• 支払いとの関係：多くの契約では「検収完了をもって支払う」と定めます。つまり、急いで検収を通すと、未確認のまま支払い義務が発生します。確認が済むまで安易に合格を出さないのが基本です。
• 契約不適合責任（旧・瑕疵担保責任）との関係：検収後に、要件を満たさない不具合が見つかった場合、開発側に修正（追完）や代金減額などを求められる制度です。ただし「いつまで請求できるか（期間）」「どこまでが対象か」は契約次第です。一般に、不具合を知ってから1年以内に通知する、といった定めを置くケースが多く見られます。

注意したいのは、検収に合格してしまうと「確認できたはずの不具合」は指摘しにくくなる点です。だからこそ、検収の段階でしっかり見ることが、後の自分たちを守ります。整理すると、検収の前後で立場は次のように変わります。

タイミング	発注側の立場
検収前	自由に指摘でき、合格を出さない限り支払い義務も生じにくい
検収後	完了扱いとなり、支払いが発生。以降の不具合は契約不適合責任の枠で対応

請負と準委任で責任の考え方が変わる点は、請負と準委任の違いもあわせてご覧ください。保守や不具合対応の範囲は、検収前に契約で決めておくと安心です。

検収期間の目安と注意

検収期間は契約で定めるのが一般的で、納品から1〜2週間程度を設定するケースが多く見られます。小規模なら数日、業務が複雑で確認項目が多ければ1カ月ほど確保することもあります。目安は次のとおりです。

システムの規模	検収期間の目安
小規模（画面数が少ない・単機能）	数日〜1週間
中規模（複数機能・複数ユーザー）	1〜2週間
大規模（基幹業務・連携多数）	2週間〜1カ月

注意点として、**「検収期間内に指摘がなければ自動的に合格とみなす」という条項（みなし検収）**が契約に入っていることがあります。うっかり期間を過ぎると、確認していなくても合格扱いになりかねません。受け取ったらすぐ確認に着手し、時間が足りなければ早めに延長を相談しましょう。繁忙期と重ならないよう、検収に人手を割ける時期を逆算してスケジュールを組むのも実務のコツです。

なお、検収期間は「長ければ安心」というものでもありません。期間が空くほど、開発側の記憶も薄れ、修正対応が後回しになりがちです。短すぎず、間延びしすぎない期間を、規模に応じて現実的に見積もるのが肝心です。あわせて、いつ・誰が・何を確認するかを最初に段取りしておけば、限られた期間でも密度の高い検収ができます。

トラブルを防ぐ進め方

検収トラブルの多くは、「合格基準があいまい」なことが原因です。次の3点を押さえるだけで、大きなもめごとはかなり防げます。

• 検収基準を契約で決める：「どうなったら合格か」を発注前に、できれば契約書や仕様書に文章で残す。「主要機能が業務データで正常動作すること」など、判断できる書き方にする。
• 途中でMVPを確認する：早い段階で実物（最小構成）を見ておくと、検収時の大きなズレを防げる。完成してから初めて見ると、直しが大がかりになる。
• 現場を巻き込む：実際に使う人の視点でチェックする。日々その業務をしている人ほど、実務での不具合に気づきやすい。

合格基準を先に決めておくと、指摘のときに「これは基準を満たしていない」と根拠を持って伝えられます。基準がないと「言った・言わない」の水掛け論になりがちです。発注全体の流れは発注の流れ7ステップ、失敗を避ける観点はシステム開発の失敗事例も参考になります。

検収でよくある落とし穴

初めての検収で陥りやすいパターンを知っておくと、事前に避けられます。

• 開発側に確認を丸投げする：「向こうがテストしたから大丈夫」と発注側が触らない。検収は発注側の責任であり、自分たちで確認しないと意味がない。
• 正常系しか試さない：うまくいく操作だけ試して、異常な入力・想定外の順番を試さない。現場では想定外がよく起きる。
• 少量データだけで判断する：数件のデータでは問題なくても、本番の件数で遅くなる・エラーになることがある。
• 口頭で指摘する：「あの画面が変」と口頭で伝えると記録が残らず、直ったかどうかも曖昧になる。指摘は必ず一覧・書面で残す。
• 期限を意識しない：みなし検収の条項に気づかず、確認しないまま期間が過ぎて合格扱いになる。

これらは、前述のチェックリストと準備を押さえておけば、ほとんど防げます。「面倒だから」と省いた確認ほど、後から大きな手戻りになって返ってくると考えておくとよいでしょう。

例：検収基準を決めずに困ったケース

たとえば、ある会社が在庫管理システムを発注し、検収基準を決めないまま「動けば良い」で進めたとします。納品後に「検索が遅い」「スマホで崩れる」と指摘したところ、開発側は「速度や対応端末は要件になかった」と主張。結局、追加費用を払って直すことになりました。

一方、別の会社は発注時に「1万件のデータで検索が3秒以内」「スマホでも主要操作ができる」と基準を文章で決めていました。納品物がこれを満たさなかったため、追加費用なしで修正してもらえました。違いは技術力ではなく、合格基準を先に言葉にしていたかどうかです。一般化すれば、検収は「終盤の作業」ではなく「発注時に基準を決めた瞬間から始まっている」といえます。

一律料金なら検収も安心

D-oneAppは最短2〜3週間でMVPをお出しし、作りながら実物を確認していく進め方が基本です。早い段階から実物を見られるので、検収時に「思っていたのと違う」という事態を防げます。料金も一律100万円（プロは200万円）で総額が固定なので、検収で修正が出ても追加費用が発生しません。「指摘したら費用が増えるのでは」という遠慮なく、納得いくまで確認していただけます。ソースコードの権利もお渡しするため、検収時に納品物一式をきちんと受け取れます。

まとめ

検収とは、納品物が要件どおりかを確認し「完了」と認める工程です。受け取り→テスト→指摘→修正→合格の流れで進み、機能・データ・性能・ドキュメントの4観点をチェックリストで確認するのが基本。検収書には検収日・対象・結果・残課題を残し、支払いや契約不適合責任の起点になることも押さえておきましょう。何よりのトラブル防止策は、合格基準を発注時に契約・仕様書で言葉にしておくことです。途中で実物を確認しておくとさらに安心です。発注の進め方は無料相談でもご案内します。