システム開発が完了し、開発会社から「検収をお願いします」と連絡が来たとき、発注者としてどう対応すればよいのか分からず困ったことはありませんか。
「システムが動いているからOKかな」と判断したいところですが、「合格にしてしまったら後から問題が出たときに自分の責任になるのではないか」「不合格にすると開発会社との関係が悪化するかもしれない」という板挟みの状況に追い込まれる発注者は少なくありません。
技術的な知識がなくても、検収で確認すべきことは実は明確に定義できます。重要なのは「何を確認するか」だけでなく、「どういう状態を合格とするか」という基準を事前に設定することです。
本記事では、非エンジニアの発注者が安心して検収を実施するための3ステップの手順と、合格・不合格の判断基準の設定方法を解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム開発の検収とは——発注者にとっての法的意味と責任範囲
検収とは、納品されたシステムが契約上の仕様を満たしているかを発注者が確認し、「受け取ります」という意思表示を行う手続きです。検収が完了すると、開発会社への報酬支払い義務が確定します。
発注者にとって重要なのは、検収が単なる「動作確認」ではなく、法的な効果を伴う手続きであるという点です。
検収とは「受け取りの意思表示」——支払いが確定するタイミング
請負契約（固定金額でシステムを発注する形式）では、原則として「成果物の完成・引き渡し」の時点で報酬支払い義務が発生します。しかし実務上は、発注者が検収を完了した時点をもって支払いの確定とすることが一般的です。
つまり検収は、発注者が「仕様通りのシステムを受け取りました」と確認し、それを開発会社に伝える意思表示です。検収前は発注者が自由に不備を指摘できる期間であり、検収完了後は原則として「仕様通り受け取った」という合意が成立します。
検収後に問題が見つかった場合の発注者の権利（契約不適合責任）
「検収してしまったら、後から問題が出ても自分の責任になるのでは？」という不安を持つ発注者は多いです。しかし、これは誤解です。
2020年4月の民法改正により、旧法の「瑕疵担保責任」は「契約不適合責任」へと改められました。改正後の制度では、発注者は契約不適合（仕様と異なる不具合）を知ってから1年以内に通知すれば、開発会社に対して修正・補修、代金減額、損害賠償などを請求できます（民法562条〜564条）。
なお、「知ってから1年」という民法上の規定は、契約書で別途定めることが可能です。実務では「検収後1年間」と明示する契約が多く、契約書の該当条項を確認しておくことが重要です。
ポイント: 検収を完了しても、後から仕様との不一致が判明した場合は修正を請求できます。「検収したら終わり」ではありません。
「みなし検収」とは——検収期間を過ぎると自動合格になる理由
契約書に「みなし検収条項」が設けられているケースがあります。これは「検収期間内に合理的な根拠を示して不合格通知をしなかった場合、検収に合格したものとみなす」という規定です。
東京地裁の令和4年6月22日判決では、みなし検収条項の有効性が認められています。この条項がある場合、検収期間を過ぎてから「実はこんな問題があって」と言っても、法的には検収完了扱いになる可能性があります。
対応策: 契約書に「みなし検収条項」がある場合は、検収期間内に必ず確認を完了するか、期間延長を文書で申請することが必要です。
非エンジニアが実施できる検収の3ステップ
技術的な知識がなくても実施できる検収の進め方を、3つのステップで解説します。
Step 1 — 業務フローテスト：「実際の業務手順」で最初から最後まで操作する
最も重要なのは、「自分たちが実際の業務でシステムを使う手順」をそのまま再現することです。開発会社が作成したテストシナリオに沿うだけでなく、自社固有の業務フローで試す必要があります。
進め方:
- 「月末の締め処理」「受発注の登録から請求書発行まで」のように、業務の開始から完了までを1本のシナリオとして定義する
- 実際の業務データ（テスト用のダミーデータ）を使って操作する
- 途中で詰まった場所、予想と異なる挙動をした場所をすべてメモする
確認すべき典型的な業務フロー例:
- 新規データの登録 → 承認 → 参照 → 更新 → 削除
- 月次集計 → CSV出力 → 別システムへのインポート
- 複数人が同時に同じデータを操作したときの挙動
具体的な操作手順のチェックリストについては、システム開発の検収・受け入れテストの進め方も合わせて参照してください。
Step 2 — 異常ケース確認：「やってはいけない操作」でシステムが壊れないか確認する
正常な操作だけでなく、「誤入力」や「予期しない操作」を行ったときにシステムが適切に対応するかを確認します。
確認する異常ケースの例:
ケース | 確認内容 |
|---|---|
必須項目を空欄にして登録ボタンを押す | エラーメッセージが表示され、登録されないこと |
数値フィールドに文字を入力する | エラーになること。システムがクラッシュしないこと |
同じデータを二重登録しようとする | 重複エラーが出るか、または設計通りの動作をすること |
権限のないユーザーでアクセスを試みる | アクセスが拒否されること |
エンジニアが「異常系テスト」と呼ぶこれらの確認は、実は発注者が最もやりやすい確認項目です。「こういう使い方をしたらどうなるだろう」という視点で操作するだけで実施できます。
Step 3 — データ整合性確認：登録したデータが正しく保存・集計されているか確認する
システムに入力したデータが正しく保存・計算・表示されているかを確認します。特に以下の点は必ず確認してください。
確認内容:
- 入力したデータが一覧画面に正しく表示されるか
- 集計・合計の計算値が正しいか（Excelなどで手計算した値と照合する）
- データを更新・削除した後、関連する画面にも反映されているか
- 期間を変えて検索したとき、正しい件数・内容が表示されるか
このステップは技術的な知識なしに実施できる上、業務に直結する問題を発見しやすい確認です。
合格・不合格の判断基準の設定方法——検収前に合意すべき3つの合格条件
検収で最も多い失敗は、「何をもって合格とするか」を事前に決めていないことです。判断基準が曖昧なまま検収を迎えると、発注者は判断に迷い、開発会社とのコミュニケーションも難しくなります。
「バグゼロ」を合格基準にしてはいけない理由——重大度分類の考え方
「バグが1つもない状態」を合格基準にすることは現実的ではありません。どんなシステムにも多少の不具合は存在し、開発完了後のシステムで完全なゼロを求めると、検収が永遠に完了しません。
代わりに、バグを重大度で分類し、「重大度別の許容件数」を合格基準にすることが実践的です。
重大度 | 定義 | 合格基準の例 |
|---|---|---|
致命的（クリティカル） | 業務が完全に停止する。データが消える | 件数ゼロが合格条件 |
重大（メジャー） | 主要機能が使えない。業務に大きな支障がある | 件数ゼロが合格条件 |
軽微（マイナー） | 使えるが一部の動作がおかしい。見た目の問題 | 期限付きで修正対応を条件に合格可 |
要望（エンハンスメント） | 今回の仕様に含まれない改善要望 | 合格条件から除外（追加開発として別途協議） |
この分類を開発会社と事前に合意しておくことで、「この不具合は不合格にすべきか」という判断が明確になります。
検収仕様書に書くべき3つの合格条件
合格基準を文書化した「検収仕様書」（または検査仕様書）を、できれば要件定義の段階で作成することを推奨します。最低限、以下の3点を文書化してください。
合格条件1: 機能要件の充足 要件定義書に記載された機能が、仕様通りに動作すること。具体的には、要件定義書の各機能項目に対して「動作確認済み/未確認/不合格」を記録できるチェックシートを作成します。
合格条件2: 重大度分類による不具合の許容基準 上記の重大度分類に基づき、「致命的・重大バグはゼロ件」「軽微バグは期限付き修正対応」という基準を明記します。
合格条件3: 検収期間と再検収のルール 検収期間（例: 納品から2週間）と、不合格の場合の修正期限・再検収の手続きを明記します。
「これは検収対象か？」——追加要件と仕様範囲の境界線の引き方
検収時によく起きるトラブルが、「この機能が使いにくいから修正してほしい」という追加要望を不合格の理由として主張するケースです。
重要な原則: 検収の合否判定は「要件定義書・仕様書に記載された内容との一致」を基準にします。検収期間中に新たに気づいた「こうしてほしかった」は、今回の検収対象外です。
- 仕様書に記載されていない機能への要望 → 追加開発として別途契約・費用が発生する
- 仕様書の記載が曖昧だった場合の解釈の違い → 開発会社と協議し、書面で合意を取る
この区別を明確にすることが、開発会社との良好な関係を維持しながら適切に不合格判断を下すための基本です。
AI機能を含む場合の追加確認項目
近年、AIチャットボット・文章生成・自動分類などのAI機能を含むシステムの開発依頼が増えています。AI機能を含む場合は、通常の検収に加えて以下の確認が必要です。
AI機能の「精度基準」——何件中何件正解すれば合格とするか
AI機能は「100%正確に動く」ことが保証されない点が、通常の機能との最大の違いです。「問い合わせの文章を分類する機能で、100件中何件以上正しく分類できれば合格か」のような精度基準を事前に合意しておく必要があります。
精度基準の設定例:
- 「テスト用100件のデータのうち、90件以上が正しいカテゴリに分類されること」
- 「過去1ヶ月の実データ50件で動作確認し、明らかな誤回答が5件以下であること」
精度基準が契約書・仕様書に記載されていない場合は、検収前に開発会社と文書で合意することを強く推奨します。
ハルシネーション（誤回答）の確認方法と許容基準の設定
生成AI機能（文章生成・Q&Aチャット等）を含むシステムでは、AI が存在しない情報を事実のように出力する「ハルシネーション」が発生する可能性があります。
確認方法:
- 答えが分かっている質問（例: 自社の住所・代表者名・商品の仕様）をシステムに入力し、正しく回答するかを確認する
- 「あり得ない質問」（例: 存在しない製品名への問い合わせ）への回答が適切に処理されるか確認する
許容基準の例:
- 「提供したデータベース内の情報への質問に対して、明らかな事実誤認の回答率が5%以下であること」
- 「回答の根拠となる情報源を明示できること」
AI機能の品質は統計的なものであるため、「1回でも誤回答したら不合格」ではなく「一定の確率での誤回答を許容するが、その割合に上限を設ける」という考え方が現実的です。
不合格にした場合の進め方と契約不適合責任の関係
不合格を通知することは、発注者の正当な権利です。適切な手続きに従えば、開発会社との関係を悪化させることなく不合格判断を下せます。
不合格通知の正しい書き方——「気になる点がある」ではなく具体的な不具合を記録する
不合格を通知する際は、口頭ではなく書面（メール可）で行い、以下の内容を明記します。
不合格通知書に含める内容:
項目 | 記載例 |
|---|---|
不合格の根拠 | 「要件定義書 第3条 受発注管理機能のうち、月次集計機能が動作しない」 |
再現手順 | 「管理画面 → 月次集計 → 2026年4月を選択 → 集計ボタンを押す → エラーが発生する」 |
重大度分類 | 「重大（Major）: 主要業務フローが停止するため」 |
修正期限の要求 | 「〇月〇日までに修正の上、再納品を依頼します」 |
曖昧な表現（「なんか動かない気がする」「使いにくい」）は不合格の根拠として認められにくい場合があります。具体的な再現手順を記録することが、発注者を守る上で重要です。
「修正しての再検収」と「合格後の契約不適合責任追及」の使い分け
検収時に問題を発見した場合、対応方法は大きく2つに分かれます。
パターン1: 検収不合格 → 修正 → 再検収
- 対象: 致命的・重大な不具合
- 手順: 不合格通知書を発行 → 開発会社が修正 → 再度検収を実施
- メリット: 問題が解決された状態で正式に受け取れる
パターン2: 検収合格 → 後日、契約不適合責任として請求
- 対象: 軽微な不具合や、後から発覚した問題
- 条件: 契約不適合を知ってから1年以内（契約書の条項を要確認）
- 注意: この選択肢は「完全には満足していないが、業務に差し支えないので一旦受け取る」場合に有効
通常は「致命的・重大バグは不合格 → 修正後に再検収」「軽微バグは合格後に別途修正依頼」という使い分けが実務的です。
検収は「開発会社を困らせる手続き」ではなく、「発注者として納得のいくシステムを受け取るための権利行使」です。合格基準を事前に合意し、手順に従って確認することで、検収は発注者にとってもシステム開発会社にとっても公平な手続きになります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
