はじめに 「検収が終わった」で気を抜くと、後で必ずしわが寄る
新しい基幹システムや業務アプリの開発が終わり、開発会社から「これで完成です、ご確認ください」と提示された成果物を、社内で最終チェックして受け入れる。この一連の手続きを検収と呼びます。先代から会社を引き継いだ後継社長にとって、この検収完了は一つの大きな山を越えた瞬間です。長い要件定義、何度も揉めた仕様変更、当初予算を超えた追加費用の交渉——それらをすべて乗り越えて、ようやく「合格」の印を押せた。ホッとするのは当然ですし、その安堵感自体は正しい感覚です。
ただ、ここで多くの後継社長がやってしまう失敗があります。検収に合格した瞬間に「これで終わった」と思い込み、開発会社との関係性についての意識をゼロに戻してしまうことです。実際には、検収合格はプロジェクトの「納品」という区切りであって、システムと開発会社との付き合いの「終わり」ではありません。むしろそこから、システムが会社の実務に定着し、育ち、長く使われていくための、もう一つのフェーズが始まります。
先代の時代からの取引先である開発会社と、事業を継いだばかりの後継社長との関係は、独特の緊張感を持っています。先代が個人的な信頼関係で「まあ、いつも通り頼むよ」で済ませていたやり取りを、後継社長は仕組みとして引き継がなければなりません。感覚や口約束に頼っていた部分を、契約書や運用ルールという形に翻訳し直す作業が、検収後にこそ必要になるのです。
この記事では、検収に合格した直後から始まる「その後」の期間に、後継社長が具体的に何を確認し、何を整え、開発会社とどう付き合っていけばよいかを、実務目線で整理します。専門用語は極力かみ砕いて説明しますので、ITに詳しくない方でも実践できる内容になっています。
検収合格の直後に確認すべき5つのこと
まず、検収に合格した直後の1〜2週間でやるべきことを整理します。ここでの確認漏れは、半年後、1年後に「まさかこんなことになるとは」という形で表面化しがちです。
1. 検収合格が意味する範囲を正確に理解する
検収に合格したというのは、「契約で決めた要件・仕様を満たしていることを、発注者側が確認して認めた」という事実にすぎません。ここで注意したいのは、検収合格は「未来永劫、このシステムに何の問題も起きないことを保証する」という意味ではないという点です。
検収時点でのテストは、限られた時間と項目の中で行われます。実際の業務で1年を通じて使い続けると、検収時には想定していなかった使い方や、月末月初など特定のタイミングでしか発生しないデータ量の負荷によって、不具合が見つかることがあります。この「検収後に見つかった不具合を誰がどう直すのか」というルールが、実は検収合格そのものとは別に決めておくべき論点です。
多くの契約書には、検収後の一定期間（多くは3ヶ月〜1年）に発見された不具合について、開発会社が無償で修正する義務を定めた条項があります。これを契約不適合責任と呼びますが、この期間と範囲がどうなっているかを、検収合格の直後にもう一度契約書を読み返して確認してください。「後で見ればいい」ではなく、「今、期間のカウントダウンが始まっている」という意識が重要です。
2. 契約書・見積書・仕様書一式を1つのフォルダに集約する
先代の時代の資料は、紙のファイルに入って倉庫の奥にある、担当者の個人のメールに埋もれている、あるいは先代の頭の中にしかない、というケースが非常に多く見られます。検収が完了したこのタイミングで、以下の資料を一式、社内で確実にアクセスできる場所（クラウドストレージのフォルダなど）にまとめておくことを強くお勧めします。
- 契約書（業務委託契約書、システム開発契約書など、原本またはスキャンデータ）
- 見積書・請求書の履歴(当初見積もりと、追加費用が発生した場合はその明細)
- 仕様書・要件定義書（最終版。途中で変更があった場合はその変更履歴も）
- 検収書・検収完了の合意を示すメールやメッセージのやり取り
- 開発会社の担当者・窓口の連絡先（担当者が変わった場合の履歴も）
- システムのID・パスワード・管理者権限の情報（誰が把握しているか）
これらが1つにまとまっていないと、次に何か問題が起きたとき、あるいは開発会社を変更しようと考えたときに、「そもそも何を契約していたのか」を確認するだけで数週間かかってしまいます。先代から会社を継いだ後継社長にとって、この資料集約作業は、システムの実態を掴むための最初の一歩でもあります。
3. 保守・運用の体制がどうなっているかを確認する
システムは作って終わりではありません。日々の運用の中で、ちょっとした操作方法の質問、パスワードリセット、軽微な表示崩れの修正など、小さな対応が必ず発生します。この「作った後の面倒を誰が見るのか」という体制を、検収合格のタイミングで明確にしておく必要があります。
多くの開発会社は、納品後の対応を別途の保守契約として契約するように提案してきます。この契約に何が含まれ、何が含まれないのかを正確に把握しておくことが重要です。「月額いくらでどこまで対応してもらえるのか」「別途費用が発生するのはどんな作業か」「対応してもらえる時間帯はいつなのか」を、検収合格の直後、記憶が新しいうちに確認しましょう。
先代の時代は、この保守契約が明文化されておらず、「困ったときに電話すれば来てくれる」という暗黙の関係で成立していたケースが多くあります。しかし、開発会社の担当者が変わったり、先代個人との人間関係で成立していた「特別対応」が後継社長の代では通用しなくなったりすることは、決して珍しい話ではありません。関係性が良好なうちに、これを文書として整理しておくことが、後々の安心材料になります。
4. 障害・不具合が起きたときの連絡フローを確認する
システムが止まった、データが表示されない、ボタンを押しても反応しない——こうした事態が起きたとき、誰に、どうやって連絡すればいいのか。この連絡フローが社内で共有されていないと、いざというときに現場が混乱し、対応が後手に回ります。
検収合格の直後に、以下を確認・整理しておきましょう。
- 緊急時の連絡先（電話番号、メールアドレス、チャットツールのID）
- 連絡してから初動対応までの目安時間はどの程度か
- 対応してもらえる曜日・時間帯（土日祝日や深夜の扱いはどうか）
- どのレベルの不具合まで無償対応で、どこから追加費用が発生するか
これらをまとめて社内で共有し、担当者が変わっても引き継がれるようにドキュメント化しておくことが、検収後の安心運用の土台になります。障害対応の連絡先や体制の取り決め方をより詳しく知りたい場合は、承継後の障害対応、誰に連絡しどこまで任せるかの取り決め方も参考になる。
5. 開発会社への「ありがとう」を言葉にして伝える
これは実務的な手続きではありませんが、非常に重要なポイントです。検収に合格したということは、開発会社のエンジニアやプロジェクトマネージャーが、何ヶ月にもわたって試行錯誤し、時には仕様変更にも対応し、御社の業務を理解しようと努力した結果です。その労力に対して、感謝の言葉を一言伝えるだけで、その後の関係性は大きく変わります。
「今後もよろしくお願いします」という一言と、「今回は本当に助かりました」という一言は、契約書には書かれない、しかし実務では非常に効果を持つコミュニケーションです。後継社長が先代から引き継いだ取引先との関係を、これから自分の代でも良好に続けていきたいのであれば、この最初の一言をおろそかにしないことをお勧めします。
検収後によくある失敗パターン
ここからは、実際に中小企業でよく見られる失敗パターンを紹介します。自社に当てはまる部分がないか、チェックしてみてください。
失敗パターン1 「もう完成したから連絡しなくていい」と思い込む
検収合格から数ヶ月後、業務の中で「あの機能、実はもう少しこうだったら使いやすいのに」という声が現場から上がってくることは、ほぼ必ず起きます。しかし、後継社長が「検収も終わったし、もう開発会社に連絡するのは気が引ける」と考えて、その声を放置してしまうケースがあります。
実際には、開発会社側もこうした「使ってみて分かった改善点」を、追加の相談として受け付ける準備をしています。連絡を控えることは、開発会社への配慮のつもりでも、実際には現場の不満が溜まり続け、システムへの信頼が損なわれていく結果につながります。小さな改善要望であれば、保守契約の範囲内で対応してもらえることも多いので、まずは相談してみる姿勢が大切です。
失敗パターン2 検収後の不具合を「使い方が悪い」で終わらせてしまう
検収後にシステムの不具合らしき現象が起きたとき、開発会社から「それは仕様です」「使い方の問題です」と言われて、そのまま納得してしまうケースがあります。もちろん、実際に操作ミスであることもありますが、契約不適合責任の期間内であれば、本来は開発会社側が無償で調査・対応すべき範囲のこともあります。
ここで後継社長がやるべきことは、「本当にこれは仕様の範囲内なのか、それとも契約不適合責任の対象になる不具合なのか」を、契約書と仕様書を見ながら冷静に確認することです。感覚だけで「まあ、仕方ないか」と受け入れてしまうと、本来無償で直してもらえたはずの不具合の修正費用を、自社で負担することになりかねません。判断に迷う場合は、契約書のコピーを手元に置いた上で、開発会社に「この現象は契約不適合責任の範囲内での対応をお願いしたいのですが」と、具体的に切り出すことが有効です。
失敗パターン3 保守契約を結ばずに放置する
見積もりの段階で保守契約の提案を受けたものの、「開発費用だけでも高かったから、保守は様子を見てから」と後回しにしてしまうケースは非常に多く見られます。しかし、保守契約を結んでいない状態でシステムに不具合が起きると、対応してもらえるまでの優先順位が下がったり、都度見積もりで割高な費用がかかったりすることがあります。
また、開発会社側から見ても、保守契約を結んでいない顧客への対応リソースは限られます。契約がない状態は、いわば「関係が切れた顧客」に近い位置づけになってしまう可能性もあるのです。検収後、実際にシステムを1〜2ヶ月運用してみて、どの程度の頻度で問い合わせや修正が必要になるかを見極めた上で、早めに保守契約を検討することをお勧めします。保守契約を更新・締結する際に開発会社から受け取っておくべきものについては、保守契約を更新する前に、開発会社から受け取っておくべきものにまとめている。
失敗パターン4 担当者の異動・退職に気づかない
開発会社側でも、担当していたプロジェクトマネージャーやエンジニアが異動や退職で変わることがあります。この引き継ぎが不十分だと、次の担当者が自社のシステムの詳細を把握していないまま対応することになり、対応品質が落ちる、あるいは同じ説明を何度もさせられる、という事態が起きます。
検収合格後、半年に1回程度は「担当者に変更はないか」「もし変わった場合、引き継ぎはどのように行われたか」を確認する習慣をつけておくと、こうした事態への備えになります。特に先代の代から付き合いのある開発会社の場合、先代を直接知る担当者が退職してしまうと、それまでの暗黙の了解や経緯が一気に失われるリスクがあります。
失敗パターン5 サービス品質の基準を確認せずに「遅い」と感じたまま放置する
システムの応答が遅い、問い合わせへの返信が遅い、といった「品質」に関する不満は、後継社長が抱えがちな悩みの一つです。しかし、そもそも契約上、どの程度の応答速度・対応速度が約束されているのかを確認していないケースが多くあります。
契約の中で、システムの稼働率や、問い合わせへの対応時間の目安などを定めた品質保証の基準をSLA（サービス品質保証）と呼びます。この基準が契約書やサービス説明資料の中に明記されているかどうかを確認し、明記されていればその基準と実際の対応を比較する、明記されていなければ「どの程度の対応を期待できるのか」を開発会社に改めて確認することが有効です。「なんとなく遅い気がする」という感覚だけで開発会社への不満を募らせるのではなく、基準を確認した上で、基準を下回っているのであれば具体的に指摘する、基準内であればそれを理解した上で付き合い方を調整する、という判断ができるようになります。
開発会社との関係を「先代の代」から「自分の代」に更新する
事業承継という文脈で特有の難しさは、開発会社との関係が「先代個人」との人間関係の延長線上で成立していた場合に生じます。先代が開発会社の社長と個人的に親しく、細かい契約条件を確認しないまま「いつもの感じで」進めていた——こうした関係は、後継社長の代になると、良くも悪くも見直しが必要になります。
なぜ「先代の暗黙の了解」は後継社長には通用しないのか
先代と開発会社の間には、長年の付き合いの中で積み上げられた信頼関係があります。「多少の無理を言っても対応してもらえる」「価格交渉も柔らかく応じてもらえる」といった暗黙の了解は、多くの場合、契約書には書かれていません。書かれていないからこそ、後継社長がその関係を引き継いだときに、同じ対応を期待してしまい、実際には得られずに戸惑う、というギャップが生まれます。
これは開発会社が不誠実だからではなく、単に「先代個人との関係性の中で成立していた特別対応」が、代替わりによって自然に薄れていくという、ごく自然な現象です。後継社長がこのギャップに気づいたら、感情的に「対応が悪くなった」と捉えるのではなく、「関係性を仕組みに落とし込むタイミングが来た」と捉え直すことが建設的です。
検収合格後こそ、条件を仕組み化する好機
検収に合格し、プロジェクトが一区切りついたタイミングは、実は開発会社との条件を再確認し、仕組みとして整理する絶好の機会です。プロジェクトの真っ最中は、仕様や納期の調整に集中せざるを得ず、契約条件について踏み込んだ話をするのは難しいものです。しかし、検収が終わり、双方が一息ついたこのタイミングであれば、次のような話し合いを持ちかけやすくなります。
- 「今後の保守対応について、改めて条件を整理させていただけますか」
- 「担当者が変わる可能性がある場合、引き継ぎのルールを決めておきたいのですが」
- 「今回の開発を踏まえて、今後追加の改修が発生した場合の見積もりの目安を教えていただけますか」
こうした話し合いは、開発会社との関係を壊すものではなく、逆に「この会社は仕組みとしてきちんと付き合ってくれる会社だ」という信頼を開発会社側に持ってもらうきっかけにもなります。曖昧なまま付き合いを続けるよりも、双方が納得できる条件を明文化しておく方が、結果的に長期的な関係の安定につながります。
先代の口約束を、開発会社に確認する
先代から「あの会社とはこういう約束になっている」と聞いていた条件が、実際に契約書に明記されているかどうかを確認することも重要です。口約束だけで、契約書に反映されていない条件は、先代が引退したり、開発会社の担当者が変わったりした瞬間に、まるで存在しなかったことになってしまうリスクがあります。
検収合格のタイミングで、先代から聞いていた条件（例えば「トラブル時は無償で駆けつけてくれる」「年に1回は無償で軽微な改修をしてくれる」など）があれば、それを開発会社の現担当者に確認し、可能であれば文書やメールの形で残しておくことをお勧めします。「今更確認するのは気まずい」と感じる後継社長もいるかもしれませんが、むしろ「代替わりを機に、条件を明確にさせていただきたい」という趣旨で伝えれば、多くの開発会社は好意的に応じてくれます。
古参社員・現場との関係もセットで整える
検収合格後の関係構築は、開発会社との間だけの話ではありません。社内、特に長年勤めている古参社員や現場のスタッフとの関係も同時に整える必要があります。というのも、新しいシステムが実際に使われ続けるかどうかは、開発会社の対応力だけでなく、現場がそのシステムをどう受け止めるかに大きく左右されるからです。
古参社員がシステムを「先代の時代のやり方」と比較する
先代の時代から働いている古参社員は、旧来のやり方(紙の帳簿、電話でのやり取り、担当者の記憶に頼った管理など)に慣れています。新しいシステムが導入されると、「前の方が早かった」「先代の頃はこんな面倒なことはしなかった」という声が出てくることは、ほぼ避けられません。
このとき、後継社長が開発会社との関係だけに気を配り、社内の不満の声を放置してしまうと、システムが定着せずに「宝の持ち腐れ」になってしまうリスクがあります。検収合格後、実際に現場でシステムを使い始めてからの最初の1〜2ヶ月は、古参社員からの声を丁寧に拾い、必要であれば開発会社に「現場からこういう声が上がっているのですが、対応可能でしょうか」と相談する、という橋渡しの役割を後継社長自身が担う必要があります。
開発会社への相談窓口を一本化する
現場のスタッフが個別に開発会社へ問い合わせを始めると、開発会社側も「誰の指示で、どこまで対応すればいいのか」が分からなくなり、対応が混乱します。検収合格後は、開発会社への相談・問い合わせの窓口を、後継社長自身か、信頼できる特定の社員1〜2名に一本化することをお勧めします。
これにより、開発会社との会話の履歴が一貫して管理でき、「言った・言わない」のトラブルも防げます。また、現場からの要望を一度後継社長側で取りまとめてから開発会社に伝えることで、優先順位をつけた効率的な依頼ができるようになります。
現場の「使いにくい」を、開発会社への改善要望に翻訳する
現場のスタッフは「使いにくい」「分かりにくい」という感覚的な不満を口にすることが多いですが、これをそのまま開発会社に伝えても、具体的な改善につながりにくいことがあります。後継社長の役割の一つは、この感覚的な不満を、開発会社が対応しやすい具体的な要望に翻訳することです。
例えば「入力が面倒」という声があれば、「どの画面の、どの項目の入力が、どういう場面で面倒に感じるのか」を掘り下げて聞き、それを開発会社に伝える。この一手間が、現場の満足度とシステムの改善速度を大きく左右します。
検収後1年間のタイムラインで考える関係構築
検収合格後の関係構築を、時間軸に沿って整理すると分かりやすくなります。以下は目安となるタイムラインです。
検収合格〜1ヶ月目
契約書・仕様書などの資料集約、保守契約の内容確認、緊急連絡フローの整理、現場への浸透状況の確認を行う期間です。この時期は、開発会社への感謝を伝えつつ、まだ気づいていない不具合や使いにくさがないか、現場からのフィードバックを積極的に集めましょう。
2〜3ヶ月目
実際に日常業務でシステムを使い込む中で、細かい改善要望が出てくる時期です。これらを取りまとめて、保守契約の範囲内でどこまで対応してもらえるかを開発会社と相談します。また、契約不適合責任の期間内に発見された不具合については、この時期までにできるだけ洗い出しておくことが望ましいです。
4〜6ヶ月目
システムが業務に定着し始める時期です。この頃には、開発会社との定例的な連絡(月1回程度の状況報告や相談の機会)を設けておくと、小さな問題が大きくなる前に共有できる関係が築けます。先代の時代からの担当者に変更がないかも、この時期に一度確認しておくとよいでしょう。
7〜12ヶ月目
契約不適合責任の期間が終了に近づく時期です(契約内容によって期間は異なるため、契約書で正確な期限を確認してください)。この期間が終わる前に、まだ気づいていない不具合がないか、社内で最終的な確認を行うことをお勧めします。期間が過ぎてからの修正は、有償対応になる可能性が高いためです。また、1年間の運用を振り返り、保守契約の内容が実態に合っているか(対応範囲が広すぎて費用が無駄になっていないか、逆に狭すぎて追加費用がかさんでいないか)を見直すタイミングでもあります。
具体的な事例で見る「検収後の関係づくり」の分かれ道
抽象的な心構えだけでは、実際の場面でどう振る舞えばいいのか分かりにくいという方もいるでしょう。ここでは、事業承継後の中小企業でよく見られる具体的なシチュエーションを取り上げ、うまくいったケースとこじれたケースを対比しながら紹介します。
事例1 追加改修の依頼で関係がこじれた製造業の後継社長
ある部品加工業を営む後継社長は、先代が使っていた紙の受注管理を、新しい受注管理システムに置き換える開発を発注しました。検収に合格し、システムは無事に稼働を始めましたが、3ヶ月ほど経過したところで、現場の事務スタッフから「取引先ごとに単価が違うのに、一括で単価を変更する機能がないと入力が大変」という声が上がりました。
後継社長はこの要望を、深く検討せずにそのまま開発会社にメールで送りました。「単価を一括変更できるようにしてほしい」という一文だけのメールです。開発会社側は、この要望が「検収時の仕様に含まれていた機能の不具合」なのか、「検収後に新たに欲しくなった追加機能」なのかを判断できず、確認のメールを返しました。ところが後継社長は「前に頼んだことがなぜまだできていないのか」という受け止め方をしてしまい、やり取りがすれ違ったまま数週間が経過し、双方に不満が残る結果になりました。
この事例の問題点は、要望を伝える際に「これは仕様の不備なのか、追加要望なのか」を後継社長自身が整理せずに伝えてしまったことです。もし最初から「検収時の仕様には入っていなかった機能だと思いますが、追加でこういう機能を付けることは可能でしょうか。可能であれば費用と期間の目安も教えてください」と伝えていれば、開発会社側も的確に見積もりを出し、スムーズに話が進んだはずです。検収後の要望は、性質を切り分けて伝えることが、関係をこじらせないための第一歩になります。仕様変更を追加費用のトラブルなく伝える具体的な手順は、仕様変更を伝えるとき、追加費用でもめないための手順で詳しく解説している。
事例2 定例連絡を続けたことで大きな障害を未然に防いだ運送業のケース
一方、ある運送業の後継社長は、検収合格後、開発会社と月1回、15分程度の電話連絡を続けていました。特に大きな問題がない月でも、「配車システムの調子はどうですか」「最近、現場から何か声は出ていますか」という程度の軽い確認を欠かさなかったといいます。
半年ほど経ったある日、開発会社の担当者から「実は、御社が使っているデータベースのソフトウェアが、来月でサポート終了になる予定です。放置すると、セキュリティ上のリスクが高まります」という連絡がありました。この情報は、開発会社側からすると「まだ深刻な問題ではないので、こちらから積極的に持ちかけるべきかどうか迷っていた」情報でしたが、定例連絡の場があったからこそ、早い段階で共有されました。後継社長はすぐに対応の相談を始め、大きな障害が起きる前に計画的な対応ができました。
この事例が示しているのは、「何もない時期にも接点を持ち続けること」の価値です。トラブルが起きてから連絡を取ろうとすると、開発会社側の対応も後手に回りがちですが、定例的な関係があると、開発会社側から能動的に情報を共有してもらえる土台ができます。
事例3 先代の「特別価格」が消えて揉めた小売業のケース
先代が経営していた頃、ある開発会社とは20年近い付き合いがあり、ちょっとした改修は「今回は無料でやっておきますよ」という対応が当たり前になっていました。後継社長が事業を継いだ後、初めての大きな改修が終わり検収に合格した際、後継社長は「いつも無料でやってもらえるものだ」という認識のまま、次の小さな改修も「無料でお願いします」と伝えました。
しかし、開発会社の担当者は先代の代から変わっており、新しい担当者は「これは有償の作業範囲になります」と回答しました。後継社長は「今までは無料だったのに」と不満を持ちましたが、実際には、その「無料対応」は先代個人と旧担当者との間の暗黙の了解であり、契約書には一切記載されていませんでした。
この事例では、双方に落ち度があるわけではなく、単純に「引き継がれるべき情報が引き継がれていなかった」ことが原因です。後継社長が検収合格のタイミングで、先代に「これまで無料でやってもらっていた作業の範囲」を確認し、それを新しい担当者にも共有しておけば、こうした行き違いは避けられたはずです。先代がまだ相談できる状況にあるなら、事業承継の早い段階で、こうした「言葉にされていない優待条件」を洗い出しておくことが重要です。こうした行き違いが実際にこじれてしまった場合の交渉の進め方は、トラブル時の交渉術。感情的にならずに解決するを参考にしてほしい。
事例4 現場の声を吸い上げる仕組みを作ったことで定着に成功した介護施設のケース
ある介護施設を運営する後継社長は、先代の代からの紙の記録を電子化する記録システムを導入しました。検収合格後、現場の介護スタッフの多くが年配で、タブレットの操作に不慣れだったため、当初は「紙の方が早い」という不満が多く上がりました。
この後継社長が行ったのは、検収合格から2週間後に、現場スタッフ全員を対象にした「使ってみてどうだったか」という簡単なヒアリングの場を設けることでした。そこで出てきた声を、後継社長自身が「操作の問題」「機能不足の問題」「単純な慣れの問題」の3つに分類し、機能不足に関する部分だけを開発会社にまとめて伝えました。操作や慣れの問題については、社内で操作マニュアルを作り直し、使い方の勉強会を開くことで対応しました。
結果として、開発会社への依頼は的確な内容に絞られ、対応もスムーズに進みました。同時に、現場スタッフも「自分たちの声が反映されている」という実感を持てたことで、システムへの抵抗感が徐々に薄れていきました。この事例が示すのは、現場の不満をすべて開発会社に投げるのではなく、社内で対応できる部分と開発会社に依頼すべき部分を後継社長が仕分ける役割を担うことの重要性です。
開発会社に送るメール・伝え方の具体例
実際に開発会社へ連絡する際、どのような言葉を選べばよいか迷う後継社長は少なくありません。ここでは、場面別に使える伝え方の型を紹介します。
感謝を伝えるとき
「先日は長期間にわたるご対応、本当にありがとうございました。おかげさまで現場でも問題なく稼働しております。今後もよろしくお願いいたします。」
このように、検収合格から数日以内に、簡潔でよい一言を送るだけで十分です。長い文章である必要はなく、タイミングの早さと誠意が伝わることが重要です。
不具合かどうか判断がつかない現象を伝えるとき
「〇〇の画面で、△△という操作をしたときに、××という表示が出ることに気づきました。仕様なのか不具合なのか判断がつかないため、一度ご確認いただけますでしょうか。発生した日時は◯月◯日◯時頃です。」
現象を具体的に、いつ・どこで・何をしたら・どうなったか、という順番で伝えると、開発会社側の調査がスムーズになります。感情的な表現(「困っています」「早く直してください」など)は最小限にとどめ、事実を先に伝えることが結果的に早い対応につながります。
追加の改修を依頼するとき
「現場で運用を始めてから、こういう場面で不便を感じるという声が出ています。当初の仕様には含まれていなかった内容かと思いますので、追加の改修として対応可能か、可能であれば費用と期間の目安をご教示いただけますでしょうか。」
追加改修であることを明確にし、費用と期間の目安を先に確認する姿勢を示すことで、開発会社側も安心して見積もりを提示しやすくなります。
保守契約の内容を確認・相談したいとき
「これまでの運用を踏まえて、今後の保守体制について改めて相談させていただきたく存じます。対応範囲や費用感について、一度お時間をいただけますでしょうか。」
「相談したい」という姿勢で伝えることで、開発会社側も一方的な要求ではなく、対話の機会として受け止めやすくなります。
担当者の変更を確認したいとき
「今後も長くお付き合いさせていただきたく思っておりますので、担当者様に変更があった場合には、事前にお知らせいただけますと助かります。」
このように伝えておくことで、開発会社側も担当者変更時の引き継ぎを意識してくれるようになります。
事業承継期特有の「二重の不安」に向き合う
後継社長が検収後の関係構築で苦労する背景には、単純な業務上の課題だけでなく、事業承継特有の心理的な負担が重なっている場合が多くあります。ここでは、その二重の不安について触れておきます。
「先代と比べられる」という不安
後継社長は、社内からも取引先からも、常に「先代と比べてどうか」という視線を意識せざるを得ない立場にあります。開発会社との関係においても、「先代はもっとうまく付き合えていたのに」と思われることを恐れて、必要な確認や交渉を遠慮してしまう後継社長は少なくありません。
しかし、開発会社側も、経営者が代替わりすることは十分に理解しています。先代と全く同じやり方を求められるとは考えていないことがほとんどです。むしろ、後継社長が自分の言葉で、自分のスタイルで関係を築こうとする姿勢を、前向きに受け止める開発会社が多いというのが実情です。比べられることを恐れて何もしないよりも、自分なりの丁寧な関係構築を進める方が、結果的に信頼を得やすくなります。
「IT分野で分からないことを聞くと恥ずかしい」という不安
もう一つの不安は、IT分野の専門知識が乏しいことへの引け目です。「こんな初歩的なことを聞いたら、開発会社に見下されるのではないか」と考えて、本来確認すべきことを聞けずに終わってしまう後継社長が多く見られます。
しかし、開発会社にとって、経営者がシステムの技術的な詳細まで理解している必要はありません。むしろ、分からないことを率直に「教えてください」と聞いてくれる経営者の方が、開発会社としても説明のしどころが分かり、対応しやすいという声も多く聞かれます。「分からないので教えてほしい」という一言を惜しまないことが、結果的に良好な関係構築の近道になります。
検収後の関係構築 チェックリスト
最後に、この記事で紹介した内容を、実際に使えるチェックリストの形でまとめます。検収合格後、順番に確認していってください。
検収合格直後(1〜2週間以内)
- 契約不適合責任の対象期間と範囲を契約書で確認したか
- 契約書・見積書・仕様書・検収完了の記録を1つの場所に集約したか
- 保守契約の有無と内容(対応範囲・費用・時間帯)を確認したか
- 障害発生時の緊急連絡先と対応フローを社内で共有したか
- 開発会社に感謝の言葉を伝えたか
1〜3ヶ月目
- 現場スタッフからのヒアリングの場を設けたか
- 開発会社への相談窓口を社内で一本化したか
- 現場の感覚的な不満を、具体的な改善要望として整理したか
- 保守契約を結んでいない場合、締結を検討し始めたか
4〜6ヶ月目
- 開発会社との定例連絡(月1回程度)の場を設けているか
- 開発会社の担当者に変更がないか確認したか
- 先代から聞いていた「暗黙の了解」を、現担当者と確認し文書化したか
7〜12ヶ月目
- 契約不適合責任の対象期間が終了する前に、社内で不具合の最終確認を行ったか
- 保守契約の内容が実態に合っているか(過不足)を見直したか
- 1年間の運用を振り返り、今後の開発会社との付き合い方について方針を持てたか
このチェックリストは、一度確認したら終わりというものではありません。事業の状況やシステムの利用状況が変われば、確認すべき内容も変わっていきます。検収合格から1年が経過した後も、半年に1回程度、このチェックリストを見直す習慣を持っておくと、開発会社との関係を長期的に健全な状態に保ちやすくなります。
よくある質問
検収に合格した後で、大きな不具合が見つかった場合はどうすればいいですか
まず契約書を確認し、契約不適合責任の対象期間内かどうかを確認してください。期間内であれば、開発会社に無償での調査・修正を依頼できる可能性が高いです。連絡する際は、いつ、どんな操作をしたときに、どんな現象が起きたかを具体的に整理して伝えると、開発会社側の対応もスムーズになります。感覚的に「なんかおかしい」と伝えるのではなく、再現できる手順を示すことが重要です。もし契約不適合責任の対象期間を過ぎていた場合は、有償対応になることが多いですが、それでも開発会社に相談する価値はあります。長年の付き合いがある会社であれば、一定の配慮をしてもらえるケースもあります。
保守契約を結んでいないのですが、今から結んでも大丈夫でしょうか
もちろん大丈夫です。むしろ、検収合格から数ヶ月経ち、実際の運用でどの程度のサポートが必要かが見えてきたタイミングで保守契約を検討するのは、合理的な進め方です。開発会社に「これまでの運用状況を踏まえて、保守契約の内容を相談したい」と伝えれば、実態に合ったプランを提案してもらえることが多いです。契約前に、過去数ヶ月の問い合わせ回数や内容を振り返り、それを開発会社との相談材料にすると、より的確な条件で契約できます。
先代の時代からの付き合いの開発会社と、今後もずっと付き合っていくべきでしょうか
必ずしも「ずっと同じ会社と付き合うべき」というわけではありません。ただ、検収合格直後のこの段階では、まずは関係を仕組み化し、条件を明確にすることを優先することをお勧めします。仕組み化した上で、対応の質や費用感に納得できない部分が続くようであれば、他の開発会社への切り替えを検討する余地は十分にあります。重要なのは、感情的な「付き合いだから」という理由だけで判断を続けるのではなく、契約内容や対応実績という具体的な材料に基づいて、その都度関係を見直せる状態を作っておくことです。
開発会社の担当者と、どのくらいの頻度で連絡を取るのが適切ですか
システムの利用頻度や規模にもよりますが、目安としては、検収合格後の最初の3ヶ月は月1回程度、その後は3ヶ月に1回程度の定期的な連絡を持つことをお勧めします。何も問題がなくても、「その後の使用状況はいかがですか」といった軽い確認の連絡を入れておくことで、開発会社側も自社のシステムへの関心を持ち続けてくれますし、いざ問題が起きたときにもスムーズに相談できる関係が保てます。全く連絡を取らない期間が長く続くと、担当者の異動や引き継ぎの機会を逃してしまうリスクもあるため、最低限の接点は維持しておくことが望ましいです。
検収後の関係が続かず、最終的に解約に至るケースの進め方は承継後に先代の開発会社と縁を切る。角を立てない解約の伝え方にまとめた。
まとめ 検収合格は「関係構築の始まり」である
検収に合格したというニュースは、後継社長にとって大きな安堵をもたらす出来事です。しかし、そこで気を抜いて「もう終わった」と考えてしまうと、その後の運用で思わぬトラブルに見舞われたり、開発会社との関係が徐々に希薄になったりするリスクがあります。
この記事で紹介したように、検収合格の直後にやるべきことは、契約内容の再確認、資料の集約、保守体制の整理、緊急連絡フローの確認、そして開発会社への感謝の表明です。さらに、先代の時代の暗黙の了解を、自分の代の仕組みとして明文化し直す作業も、このタイミングでこそ取り組みやすくなります。
同時に、社内の古参社員や現場のスタッフとの関係を整え、開発会社への相談窓口を一本化し、現場の感覚的な不満を具体的な改善要望に翻訳する役割を後継社長自身が担うことも欠かせません。
検収合格は、システムと開発会社との付き合いの「終わり」ではなく、「本当の付き合いが始まる入口」です。この入口をどう歩き出すかによって、その後1年、3年、5年とシステムが会社の中でどう育っていくかが大きく変わります。先代から引き継いだ事業を、自分の代でさらに前進させていくためにも、検収合格後のこの時期を、開発会社との関係を丁寧に築き直す好機として活用してください。
