検収で見つけた不具合の頼み方。後継社長が開発会社に伝える手順と記録

検収の書類にサインする前に、後継社長の手が止まった理由

以下は、承継直後によく起きる場面を組み立てた例です。特定の会社の出来事ではありません。

先代が病気で急に退いてから半年。後継社長である佐藤さん（42歳）の会社では、先代が最後に発注した基幹システムのリプレイスがちょうど納品の時期を迎えていた。開発会社の担当者がノートパソコンを開き、「これで検収完了のご署名をいただければ、残金のご請求書をお送りします」と切り出した。佐藤さんは画面に表示された納品物一覧をざっと眺めた。受注管理、在庫管理、請求書発行の三つの機能が並び、それぞれ「実装済み」というステータスがついている。だが、その「実装済み」が何を確認した結果なのか、佐藤さんにはまったく分からなかった。

先代は現場に出ながら経営もこなす人で、システムの話は担当していた古参の総務部長と開発会社の間で進んでいた。佐藤さんは会議には同席していたが、要件定義の細かい議事録までは目を通していない。今、目の前にあるのは検収書という一枚の紙と、動くのか動かないのか実感の持てない画面だけだ。サインをすれば、そこから先の不具合は「有償の追加対応」になるかもしれない。サインをしなければ、開発会社への支払いが止まり、関係がこじれるかもしれない。どちらに転んでも、後継社長としての最初の重要な経営判断が、素性の分からない書類一枚に集約されてしまっている。

隣の椅子には、経理を担当している奥さんが心配そうな顔で座っている。開発会社の担当者は柔らかい口調で「先代様にはいつも快くご判断いただいていたので」と言葉を添えるが、その一言が余計に佐藤さんの背中を押してくる。ここでサインをしなければ、先代の代からの付き合いに水を差すことになるのではないか。だが、サインをした瞬間に何が確定するのかも分からないまま署名するのは、経営者としてあまりに危うい。佐藤さんは結局、「少し社内で確認してからもう一度連絡します」とだけ伝え、その場での署名を持ち帰った。同じ場面で、その場の空気に押されてペンを取ってしまう後継社長もいる。

この場面は特殊な例ではない。事業承継のタイミングとシステムの納品タイミングは重なることがある。先代が最後の大型投資として発注したシステムが、代替わりの直後に完成する。あるいは、先代の在任中には要件定義だけが終わっていて、実装と検収は後継社長の手に渡ってから行われる。いずれの場合も、後継社長は検収という工程の意味を正確に理解していないまま、重い判断を求められることになる。本稿では、この検収という工程で後継社長が具体的に何を確認すべきか、そして納品後に見つかった不具合をどう開発会社に依頼すれば無用な対立や追加費用を避けられるかを、実務の手順として整理する。開発会社との関係は、これから何年も続いていくものだ。最初の検収での対応が、その後の付き合い方の前提になる。

この記事で扱うのは、検収の場や検収後に見つかった不具合を、開発会社にどう伝えて直してもらうかです。要点は次の3つです。

• 不具合は「再現手順・期待した動き・実際の動き」をそろえ、仕様書の該当箇所を添えて書面で伝えます。 「動かない」「使いにくい」だけでは、不具合か追加要望かの判断が進みません
• 署名の前に、未了の不具合を一覧にして対応期限を文書に残します。 条件付き合格にすれば、支払いを止めずに対応義務を残せます
• 検収後に見つかった不具合にも、通知の期限があります。 請負契約なら民法上は不適合を知った時から1年以内の通知が原則ですが、契約書の定めを先に確認します

検収という言葉の基本と納品時のテストの進め方は検収とは？後継社長が納品時にやるべき確認と落とし穴で、合格基準を契約前に決める方法は「完成」の基準はどこで決まるか。検収前に定義しておく方法で扱っています。この記事は、その先の「見つかった不具合の扱い」に絞ります。

なぜ後継社長は検収でつまずくのか

検収という工程が持つ二つの意味

まず前提として、検収には二つの側面がある。ひとつは「契約上の意味」で、検収書に署名することは、納品物が発注時の仕様どおりに完成したことを発注者側が認め、残金の支払い義務を確定させる行為だ。もうひとつは「実務上の意味」で、検収は実際に業務で使ってみて困らないかを確かめる最後のチェックポイントである。契約書の条文上はどちらも「検収」という一語で片付けられてしまうため、この二重性を意識していないと、後継社長は自分がいったい何にサインしようとしているのかを取り違えたまま署名してしまう。

この二つの意味がずれると、トラブルが起きる。開発会社にとっての検収は基本的に契約上の意味が主で、「仕様書に書かれた機能が動くかどうか」を確認する工程だと捉えられている。一方、発注者である会社の現場は「自分たちの日々の業務が問題なく回るかどうか」を確認したいと思っている。仕様書に書かれていたことと、現場が実際に必要としていたことの間には、多かれ少なかれギャップがある。要件定義の段階でそのギャップをどれだけ潰せたかによって、検収時に発覚する問題の量は変わってくる。

このギャップは、開発会社が悪意を持って手を抜いているから生まれるわけではない。ソフトウェア開発という営みそのものが、最初に紙の上で決めた仕様と、実際に人間が手を動かして作り上げた完成物との間に、多少のズレを生み出しやすい性質を持っている。文章で「在庫が一定数を下回ったら通知する」と書かれていても、「一定数」がいくつなのか、通知は画面表示なのかメールなのか、誰に届けばいいのか、細部まで詰めて書かれた仕様書は実際には多くない。細部が詰められていない部分は、開発を担当するエンジニアが自分なりの解釈で実装を進めることになり、その解釈が発注者側の期待と一致するとは限らない。検収とは、この解釈のズレが実際にどこにどれだけ残っているかを、最後にまとめて確認する場だと考えるとわかりやすい。

後継社長がつまずく最大の理由は、この「仕様書に書かれたこと」を自分が把握していない、という点にある。要件定義に立ち会っていたのが先代や古参の総務部長であれば、後継社長は「何を約束したシステムなのか」を検収の場で初めて知ることになる。約束の内容を知らないまま、約束が守られたかどうかを判断することはできない。これは能力の問題ではなく、単純に情報が引き継がれていないという構造上の問題だ。

情報が引き継がれない4つの経路

システム発注に関する情報が後継社長に引き継がれない経路には、大きく4つのパターンがある。

一つ目は、先代がシステムの発注や契約の話を「経営の重要事項」ではなく「現場の細かい話」として扱っていたケースだ。先代の頭の中では、いくら投資したか、いつ完成するかは重要事項だが、具体的にどの機能をどう作るかは総務部長や現場担当者に任せる話になっている。このため、事業承継の引き継ぎ資料には「システム投資：〇〇万円、来期完成予定」という一行しか残らず、仕様書や議事録は現場の引き出しの中に眠ったままになる。

二つ目は、開発会社との窓口が先代個人ではなく、先代が信頼していた特定の社員に一本化されているケースだ。中小企業の場合、システム導入は多くの部署にとって初めての経験であり、社内で一人だけが開発会社とのやり取りに慣れていくということが起こりやすい。その担当者が窓口を独占していると、進捗も課題も要件変更の経緯も、その担当者の頭の中にしか残らない。後継社長が代替わりした時点で、その担当者が退職や異動で不在になっていると、情報は完全に失われる。

三つ目は、契約書や仕様書そのものが更新されずに古い状態で残っているケースだ。要件定義後にも現場からの要望で機能の追加や変更が発生することは珍しくないが、その変更が口頭やチャットのやり取りだけで済まされ、正式な仕様書に反映されないまま進んでしまうことがある。この場合、検収の場に置かれている仕様書と、実際に開発会社が作ったシステムの間にもズレがあり、後継社長がどちらを信じればいいのか分からなくなる。

四つ目は、承継そのものが急だったために、そもそも引き継ぎの時間が確保できなかったというケースも見逃せない。先代が急病や急逝で退任した場合、後継社長は経理・人事・取引先対応など、優先度の高い業務に忙殺され、システムの発注状況を確認する時間的余裕がないまま数か月が過ぎてしまうことがある。この間に検収の期限だけは契約書通りに進行しており、後継社長が気づいた時点で、すでに開発会社側から「そろそろ検収を」という打診が来ている、という状況に置かれることも珍しくない。時間的な余裕のなさが、検収の準備不足に直結してしまう構造がここにもある。

「動いている」ことと「使える」ことの違い

検収でもう一つ見落とされやすいのが、「動いている」ことと「業務で使える」ことの違いだ。開発会社が示す動作確認は、多くの場合、決められたテストケースに沿って機能を一つずつ実行し、想定どおりの結果が出るかを確認する作業である。これは重要な工程だが、実際の業務データの量や、実際のオペレーションの手順、実際に使う社員のITスキルまでは反映されていないことが多い。

たとえば在庫管理システムであれば、テストデータでは数十件の商品しか登録されていないが、実際の運用では数千件の商品を扱う。数十件では一瞬で表示される検索機能が、数千件になると数秒待たされる、というのはよくある話だ。あるいは、テストでは開発会社の担当者や情報システムに詳しい社員が操作しているが、実際に毎日使うのはパソコン操作に慣れていないパート従業員だったりする。画面の表示は仕様通りでも、実務でその通りに運用できるかどうかは別の問題として検証しなければならない。

後継社長がこの違いを理解していないと、「開発会社が動作確認済みと言っているのだから大丈夫だろう」という判断で検収書に署名してしまい、稼働後に現場から「使いにくい」「遅い」「思っていたのと違う」という声が噴出する事態になる。そしてその時点で検収が完了していると、開発会社に対して「これは契約時の仕様通りに作った結果であり、追加のご要望であれば別途お見積りします」と返される可能性が高い。

この落差が生まれる背景には、開発を依頼する側と実際に使う側の距離の問題もある。中小企業では、システムの発注窓口になるのは経営層や管理部門であり、実際に毎日そのシステムに向き合うのは現場の従業員だ。窓口となる側が「業務が回るシステムになっているか」を体感的に理解していないまま検収の判断を下すと、机上では正しく見える確認作業が、実際の現場感覚とはかけ離れたものになってしまう。後継社長自身が現場の作業を熟知している場合はこのリスクは小さくなるが、先代の代から現場を離れて経営に専念してきた後継社長ほど、この落差に気づきにくい。検収完了後、開発会社とどう関係を築いていくかについては、検収に合格した後、開発会社との関係で気をつけたいことで扱っている。

先代の人間関係が判断を鈍らせる構造

事業承継特有の事情として、開発会社との関係が先代個人の信頼関係の上に成り立っていることも、検収の判断を難しくする一因になる。先代が長年付き合ってきた開発会社であれば、後継社長としては「先代が選んだ会社なのだから、無下に疑うのも気が引ける」という心理が働きやすい。特に、開発会社の担当者が先代の葬儀や引き継ぎの場に顔を出し、「先代には本当にお世話になりました」といった言葉をかけてくることもある。そうした人間関係の文脈の中で、契約書や仕様書というドライな基準で判断することに抵抗を感じる後継社長は少なくない。

しかし、検収は感情や信頼関係とは別の、契約上の手続きである。人間関係を大切にすることと、納品物を仕様書に基づいて厳密に確認することは両立できる。むしろ、確認すべき点をきちんと確認したうえで署名する方が、開発会社にとっても後々のトラブルを避けられるため、双方にとって望ましい進め方だと理解しておく必要がある。

加えて、事業承継直後の後継社長は「自分がまだ会社の実権を完全には握っていない」という感覚を持っていることが多く、その不安が、開発会社に対して強い態度で確認を求めることへの心理的なハードルになっている場合もある。古参社員や取引先が先代のやり方を懐かしむ空気の中で、後継社長が独自の判断基準を持ち出すことに気後れを感じるのは自然な反応だ。だが、検収における確認は、先代のやり方を否定する行為ではなく、契約の当事者として当然に求められる責務である。この点を後継社長自身がまず自分の中で整理しておくことが、落ち着いた判断につながる。

署名の前に、何をそろえておくか？

契約書・仕様書・変更の記録をそろえ、見つかった不具合を「未了事項リスト」にまとめてから署名を判断します。確認項目の全体は別記事のチェックリストが使えます。

不具合を正しく伝えるには、何を約束したシステムなのかを先に押さえる必要があります。検収の予定が決まったら、遅くとも1週間前までに次の3点を手元にそろえます。

仕様書を受け取ったら、社長自身が一度通読し、分からない表現はその場で開発会社に説明を求めます。後の「不具合か追加要望か」の切り分けは、この仕様書が根拠になります。

検収の当日に見つかった問題は、署名の前に一覧にします。大部分が仕様どおりに動き、一部に不具合が残る場合は、未了事項ごとに対応期限と無償か有償かを明記したうえで「条件付き合格」とする進め方があります。基本機能が動かない、移行したデータが合わないといった場合は、不合格として修正を先に依頼します。合格・条件付き合格・不合格の判定基準を事前に決める方法は、前述の完成基準の記事で詳しく扱っています。

以下の3つは、承継後によく起きる状況を組み合わせた検討例です。実在の企業の事例ではありません。自社の契約書と照らし合わせながら読んでください。

検討例1：検収書に署名した翌月に基幹システムが止まった建材商社

従業員35名の建材商社では、先代の急逝から3か月後に、先代が発注していた受発注管理システムの納品を迎えた。後継社長は先代の長男で、要件定義の会議には数回しか出ておらず、詳細な仕様は把握していなかった。開発会社の担当者から「テストは一通り完了しています」と説明を受け、画面上で受注登録から出荷指示までの流れが一通り動くのを見て、その場で検収書に署名した。

問題が起きたのは翌月、月末の請求書一括発行のタイミングだった。テスト環境では十数件の注文データしか登録されていなかったため気づかなかったが、実際の月末処理では数百件の受注データを一度に処理する必要があり、処理の途中でシステムが固まって止まってしまった。慌てて開発会社に連絡したところ、「検収完了後の不具合対応は、契約書上、有償の保守契約の範囲内で対応します」という回答が返ってきた。保守契約はまだ結んでおらず、急遽スポット対応として見積りを取ったところ、当初の想定を大きく超える金額が提示された。

このケースの問題は、検収時に実際の業務ボリュームに近いデータでの動作確認をしていなかったことにある。もし検収前に「月末の一括処理を想定したテストデータでの動作確認」を合格基準に含めていれば、この不具合は検収時点で発見でき、無償修正の対象として交渉できたはずだった。後継社長が検収の意味を十分に理解していなかったために、本来であれば納品側の責任で直すべき不具合の修正費用を、発注側が追加で負担する結果になってしまった。

この会社ではその後、後継社長が過去のやり取りを開発会社にすべて開示してもらい、要件定義の段階で「月末の一括処理」についての記載が仕様書にあったことを確認できた。仕様書に記載があった以上、本来は無償修正の対象になるはずだという主張を後継社長が根拠を示して行ったところ、開発会社側も条文を確認し、最終的には一部無償・一部有償という折衷案で対応することになった。完全な無償対応を得ることはできなかったが、根拠を示して交渉することで、当初に提示された金額より低い費用で修正を終えられた。この経験から、後継社長は以後、どのシステム関連の契約でも、検収前に必ず仕様書を通読することを社内のルールとして定めた。

検討例2：「条件付き合格」を活用して交渉力を残した食品加工会社

従業員18名の食品加工会社では、先代から会社を継いだ二代目社長が、先代の在任中から進んでいた在庫管理システムの導入を引き継いだ。検収の当日、基本的な入出庫の記録や在庫の一覧表示は問題なく動作していたが、賞味期限が近い商品を自動で警告表示する機能に不具合があり、期限が過ぎた商品でも警告が出ないケースがあることが分かった。

この後継社長は、事前に商工会の経営相談窓口でシステム導入の進め方について相談しており、検収の合格基準を事前に開発会社とすり合わせておくという助言を受けていた。そのため、検収当日には未了事項リストをその場で作成し、「賞味期限警告機能の不具合は2週間以内に無償で修正すること」「修正完了後、再度動作確認の場を設けること」という条件を文書に明記した上で、条件付き合格として検収を進めた。

開発会社側も、契約時の仕様に明記されていた機能の不具合であることを認め、2週間後に無償で修正を完了させた。この事例のポイントは、検収の場で「動く部分」と「動かない部分」を明確に切り分け、動かない部分についてだけ対応義務を文書で残したことだ。全体を不合格にして納品全体を止めてしまうと開発会社との関係が硬直化しかねないが、条件付き合格という形にすることで、双方にとって現実的な進め方ができた。

検討例3：古参の総務部長の独断で検収が進んでいた印刷会社

従業員50名の印刷会社では、先代から経営を引き継いだ後継社長が、あるとき偶然、経理担当者から「システムの残金の請求書が来ているが、承認していいか」という確認を受けた。後継社長はそのシステムの検収がすでに完了していることをそこで初めて知った。調べてみると、先代の時代から開発会社との窓口を務めていた古参の総務部長が、後継社長への相談なしに独断で検収書に署名していたことが分かった。

総務部長にヒアリングしたところ、「先代の時代からのやり方で、システムのことは自分が窓口として処理してきた。特に大きな問題もなかったので、いつも通り検収を進めた」という説明だった。実際にシステムを確認してみると、大きな不具合はなかったものの、当初の要件定義にあった一部の機能が実装されておらず、総務部長自身もその欠落に気づいていなかったことが判明した。

このケースが示しているのは、事業承継後は「誰が検収の最終決定権を持つか」を明確にしておく必要があるということだ。先代の時代からの慣習で特定の社員が窓口を独占している場合、後継社長が知らないうちに重要な契約上の判断が進んでしまうリスクがある。承継後は早い段階で、開発会社に対しても社内に対しても、「システム関連の契約上の最終決定は後継社長が行う」ということを明確に伝え、検収を含む重要な意思決定の前には必ず報告を受ける体制に切り替えることが望ましい。

その後、この後継社長は開発会社に対して正式な文書で「今後、契約に関わる意思決定はすべて後継社長が最終確認を行う」という体制変更を通知した。総務部長にも、悪気があったわけではないことを理解しつつ、今後は検収前に必ず後継社長への報告を経るよう業務の進め方を改めてもらった。総務部長自身も、長年一人で判断してきた重責から解放されたことで、むしろ気持ちが軽くなったという。この事例は、情報の一本化が特定の担当者の独断ではなく、後継社長を含めた体制として機能するよう見直すことの重要性を物語っている。開発会社の担当者交代が起きた際に確認すべきことは、開発会社の担当者交代、後継社長が引き継ぎで確認すべきことにまとめている。

不具合を見つけたら、開発会社にどう伝えるか？

再現手順・期待した動き・実際の動きを1件ずつ書き、仕様書の該当箇所と業務への影響、希望する期限を添えて、メールなど記録に残る形で送ります。

検収の場で見つかった場合も、稼働後に見つかった場合も、伝え方の基本は同じです。

1件ごとに書く項目（記入例）

「動かない」「おかしい」だけの報告では、開発会社の担当者が手元で同じ操作を試しても再現できず、対応が止まります。1件ごとに次の項目を埋めてから送ります。以下は受注管理システムを題材にした記入例です。自社のシステムと業務に置き換えて使ってください。

画面の写真やスクリーンショットを添えると、再現の手がかりが増えます。

不具合か追加要望かを、仕様書で切り分ける

依頼する前に、それが「契約時の仕様と違う動き」なのか「仕様に書かれていないことを求めている」のかを、仕様書を見返して整理します。

すべてをまとめて「直してください」と送ると、開発会社は一律に「仕様どおりなので追加費用です」と返しやすくなります。社長側が根拠を示して分けておけば、無償か有償かの判断が1件ずつ進みます。判断に迷うものを無理に不具合として押し通さず、「協議」の欄に入れておくと、関係をこじらせずに話を進められます。

対応の優先順位と期限を明確に伝える

複数の不具合が同時に見つかった場合、すべてを同じ優先度で依頼すると、開発会社側もどこから手をつけるべきか判断がつかず、対応が遅れがちになる。業務への影響度に応じて「これは業務が止まるレベルなので今週中に対応してほしい」「これは運用に支障はないが、来月末までに直してほしい」というように、優先順位と希望する対応期限を明確に伝える。期限を示さずに依頼すると、開発会社側の他の業務との優先順位付けで後回しにされる可能性が高くなる。

対応内容と結果を記録に残す

不具合の報告から対応完了まで、口頭やチャットでのやり取りだけで済ませず、要点をメールなどの形で残す。誰がいつ何を依頼し、開発会社がいつどう対応し、いつ再確認が完了したか、という記録があれば、同種の不具合が再発した場合の参照にもなるし、保守契約の範囲内で対応すべきものだったかどうかの判断材料にもなる。特に、無償対応してもらった不具合については、それが無償だった理由（契約時の仕様に反する不具合であったこと）を記録に残しておくと、将来同じような議論が起きた際に有効な根拠になる。この記録は一覧表の形にして社内で共有しておくと、後継社長以外の担当者が問い合わせ対応をする際にも役立ち、開発会社とのやり取りが特定の個人に依存しない体制づくりにもつながる。

検収後に見つけた不具合は、いつまでに伝えるか

請負契約の場合、民法637条は、注文者が不適合を知った時から1年以内にその旨を請負人に通知しないと、修正の請求などができなくなると定めています（e-Gov法令検索「民法」）。これは契約不適合責任の期間の原則で、契約書で別の期間や範囲を定めている場合があります。まず自社の契約書の条項を確認し、見つけた時点で日付の残る形で通知しておきます。

開発の契約が請負ではなく準委任の形になっている場合は、責任の考え方が変わります。契約の種類の違いは請負契約と準委任契約、何がどう違うのかで整理しています。条項の読み方で判断がつかないときは、弁護士に確認してください。

よくある失敗パターン

失敗パターン1 「先代が信頼していた会社だから」と確認を省略する

先代が長年付き合ってきた開発会社に対して、後継社長が疑いの目を向けることに抵抗を感じ、確認作業を簡略化してしまうことがある。開発会社の担当者が誠実であることと、納品物が仕様通りに完成していることは、本来別の話だ。誠実な担当者であっても、人員不足やスケジュールの都合で確認が甘くなっていることはあり得る。信頼関係を保ちながらも、契約書や仕様書という客観的な基準で確認する姿勢は、開発会社にとっても失礼にはならない。発注者が確認する会社だと分かれば、開発会社も納品前の確認に手をかけやすくなる。この失敗パターンに陥りやすい後継社長の共通点は、「確認すること」と「疑うこと」を同じ意味で捉えてしまっていることにある。確認は疑いではなく、契約の当事者として当然に行うべき手続きであり、それを丁寧に行う後継社長の方が、長期的には開発会社からも信頼を得やすい。

失敗パターン2 検収を急ぎすぎて未了事項を口約束のままにする

先代の時代の慣習や、経理上の締めのタイミングなどの都合で、「今月中に検収を終わらせないといけない」という時間的な制約に追われ、細かい不具合を「あとで直してもらう約束で」という口約束だけで済ませてしまうケースがある。口約束は、担当者の異動や退職、あるいは単純な記憶の食い違いによって、後から「そんな約束はしていません」ということになりかねない。どうしても期限内に検収を終える必要がある場合は、前述の「条件付き合格」の形を取り、未了事項と対応期限を必ず文書として残す。時間の制約があるときほど、文書化を省いた判断が後で高くつきます。

失敗パターン3 現場の声を検収に反映させずに後から噴出させる

検収の場に立ち会うのが後継社長や情報システム担当者だけで、実際にそのシステムを毎日使う現場の従業員が確認に参加していないケースも多い失敗パターンだ。この場合、検収時点では機能面の不具合は見つからなくても、稼働後に現場から「使いにくい」「手順が増えて余計に時間がかかる」といった声が次々に上がってくる。これらは厳密には「不具合」ではなく「使い勝手の問題」であることが多いため、検収完了後に指摘しても、開発会社側からは追加要望として有償対応を提示されることが多い。現場の従業員に検収前の試用期間を設け、実際の業務フローに沿って操作してもらい、その声を検収の合格基準に反映させることで、この失敗は避けられる。

失敗パターン4 開発会社からの説明を録音や議事録に残さずに聞き流す

検収の場で開発会社の担当者が口頭で行う説明、たとえば「この機能は次のバージョンで対応予定です」「この部分は仕様の範囲外なので別途費用がかかります」といった発言は、後々のトラブルの火種になりやすい。その場では納得して聞いていても、時間が経てば発言の細部は忘れてしまう。担当者の発言は、可能であれば録音するか、少なくとも要点をその場でメモに取り、検収終了後にメールで「本日の確認内容は以下の通りと認識しています」という形で共有し、開発会社側からの確認の返信をもらっておく。この一手間を省くと、数か月後に「そんな説明は受けていない」という食い違いが起きたとき、どちらの記憶が正しいかを確かめる手段がなくなります。

よくある質問

検収後に見つかった不具合は、いつまでに伝えればいいですか

請負契約の場合、民法637条では、不適合を知った時から1年以内に開発会社へ通知しないと、修正の請求などができなくなるのが原則です。ただし契約書で別の期間や範囲を定めていることがあるため、まず契約書の条項を確認します。見つけた時点で、日付の残るメール等で通知しておくのが確実です。仕様どおりに動いているが使いにくい、という種類の問題は追加要望として扱われやすい点にも注意します。

開発会社の担当者から「検収完了とみなします」というメールが来て、期限内に返信しなかった場合、どうなりますか

契約書に「一定期間内に異議がなければ検収完了とみなす」という、いわゆるみなし検収の規定がある場合、期限内に具体的な不具合や懸念点を示して返信しなければ、その規定通りに検収完了とみなされてしまう可能性がある。多忙で確認が後回しになりがちな時期であっても、みなし検収の期限が設定されているメールを受け取った場合は、少なくとも「確認中なので期限を延長してほしい」という返信だけは早めに送っておくべきだ。何も返信しないことが最も不利な結果を招く。

先代の時代の要件定義書が見つからない場合、検収はどう進めればいいですか

要件定義書が社内に残っていなくても、開発会社側は業務として作成した文書を保管しているはずなので、まずは開発会社に正式な要件定義書または仕様書の再提出を依頼する。開発会社からの提出物と、実際に画面上で動いている機能を照らし合わせ、食い違いがあれば、その場で開発会社の担当者に経緯を確認する。合わせて、要件定義の会議に出席していた社内の担当者（総務部長や現場責任者など）に当時の記憶をヒアリングし、可能な範囲で経緯を再構成しておくことも有効だ。文書が完全に見つからない状態で検収を進めるのはリスクが高いため、時間がかかっても文書の再提出を優先する方がよい。

検収時に見つかった不具合が多く、開発会社との関係を損ねずに交渉するにはどうすればいいですか

まず、見つかった不具合を一覧化し、契約時の仕様に対する不具合なのか、追加要望なのかを整理したリストを作成する。それを開発会社に提示し、「これらはすべて契約時の仕様に基づく確認結果であり、追加のご負担をお願いするものではありません」という前提を明確に伝えたうえで、対応期限について協議する。感情的な対立を避けるためには、不具合の指摘を「開発会社の能力不足を責める言葉」ではなく「仕様との差異を客観的に共有する言葉」で伝える。同時に、条件付き合格という形で一部の支払いを進めることを提案すれば、開発会社側にとっても対応するインセンティブが生まれ、交渉がまとまりやすくなる。

自分だけでは技術的な妥当性を判断しにくい場合は、開発会社とは別の立場から助言を受ける方法もあります。国が47都道府県に設置している「よろず支援拠点」は、中小企業の経営相談を無料で受け付けています（よろず支援拠点）。相談に行く際は、契約書と仕様書の写し、不具合の一覧、これまでのやり取りのメモを持参すると、限られた時間でも状況を伝えやすくなります。契約条項の解釈が争点になっている場合は、弁護士への相談を検討してください。

まとめ

承継直後に納品を迎えるシステムの検収は、社長が契約の中身を把握しないまま判断を求められやすい場面です。原因は、先代の代に進んだ要件定義の内容や、窓口だった社員の頭の中にある情報が引き継がれていないことにあります。

不具合を見つけたときに社長がやることは、次の4つに絞れます。

1. 契約書・仕様書・変更の記録をそろえ、何を約束したシステムかを押さえる
2. 不具合を1件ずつ、再現手順・期待した動き・実際の動き・仕様書の該当箇所で書く
3. 不具合・追加要望・協議に分け、業務への影響に応じた期限を添えて送る
4. 依頼から再確認までを一覧に記録し、契約書の通知期限を過ぎないようにする

先代が築いた開発会社との関係を大切にしながら、契約の当事者として確認する。この2つは同時にできます。根拠をそろえて伝える発注者のほうが、開発会社にとっても対応の判断がしやすく、これから続く付き合いの土台になります。刷新を社内主導で進めるか外注に任せきりにするかの判断軸は、刷新を社内主導で進めるか外注に任せきりにするかの決め方も参考にしてください。