検収の書類にサインする前に、後継社長の手が止まった理由
先代が病気で急に退いてから半年。後継社長である佐藤さん（仮名、42歳）の会社では、先代が最後に発注した基幹システムのリプレイスがちょうど納品の時期を迎えていた。開発会社の担当者がノートパソコンを開き、「これで検収完了のご署名をいただければ、残金のご請求書をお送りします」と切り出した。佐藤さんは画面に表示された納品物一覧をざっと眺めた。受注管理、在庫管理、請求書発行の三つの機能が並び、それぞれ「実装済み」というステータスがついている。だが、その「実装済み」が何を確認した結果なのか、佐藤さんにはまったく分からなかった。
先代は現場に出ながら経営もこなす人で、システムの話は担当していた古参の総務部長と開発会社の間で進んでいた。佐藤さんは会議には同席していたが、要件定義の細かい議事録までは目を通していない。今、目の前にあるのは検収書という一枚の紙と、動くのか動かないのか実感の持てない画面だけだ。サインをすれば、そこから先の不具合は「有償の追加対応」になるかもしれない。サインをしなければ、開発会社への支払いが止まり、関係がこじれるかもしれない。どちらに転んでも、後継社長としての最初の重要な経営判断が、素性の分からない書類一枚に集約されてしまっている。
隣の椅子には、経理を担当している奥さんが心配そうな顔で座っている。開発会社の担当者は柔らかい口調で「先代様にはいつも快くご判断いただいていたので」と言葉を添えるが、その一言が余計に佐藤さんの背中を押してくる。ここでサインをしなければ、先代の代からの付き合いに水を差すことになるのではないか。だが、サインをした瞬間に何が確定するのかも分からないまま署名するのは、経営者としてあまりに危うい。佐藤さんは結局、「少し社内で確認してからもう一度連絡します」とだけ伝え、その場での署名を持ち帰った。この判断ができたことは幸運だったが、多くの後継社長は、同じ場面でその場の空気に押されてペンを取ってしまう。
この場面は特殊な例ではない。事業承継のタイミングとシステムの納品タイミングが重なるケースは非常に多い。先代が最後の大型投資として発注したシステムが、代替わりの直後に完成する。あるいは、先代の在任中には要件定義だけが終わっていて、実装と検収は後継社長の手に渡ってから行われる。いずれの場合も、後継社長は検収という工程の意味を正確に理解していないまま、重い判断を求められることになる。本稿では、この検収という工程で後継社長が具体的に何を確認すべきか、そして納品後に見つかった不具合をどう開発会社に依頼すれば無用な対立や追加費用を避けられるかを、実務の手順として整理する。開発会社との関係は、これから何年も続いていくものだ。最初の検収での対応の仕方が、その後の関係の質を大きく左右する。
なぜ後継社長は検収でつまずくのか
検収という工程が持つ二つの意味
まず前提として、検収には二つの側面がある。ひとつは「契約上の意味」で、検収書に署名することは、納品物が発注時の仕様どおりに完成したことを発注者側が認め、残金の支払い義務を確定させる行為だ。もうひとつは「実務上の意味」で、検収は実際に業務で使ってみて困らないかを確かめる最後のチェックポイントである。契約書の条文上はどちらも「検収」という一語で片付けられてしまうため、この二重性を意識していないと、後継社長は自分がいったい何にサインしようとしているのかを取り違えたまま署名してしまう。
この二つの意味がずれると、トラブルが起きる。開発会社にとっての検収は基本的に契約上の意味が主で、「仕様書に書かれた機能が動くかどうか」を確認する工程だと捉えられている。一方、発注者である会社の現場は「自分たちの日々の業務が問題なく回るかどうか」を確認したいと思っている。仕様書に書かれていたことと、現場が実際に必要としていたことの間には、多かれ少なかれギャップがある。要件定義の段階でそのギャップをどれだけ潰せたかによって、検収時に発覚する問題の量は変わってくる。
このギャップは、開発会社が悪意を持って手を抜いているから生まれるわけではない。ソフトウェア開発という営みそのものが、最初に紙の上で決めた仕様と、実際に人間が手を動かして作り上げた完成物との間に、多少のズレを生み出しやすい性質を持っている。文章で「在庫が一定数を下回ったら通知する」と書かれていても、「一定数」がいくつなのか、通知は画面表示なのかメールなのか、誰に届けばいいのか、細部まで詰めて書かれた仕様書は実際には多くない。細部が詰められていない部分は、開発を担当するエンジニアが自分なりの解釈で実装を進めることになり、その解釈が発注者側の期待と一致するとは限らない。検収とは、この解釈のズレが実際にどこにどれだけ残っているかを、最後にまとめて確認する場だと考えるとわかりやすい。
後継社長がつまずく最大の理由は、この「仕様書に書かれたこと」を自分が把握していない、という点にある。要件定義に立ち会っていたのが先代や古参の総務部長であれば、後継社長は「何を約束したシステムなのか」を検収の場で初めて知ることになる。約束の内容を知らないまま、約束が守られたかどうかを判断することはできない。これは能力の問題ではなく、単純に情報が引き継がれていないという構造上の問題だ。
情報の引き継ぎが起きない三つの経路
システム発注に関する情報が後継社長に引き継がれない経路には、大きく三つのパターンがある。
一つ目は、先代がシステムの発注や契約の話を「経営の重要事項」ではなく「現場の細かい話」として扱っていたケースだ。先代の頭の中では、いくら投資したか、いつ完成するかは重要事項だが、具体的にどの機能をどう作るかは総務部長や現場担当者に任せる話になっている。このため、事業承継の引き継ぎ資料には「システム投資：〇〇万円、来期完成予定」という一行しか残らず、仕様書や議事録は現場の引き出しの中に眠ったままになる。
二つ目は、開発会社との窓口が先代個人ではなく、先代が信頼していた特定の社員に一本化されているケースだ。中小企業の場合、システム導入は多くの部署にとって初めての経験であり、社内で一人だけが開発会社とのやり取りに慣れていくということが起こりやすい。その担当者が窓口を独占していると、進捗も課題も要件変更の経緯も、その担当者の頭の中にしか残らない。後継社長が代替わりした時点で、その担当者が退職や異動で不在になっていると、情報は完全に失われる。
三つ目は、契約書や仕様書そのものが更新されずに古い状態で残っているケースだ。要件定義後にも現場からの要望で機能の追加や変更が発生することは珍しくないが、その変更が口頭やチャットのやり取りだけで済まされ、正式な仕様書に反映されないまま進んでしまうことがある。この場合、検収の場に置かれている仕様書と、実際に開発会社が作ったシステムの間にもズレがあり、後継社長がどちらを信じればいいのか分からなくなる。
さらに、四つ目の経路として、承継そのものが急だったために、そもそも引き継ぎの時間が確保できなかったというケースも見逃せない。先代が急病や急逝で退任した場合、後継社長は経理・人事・取引先対応など、優先度の高い業務に忙殺され、システムの発注状況を確認する時間的余裕がないまま数か月が過ぎてしまうことがある。この間に検収の期限だけは契約書通りに進行しており、後継社長が気づいた時点で、すでに開発会社側から「そろそろ検収を」という打診が来ている、という状況に置かれることも珍しくない。時間的な余裕のなさが、検収の準備不足に直結してしまう構造がここにもある。
「動いている」ことと「使える」ことの違い
検収でもう一つ見落とされやすいのが、「動いている」ことと「業務で使える」ことの違いだ。開発会社が示す動作確認は、多くの場合、決められたテストケースに沿って機能を一つずつ実行し、想定どおりの結果が出るかを確認する作業である。これは重要な工程だが、実際の業務データの量や、実際のオペレーションの手順、実際に使う社員のITスキルまでは反映されていないことが多い。
たとえば在庫管理システムであれば、テストデータでは数十件の商品しか登録されていないが、実際の運用では数千件の商品を扱う。数十件では一瞬で表示される検索機能が、数千件になると数秒待たされる、というのはよくある話だ。あるいは、テストでは開発会社の担当者や情報システムに詳しい社員が操作しているが、実際に毎日使うのはパソコン操作に慣れていないパート従業員だったりする。画面の表示は仕様通りでも、実務でその通りに運用できるかどうかは別の問題として検証しなければならない。
後継社長がこの違いを理解していないと、「開発会社が動作確認済みと言っているのだから大丈夫だろう」という判断で検収書に署名してしまい、稼働後に現場から「使いにくい」「遅い」「思っていたのと違う」という声が噴出する事態になる。そしてその時点で検収が完了していると、開発会社に対して「これは契約時の仕様通りに作った結果であり、追加のご要望であれば別途お見積りします」と返される可能性が高い。
この落差が生まれる背景には、開発を依頼する側と実際に使う側の距離の問題もある。中小企業では、システムの発注窓口になるのは経営層や管理部門であり、実際に毎日そのシステムに向き合うのは現場の従業員だ。窓口となる側が「業務が回るシステムになっているか」を体感的に理解していないまま検収の判断を下すと、机上では正しく見える確認作業が、実際の現場感覚とはかけ離れたものになってしまう。後継社長自身が現場の作業を熟知している場合はこのリスクは小さくなるが、先代の代から現場を離れて経営に専念してきた後継社長ほど、この落差に気づきにくい。検収完了後、開発会社とどう関係を築いていくかについては、検収に合格した後、開発会社との関係で気をつけたいことで扱っている。
先代の人間関係が判断を鈍らせる構造
事業承継特有の事情として、開発会社との関係が先代個人の信頼関係の上に成り立っていることも、検収の判断を難しくする一因になる。先代が長年付き合ってきた開発会社であれば、後継社長としては「先代が選んだ会社なのだから、無下に疑うのも気が引ける」という心理が働きやすい。特に、開発会社の担当者が先代の葬儀や引き継ぎの場に顔を出し、「先代には本当にお世話になりました」といった言葉をかけてくることもある。そうした人間関係の文脈の中で、契約書や仕様書というドライな基準で判断することに抵抗を感じる後継社長は少なくない。
しかし、検収は感情や信頼関係とは別の、契約上の手続きである。人間関係を大切にすることと、納品物を仕様書に基づいて厳密に確認することは両立できる。むしろ、確認すべき点をきちんと確認したうえで署名する方が、開発会社にとっても後々のトラブルを避けられるため、双方にとって望ましい進め方だと理解しておく必要がある。
加えて、事業承継直後の後継社長は「自分がまだ会社の実権を完全には握っていない」という感覚を持っていることが多く、その不安が、開発会社に対して強い態度で確認を求めることへの心理的なハードルになっている場合もある。古参社員や取引先が先代のやり方を懐かしむ空気の中で、後継社長が独自の判断基準を持ち出すことに気後れを感じるのは自然な反応だ。だが、検収における確認は、先代のやり方を否定する行為ではなく、契約の当事者として当然に求められる責務である。この点を後継社長自身がまず自分の中で整理しておくことが、落ち着いた判断につながる。
検収で確認すべきポイント
ここからは、実際に検収の場で後継社長が確認すべき具体的なポイントを、手順に沿って整理する。
ステップ1 契約書・仕様書・議事録を検収前に手元に揃える
検収の当日にいきなり画面を見せられて判断を求められる状況は避けたい。検収の予定が決まったら、遅くとも一週間前までに、以下の書類を開発会社から提出してもらい、社内でも探し出しておく。
まず契約書そのもの。特に「検収の定義」がどう書かれているかを確認する。検収完了の条件が「発注者が動作確認を行い、異議がなければ検収完了とみなす」という記載になっている場合、何も言わずに一定期間が過ぎると自動的に検収完了とみなされる契約もある。このみなし規定の有無と期間は必ず確認する。また、検収完了後の不具合対応がどの範囲まで無償で行われるのか、保証期間が何か月に設定されているのかも、この段階で条文を読み込んでおく。
次に要件定義書または仕様書。どの機能をどう動かすと約束したのかが書かれた、最も重要な基準文書だ。これが手元にない、あるいは古いバージョンしか残っていないという場合は、検収前に開発会社に最新版の提出を依頼する。開発会社側が正式に保管しているはずの文書なので、依頼すれば通常は入手できる。仕様書を受け取ったら、後継社長自身が最初から最後まで一読し、分からない専門用語やシステム的な表現があれば、遠慮なく開発会社に説明を求めておく。ここで理解を諦めてしまうと、検収の場での判断がまた他人任せになってしまう。
そして、要件定義後に発生した変更の履行が分かる資料。打ち合わせの議事録、メールやチャットのやり取り、変更依頼書などが該当する。口頭やチャットでのやり取りしか残っていない変更点があれば、それも含めて仕様の全体像を把握しておく。最後に、見積書と請求書も並べて確認しておきたい。当初の見積りから追加費用が発生している場合、その追加がどの変更に対応するものなのかを突き合わせておくことで、検収時に「なぜこの機能に追加費用がかかっているのか」を疑問なく確認できる。
ステップ2 検収の合格基準を事前にすり合わせる
書類を揃えたら、検収に立ち会う前に、開発会社と「何を確認すれば検収完了とするか」という合格基準を、口頭ではなく文書やメールで明確にすり合わせておく。よくある基準の項目は次の通りだ。
仕様書に記載された全機能が、記載された条件で正しく動作すること。特に例外的な入力（空欄、規定外の文字数、規定外の日付形式など）に対してエラーメッセージが表示されるか、システムが落ちずに処理を継続できるかは重要な確認点になる。
実際の業務データに近いボリュームでの動作速度。前述の在庫管理システムの例のように、テストデータの少なさで検証が甘くなっていないかは、事前にすり合わせておくべき項目だ。可能であれば、実データに近いサンプルデータを開発会社に渡し、そのデータで動作確認をしてもらうよう依頼する。
実際に使う社員による操作確認。情報システムに詳しい担当者だけでなく、日常的にそのシステムを使う予定の社員（パート従業員や年配の社員なども含む）に実際に操作してもらい、迷わず使えるかを確認する。ここで「使いにくい」という声が出た場合、それが契約時の要求に対する不具合なのか、それとも要求自体になかった追加要望なのかを区別して記録しておく。
この合格基準のすり合わせを検収前に行っておくことで、検収当日に「これは仕様通りです」「いえ、これでは業務が回りません」という水掛け論を避けられる。合格基準をすり合わせる際には、必ず日付を明記したメールで残しておくことも忘れてはならない。口頭でのすり合わせだけで済ませると、検収当日になって「そのような基準は伝えられていない」という食い違いが起きかねない。件名に「検収合格基準について」と明記したメールを一本送っておくだけで、後々の証拠として十分に機能する。
ステップ3 検収チェックリストを用いて機能を一つずつ確認する
検収の当日は、以下のようなチェックリストに沿って、担当者と一緒に一つずつ機能を確認していく。チェックリストは表形式にして、「確認項目」「確認結果」「担当者コメント」の欄を用意し、その場で記入していくのが望ましい。
まず基本機能の動作確認。仕様書に記載された機能を一覧化し、実際に画面を操作しながら一つずつ、記載通りに動くかを確認する。ここで大事なのは、開発会社の担当者にデモをしてもらうだけでなく、後継社長自身、または現場の担当者が実際にキーボードとマウスを操作して確認することだ。デモだけでは操作の癖や画面遷移の分かりにくさに気づけない。
次にデータ移行の正確性の確認。旧システムや紙の帳簿から新システムにデータを移行している場合、移行後のデータが正確かどうかは特に念入りに確認すべき項目だ。取引先の件数、在庫の数量、過去の売上金額の合計など、集計値が旧システムと一致しているかを突き合わせる。データ移行の不具合は後から発覚すると原因の特定が非常に難しくなるため、検収の時点で徹底的に確認しておく必要がある。
三つ目に、権限設定とセキュリティの確認。誰がどの機能にアクセスできるか、パスワードの管理方法、退職者のアカウント削除の手順などが仕様通りに設定されているかを確認する。中小企業では権限設定が甘くなりがちで、全社員が全データを見られる状態になっていることもあるため、意図した設計になっているかをここで確認する。
四つ目に、バックアップと障害時の復旧手順の確認。システムに障害が起きた場合、どこまでのデータが復旧できるのか、復旧にどれくらいの時間がかかるのかを、実際に確認するか、少なくとも文書で説明を受ける。特に、開発会社に運用を任せている場合は、この復旧手順が仕様書や運用マニュアルに明記されているかを確認する。
五つ目に、マニュアルと引き継ぎ資料の確認。システムの操作マニュアルが整備されているか、運用中に発生し得る典型的な問い合わせとその対応方法がまとめられているかを確認する。マニュアルが「後日提出します」となっている場合、それも検収完了の条件に含めるかどうかを明確にしておく。
六つ目に、他システムとの連携部分の確認。会計ソフトや既存の販売管理システムなど、他のシステムとデータを連携させる仕組みが仕様に含まれている場合、その連携が実際に動くかどうかは特に念入りに確認する必要がある項目だ。連携部分は開発の後半でまとめて実装されることが多く、テスト不足のまま検収の日を迎えているケースが少なくない。実際にデータを送受信させ、期待した形式で反映されるかを目視で確認する。
七つ目に、契約書に記載された保守・サポート体制との整合性の確認。検収完了後、誰にどう連絡すれば不具合対応や操作の問い合わせに応じてもらえるのか、対応時間や休日の扱いはどうなっているのかを、この段階で確認しておく。稼働してから初めて「休日は対応してもらえない」と知るよりも、検収の場で確認しておく方が安心して運用を始められる。
ステップ4 検収の結果を「合格」「条件付き合格」「不合格」に分けて記録する
すべての確認項目を終えたら、結果を安易に「合格」か「不合格」の二択で決めてしまわず、「条件付き合格」という選択肢も活用する。条件付き合格とは、大部分の機能は仕様通りに動作しているが、一部に軽微な不具合や改善要望があり、それらの対応期限を定めたうえで検収を進める、という進め方だ。
すべてが完璧に仕上がっているシステムはむしろ稀であり、多少の細かい不具合が残っている状態で検収の期限を迎えることは実務ではよくある。この場合、後継社長が取るべき現実的な対応は、残っている不具合や改善要望を一覧化した「未了事項リスト」を作成し、それぞれに対応期限と対応方法（無償修正か有償対応か）を明記したうえで、双方が合意した文書として残すことだ。これによって、検収書に署名しても、未了事項については開発会社の対応義務が残ることを明確にできる。
一方で、基本機能そのものが動かない、データ移行が大幅に間違っている、といった重大な不具合が見つかった場合は、そのまま不合格として検収を延期し、開発会社に修正を依頼するべきだ。ここで「早く終わらせたい」という気持ちに引かれて安易に合格としてしまうと、後々の不具合対応の交渉力を大きく失うことになる。
ケーススタディ1 検収書に署名した翌月に基幹システムが止まった建材商社
従業員35名の建材商社では、先代の急逝から3か月後に、先代が発注していた受発注管理システムの納品を迎えた。後継社長は先代の長男で、要件定義の会議には数回しか出ておらず、詳細な仕様は把握していなかった。開発会社の担当者から「テストは一通り完了しています」と説明を受け、画面上で受注登録から出荷指示までの流れが一通り動くのを見て、その場で検収書に署名した。
問題が起きたのは翌月、月末の請求書一括発行のタイミングだった。テスト環境では十数件の注文データしか登録されていなかったため気づかなかったが、実際の月末処理では数百件の受注データを一度に処理する必要があり、処理の途中でシステムが固まって止まってしまった。慌てて開発会社に連絡したところ、「検収完了後の不具合対応は、契約書上、有償の保守契約の範囲内で対応します」という回答が返ってきた。保守契約はまだ結んでおらず、急遽スポット対応として見積りを取ったところ、当初の想定を大きく超える金額が提示された。
このケースの問題は、検収時に実際の業務ボリュームに近いデータでの動作確認をしていなかったことにある。もし検収前に「月末の一括処理を想定したテストデータでの動作確認」を合格基準に含めていれば、この不具合は検収時点で発見でき、無償修正の対象として交渉できたはずだった。後継社長が検収の意味を十分に理解していなかったために、本来であれば納品側の責任で直すべき不具合の修正費用を、発注側が追加で負担する結果になってしまった。
この会社ではその後、後継社長が過去のやり取りを開発会社にすべて開示してもらい、要件定義の段階で「月末の一括処理」についての記載が仕様書にあったことを確認できた。仕様書に記載があった以上、本来は無償修正の対象になるはずだという主張を後継社長が根拠を示して行ったところ、開発会社側も条文を確認し、最終的には一部無償・一部有償という折衷案で対応することになった。完全な無償対応を得ることはできなかったが、根拠を示して交渉することで、当初提示された金額よりも大幅に低い費用で修正を完了させることができた。この経験から、後継社長は以後、どのシステム関連の契約でも、検収前に必ず仕様書を通読することを社内のルールとして定めた。
ケーススタディ2 「条件付き合格」を活用して交渉力を残した食品加工会社
従業員18名の食品加工会社では、先代から会社を継いだ二代目社長が、先代の在任中から進んでいた在庫管理システムの導入を引き継いだ。検収の当日、基本的な入出庫の記録や在庫の一覧表示は問題なく動作していたが、賞味期限が近い商品を自動で警告表示する機能に不具合があり、期限が過ぎた商品でも警告が出ないケースがあることが分かった。
この後継社長は、事前に商工会の経営相談窓口でシステム導入の進め方について相談しており、検収の合格基準を事前に開発会社とすり合わせておくという助言を受けていた。そのため、検収当日には未了事項リストをその場で作成し、「賞味期限警告機能の不具合は2週間以内に無償で修正すること」「修正完了後、再度動作確認の場を設けること」という条件を文書に明記した上で、条件付き合格として検収を進めた。
開発会社側も、契約時の仕様に明記されていた機能の不具合であることを認め、2週間後に無償で修正を完了させた。この事例のポイントは、検収の場で「動く部分」と「動かない部分」を明確に切り分け、動かない部分についてだけ対応義務を文書で残したことだ。全体を不合格にして納品全体を止めてしまうと開発会社との関係が硬直化しかねないが、条件付き合格という形にすることで、双方にとって現実的な進め方ができた。
ケーススタディ3 古参の総務部長の独断で検収が進んでいた印刷会社
従業員50名の印刷会社では、先代から経営を引き継いだ後継社長が、あるとき偶然、経理担当者から「システムの残金の請求書が来ているが、承認していいか」という確認を受けた。後継社長はそのシステムの検収がすでに完了していることをそこで初めて知った。調べてみると、先代の時代から開発会社との窓口を務めていた古参の総務部長が、後継社長への相談なしに独断で検収書に署名していたことが分かった。
総務部長にヒアリングしたところ、「先代の時代からのやり方で、システムのことは自分が窓口として処理してきた。特に大きな問題もなかったので、いつも通り検収を進めた」という説明だった。実際にシステムを確認してみると、大きな不具合はなかったものの、当初の要件定義にあった一部の機能が実装されておらず、総務部長自身もその欠落に気づいていなかったことが判明した。
このケースが示しているのは、事業承継後は「誰が検収の最終決定権を持つか」を明確にしておく必要があるということだ。先代の時代からの慣習で特定の社員が窓口を独占している場合、後継社長が知らないうちに重要な契約上の判断が進んでしまうリスクがある。承継後は早い段階で、開発会社に対しても社内に対しても、「システム関連の契約上の最終決定は後継社長が行う」ということを明確に伝え、検収を含む重要な意思決定の前には必ず報告を受ける体制に切り替えることが望ましい。
その後、この後継社長は開発会社に対して正式な文書で「今後、契約に関わる意思決定はすべて後継社長が最終確認を行う」という体制変更を通知した。総務部長にも、悪気があったわけではないことを理解しつつ、今後は検収前に必ず後継社長への報告を経るよう業務の進め方を改めてもらった。総務部長自身も、長年一人で判断してきた重責から解放されたことで、むしろ気持ちが軽くなったという。この事例は、情報の一本化が特定の担当者の独断ではなく、後継社長を含めた体制として機能するよう見直すことの重要性を物語っている。開発会社の担当者交代が起きた際に確認すべきことは、開発会社の担当者交代、後継社長が引き継ぎで確認すべきことにまとめている。
不具合を見つけたときの依頼の仕方
検収が完了した後、あるいは検収の場で不具合が見つかった場合、開発会社にどう依頼すれば、スムーズかつ後々のトラブルを避けられる形で対応してもらえるのか。ここでは依頼の具体的な作法を整理する。
不具合の再現手順を具体的に書く
「動かない」「おかしい」といった漠然とした報告では、開発会社側も原因の特定に時間がかかり、対応が遅れる。担当者が手元で同じ操作を試しても再現しない、という状態が続くと、対応そのものが宙に浮いてしまう。不具合を報告する際は、次の要素を必ず含める。
いつ発生したか（日付と時刻）、誰が操作していたか（担当者名または役職）、どの画面でどのボタンを押したか、どのようなデータを入力していたか、その結果どうなったか（エラーメッセージの文言、画面が固まった、想定と違う数値が表示された、など）。可能であれば、その場面のスクリーンショットを添付する。これらの情報が揃っていれば、開発会社の担当者はその場で再現テストを行い、原因を特定する時間を大幅に短縮できる。
不具合か追加要望かを自分なりに切り分けておく
不具合対応を依頼する前に、それが「契約時の仕様に反する不具合」なのか、「契約時には想定していなかった追加の要望」なのかを、自分なりに整理しておくことも重要だ。仕様書を見返し、該当する機能がどう書かれていたかを確認し、実際の動作がそこから外れているのであれば不具合、書かれていた内容以上のことを求めているのであれば追加要望、という区別をつける。
この切り分けを自分でせずに、すべてを「直してください」という一括りの依頼にしてしまうと、開発会社側も「これは仕様通りなので追加費用が発生します」という返答を機械的にしてしまい、交渉が長引く原因になる。逆に、後継社長側が「これは仕様書のこの部分に該当する不具合だと考えていますが、いかがでしょうか」と根拠を示して依頼すれば、開発会社側も無償対応か有償対応かの判断がしやすくなり、話が早く進む。
対応の優先順位と期限を明確に伝える
複数の不具合が同時に見つかった場合、すべてを同じ優先度で依頼すると、開発会社側もどこから手をつけるべきか判断がつかず、対応が遅れがちになる。業務への影響度に応じて「これは業務が止まるレベルなので今週中に対応してほしい」「これは運用に支障はないが、来月末までに直してほしい」というように、優先順位と希望する対応期限を明確に伝える。期限を示さずに依頼すると、開発会社側の他の業務との優先順位付けで後回しにされる可能性が高くなる。
対応内容と結果を記録に残す
不具合の報告から対応完了まで、口頭やチャットでのやり取りだけで済ませず、要点をメールなどの形で残す。誰がいつ何を依頼し、開発会社がいつどう対応し、いつ再確認が完了したか、という記録があれば、同種の不具合が再発した場合の参照にもなるし、保守契約の範囲内で対応すべきものだったかどうかの判断材料にもなる。特に、無償対応してもらった不具合については、それが無償だった理由（契約時の仕様に反する不具合であったこと）を記録に残しておくと、将来同じような議論が起きた際に有効な根拠になる。この記録は一覧表の形にして社内で共有しておくと、後継社長以外の担当者が問い合わせ対応をする際にも役立ち、開発会社とのやり取りが特定の個人に依存しない体制づくりにもつながる。
よくある失敗パターン
失敗パターン1 「先代が信頼していた会社だから」と確認を省略する
先代が長年付き合ってきた開発会社に対して、後継社長が疑いの目を向けることに抵抗を感じ、確認作業を簡略化してしまうケースは非常に多い。開発会社の担当者が誠実であることと、納品物が仕様通りに完成していることは、本来別の話だ。誠実な担当者であっても、人員不足やスケジュールの都合で確認が甘くなっていることはあり得る。信頼関係を保ちながらも、契約書や仕様書という客観的な基準で確認する姿勢は、開発会社にとっても失礼にはならない。むしろ発注者側がきちんと確認する会社だと分かれば、開発会社側も納品物の品質により気を配るようになる、という好循環が生まれることも多い。この失敗パターンに陥りやすい後継社長の共通点は、「確認すること」と「疑うこと」を同じ意味で捉えてしまっていることにある。確認は疑いではなく、契約の当事者として当然に行うべき手続きであり、それを丁寧に行う後継社長の方が、長期的には開発会社からも信頼を得やすい。
失敗パターン2 検収を急ぎすぎて未了事項を口約束のままにする
先代の時代の慣習や、経理上の締めのタイミングなどの都合で、「今月中に検収を終わらせないといけない」という時間的な制約に追われ、細かい不具合を「あとで直してもらう約束で」という口約束だけで済ませてしまうケースがある。口約束は、担当者の異動や退職、あるいは単純な記憶の食い違いによって、後から「そんな約束はしていません」ということになりかねない。どうしても期限内に検収を終える必要がある場合は、前述の「条件付き合格」の形を取り、未了事項と対応期限を必ず文書として残すことが重要だ。時間的な制約があるからこそ文書化を省略してしまう、という一見合理的に見える判断が、実は最も後になって高くつく失敗であることを、後継社長は肝に銘じておく必要がある。
失敗パターン3 現場の声を検収に反映させずに後から噴出させる
検収の場に立ち会うのが後継社長や情報システム担当者だけで、実際にそのシステムを毎日使う現場の従業員が確認に参加していないケースも多い失敗パターンだ。この場合、検収時点では機能面の不具合は見つからなくても、稼働後に現場から「使いにくい」「手順が増えて余計に時間がかかる」といった声が次々に上がってくる。これらは厳密には「不具合」ではなく「使い勝手の問題」であることが多いため、検収完了後に指摘しても、開発会社側からは追加要望として有償対応を提示されることが多い。現場の従業員に検収前の試用期間を設け、実際の業務フローに沿って操作してもらい、その声を検収の合格基準に反映させることで、この失敗は避けられる。
失敗パターン4 開発会社からの説明を録音や議事録に残さずに聞き流す
検収の場で開発会社の担当者が口頭で行う説明、たとえば「この機能は次のバージョンで対応予定です」「この部分は仕様の範囲外なので別途費用がかかります」といった発言は、後々のトラブルの火種になりやすい。その場では納得して聞いていても、時間が経てば発言の細部は忘れてしまう。担当者の発言は、可能であれば録音するか、少なくとも要点をその場でメモに取り、検収終了後にメールで「本日の確認内容は以下の通りと認識しています」という形で共有し、開発会社側からの確認の返信をもらっておく。この一手間を惜しんだために、数か月後に「そんな説明は受けていない」という水掛け論になるケースは後を絶たない。
よくある質問
検収書に一度署名してしまったら、後から不具合を指摘することはできませんか
契約書の内容次第だが、多くの契約では、検収完了後であっても、契約時の仕様に明確に反する不具合（バグ）については、一定の保証期間内であれば無償修正の対象になると定められていることが多い。検収書に署名したこと自体が、すべての不具合について発注者が責任を負うという意味にはならない。ただし、検収後に見つかった問題が「仕様の記載通りに動いているが、使い勝手が悪い」という種類のものであれば、それは不具合ではなく追加要望とみなされ、有償対応になる可能性が高い。署名前に契約書の保証期間や無償修正の範囲についての条項を確認しておくことが重要だ。
開発会社の担当者から「検収完了とみなします」というメールが来て、期限内に返信しなかった場合、どうなりますか
契約書に「一定期間内に異議がなければ検収完了とみなす」という、いわゆるみなし検収の規定がある場合、期限内に具体的な不具合や懸念点を示して返信しなければ、その規定通りに検収完了とみなされてしまう可能性がある。多忙で確認が後回しになりがちな時期であっても、みなし検収の期限が設定されているメールを受け取った場合は、少なくとも「確認中なので期限を延長してほしい」という返信だけは早めに送っておくべきだ。何も返信しないことが最も不利な結果を招く。
先代の時代の要件定義書が見つからない場合、検収はどう進めればいいですか
要件定義書が社内に残っていなくても、開発会社側は業務として作成した文書を保管しているはずなので、まずは開発会社に正式な要件定義書または仕様書の再提出を依頼する。開発会社からの提出物と、実際に画面上で動いている機能を照らし合わせ、食い違いがあれば、その場で開発会社の担当者に経緯を確認する。合わせて、要件定義の会議に出席していた社内の担当者（総務部長や現場責任者など）に当時の記憶をヒアリングし、可能な範囲で経緯を再構成しておくことも有効だ。文書が完全に見つからない状態で検収を進めるのはリスクが高いため、時間がかかっても文書の再提出を優先する方がよい。
検収時に見つかった不具合が多く、開発会社との関係を損ねずに交渉するにはどうすればいいですか
まず、見つかった不具合を一覧化し、契約時の仕様に対する不具合なのか、追加要望なのかを整理したリストを作成する。それを開発会社に提示し、「これらはすべて契約時の仕様に基づく確認結果であり、追加のご負担をお願いするものではありません」という前提を明確に伝えたうえで、対応期限について協議する。感情的な対立を避けるためには、不具合の指摘を「開発会社の能力不足を責める言葉」ではなく「仕様との差異を客観的に共有する言葉」で伝えることが重要だ。同時に、条件付き合格という形で一部の支払いを進めることを提案すれば、開発会社側にとっても対応するインセンティブが生まれ、交渉がまとまりやすくなる。
なお、自分一人では技術的な妥当性の判断が難しいと感じる場合は、開発会社とは別の第三者的な立場から助言を得られる窓口を頼るのも有効な選択肢だ。地域の商工会議所やよろず支援拠点では、IT導入に関する相談を受け付けていることが多く、契約書の内容や検収の進め方について客観的な視点でのアドバイスを得られる場合がある。事業承継の支援を専門に行う機関でも、システム関連の契約が承継の障害になっている相談は珍しくないため、担当者に一度相談してみる価値がある。相談に向かう際は、契約書や仕様書のコピー、そしてこれまでのやり取りを整理したメモを準備しておくと、限られた相談時間の中でも的確な助言を受けやすくなる。一人で抱え込まず、外部の視点を積極的に取り入れる姿勢そのものが、後継社長としての判断の質を高めていく。
まとめ
事業承継の直後に納品を迎える基幹システムの検収は、後継社長にとって「契約書の内容を理解していないまま、重い経営判断を求められる」という構造的に不利な場面になりやすい。この不利さの根本原因は、先代の時代に進んだ要件定義の内容や、開発会社との窓口を務めていた社員の頭の中にある情報が、後継社長にきちんと引き継がれていないことにある。
この構造を変えるためには、検収の前に契約書・仕様書・議事録を手元に揃え、開発会社との間で合格基準を事前にすり合わせ、実際の業務データや実際に使う現場の従業員による確認を経て、必要であれば「条件付き合格」という形で未了事項を文書に残す、という手順を丁寧に踏むことが欠かせない。そして、検収後に不具合が見つかった場合も、再現手順を具体的に示し、不具合か追加要望かを自分なりに切り分け、優先順位と期限を明確に伝えるという作法を守ることで、開発会社との関係を損ねずに、必要な対応を確実に引き出すことができる。
先代が築いてきた開発会社との信頼関係を大切にすることと、後継社長として契約上の確認をきちんと行うことは、決して矛盾しない。むしろ、検収という工程を正しく理解し、根拠を持って対応することこそが、これから何年も付き合っていく開発会社との関係を、より健全なものにしていく第一歩になる。刷新を社内主導で進めるか外注に任せきりにするかという判断軸は、刷新を社内主導で進めるか外注に任せきりにするかの決め方も参考にしてほしい。
事業承継の直後は、経理、人事、取引先対応など、優先度の高い課題が次々と押し寄せてくる時期であり、システムの検収に十分な時間を割くことが難しいと感じる後継社長も多いだろう。しかし、検収は一度署名してしまえば取り戻すことが難しい、契約上の重要な節目である。多忙な時期であっても、書類を揃え、合格基準をすり合わせ、チェックリストに沿って確認するという一連の手順を、たとえ時間がかかっても踏むことが、結果的には後々の余計な手間とコストを減らすことにつながる。後継社長としての最初のシステム関連の判断を、焦って済ませるのではなく、落ち着いて根拠のある判断として下せるかどうかが、その後の開発会社との関係、そして社内での意思決定の進め方そのものを方向づけていく。
