納品物は何をもって「完成」とするか、検収の基準を決める
月曜の朝、届いたメールに「検収完了のご確認をお願いします」とあった
先代から会社を引き継いで一年半。金曜の夕方、開発会社から「予定通り本番リリースが完了しました」という報告が届いた。ホッとしたのも束の間、月曜の朝には「検収完了のご確認をお願いします。ご確認後、請求書を発行させていただきます」という一文が添えられたメールが待っていた。
添付されていたのは、リリース完了報告書と、動作確認用のURL、それだけだった。何を基準に「完成」と判断すればいいのか、そもそもどこまで動けば「完成」なのか、後継社長には皮膜一枚のイメージしかない。先代の時代はシステムといえば紙の業務日報をExcelに置き換える程度で、検収というものが会話と信頼だけで済んでいた。ところが今回は、基幹システムのリプレイスに近い規模の開発案件で、金額も先代時代の比較にならないほど大きい。
パソコンの画面を開き、渡されたURLをクリックする。トップページは表示される。ログインもできる。だが、実際に自社の業務フローに当てはめてみると、見積書を発行する画面で消費税の表示が一箇所だけ違う気がする。過去の受注データを検索する画面では、思ったより結果が出てくるのに時間がかかっている。これは「不具合」なのか、「まだ確認していないだけ」なのか、それとも「もともとこういう仕様だった」のか、後継社長には判断がつかない。
隣の席では、経理を任せている番頭格の社員が「社長、これでハンコ押しちゃっていいんですか。何かあったときにうちが全部リスクを負うことになりませんか」と聞いてくる。答えられない。先代が生きていた頃は、外部に発注する仕事といえば工場の設備や内装工事が中心で、「図面通りにできているか」「動くかどうか」を目で見て判断できた。しかしソフトウェアは違う。画面の裏側でどう動いているか、何がテストされていて何がテストされていないか、外から見ただけでは分からない。
これは特殊な状況ではない。事業承継した企業がシステム開発を発注する場面では、必ずどこかで「検収」という壁にぶつかる。そして多くの後継社長が、この壁の正体を正確に理解する前に、なんとなく請求書に押印してしまい、後になって「思っていたのと違う」というトラブルに発展する。この記事では、納品物の「完成」をどう定義し、検収の基準をどう決めるべきかを、事業承継の当事者という立場から、実務レベルで解説していく。
考えてみれば、先代から会社を引き継ぐということは、先代が築いてきた取引先との関係、社員との信頼関係、そして業務のやり方をそのまま受け継ぐことでもある。しかしシステム開発という領域だけは、先代の時代の経験がそのまま活かせない。なぜなら、先代の時代にはそもそも存在しなかった規模と複雑さのシステムを、後継社長の代で初めて導入しようとしているケースが多いからだ。工場の機械を新調するときのように「動くかどうか」を目で確認すればよい、という感覚で臨んでしまうと、必ずどこかで足をすくわれる。だからこそ、検収という手続きの本質を正しく理解し、自社なりの基準を持つことが、事業承継後の経営者にとって避けて通れない課題になっている。
なぜ「検収基準が曖昧」という問題が起こるのか
検収という概念そのものが業種によって全く違う意味を持っている
まず整理しておきたいのは、「検収」という言葉の意味が、業種によって全く異なるという事実である。製造業や建設業で使われてきた「検収」は、契約書や図面、仕様書に明記された物理的な仕上がりを、目視や計測器で確認する行為だった。納品された機械が図面通りのサイズで動くか、建物が設計通りに建っているか、これは基本的に「見れば分かる」領域の話である。
先代が長年その業界で経験を積んできた場合、後継社長にも「検収とはこういうものだ」という感覚が染み付いている。ところがソフトウェア開発における検収は、この感覚とは根本的に性質が異なる。ソフトウェアには「見た目が正しく動いているように見えても、内部のロジックが間違っている」というケースが無数に存在する。画面上は正常に表示されているが、実は裏側のデータベースに誤った値が書き込まれている、といった不具合は、目視だけでは絶対に見つからない。
さらに厄介なのは、ソフトウェアの「正しさ」は仕様書という文書に依存しているという点である。仕様書に書かれていないことは、開発会社側も「作っていない」し、テストもしていない。逆に、発注者側が「当然含まれているはず」と思い込んでいる機能が、実は仕様書に一行も記載されていなかった、というギャップが頻繁に発生する。これは開発会社が悪意を持って手を抜いているわけではなく、単に「言葉にされていない前提」が発注者と開発者の間で食い違っているだけのことが多い。
建築であれば、図面に描かれていない部分は「一般的な施工基準」や「建築基準法」といった業界共通のルールで補完される余地がある。ところがソフトウェア開発には、そうした業界共通の暗黙のルールがほとんど存在しない。ある会社にとっての「当たり前の仕様」が、別の会社では「オプションの追加機能」として扱われることもある。この曖昧さこそが、検収の場面で最も多くのトラブルを生む火種になっている。
発注者側に技術的な検証能力がないという構造的な非対称性
事業承継の後継社長が置かれている状況で最も深刻なのは、この「発注者と開発者の間の情報の非対称性」である。先代の時代からの取引先である工務店や設備業者であれば、後継社長も現場に足を運び、実際にモノを見て、体感的に品質を判断できた。しかしソフトウェア開発においては、発注者側にプログラムのコードを読む能力もなければ、テストの網羅性を評価する知識もない。
この非対称性は、検収というプロセスにおいて決定的な問題を生む。なぜなら、検収とは本質的に「発注者が、契約通りのものが納品されたかを確認し、合意する」行為だからである。確認する能力がなければ、検収は形だけの儀式になり、実質的には「開発会社の言うことを信じて押印する」だけの作業に堕してしまう。
これは発注者にとって非常にリスクの高い状態である。なぜなら、検収完了のサインをした瞬間から、法的には「納品物に問題がない」と認めたことになり、後から不具合が見つかっても、開発会社側に無償での修正義務を主張することが難しくなるケースがあるからだ。契約書に検収条項がどう書かれているかにもよるが、一般的に検収完了は代金支払い義務の発生条件であり、かつ契約不適合責任(旧・瑕疵担保責任)を追及できる期間の起点にもなる。つまり検収基準が曖昧なまま押印することは、自社が将来主張できる権利を自ら手放すことに等しい。
さらに言えば、この非対称性は時間が経つほど発注者に不利に働く。開発会社は日々多くのプロジェクトを手がけており、契約書の書き方、検収の進め方、トラブルが起きた際の対応の落としどころについて、豊富な経験とノウハウを蓄積している。一方、発注者である事業承継後の企業は、システム開発を発注する機会そのものが数年に一度、あるいは事業承継のこの一回きりということも珍しくない。経験の蓄積量が全く違う両者が、対等な立場で交渉しているつもりでも、実際には情報量に大きな差がある状態で話が進んでいる。この構造を自覚しておくことが、検収基準を自分の言葉で決めるための第一歩になる。
先代の時代の「発注文化」が引き継がれてしまう危険性
事業承継特有の問題として、先代が築いてきた「発注文化」がそのまま引き継がれてしまうケースがある。先代が長年付き合ってきた開発会社やシステムベンダーがいる場合、「あの会社は昔から世話になっているから」「先代の代からの関係だから」という理由で、契約内容や検収プロセスを厳密にチェックしないまま発注が継続されることがある。
しかし、事業承継のタイミングというのは、実は検収の仕組みを見直す絶好の機会でもある。先代の時代には、システムの規模が小さく、検収が曖昧でも大きな問題にならなかったかもしれない。しかし後継社長の時代には、業務の複雑化やDXの進展によって、システムの規模も金額も拡大している。「昔からの付き合いだから」という理由だけで、検収の甘さを引き継いでしまうと、規模が大きくなった分だけリスクも拡大していることに気づかないまま、大きな損失を被る可能性がある。
また、先代から経営権を引き継いだばかりの後継社長は、社内での発言力や経験の蓄積がまだ十分でないことが多い。開発会社の担当者から「これはもう業界標準の仕様です」「先代の時代からこの範囲でやっています」と言われると、それを鵜呑みにしてしまいやすい。開発会社が悪質だというわけではなく、単に「先代時代の暗黙の了解」が、後継社長には共有されていないという情報の断絶が起きているのである。
この情報の断絶は、想像以上に根深い問題を引き起こす。先代が長年の付き合いの中で「今回は多少無理を言っても融通してくれるだろう」「この程度の不具合なら次回の改修でまとめて直してもらえばいい」といった、独自の力加減で取引を進めていたケースは少なくない。後継社長にはその力加減が全く見えないため、先代であれば当然求めていたはずの修正要求を、遠慮して言えなかったり、逆に先代が大目に見ていた程度の軽微な不具合を、必要以上に厳しく問題視してしまったりする。どちらに転んでも、開発会社との関係性に不要な緊張を生む結果になりかねない。だからこそ、先代の感覚に頼るのではなく、誰が見ても同じ判断ができる客観的な基準を、後継社長自身の手で作り直す必要がある。
「完成」の定義が契約書に書かれていない、あるいは書かれていても抽象的すぎる
多くの中小企業のシステム開発契約書を見ると、「完成」の定義が驚くほど曖昧であることが分かる。「本契約に基づき、乙(開発会社)は甲(発注者)に対し、別紙仕様書に定めるシステムを納品する」という一文はあっても、「何をもって納品完了とするか」「検収の合格基準は何か」「検収期間は何日か」「不合格の場合の手続きはどうなるか」といった具体的な取り決めが抜けていることが非常に多い。
これは契約書のテンプレートが古いまま使われ続けている場合や、開発会社側が提示した契約書をそのまま使ってしまい、発注者側が検収条項を精査していない場合に起こる。特に事業承継直後は、社内に契約書を精査できる法務人材がいなかったり、先代の代からの契約書フォーマットをそのまま流用していたりするため、この問題が顕在化しやすい。
「完成」の定義が曖昧だと、検収のタイミングで「これで完成と言えるのか」という水掛け論になる。開発会社は「仕様書に書かれた機能はすべて実装した。これで完成だ」と主張し、発注者は「動かしてみたら期待していた動きと違う。これでは完成とは言えない」と反論する。どちらの主張にも一定の正当性があり、契約書に明確な基準がなければ、この対立を解消する手段がない。最終的には「これ以上揉めても仕方がない」という空気の中で、なんとなく検収書に押印してしまうケースが後を絶たない。
テスト工程の可視化不足という技術的な原因
もう一つの構造的な原因は、開発プロセスにおけるテスト工程が発注者側から見えにくいという点にある。優れた開発会社であれば、単体テスト、結合テスト、システムテスト、受け入れテスト(UAT)という段階を踏み、各段階でテスト項目と結果を記録している。しかし、その記録が発注者側に共有されないまま、最終的に「リリース完了」という報告だけが届くことがある。
発注者側がテスト結果のエビデンス(証跡)を受け取っていなければ、検収の判断材料はUI上の見た目だけになってしまう。見た目のチェックだけでは、裏側の計算ロジックの誤りや、大量データを処理したときのパフォーマンス低下、セキュリティ上の脆弱性などは絶対に発見できない。検収基準を「見た目が正しく動くこと」だけに置いてしまうと、リリース後数か月経ってから、繁忙期に大量のデータを処理した瞬間にシステムが止まる、といった重大な不具合が初めて表面化することになる。
加えて、開発の現場ではスケジュールの遅延を吸収するために、テスト工程が最初に削られる、という力学が働きやすいことも知っておく必要がある。要件定義や実装に時間がかかってしまった場合、当初の予定していたリリース日を守ろうとすると、最後に残された調整弁はテスト期間になりがちである。発注者側からは開発の進行状況が見えないため、「本当に十分なテストが行われたのか」を検収の場面で初めて疑わなければならない、という構造的な弱さがここにも存在する。だからこそ、検収の基準としてテストの証跡を求めることは、単なる形式的な要求ではなく、開発工程全体の健全性を事後的に検証するための、発注者に残された唯一の手段だと言える。
以上のように、検収基準が曖昧になる背景には、業種を超えた「検収」概念の誤解、発注者と開発者の情報の非対称性、事業承継特有の発注文化の継承、契約書における完成定義の欠落、テスト工程の不可視性という、複数の構造的要因が積み重なっている。これらを一つひとつ解きほぐし、後継社長が自分の言葉で「完成」を定義し、検収の基準を主体的に決められるようにすることが、この記事の目的である。
ケーススタディで見る、検収基準が曖昧だったことの代償
ケース1 老舗製造業の受発注システムリプレイスで発生した「二重入力地獄」
創業60年の金属加工業を三代目として引き継いだ社長のケースである。先代の代から使っていた受発注管理システムが古すぎて動作が不安定になり、リプレイスを決断した。開発会社は先代の時代から付き合いのある会社で、見積もりも相場より安く、信頼していた。
契約書には「受発注管理機能一式を実装する」という記載しかなく、具体的にどの画面で何ができるかという仕様の詳細は口頭での打ち合わせに委ねられていた。開発が進み、リリース予定日が近づいたところで、開発会社から「予定通り完成しました。ご確認をお願いします」という連絡が来た。
後継社長は画面を一通り触ってみて、受注登録ができること、見積書が出力できることを確認し、検収書に押印した。しかし本稼働後、経理担当者から「前システムでは自動連携していた在庫データが、今回のシステムでは手動で二重入力しなければならない」という報告が上がってきた。開発会社に確認すると、「在庫連携は当初のヒアリングで『検討中』とされていたため、仕様書には含めていない。追加開発として別途お見積もりします」という回答だった。
後継社長は「当然引き継がれる機能だと思っていた」と主張したが、口頭でのやり取りに証拠がなく、仕様書にも記載がないため、開発会社の主張を覆すことができなかった。結果として、追加開発費用として当初の契約額の3割に近い金額を追加で支払うことになった。この案件で最大の問題点は、検収の時点で「現行システムでできていたことが、新システムでも同等にできるか」という比較検証を行っていなかったことである。見た目の画面が動くことだけを確認し、業務フロー全体を通した検証をしていなかったために、リリース後に初めて機能不足が発覚した典型例である。
さらに悪いことに、この会社では二重入力が発覚した後も、現場の従業員が「新しいシステムは使いにくい」という不満を口にするようになり、一部の従業員は旧システムのExcel台帳を独自に維持し続けるという、いわば「シャドーIT」的な運用が定着してしまった。後継社長が気づいた頃には、正式なシステムのデータと現場の裏帳簿の数字がずれているという、さらに厄介な二次被害が発生していた。検収の甘さは、追加費用という直接的なコストだけでなく、現場の業務運用そのものを歪めるという、見えにくい形でも会社に損害を与えることがある。この社長は後に、「もし検収の際に、既存システムでできていた業務を一覧化して突き合わせる作業をしていれば、この事態は防げたはずだ」と振り返っている。
ケース2 卸売業の在庫管理システムで発生した「検収後の重大バグ」
先代の急逝により急遽事業を引き継いだ二代目社長のケースである。引き継ぎ直後で経営全体を把握するだけで手一杯だった時期に、先代が発注していた在庫管理システムの開発プロジェクトが完了を迎えた。後継社長は開発の経緯を詳しく知らないまま、開発会社から提示された検収書に、担当の若手社員の「動作確認は問題なさそうです」という一言だけを信じて押印した。
検収完了から2か月後、月末の棚卸処理を実行したところ、在庫数量の集計結果が実際の在庫と大きく異なることが発覚した。原因を調査すると、複数の倉庫をまたいだ在庫移動を処理する際のロジックに誤りがあり、特定の条件下でのみ数量が正しく反映されないという不具合だった。この不具合は、通常の入出庫処理だけを試すテストでは発見できず、複数倉庫間の移動処理という特殊なシナリオを実際にテストしなければ見つからないものだった。
開発会社に修正を依頼したところ、「検収完了後3か月を過ぎているため、無償修正の対象外です。有償対応となります」という回答が返ってきた。契約書を確認すると、たしかに「検収完了後、無償保証期間は3か月とする」という条項があり、発覚のタイミングがぎりぎりその期間を過ぎていた。後継社長は「検収の時点でテストシナリオが不十分だったことに気づけなかった」ことを深く後悔したという。この案件の教訓は、検収時にどのようなテストシナリオが実施されたかを確認し、業務上想定されるすべてのパターン(特に複数の要素が絡む複雑なケース)がテスト対象になっているかを検収基準に含めておくべきだったという点である。
この会社にとってさらに痛手だったのは、在庫の集計誤りによって、実際には在庫がないはずの商品を受注してしまい、取引先への納期を守れなかったという事態が発生したことである。取引先からの信用を一部損ない、その後の受注量にも影響が出たという。単なるシステムの不具合が、システムの外側にある取引関係にまで波及した典型例である。後継社長は「先代が急に亡くなり、引き継ぎの混乱の中で検収の重みを実感する余裕がなかった」と当時を振り返っているが、逆に言えば、混乱している時期こそ、社内の誰か一人にでも検収の重要性を認識させておく仕組みが必要だったということでもある。事業承継の初期は、経営者の目が行き届かない領域がどうしても生まれやすい。だからこそ、検収のような重要な意思決定を、社長個人の注意力だけに依存させない仕組み作りが求められる。
ケース3 サービス業の予約管理システムで起きた「検収基準を明文化して救われた」成功例
三代目として老舗の旅館グループを引き継いだ社長のケースは、逆に検収基準を事前に明確化していたことで大きなトラブルを避けられた例である。この社長は、事業承継前に別業界でIT関連の仕事に携わっていた経験があり、システム開発における検収の重要性を理解していた。
予約管理システムの開発を発注する際、契約書に「検収合格基準書」という別紙を添付することを開発会社に要求した。その基準書には、「受入テスト項目一覧」として、通常予約、キャンセル、団体予約、繁忙期の同時アクセス、決済連携などのシナリオごとに、期待される動作結果を具体的に記載した。さらに「検収期間は納品後10営業日とし、期間中に発見された不具合は開発会社の責任で無償修正すること」「検収期間中の修正後は、再度該当項目のテストを実施し、合格を確認した上で最終検収とすること」という手続きも明文化した。
開発が完了し、実際にこの基準書に基づいてテストを実施したところ、団体予約の際に人数によって金額計算が誤るという不具合が発見された。基準書があったおかげで、これは「検収不合格」であることが明確であり、開発会社も反論の余地なく無償で修正に応じた。修正後、再テストを実施して合格を確認し、そこで初めて検収完了とした。
この社長は振り返って、「基準書を作る作業自体は面倒だったが、いざ不具合が見つかったときに『これは仕様外の要求ではないか』という水掛け論に一切ならなかったことが最大の価値だった」と語っている。検収基準を事前に明文化しておくことは、単に品質を守るためだけでなく、発注者と開発者の間の不要な対立を避けるための予防策としても機能する。この成功例は、後継社長が検収基準を主体的に設計することの重要性を端的に示している。
さらに興味深いのは、この基準書が、開発会社にとってもプラスに働いたという点である。開発会社の担当者は、「何を満たせば検収完了になるかが明確なので、開発の優先順位をつけやすかった」と後に感想を語っていたという。発注者が基準を明確にすることは、開発会社にとって「合格ラインが見えない不安」を取り除くことにもつながり、結果的に双方の作業効率を高める効果すら生む。検収基準の明文化は、発注者を守るための防御策であると同時に、開発プロジェクト全体を円滑に進めるための共通言語としても機能するのである。この旅館グループでは、その後の追加改修や別システムの発注においても、同様の基準書を作成する運用が定着し、開発会社との関係はむしろ以前よりも強固になったという。
実務対応:検収基準を決めるための具体的なステップ
ここからは、実際に後継社長が検収基準を決める際に踏むべきステップを、チェックリスト形式で解説する。上流(契約前)から下流(検収実施時)まで、時系列に沿って整理した。
ステップ1 契約書に「完成」の定義を明記させる
契約書における最も基本的かつ重要な作業は、「何をもって完成とするか」を具体的な言葉で定義することである。「システムを完成させ納品する」という抽象的な表現ではなく、「別紙仕様書に定めるすべての機能が、別紙テスト項目一覧に定める合格基準を満たした状態」といった、検証可能な形で定義する必要がある。
このとき重要なのは、「完成」を判定する主体を明確にすることである。開発会社が「完成した」と一方的に宣言するのではなく、発注者が定めた基準に基づいて発注者自身が判定する、という構造を契約書に落とし込む。これにより、検収の主導権が発注者側にあることが明文化される。
また、検収期間についても具体的な日数を定めておく必要がある。一般的には10営業日から20営業日程度が実務上のバランスが取れた期間とされるが、システムの規模や複雑さに応じて調整する。あまりに短い期間を設定すると、十分な検証ができないまま検収完了とみなされてしまう危険があるため、自社の検証体制に見合った期間を確保することが重要である。
さらに、契約書には「検収期間内に発注者から何らかの回答がない場合、自動的に検収完了とみなす」という、いわゆる「みなし検収」条項が入っていることが多い。この条項自体は開発会社の権利を守るための一般的な内容であり、それ自体が不当というわけではないが、発注者側がこの条項の存在を認識していないと、うっかり検収期間を過ごしてしまい、内容を確認する前に自動的に検収完了とみなされてしまう危険がある。契約書を受け取った際には、みなし検収条項が存在するかどうか、存在する場合はその期間が何日に設定されているかを必ず確認し、社内のスケジュールに検収作業の期限をあらかじめ組み込んでおく必要がある。みなし検収条項に限らず、先代の代の契約書に他にどのような見落としがちな条項が潜んでいるかは、先代の代の契約書に潜むトラブルの芽。後継社長が入れるべき条項でまとめて確認できる。
ステップ2 仕様書を「業務フロー単位」で読み直す
多くの発注者は、仕様書を「画面単位」で確認する。画面Aにはこの入力項目がある、画面Bにはこのボタンがある、という確認は行うが、業務が実際にどのような順番で流れるかという「業務フロー」全体を通した検証を怠りやすい。
先代の時代からの業務フローを、後継社長自身が一度紙に書き出してみることを強く勧める。受注が入ってから、在庫を確認し、出荷指示を出し、請求書を発行し、代金を回収するまでの一連の流れを、部門を横断して書き出す。そして、その流れの各ステップが、新しいシステムのどの画面・どの機能に対応しているかを一つずつ突き合わせる。この作業を通じて、「先代の時代に当然行われていた業務が、新システムでは想定されていない」というギャップに気づくことができる。ケース1で紹介した二重入力地獄は、まさにこの業務フロー単位の確認を怠ったことが原因だった。
この業務フローの書き出し作業は、社長一人で行うのではなく、各部門の担当者を集めてワークショップ形式で行うことが望ましい。営業担当者が把握している受注時の業務と、倉庫担当者が把握している出荷時の業務、経理担当者が把握している請求と回収の業務は、それぞれ担当者本人にしか見えていない細かい手順を含んでいることが多い。これらを一枚の図に統合することで、初めて会社全体の業務フローの全体像が見える。そして、その全体像を仕様書と突き合わせることで、「誰も気づいていなかった仕様の抜け漏れ」を検収前の段階で発見できる可能性が高まる。
ステップ3 テストシナリオと結果のエビデンスを開発会社から必ず受け取る
検収の判断材料として、開発会社が実施したテストの記録(テスト項目一覧、実施結果、発見された不具合とその対応状況)を必ず文書またはスプレッドシートの形式で受け取る。単に「テストは問題ありませんでした」という口頭やメールの一文で済ませてはならない。
このテスト記録を受け取ったら、後継社長自身、あるいは社内の実務担当者が、そのテスト項目が自社の業務で実際に発生するパターンを網羅しているかを確認する。特に、「例外的な状況」(繁忙期の同時アクセス、大量データの処理、複数拠点をまたいだ処理、決済や返金といった金銭が絡む処理)がテスト対象に含まれているかは重点的に確認すべきポイントである。ケース2の在庫管理システムの不具合は、複数倉庫間の移動という例外的なパターンがテストされていなかったために本稼働後に発覚した。
また、テスト記録を確認する際には、テストの「実施日」と「実施者」もあわせて確認しておくとよい。開発を担当したエンジニア自身が自分の書いたコードをテストする場合、無意識のうちに自分が想定した使い方の範囲でしかテストしないという傾向がある。理想的には、開発を担当した人とは別のテスト担当者、あるいは発注者側の視点に近い立場の人がテストを行っている方が、見落としのリスクは下がる。小規模な開発会社では専任のテスト担当者を置いていないことも多いが、その場合でも「誰がどのような視点でテストしたか」を確認しておくことは、テスト結果の信頼度を判断するための重要な材料になる。
ステップ4 受け入れテスト(UAT)を自社の実務担当者が実際に手を動かして行う
検収の中核となるのが、発注者側の実務担当者が実際にシステムを操作して確認する受け入れテスト(User Acceptance Test、UAT)である。これは開発会社に任せるのではなく、実際にその業務を日常的に行っている社員が担当することが望ましい。経理担当者であれば経理業務のシナリオを、営業担当者であれば受注から請求までのシナリオを、それぞれ実際の業務データに近い形で入力し、期待通りの結果が出るかを確認する。
このとき、テストシナリオをあらかじめ紙やスプレッドシートに書き出しておき、「何を入力したら、何が表示されるべきか」を事前に定義してからテストを実施することが重要である。思いつきで画面を触るだけでは、確認漏れが発生しやすい。ケース3の旅館グループの例のように、団体予約、繁忙期の同時アクセスといった具体的なシナリオを列挙し、一つずつ実施結果を記録していく方法が効果的である。
受け入れテストを実施する際には、正常な操作だけでなく、あえて間違った操作をしてみることも重要である。例えば、必須項目を空欄のまま登録しようとしたらどうなるか、金額にマイナスの数字を入力したらどうなるか、同じ内容を二重に登録しようとしたらどうなるか、といった「意図的な誤操作」への挙動を確認しておくことで、実際の業務で従業員がうっかり誤入力をした際に、システムがどう振る舞うかを事前に把握できる。エラーメッセージが分かりやすく表示されるか、システムが異常なデータのまま処理を進めてしまわないか、といった観点も検収の重要なチェックポイントになる。
ステップ5 「合格」「条件付き合格」「不合格」を判定する基準をあらかじめ決めておく
検収の実施時に「合格か不合格か」の二択で判断すると、軽微な不具合が見つかった場合に「これくらいなら合格にしてしまおうか」という妥協が生まれやすい。事前に、不具合の重大度を分類する基準を決めておくことを推奨する。
例えば、「業務が完全に止まる、または金額に誤りが生じる不具合」は不合格、「業務は継続できるが表示や操作性に問題がある不具合」は条件付き合格(期限を定めて修正を求める)、「軽微な表記の揺れなど業務に影響しない事項」は合格としつつ改善要望として別途申し出る、といった三段階の基準を用意しておく。この基準があることで、検収の現場で感情的な判断や場当たり的な妥協を避けることができる。
ステップ6 検収完了後の保証期間と、その間の不具合対応の取り決めを確認する
検収が完了した後も、一定期間は無償で不具合修正に対応してもらえる「保証期間」を契約に含めることが望ましい。この保証期間がどのくらいの長さか、保証の対象となる不具合の範囲(仕様通りに動作しない場合のみか、性能面の問題も含むか)を、検収前に必ず確認する。
ケース2のように、検収完了から一定期間を過ぎた時点で発覚した不具合が有償対応とされてしまうケースは少なくない。保証期間は最低でも3か月、システムの規模や利用開始後の閑散期・繁忙期のサイクルを考慮すると6か月程度が望ましい場合もある。特に季節性のある業務(決算処理、棚卸、年末調整など)を含むシステムであれば、そのサイクルを一度経験するまでの期間を保証期間に含めるべきである。
ステップ7 検収書に押印する前に、社内の複数人で確認するプロセスを設ける
事業承継直後は、後継社長一人がすべての判断を担わなければならない場面が多い。しかし検収という重要な意思決定を、社長一人の感覚だけで行うのはリスクが高い。実際にシステムを使う現場の担当者、経理や法務的な視点を持つ番頭格の社員、可能であれば外部の詳しいアドバイザーなど、複数の視点でチェックする体制を作ることを勧める。
特に、先代の時代から会社に在籍しているベテラン社員は、業務のディテールを最も理解している存在である。後継社長が気づかない業務上の抜け漏れを、現場の視点から指摘してもらうことは非常に有効である。検収書への押印は、その確認プロセスをすべて経た後の、最後の一歩として位置づけるべきである。
チェックリストまとめ
以下は、検収の場面で確認すべき項目を一覧化したものである。
一つ目、契約書に「完成」の定義が具体的な文言で明記されているか。抽象的な「システムを完成させる」という表現だけになっていないか確認する。二つ目、検収期間が明確に定められており、自社の検証体制に見合った長さになっているか。三つ目、仕様書を業務フロー単位で読み直し、先代の時代に行っていた業務がすべて新システムでカバーされているかを確認したか。四つ目、開発会社からテスト項目一覧と実施結果のエビデンスを受け取ったか。五つ目、そのテスト項目に、繁忙期や例外パターンなど自社特有のリスクの高い業務シナリオが含まれているか。六つ目、受け入れテストを実際の実務担当者が手を動かして実施したか。七つ目、合格・条件付き合格・不合格を判定する基準を検収実施前に決めておいたか。八つ目、検収完了後の保証期間と対応範囲が契約書または合意文書に明記されているか。九つ目、検収書への押印を、複数人の確認プロセスを経た上で行っているか。十つ目、検収完了後に発見された不具合の連絡経路と対応フローが社内で共有されているか。
これらの項目を一つひとつ潰していくことで、検収基準の曖昧さから生じるトラブルの大部分は事前に防ぐことができる。
よくある失敗パターン3つ
失敗パターン1 「動いているように見える」ことを「完成」と混同する
最も頻繁に見られる失敗は、画面が表示され、ボタンを押して何らかの反応があることを確認しただけで「動いている」と判断し、それを「完成」と同義に捉えてしまうことである。ソフトウェアの世界では、見た目が正常に動作していても、裏側のロジックに誤りが潜んでいることは日常的に発生する。
特に事業承継直後の後継社長は、システムの内部構造を理解していないことが多く、表面的な動作確認だけで安心してしまいがちである。この失敗を避けるためには、「見た目の確認」と「業務ロジックの確認」を明確に分けて考える習慣を持つ必要がある。見た目の確認は誰でもできるが、業務ロジックが正しいかどうかは、実際の業務データに近い形でテストを行わなければ判断できない。特に金額計算、在庫数量の集計、日付をまたぐ処理といった、間違えると業務に直接的な損害が生じる箇所については、単純な動作確認では不十分であり、複数のパターンを組み合わせたテストが必要であることを認識しておくべきである。
失敗パターン2 「早く終わらせたい」という心理から検収を急いでしまう
事業承継直後の後継社長は、システム開発以外にも取引先との関係構築、社内体制の整備、先代からの引き継ぎ業務など、多くのタスクを同時に抱えている。その中で、開発会社から「検収完了のご確認をお願いします」という連絡を受けると、「これも早く片付けてしまいたい」という心理が働きやすい。
この心理は非常に危険である。検収は、システムの品質を確認し、将来のトラブルを未然に防ぐための最後の関門である。ここを急いで通過してしまうと、後々発覚する不具合への対応において、発注者側が不利な立場に置かれる可能性が高くなる。検収にかける時間は、目先の忙しさに対して惜しむべきものではなく、将来発生しうる大きなコストやトラブルを予防するための投資だと捉える必要がある。忙しい時期であればこそ、検収作業だけは意図的にスケジュールを空け、集中して取り組む時間を確保することが望ましい。あるいは、検収作業自体を信頼できる番頭格の社員や外部の専門家に委任し、社長自身は最終的な承認判断だけを行うという役割分担も現実的な対応策である。なお、検収に納得できないまま「このまま進めてよいのか」と迷う場合は、そもそもプロジェクト自体を一度立ち止まるべきタイミングなのかを見極める視点も必要になる。刷新の途中で計画を止めるべきタイミングの見極め方を判断材料の一つとして参照してほしい。
失敗パターン3 開発会社との関係性を重視しすぎて、指摘すべきことを指摘しない
先代の時代からの付き合いがある開発会社に対しては、「長年世話になっているから」「無理を言うと今後の関係が悪くなるかもしれない」という配慮から、明らかに問題がある納品物に対しても強く指摘できないというケースが見られる。これは特に、後継社長が社長としての立場にまだ十分に自信を持てていない時期に起こりやすい。
しかし、検収は品質を確認するための客観的な手続きであり、人間関係の配慮とは本来別の話である。むしろ、長年の付き合いがある開発会社であればこそ、検収を厳格に行うことで、双方にとって健全な取引関係を継続できる。問題を指摘しないまま検収を通してしまうと、開発会社側にも「この発注者は多少雑な納品でも通ってしまう」という認識が生まれ、結果的に今後の取引全体の品質が下がっていく悪循環に陥る可能性がある。指摘すべきことを事実として冷静に伝え、修正を求めることは、関係性を壊す行為ではなく、むしろ長期的に良好な関係を維持するための必要なコミュニケーションであると理解しておくべきである。
FAQ よくある質問
検収書に一度押印してしまった後でも、不具合を指摘して修正を求めることはできますか
契約書の内容によって対応は異なるが、一般的には検収完了後も一定の保証期間内であれば、契約不適合(仕様通りに動作しない状態)を理由に無償修正を求めることは可能である場合が多い。ただし、保証期間を過ぎている場合や、契約書に「検収完了をもって全ての責任が発注者に移転する」といった条項がある場合は、修正を求めることが難しくなる。まずは契約書の保証条項を確認し、可能であれば早い段階で弁護士など専門家に相談することを勧める。重要なのは、不具合を発見した時点で記録を残し、開発会社に対して速やかに書面(メールでも構わない)で連絡することである。連絡が遅れるほど、開発会社側が「使用開始後に発生した別の問題ではないか」と反論する余地が生まれてしまう。実際に不具合を見つけたときの具体的な依頼の仕方については、後継社長が知っておきたい検収の要点と不具合対応の頼み方で詳しく解説している。
開発会社から「これ以上テストすると追加費用が発生します」と言われました。どう対応すべきですか
まず、契約書における検収の範囲がどこまでを含んでいるかを確認する必要がある。当初の契約で合意した仕様書の範囲内のテストであれば、追加費用を求められる根拠は基本的にない。一方で、当初の仕様書に含まれていない新しい要望を追加でテストしてほしいという場合は、それは仕様変更や追加開発に該当する可能性があり、追加費用が発生することも妥当な場合がある。この区別をつけるためにも、仕様書と当初の契約範囲を明確にしておくことが重要である。判断に迷う場合は、開発会社に対して「この項目は当初の仕様書のどの部分に対応するテストか」を明確に説明してもらい、双方で認識を合わせることから始めるべきである。
社内にシステムに詳しい人材がいない場合、検収はどうやって進めればいいですか
技術的な詳細を評価する専門知識がなくても、検収の核心は「業務が実際に問題なく回るかどうか」を確認することにある。したがって、システムの内部構造を理解する必要はなく、実際にその業務を担当している現場のスタッフに、日常業務で使う操作を一通り試してもらうことが最も重要な検収作業になる。加えて、外部のITコンサルタントやシステム開発の経験がある専門家に、検収時のみスポットで確認を依頼するという方法も有効である。継続的な契約を結ぶ必要はなく、検収のタイミングだけ第三者の目を入れることで、専門知識の不足を補うことができる。特に金額の大きいプロジェクトや基幹システムのリプレイスのような重要度の高い案件では、この第三者チェックを検討する価値は高い。
先代の時代からの開発会社で、これまで検収を厳密にやってこなかった場合、今から厳格にすると関係が悪化しませんか
検収を厳格にすることと、開発会社との関係性を損なうことは、本質的には別の問題である。むしろ、検収基準を明文化し、双方が納得できる客観的な基準に基づいて確認作業を行うことは、開発会社側にとっても「何を満たせば検収完了になるか」が明確になるというメリットがある。事業承継のタイミングは、こうした取引の仕組みを見直す自然なきっかけとして開発会社側にも説明しやすい。「先代から引き継いだ立場として、今後も長くお付き合いさせていただきたいので、これからは検収の手順を明確にしていきたい」という伝え方をすれば、多くの開発会社は前向きに受け止めてくれる。もし、この提案に強く抵抗する開発会社があれば、それはむしろ今後の取引を見直す一つの判断材料になるとも言える。
まとめ
先代から会社を引き継いだ後継社長にとって、システム開発の検収は、これまで経験してきた製造や建築の検収とは全く異なる性質を持つ作業である。ソフトウェアは目に見えない部分が多く、発注者側に技術的な検証能力がないという構造的な非対称性が存在する。だからこそ、検収を「なんとなく動いていることを確認して押印する儀式」にしてしまうと、リリース後に重大な不具合が発覚し、大きな追加コストや業務停止といったリスクを招くことになる。
この記事で紹介したように、検収基準を主体的に決めるためには、契約書に「完成」の定義を具体的な言葉で明記すること、仕様書を業務フロー単位で読み直すこと、開発会社からテストのエビデンスを必ず受け取ること、実務担当者による受け入れテストを実施すること、合格・不合格の判定基準を事前に決めておくこと、そして検収完了後の保証期間を確認することが、実務上の要点になる。これらは特別な技術知識を必要とするものではなく、経営者としての基本的な確認作業の積み重ねである。
先代の時代の発注文化をそのまま引き継ぐのではなく、事業承継というタイミングを、自社の検収の仕組みを見直す好機として捉えることを勧めたい。検収基準を明文化し、複数人でのチェック体制を整えることは、目先の手間はかかるものの、将来の大きなトラブルを防ぎ、開発会社との健全で長期的な関係を築くための土台になる。「完成」とは何かを自分の言葉で定義できるようになったとき、後継社長は初めて、システム開発という不透明な領域においても、経営者としての主導権を確立できたと言えるだろう。
なお、検収という手続きそのものの流れやチェックリスト、不具合発覚時のよくある質問を一通り確認したい場合は、検収とは？後継社長が納品時にやるべき確認と落とし穴を先に読むと、この記事で扱う「完成の基準を決める」話がより理解しやすくなる。
