# システム開発の検収方法｜受入テストと注意点

- 公開日: 2026-09-14
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/system-development-acceptance-testing

システム開発の検収では、発注者が契約・要件に照らして納品物を確認し、受領可否を判断します。成功の要点は、発注前に受入基準・期間・不具合の扱いを契約へ明記し、納品前から受入テストを準備することです。期間は小規模で2〜10営業日、中規模で2〜6週間が一般的な目安です。

検収を単なる動作確認や納品書への押印と考えると、公開後に「必要な業務が完了できない」「仕様に含まれると思っていた機能がない」といった問題が起こります。一方、基準を決めずにすべての不具合がなくなるまで検収しない進め方も、判断の長期化や追加費用の原因になります。

本記事では、システム開発を外注する発注者に向けて、検収条件の決め方、受入テストの手順、期間・費用の目安、契約と見積もりの確認点を解説します。

## システム開発の検収とは発注者が納品物を受け入れる判断工程

検収とは、納品されたシステムや関連資料が契約で合意した内容に適合しているかを発注者が確認し、受領するかどうかを判断する工程です。画面が開くかだけでなく、業務目的を達成できること、必要な成果物がそろっていることまで確認します。

受入テスト（UAT＝実際の利用者が業務上使えるかを確かめるテスト）は、検収判断に必要な証拠を集める主要な手段です。ただし、受入テストと検収は同じ意味ではありません。受入テストが技術的・業務的な確認作業であるのに対し、検収は契約に基づく正式な受領判断です。

### 開発会社のテストと発注者の受入テストの違い

| 確認工程 | 主な担当 | 確認する内容 | 判断の例 |
|---|---|---|---|
| 単体・結合テスト | 開発会社 | 個々の機能や機能間の連携 | 計算結果やAPI連携が設計どおりか |
| システムテスト | 開発会社または第三者 | システム全体の品質 | 性能、障害時の挙動、セキュリティなど |
| 受入テスト | 発注者の業務部門・情報システム部門 | 実際の業務を完了できるか | 申請から承認、帳票出力まで進められるか |
| 検収 | 発注責任者 | 契約上の納品条件を満たしたか | 受領、修正後の再検収、検収留保など |

開発会社が行うテストで不具合が見つからなくても、受入テストは必要です。開発会社は仕様どおりに動くことを中心に確認しますが、その仕様で現場業務が本当に成立するかは、発注者側でなければ判断しにくいためです。

一方、システムテストを第三者へ依頼し、性能や複数端末での動作などを詳しく確認したい場合は、[システムテスト費用の相場｜外注範囲と選び方](https://www.geek-bridge.com/column/system-test-outsourcing-cost)も参考にしてください。

### 検収対象はプログラムだけではない

検収対象は、契約や案件によって次のように異なります。

- Webシステムやスマートフォンアプリの本体
- 管理画面、バッチ処理、外部サービスとの連携機能
- ソースコードとリポジトリ（＝ソースコードを管理する保管場所）
- 設計書、テスト結果、操作マニュアル
- データ移行の結果と件数照合表
- クラウド、ドメイン、外部サービスの管理アカウント
- ストア申請や本番環境への公開作業
- ライセンス情報や利用している外部製品の一覧

発注者がよく見落とすのが、アカウントやソースコードの引き渡しです。システムは動いていても、発注者が管理権限を保有していなければ、将来の保守会社変更や追加開発が難しくなります。納品物一覧は契約前に確定し、提出形式や保管場所まで決めておきましょう。

## 検収条件と受入基準は開発前に決める

検収を円滑に進める最も有効な方法は、要件定義（＝作るものを決める工程）の段階で受入基準を決めることです。納品後に基準を作ると、当初仕様の不具合なのか、新しい要望なのかを区別できません。

発注のご相談を受ける開発会社の立場では、開発終盤になって「検収では何を確認すればよいですか」と聞かれることがあります。しかし、検収項目を終盤に作ると、重要な業務条件が仕様へ反映されていないことが判明しても、納期や予算内で修正できない可能性があります。

### 曖昧な要望を測定可能な基準へ変える

「使いやすい」「速い」「十分なセキュリティ」といった表現だけでは、合否を客観的に判断できません。受入基準は、条件、操作、期待結果を第三者が読んでも再現できる形にします。

| 曖昧な基準 | 検収に使える基準の例 |
|---|---|
| 申請できること | 一般社員が必須項目を入力して申請すると、所属長の承認一覧へ表示されること |
| 表示が速いこと | 合意したテスト環境とデータ件数において、対象画面が定めた時間内に表示されること |
| 権限管理ができること | 一般社員は自分の申請のみ、部門長は所属部門、管理者は全件を閲覧できること |
| データ移行が完了すること | 対象件数、金額合計、必須項目、重複件数を照合し、許容差の範囲内であること |
| スマートフォンに対応すること | 合意したOS・端末・ブラウザの組み合わせで主要操作を完了できること |

性能などの数値は、事業上必要な水準から決めます。根拠なく厳しい数値を指定すると開発費が増え、緩すぎると実運用に耐えません。利用者数、繁忙時間、想定データ量、業務への影響を開発会社へ伝え、測定条件と併せて合意してください。

### 不具合の重要度と合否条件を決める

不具合が1件でもあれば不合格とするのではなく、事業への影響で分類して判断する方法が現実的です。

| 重要度 | 状態の例 | 検収判断の考え方 |
|---|---|---|
| 致命的 | システムを利用できない、重大な情報漏えいにつながる | 原則として修正・再テスト後に検収 |
| 重大 | 主要業務を完了できない、データが破損する | 原則として修正・再テスト後に検収 |
| 中程度 | 代替手段はあるが業務負担が大きい | 件数や影響範囲、修正予定を踏まえて判断 |
| 軽微 | 文言、余白、限定的な表示崩れ | 修正期限を書面で合意して受領する場合がある |

軽微な不具合を残して検収する場合は、「後で直す」という口頭合意だけで済ませないことが重要です。不具合番号、対象箇所、修正期限、再確認の方法、費用負担を記録します。条件付きの検収が可能かどうかも契約内容によるため、発注者だけで判断せず開発会社と書面で合意してください。

### 検収条件を決めるチェックリスト

依頼前から開発初期までに、次の項目を整理しておきます。

- [ ] 検収対象となる機能と対象外の機能
- [ ] 納品物の一覧、ファイル形式、提出場所
- [ ] 利用者の役割と権限パターン
- [ ] 業務上必ず成功しなければならない操作
- [ ] 対応する端末、OS、ブラウザ
- [ ] 想定利用者数、データ量、応答時間などの非機能条件
- [ ] 外部システム、決済、メールなどの連携条件
- [ ] データ移行の対象と照合方法
- [ ] 不具合の重要度と検収可能な残件数
- [ ] 検収期間、修正期間、再検収期間
- [ ] 検収完了を通知する担当者と方法
- [ ] 期間内に回答しない場合の扱い
- [ ] 検収後の保証、保守、契約不適合への対応

受入項目の抜けを減らすには、最初に機能の全体像を整理する必要があります。整理方法が分からない場合は、[機能一覧の作り方｜システム開発の依頼準備](https://www.geek-bridge.com/column/system-function-list-preparation)を参照し、各機能へ受入条件をひも付けると確認しやすくなります。

## 受入テストから検収完了までの進め方

受入テストは、納品された後に慌てて始めるのではなく、開発中から準備します。中規模以上の案件では、納品予定日の1〜3週間以上前からテストケースと担当者を確定しておくと進めやすくなります。

### ステップ1．契約書と仕様書から検収範囲を確定する

最初に、契約書、見積書、要件定義書、仕様書、議事録、変更管理表を確認します。資料ごとに内容が異なる場合は、どの文書を優先するか開発会社へ確認してください。

特に、開発中の口頭要望やチャット上の相談が正式な仕様変更として合意されているとは限りません。次の3種類に分けると判断しやすくなります。

1. 当初から契約に含まれる機能
2. 変更手続きを経て追加された機能
3. 将来対応とした要望や契約対象外の機能

検収時に3を「当然含まれている」と主張すると、追加開発費やスケジュールをめぐる認識違いが生じます。変更の合意は、金額、納期、検収基準への影響まで記録しましょう。

### ステップ2．受入テスト計画とテストケースを作る

テストケースとは、確認する条件・操作・期待結果をまとめた項目です。すべての組み合わせを網羅するのが難しい場合は、売上、顧客対応、法令対応などへの影響が大きい業務を優先します。

最低限、テストケースには次の内容を記載します。

- テストケース番号
- 対象機能と関連する要件
- 実施前の条件
- 操作手順と入力データ
- 期待する結果
- 実際の結果
- 合格・不合格・保留の判定
- 画面キャプチャやログなどの証拠
- 実施者と実施日
- 不具合番号

正常に完了する操作だけでなく、入力ミス、権限不足、処理の中断、外部連携の失敗なども確認します。たとえば決済機能であれば、決済成功だけでなく、失敗、キャンセル、二重操作、返金、通知不達の扱いも重要です。

### ステップ3．環境・アカウント・テストデータを用意する

テスト環境は、本番に近い構成であることが望ましいものの、本番データを安易に複製してはいけません。個人情報や機密情報は、マスキング（＝内容を特定できない形へ置き換える処理）したデータやテスト専用データを使います。

準備時には次を確認します。

- 利用者、承認者、管理者など必要な権限のアカウントがあるか
- 外部サービスをテストモードで利用できるか
- メールや通知が実在の顧客へ送信されないか
- 本番相当のデータ件数で性能を確認できるか
- テスト後にデータを初期化できるか
- 不具合確認に必要なログを取得できるか

環境準備の遅れは、実施期間を圧迫します。誰が、いつまでに、何を用意するかを受入テスト計画へ記載してください。

### ステップ4．利用部門を含めてテストを実施する

情報システム部門だけでなく、実際にシステムを利用する業務部門にも参加してもらいます。現場担当者は、開発資料に書かれていない例外処理や繁忙時の運用を把握しているからです。

| 担当 | 主な役割 |
|---|---|
| 事業責任者 | 合否基準、優先順位、検収可否の最終判断 |
| 業務部門 | 実際の業務手順による受入テスト |
| 情報システム部門 | 環境、権限、セキュリティ、運用面の確認 |
| 開発会社 | テスト支援、不具合調査、修正、技術説明 |
| 第三者テスト会社 | 必要に応じた客観的な品質確認 |

不具合を報告するときは、「動かない」だけでは調査に時間がかかります。利用環境、操作手順、入力値、発生日時、期待結果、実際の結果、画面キャプチャを残してください。

### ステップ5．不具合を整理し、修正・再テスト後に検収する

報告された事象は、開発会社と発注者で次のいずれかに分類します。

- 合意した仕様に対する不具合
- 環境や設定の問題
- 操作方法の誤解
- 仕様書にない追加要望
- 調査中で判定できない事象

不具合修正後は、修正箇所だけでなく関連機能も確認します。ある修正によって別の機能へ影響が出ることがあるためです。この確認は回帰テスト（＝修正で既存機能が壊れていないか確かめるテスト）と呼ばれます。

受入基準を満たしたら、契約で指定された方法に従い、検収書やメールなどで検収完了を通知します。未解決事項がある場合は、一覧と対応期限を添付し、双方が同じ内容を保管してください。

### 検収期間の一般的な目安

| 開発規模 | 検収期間の目安 | 想定される内容 |
|---|---:|---|
| 小規模 | 2〜10営業日 | 単一部門、限定的な機能、外部連携が少ない |
| 中規模 | 2〜6週間 | 複数部門、権限管理、帳票、外部連携がある |
| 大規模・基幹系 | 1〜3か月以上 | 多数部門、大量データ移行、複数システム連携がある |

期間は一般的な目安です。機能数が少なくても、利用部門の調整や決裁に時間がかかれば検収期間は長くなります。反対に、短期間へ圧縮すると重要な例外処理を確認できません。希望公開日から、修正と再テストの予備期間を含めて逆算しましょう。

## 検収の費用・契約・開発会社選びで失敗を防ぐポイント

検収にかかる費用は、受入テストを社内で行うか、開発会社や第三者へどこまで依頼するかで変わります。見積もりでは、テスト準備、実施支援、不具合修正を分けて確認することが重要です。

### 検収・受入テスト支援の費用相場

| 支援内容 | 費用の一般的な目安 | 主な作業 |
|---|---:|---|
| 小規模な受入テスト支援 | 20万〜80万円 | 計画、主要ケース作成、実施支援 |
| 中規模な受入テスト支援 | 80万〜300万円 | 複数業務・権限のケース作成、進捗管理、再テスト |
| 大規模・基幹系の支援 | 300万円以上 | 多部門調整、大量データ、外部連携、長期間の管理 |
| 第三者による品質確認 | 50万〜300万円以上 | 独立したテスト設計・実施・報告 |

金額は一般的な目安であり、機能数、端末数、データ移行、性能・セキュリティ確認、支援期間によって大きく変わります。また、表の金額は社内の人件費を含みません。業務部門がテストに参加する時間も、発注者側の工数として予算とスケジュールに入れてください。

不具合修正費の扱いは契約によって異なります。請負契約（＝完成した成果物に対して報酬を支払う契約）で、合意仕様との不一致に該当する修正は当初費用に含まれることが一般的ですが、追加機能や仕様変更は別費用になります。準委任契約（＝一定の業務遂行に対して報酬を支払う契約）では、調査や修正にも作業時間に応じた費用が発生する場合があります。

### 見積もりで確認する項目

検収支援の見積書では、総額だけでなく次の内訳を確認します。

- 受入テスト計画の作成費
- テストケースの作成数と対象範囲
- テスト環境とデータの準備費
- テスト実施時の立ち会い・問い合わせ対応費
- 不具合の調査・修正費
- 修正後の再テスト費
- 端末、OS、ブラウザの対象数
- 進捗管理と結果報告書の作成費
- 期間延長時の追加単価
- 出張や端末購入などの実費

特に注意したいのは、「不具合修正一式」という曖昧な記載です。仕様不一致の修正と追加要望をどう区別するか、何回までの再テストが含まれるかを確認してください。

### 契約書で確認する条項

契約締結前には、少なくとも次の項目を確認します。

- 納品物と納品方法
- 納品日、検収開始日、検収期間
- 検収基準と参照する仕様書
- 不合格の通知方法と期限
- 修正および再検収の手順
- 期間内に通知しない場合の見なし検収
- 検収前に本番利用を始めた場合の扱い
- 検収と請求・支払時期の関係
- 契約不適合責任の期間と対応範囲
- 保証期間と保守契約の役割分担
- ソースコード、知的財産権、アカウントの引き渡し

見なし検収とは、一定期間内に発注者から不合格の通知がなければ、検収したものと扱う定めです。社内承認に時間がかかる企業では、検収期間が短すぎると確認前に期限を迎える可能性があります。

契約不適合責任とは、納品物が契約で合意した内容と異なる場合に、修補などを求めるためのルールです。適用条件や期間は契約によって異なるため、重要案件では法務担当者や弁護士にも確認してください。

### 検収に強い開発会社を見極める質問

開発会社の比較では、開発実績だけでなく、納品・検収までの進め方を質問します。

| 質問 | 評価したい回答 | 注意したい状態 |
|---|---|---|
| 受入基準をいつ決めますか | 要件定義中に要件とひも付けて決める | 納品後に確認すればよいと説明する |
| テストケースは誰が作りますか | 発注者と役割を分担し、業務部門も確認する | 開発会社だけで完結させる |
| 不具合の重要度はどう判断しますか | 業務影響と客観的基準で分類する | 担当者の感覚だけで判断する |
| 修正後は何を確認しますか | 関連機能を含めて回帰テストする | 修正箇所だけを見る |
| 納期が遅れた場合はどうしますか | 検収期間を削らず計画を再調整する | 検収を省略して公開を優先する |
| 納品時に何を引き渡しますか | ソース、資料、アカウントを具体的に示す | プログラム本体しか説明しない |

品質への質問に対して、ツール名や専門用語だけでなく、発注者がどの時点で何を判断するかまで説明できる会社を選びましょう。検収を開発の最後にある形式的な作業ではなく、要件定義から続く品質管理として扱っているかが重要です。

### よくある失敗と回避策

| よくある失敗 | 起こり得る問題 | 回避策 |
|---|---|---|
| 納品後にテスト項目を考える | 確認漏れ、期間不足 | 開発中に計画と担当者を決める |
| 正常な操作しか確認しない | 例外処理や権限の不具合を見逃す | エラー、取消、重複操作も確認する |
| 業務部門が参加しない | 現場の運用に合わない | 重要業務の担当者を実施者に含める |
| 不具合を口頭やチャットだけで伝える | 再現できず、修正漏れが起こる | 番号、手順、証拠、状態を一覧管理する |
| すべての不具合を同じ扱いにする | 判断が長期化する | 業務影響に応じて重要度を分類する |
| 検収前に本番利用を開始する | 障害時の責任や支払いが曖昧になる | 先行利用の条件を契約で決める |
| 軽微な残件を口頭で先送りする | 検収後に対応されない | 修正期限と費用負担を書面化する |

検収条件、契約、テスト体制を案件に合わせて整理したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。

## まとめ

- 検収は、発注者が納品物を契約・要件と照合して正式に受領する判断工程です
- 受入テストは検収の根拠を集める作業であり、開発会社のシステムテストとは目的が異なります
- 受入基準は納品後ではなく、要件定義や契約締結の段階で決めます
- 合否条件は、不具合ゼロではなく、業務影響に基づく重要度と許容条件で定めます
- 検収期間の目安は、小規模で2〜10営業日、中規模で2〜6週間、大規模・基幹系で1〜3か月以上です
- 受入テスト支援の費用は、小規模で20万〜80万円、中規模で80万〜300万円、大規模では300万円以上が一般的な目安です
- 契約書では、検収期間、見なし検収、不合格通知、修正・再検収、契約不適合責任を確認します
- 開発会社を選ぶ際は、要件定義から検収を設計し、発注者の役割まで具体的に説明できるかを見極めます

## よくある質問

### システム開発の検収期間はどのくらい必要ですか？

一般的な目安は、小規模なら2〜10営業日、中規模なら2〜6週間、大規模・基幹系なら1〜3か月以上です。機能数だけでなく、利用部門数、外部連携、権限パターン、データ移行の確認量を踏まえて決めます。

### 不具合が1件でも残っていると検収できませんか？

必ずしも不具合をゼロにする必要はありません。業務停止やデータ破損につながる重大な不具合は解消を原則とし、軽微な表示崩れなどは修正期限と対応方法を書面で合意したうえで検収する方法があります。最終的には契約と受入基準に従って判断します。

### 検収後に不具合が見つかった場合はどうなりますか？

契約不適合責任、保証期間、保守契約などの定めに基づいて対応します。ただし、当初仕様との不一致なのか、追加要望なのかで費用負担が変わるため、再現手順と証拠を残し、仕様書や議事録と照合することが重要です。

### 受入テストを開発会社へ任せてもよいですか？

テストケース作成や実施作業は開発会社へ依頼できますが、業務上受け入れられるかという最終判断は発注者が担うのが基本です。開発会社のテスト結果だけに頼らず、実際の利用部門が重要業務を確認する体制を整えましょう。