システム開発の検収とは｜納品時の確認項目と進め方
システム開発の検収は、納品されたシステムが、事前に合意した内容を満たしているかを発注側が確かめ、受け入れるかどうかを判断する手続きです。この記事では、検収の意味と契約上の位置づけ、確認すべき観点、進め方、そしてよくあるトラブルとその防ぎ方を整理します。
検収で大切なのは、納品日に慌てて確認を始めることではありません。開発が始まる前に「何をもって合格とするか」を決めておくことで、検収はずっと落ち着いて進められます。
システム開発の検収とは何か
検収は「受け入れの判断」
検収とは、納品された成果物を発注側が確認し、契約で合意した内容どおりに出来上がっているかを判断して、受け入れる手続きのことです。「納品」は開発会社が成果物を渡す行為、「検収」は受け取った側が中身を確かめて受け入れる行為、と分けて考えると分かりやすくなります。
システムは、建物や家具のように目で見てすぐに良し悪しが分かるものではありません。画面が表示されても、裏側のデータの扱いや、特定の操作をしたときの挙動に問題が残っていることがあります。だからこそ、受け入れる前に確認する時間と手順が必要になります。
契約上の意味
検収には、実務上いくつかの意味があります。
- 成果物を受け入れたという、発注側の意思表示になる
- 多くの契約で、支払いの条件や時期の基準になる
- 検収後に見つかった不具合の扱い（修正の責任）を考える起点になる
どの時点で何が決まるかは、契約書の内容によって変わります。契約を結ぶ前に、検収の条項を読んで確認しておくことが大切です。
また、契約の形によっても検収の位置づけは異なります。成果物の完成を約束する「請負契約」では、検収は完成を確認する重要な節目です。一方、作業の遂行そのものを約束する「準委任契約」では、完成の保証を前提としないため、検収の考え方が変わります。この違いは、受託開発とは？依頼の流れ・契約形態・新規事業の選び方でも整理しています。
検収の前に決めておく「検収基準」
基準がないと、合否が決まらない
検収でもっとも多いつまずきは、「何をもって合格とするか」が決まっていないことです。基準がなければ、発注側は「思っていたものと違う」と感じ、開発側は「合意した仕様どおりに作った」と考えるという、平行線になりかねません。
検収基準は、契約や要件定義の段階で、次のような形で決めておくと運用しやすくなります。
- 確認する機能の一覧（どの機能を、どの順番で確認するか）
- 各機能の合格条件（どういう結果が出れば合格か）
- 不具合が見つかったときの扱い（重大度の分け方と、修正の期限）
- 検収にかける期間と、確認する担当者
- 合格・不合格を判断する人
要件の段階であいまいだった箇所は、検収の場で争点になりやすい部分です。要件を先に固める考え方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で詳しく扱っています。
重大度を分けておく
不具合は、すべてが同じ重さではありません。たとえば次のように分けておくと、検収の判断がしやすくなります。
- 重大：主要な機能が使えない、データが壊れる、など。修正されるまで合格にしない
- 中程度：使えるが、手順が不便、表示が崩れる、など。修正の時期を相談して決める
- 軽微：文言の誤りや、見た目の細かな違い、など。後日の修正でもよいか話し合う
この分け方を事前に合意しておくと、「小さな不具合が残っているから、全体を不合格にするのか」といった議論を避けられます。
検収で確認する4つの観点
1. 機能：決めたことができるか
もっとも基本になるのが、機能の確認です。要件定義書や仕様書に書かれた機能が、そのとおりに動くかを一つずつ確かめます。
確認するときは、正常な操作だけでなく、次のようなケースも試します。
- 入力が空のまま送信する、極端に長い文字を入れる
- 同じ操作を続けて何度も行う
- 権限の違うユーザーで、同じ画面を開く
- 途中で画面を戻る、ブラウザを閉じて再度開く
「正しく使ったときに動く」だけでは、実際の運用で問題が起きる可能性が残ります。利用者は、開発側が想定した順番どおりには操作してくれないからです。
2. 非機能：速さ・安全性・使いやすさ
機能が動くことと同じくらい、非機能の確認も重要です。非機能とは、機能そのものではなく、システムの品質に関わる性質のことで、たとえば次のようなものがあります。
- 性能：画面の表示や処理にかかる時間は、想定の利用人数で許容できるか
- セキュリティ：権限の管理、通信の保護、入力値の検証などが考慮されているか
- 操作性：初めて使う人が、迷わずに操作できるか
- 可用性：障害が起きたときの復旧の手順は決まっているか
非機能は、要件として数値や条件で書かれていないと、検収では確認しにくい部分です。「ある程度速く」といった表現ではなく、「一覧画面は何秒以内に表示する」のように、確かめられる形で決めておくことが重要です。
AIを使って作られたコードを受け取る場合の安全面の確認点は、AI生成コードのセキュリティ｜確認点と人の役割で整理しています。
3. データと環境：本番で動くか
開発側の環境で動いていても、本番の環境で同じように動くとは限りません。検収では、次の点も確かめます。
- 本番と同じ構成のテスト環境で動作するか
- 既存データの移行が必要な場合、移行後のデータが正しいか
- 外部サービス（決済、メール送信、認証など）との連携が正しく動くか
- バックアップと復元の手順が用意されているか
外部サービスとの連携は、テスト用の設定では問題なくても、本番の設定に切り替えると動かない、ということが起こり得ます。本番に近い条件での確認を、検収の工程に入れておくと安心です。
4. 成果物と引き継ぎ資料
システムが動くことに加えて、運用を続けるために必要なものが揃っているかも確認します。
- ソースコードと、その権利の扱い
- 設計書、データベースの定義書、画面の一覧
- 環境の構築手順、運用の手順書
- 管理画面の使い方や、問い合わせ時の対応方法
特にソースコードの権利は、契約の内容によって帰属が異なります。契約前の確認点は、システム開発の著作権帰属は誰のもの？契約前の確認点にまとめています。
資料が整っていないと、担当者が変わったり、別の会社に保守を引き継いだりするときに困ります。AIが生成したコードを含む場合の保守の観点は、AI生成コードの保守は可能か｜引き継ぎと改修の確認点でも扱っています。
検収の進め方：準備から合否判断まで
ステップ1：確認のシナリオを作る
機能の一覧をそのまま眺めるのではなく、実際の業務や利用の流れに沿った「シナリオ」を作ると、抜けが減ります。たとえば会員制のサービスなら、次のような流れです。
- 新規に会員登録する
- ログインして、プロフィールを編集する
- サービスの主要な機能を利用する
- 退会し、データが想定どおりに扱われるか確かめる
シナリオごとに「期待する結果」を書いておき、実際の結果と照らし合わせて、合格・不合格を記録していきます。
ステップ2：確認する人を決める
検収は、開発の担当者だけで行うものではありません。実際にシステムを使う人や、事業の責任者が加わることで、「仕様どおりだが使いにくい」といった問題に気づきやすくなります。
ここで重要になるのが、発注側で判断する人を決めておくことです。確認のたびに意見が割れ、判断が止まってしまうと、検収が長引きます。発注側の役割は、発注側のプロダクトオーナーとは｜役割と判断のしかたで詳しく扱っています。
ステップ3：不具合を記録して共有する
不具合が見つかったら、次の内容を記録して、開発側と共有します。
- どの画面で、どの操作をしたか
- 期待した結果と、実際の結果
- 画面の写真や、表示されたメッセージ
- 重大度の判断
口頭だけのやり取りでは、後から「言った・言わない」になりやすくなります。一覧にまとめ、修正の状況が見えるようにしておくと、再確認の手間も減ります。
ステップ4：修正後に再確認する
修正が入ったら、不具合が直ったことだけでなく、周辺の機能に影響が出ていないかも確認します。ある箇所の修正が、別の箇所の挙動を変えてしまうことがあるためです。すでに合格とした機能のうち、関連する部分は再度確認しておくと安心です。
こうした確認は、人が行う部分と、テストを自動化して効率を上げる部分に分けられます。自動化の考え方は、AIのテスト自動生成｜任せる範囲と人が見る確認項目で整理しています。
ステップ5：合否を判断し、記録を残す
基準を満たしていれば、検収完了として受け入れの手続きを行います。このとき、検収の完了を示す書面（検収書など）を取り交わすのが一般的です。残っている軽微な不具合があれば、その扱い（いつまでに、誰が修正するか）も記録しておきます。
検収でよくあるトラブルと防ぎ方
基準があいまいなまま進んでしまう
先ほど触れたとおり、検収基準が決まっていないと、合否の判断で意見が分かれます。防ぐには、契約や要件定義の段階で、確認する項目と合格の条件を文書にしておくことです。
「不具合」と「追加の要望」が混ざる
検収の場で、「ここも変えてほしい」という要望が出ることがあります。これが、合意した仕様どおりに動いていない「不具合」なのか、仕様に入っていなかった「追加の要望」なのかは、費用や期限の扱いが変わるため、区別が必要です。
区別するための拠り所は、合意した仕様の記録です。仕様の記録が口頭だけだと、判断が難しくなります。仕様の伝え方に不安がある場合は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせが参考になります。
検収の期間が確保されていない
納品の直後に、数日で確認を終えなければならない、というスケジュールは危険です。発注側の担当者も通常の業務を抱えているため、確認の時間を確保できないまま期限を迎えることがあります。
契約では、検収の期間が定められていることが多く、その期間内に連絡がない場合は合格とみなす（みなし検収）という条項が置かれることもあります。条項の有無と内容は、契約前に読んで、確認できる期間があるかを見ておきましょう。スケジュールに関わる原因と対策は、システム開発が遅延する原因と、発注時にできる防ぎ方にもまとめています。
検収が「形式的な確認」で終わる
「動いているようだから、合格にしよう」と、短い時間で済ませてしまうケースもあります。しかし、検収後に不具合が見つかった場合、修正の扱いが検収前とは変わる可能性があります。形式的に済ませず、確認の時間をしっかり取ることが、結果的に自分たちを守ります。
検収を通った後に残ること
検収後の不具合の扱い
検収に合格した後でも、運用を始めてから不具合が見つかることはあります。請負契約の場合、民法には「契約不適合責任」という考え方があり、引き渡された成果物が契約の内容に適合しないときに、修正などを求められる場合があります。ただし、通知の期限などの条件があり、契約で別の定めを置くこともあります。実際の扱いは契約書の内容と、必要に応じて専門家の確認によって判断してください。
なお、経済産業省が公表している「情報システム・モデル取引・契約書」は、システム開発の契約の考え方を整理した資料で、検収や契約不適合の扱いを考えるときの参考になります。
保守・改善の体制
システムは、納品して終わりではなく、使いながら直し、育てていくものです。検収の後に、誰が保守を行い、機能の追加はどう扱うのかが決まっていないと、運用で行き詰まります。検収の前に、保守の範囲と窓口を確認しておきましょう。納品後の考え方は、システムは納品後の改善で育てる｜新規事業の考え方で扱っています。
新規事業のシステム開発で、検収を楽にする考え方
新規事業のシステムは、要件を最初に細かく固めきれないことが多くあります。市場の反応を見ながら、作るものが変わっていくためです。そうした場合、納品の最終日にすべてを一度に検収する進め方は、負担が大きくなりがちです。
負担を減らす考え方として、次のようなものがあります。
- 開発の途中で、動く実物を見ながら確認を重ねる
- 最初は小さな範囲に絞って作り、確認を済ませてから広げる
- 合格の基準を、事業として確かめたいこと（利用者が使うか、業務が回るかなど）と結びつけて決める
実物を見ながら確認する機会が早い段階にあると、「納品されたら思っていたものと違った」という事態は起こりにくくなります。小さく作って確かめる進め方は、新規事業の開発は小さく作って確かめる投資判断の進め方にまとめています。
また、検収を含む外注全体の流れや、失敗しないための確認点は、システム開発の外注ガイド｜依頼の流れと失敗の防ぎ方で整理しています。すでに外注でうまくいかなかった経験がある場合は、システム開発の外注で失敗後のやり直し｜再依頼の見直し点も役に立ちます。
AIを使った開発でも、受け入れる側の確認が不要になるわけではありません。品質を判断する人の役割は、AI開発でも品質には人の確認が必要な理由で解説しています。
まとめ
システム開発の検収は、納品されたシステムが事前の合意どおりに出来ているかを確かめ、受け入れるかどうかを判断する手続きです。要点は次のとおりです。
- 検収は、支払いや検収後の不具合の扱いに関わる重要な節目になる
- 開発が始まる前に、検収基準（確認する項目、合格の条件、不具合の重大度）を決めておく
- 確認の観点は、機能、非機能（性能・安全性・操作性）、データと環境、成果物と引き継ぎ資料の4つ
- 不具合と追加の要望を区別するため、合意した仕様を文書で残す
- 検収の期間と、判断する担当者を確保する
- 新規事業では、実物を見ながら早い段階で確認を重ねると、最終の検収の負担が小さくなる
検収を楽にする近道は、納品の日ではなく、開発を始める前の準備にあります。何を確かめれば合格と言えるのかを、先に言葉にしておくことが大切です。
JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただける受託開発サービスです。検収で「思っていたものと違った」が起こりにくい進め方を考えている新規事業の担当者の方は、JustFitのサービス紹介もご覧ください。