システム開発の検収とは。動くだけで合格にしない

納品された画面は一応動きます。しかし、現場担当者が操作すると、承認後の取消しができません。開発会社からは、今日中に検収書へサインしてほしいと言われています。

システム開発の検収とは、納品物が合意した仕様と受入条件に合うかを発注側が確かめ、合否を記録する手続きです。画面が開くかだけを見る時間でも、開発会社の説明を聞いて印鑑を押す行事でもありません。

僕なら、業務に必要な操作が通らないまま検収書へサインしません。仕様書、受入テストの結果、不一致を示す画面を並べ、合格か修正後の再検査かを決めます。「思っていたのと違う」という感想だけでは、開発会社も直す範囲を決められません。

システム開発の検収とは、仕様との一致を確かめる手続きです

開発会社が実施するテストと、発注側の検収は役割が異なります。開発会社はプログラムや連携が設計どおり動くかを確認します。発注側は、納品された版を使って、発注時に合意した業務を実行できるかを確認します。

たとえば受注管理システムなら、担当者が注文を登録し、上長が承認し、請求データを作り、誤った注文を取り消すところまで通します。正常な一件だけでは足りません。権限のない社員が承認できないか、同じ注文を二重登録しないか、外部連携が失敗した際に再送できるかも確かめます。

IPAが2025年4月8日に更新した情報システム・モデル取引・契約書（第二版）では、検査仕様書にテスト項目、テストデータ、方法、期間などを定め、システム仕様書と納品ソフトウェアが合うかを検査する形を示しています。検査仕様書は発注側が中心となって作り、開発会社と確定する想定です。

IPAの資料は、一部企画を含む受託開発と保守運用を対象にしたモデル契約です。個別案件へ自動で適用される規則でも、開発成功率を測った調査でもありません。自社の基本契約、個別契約、発注書に合わせて使う必要があります。CTO代行の契約書を確認する場合も、契約名だけで判断せず、実際の業務と責任を読む点は共通します。

開発方式によって、合否を決める単位も変わります。完成時にまとめて受け取る案件と、小さな機能を順に確認する案件では、検査期間と記録の置き方が同じではありません。発注者が選ぶアジャイルとウォーターフォールの違いも踏まえ、何をいつ受け入れるかを着手前に決めます。

「動くけど思っていたのと違う」を三つに分けます

最初に見るのは、契約書だけではありません。要件定義書、システム仕様書、画面案、議事録、課題管理ツールの決定履歴を開きます。文書の優先順位が基本契約や個別契約に書かれている場合は、優先順位も確認します。

一つ目は、合意した内容と動作が違う場合です。権限表に「店舗責任者は承認できる」と書かれているのに承認ボタンが出ないなら、仕様との不一致を具体的に示せます。発生手順、利用者の役割、入力値、期待した結果、実際の結果、画面の記録をそろえます。

二つ目は、必要な業務が文書に書かれていない場合です。店舗責任者の承認が必要なのに、要件定義書には「承認機能」としか書かれていなければ、誰の承認を合意したのかが曖昧です。議事録や画面案まで戻り、発注側の伝達不足、開発会社の確認不足、双方の認識差を切り分けます。

三つ目は、納品画面を見て初めて欲しくなった改善です。十件を一括承認したいという希望が合意資料に入っていなければ、追加開発として範囲、費用、納期を相談する場面になり得ます。新しい希望を不具合と呼ぶと、本来直すべき不一致まで交渉材料に見えてしまいます。

境界が曖昧な場合、担当者同士の記憶で決着させません。合意資料のどの文章を根拠にするか、想定した利用場面は何か、修正しなければ契約目的へどの程度影響するかを両社の責任者が記録します。法的な扱いまで争いが及ぶ場合は、資料一式を弁護士などの専門家へ見せます。

システム開発の検収拒否は、具体的な不一致を書いて伝えます

検収拒否は、納期を延ばしたり支払いを止めたりするための便利な言葉ではありません。検査期間内に受入テストを行い、合意した基準へ達していない理由を文書で伝える手続きです。

受入テストへ進む前の単体・結合・システムテストと発注者の関わり方は、システム開発のテスト工程で整理しています。開発中の品質確認と納品版の検収を同じ合否判定にしないことが重要です。

IPAのモデル契約も、不合格時には具体的な理由を書面で速やかに伝え、修正または追完を求める形を示しています。一方で、検査期間内に具体的な異議を文書で示さない場合、合格とみなす条項も置いています。自社の契約に同じ条項があるとは限りませんが、担当者が忙しいという事情だけで検査期限を過ぎるのは危険です。

不合格の連絡には、課題番号、確認した環境と版、操作手順、入力データ、仕様書の該当箇所、期待結果、実際の結果、業務への影響を入れます。「使いにくい」「品質が低い」ではなく、「経理担当でログインすると、仕様書4.2にある請求確定ボタンが表示されない」と書けば、再現と修正へ進めます。

軽微な不一致を残して利用開始する場合も、口頭の「後で直します」で合格にしません。不一致の一覧、修正期限、再検査の担当者、修正できなかった場合の扱い、保守開始日を合意文書へ残します。条件付きの合格を契約が想定していない場合は、契約担当者と専門家に変更書面の要否を確認します。

提案段階では、完成した画面より不合格時の対応を聞きます。失敗を再現し、原因と修正範囲を説明できる会社を選びます。

検収書へサインした後は、状態を変える前に記録します

検収後に不具合が見つかっても、署名した事実だけで全ての対応を直ちに失うとは限りません。最初に納品時の版を保全し、発見日時、操作した利用者、入力値、画面録画、エラーログ、業務への影響を残します。修正作業で状態が変わる前に、再現条件を固定します。

次に、観測した不一致、仕様書の該当箇所、業務への影響、調査回答を求める日を契約上の窓口へ送ります。無償修正の対象、通知期限、保守契約との境界は契約ごとに異なります。契約時点で、納品後の修正と保守を別の項目へ分けてください。検収を担当する人は、法的な結論を先に出すのではなく、証拠を失わずに初動を記録します。

次のシステム開発では検収項目を着手前に書きます

検収時の争いは、納品日の会議だけでは防げません。要件定義の段階で、利用者が行う業務を一つずつ選び、誰が、どの画面で、どのデータを使い、何が表示されたら合格かを書きます。開発会社が実装へ入る前なら、必要なテストデータや外部連携の準備も見積もりへ入れられます。

受入テストには、実際に操作する社員を参加させます。経営者と開発会社だけで画面を見ても、月末の締め処理、承認者が休んだ日の代行、取消し後の会計連携までは見つけにくいからです。現場担当者には完成画面を初めて見せるのではなく、要件定義中の画面案と検査項目も確認してもらいます。

テスト結果には、実施日、検証環境、ソフトウェアの版、担当者、入力、期待結果、実際の結果、証拠、合否を残します。障害管理表と受入テスト表を分ける場合も、課題番号で結びます。誰が口頭で了承したかではなく、どの版のどの項目へ合格したかを後から追える状態にします。

検収対象の資料や権限を漏らさないため、システム開発の成果物を受領形式と確認方法まで定義する手順も成果物一覧へ反映します。

明日は、契約書の検収条項、最新版の仕様書、受入テスト表を同じ机に置いてください。注文登録から取消しまでの業務を一件選び、担当者、承認者、例外操作、外部連携までテスト表へ書きます。検収期限とテスト担当者が空欄なら、開発会社へ日程を送り、検査に使う版を固定します。

すでに検収期限が近い場合は、未確認の項目を合格扱いにしません。確認できていない範囲と必要な日数を文書で伝え、期限変更が必要なら両社の契約担当者で合意します。検収書へサインする基準を先に書けば、「動くけど思っていたのと違う」という会話を、仕様と記録に基づく判断へ変えられます。