検収（受け入れテスト）で確認すべきこと

開発会社から「完成しました。ご確認ください」と連絡が来たとき、何をどこまで確認すれば「受け取った」と言えるのでしょうか。検収（納品物が契約どおりか発注側が確認し、受け入れを認める手続き）は、Webシステム開発の中で発注側が主役になる数少ない工程です。この記事では、検収を手順に分けて、確認すべき点と記録の残し方を整理します。

検収は「作られたもの」と「頼んだもの」を照合する作業

検収でよくある誤解は、「動けば合格」と考えてしまうことです。検収の本質は、要件定義（作るものと目的を決める工程）や設計書で合意した内容と、実際に納品されたものを照らし合わせることにあります。

請負契約（完成に対して対価を払う契約）では、検収の完了が支払いの条件になるのが一般的です。つまり検収は、発注側が「これで完成と認める」と表明する行為でもあります。

手順1: 検収条件を契約と要件定義で確認する

テストを始める前に、何をもって合格とするかを確認します。契約書や発注書に「検収条件」「検収期間」の記載があるはずなので、まずそこを読み直してください。

• 検収の対象範囲: 今回の納品に含まれる機能と、次回以降に回された機能の区別
• 合格の基準: 全機能が動くことか、重大な不具合がないことか
• 検収期間: 納品から何日以内に結果を伝えるか（期間内に連絡がないと合格とみなす条項があることが多い）
• 不合格時の扱い: 修正後に再検収するか、部分的に受け入れるか

要件定義書や基本設計・詳細設計の設計書があれば、そこに書かれた機能一覧が検収のチェックリストの土台になります。文書がない場合は、見積書の明細や打ち合わせの議事録から機能一覧を作り、開発会社と「この一覧で確認します」と認識を合わせてから始めてください。

手順2: テスト項目を業務の流れに沿って作る

テスト項目は、機能を一つずつ確認する「機能単位」と、実際の業務を最初から最後まで通す「業務シナリオ」の二段構えで作ると漏れが減ります。

想定例：受注管理システムの検収では、「受注を登録し、納品書を出力し、月末に売上を集計する」という一連の流れを、実際の過去データを使って通してみます。単体では動く機能が、つなげると入力値が引き継がれない、といった不具合はシナリオを通してこそ見つかります。

テスト項目は開発会社が用意する場合もありますが、業務を知っているのは発注側です。開発会社の項目に、自社の業務で特に重要な場面や、例外的な処理（返品、キャンセル、期末処理など）を足してください。

手順3: ステージング環境で実施する

検収は本番環境ではなく、ステージング（本番と同じ構成で用意した確認用の環境）で行うのが原則です。本番で試すと、テスト用のデータが実データに混ざったり、確認中の不具合が実際の利用者に影響したりします。

実施するときの注意点は次のとおりです。

• 実際に業務を行う担当者が操作する。発注担当者だけで済ませない
• 本番に近いデータ量で試す。少ないデータでは速度の問題が見えない
• スマートフォン、複数のブラウザ、社内の実機など、実際の利用環境で確認する
• 結果を項目ごとに記録し、「たぶん大丈夫」を残さない
• 検収期間の中で、修正と再確認の時間を見込んでおく

手順4: 不具合を記録し、原因を切り分ける

見つかった問題は、そのすべてが開発会社の責任とは限りません。記録するときに、次の三つに切り分けておくと、後の交渉が円滑になります。

記録には、操作手順、期待した結果、実際の結果、画面のスクリーンショット、発生日時を残します。

手順5: 検収書を作成し、残課題を明記する

すべての確認が終わったら、検収書（受け入れを認める書面）を作成します。開発会社の書式がある場合も多いですが、次の内容が含まれているか確認してください。

• 検収の対象（システム名、納品物の一覧、版）
• 検収日と検収者
• 合格・条件付き合格・不合格の別
• 条件付き合格の場合、残っている課題と対応期限
• 仕様の認識違いとして協議した項目と、その結論

軽微な問題が残っていても、業務に支障がなければ「残課題を明記した上で検収する」という選択は現実的です。逆に、重大な不具合を残したまま期限に追われて検収してしまうと、以後の修正が有償扱いになる可能性があります。

契約不適合責任との関係

検収後に不具合が見つかった場合、契約不適合責任（納品物が契約内容に適合しない場合に、修補や代金減額などを求められる責任）が問題になります。検収を通過しても責任が消えるわけではありませんが、契約書で「検収後一定期間内」のように期間が定められていることが一般的です。

大切なのは、検収時点で「何が合意した仕様か」を文書で示せる状態にしておくことです。仕様が曖昧だと、不適合なのか仕様どおりなのかを判断できず、責任を問うこと自体が難しくなります。要件定義書、テスト項目、検収書の三つが揃っていると、公開後の議論がずっと簡単になります。公開後の修正や改善を継続的に頼むなら、保守（公開後の維持管理）契約の中で対応範囲を決めておく方法もあります。

動くかではなく、頼んだものかを照合する

検収は、動くかどうかを見る作業ではなく、頼んだものと作られたものを照合し、結果を書面に残す作業です。検収条件の確認、業務の流れに沿ったテスト項目、ステージングでの実施、不具合の切り分け、残課題を明記した検収書、という手順を踏めば、公開後の「言った・言わない」を大きく減らせます。検収の進め方や業務効率化システム開発のご相談はお問い合わせからどうぞ。

一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。