開発会社の乗り換え手順、承継を機に整理する引き継ぎ資料一覧

先代の代から付き合いのある開発会社に、いつまで頼み続けるべきか。承継したばかりの経営者がまず直面するのは、契約書がどこにあるかも分からない、ログイン情報を誰が持っているかも分からない、という「引き継ぎ資料の不在」という壁です。結論から言えば、開発会社を乗り換えるかどうかを決める前に、まず「今何を持っているか」を洗い出す引き継ぎ資料一覧を作ることが最初の一歩になります。乗り換えの是非を判断する材料は、その一覧を作った後にしか出てきません。

この記事は、次のような状態にある方に向けて書いています。先代が亡くなって、あるいは引退して、会社のホームページや基幹システムを作った開発会社との付き合いだけが宙に浮いている。年に一度、保守費用の請求書だけが届くが、何の作業に対する費用か分からない。担当者の名刺はあるが、その会社が今も存続しているか、担当者が今もそこにいるかは確認していない。古参の総務担当は「昔からその会社にお願いしている」と言うだけで、契約内容までは把握していない。そして何より、株式や登記の引き継ぎには顧問税理士や弁護士という相談先がいるのに、システムやITベンダーとの関係については誰に相談すればいいのか分からない——という孤独感を抱えている方です。

なぜ承継のタイミングで整理が必要なのか

先代が現役だった時代は、開発会社との関係は「先代とその会社の担当者の個人的な信頼関係」で成立していたケースが多くあります。契約書を交わさず口約束で継続してきた、見積もりも先代の一存で承認してきた、という会社は決して珍しくありません。ところが承継が起きた瞬間、その信頼関係の土台は失われます。新しい社長は先代でも担当者でもない第三者であり、ベンダー側からすれば「関係性がリセットされた顧客」として扱われる可能性があります。

中小企業庁がまとめた事業承継ガイドラインでも、事業承継は「人（経営権）」「資産」「知的資産」の三要素の引き継ぎだと整理されています。会社の設備やノウハウ、顧客との関係性といった知的資産は、代表者が変わる際に最も抜け漏れが生じやすい領域です。システムやITベンダーとの関係は、この知的資産の中でも特に見えにくい部類に入ります。株式の名義や不動産の登記であれば、法務局や株主名簿という「答え合わせができる場所」がありますが、ドメインの管理者情報やサーバーの契約者名義には、そうした公的な確認窓口がありません。

引き継ぎ資料一覧という考え方がなぜ有効か

多くの承継経営者がやってしまう失敗は、いきなり「このベンダーを変えるべきか」を考え始めることです。しかし判断材料がない状態で乗り換えの損得を計算しても、答えは出ません。先に必要なのは、今の契約関係とシステムの実態を一枚の紙、あるいは一つの表に落とし込む作業です。これが本記事でいう「引き継ぎ資料一覧」であり、システム管理台帳の考え方に近いものです。

一覧を作る過程そのものが、実は最大の効果を持っています。作業を始めると、契約書が見当たらない、ログイン情報が担当者の私物のメモにしかない、といった事実が次々と判明します。この「見えないものが見える化する」プロセスこそが、乗り換えるか継続するかを判断する土台になります。

台帳をあらためて作り直す会社もあれば、実は昔にどこかで作った台帳が社内のどこかに眠っていて、それを掘り出すだけで済む会社もあります。どちらのパターンでも、承継直後にまず着手すべき作業であることに変わりはありません。台帳が「ある」状態と「ない」状態の差は、緊急時の対応スピードに直結します。サーバーが落ちた、ドメインの更新が切れた、といった有事が起きたとき、台帳があれば数分で状況を確認できますが、台帳がなければ関係者への聞き取りから始めることになり、その間サービスが止まったままになります。

引き継ぎ資料一覧に含めるべき8項目

システム開発会社の乗り換えに関する専門記事でも、実態把握と契約関連情報の確認が最初のステップとして挙げられています。これを承継の文脈に合わせて整理すると、以下の8項目が引き継ぎ資料一覧の核になります。

• 契約書・見積書・請求書の現物（原本またはPDF）
• ドメインの登録者情報（レジストラのアカウントと管理者メールアドレス）
• サーバー・ホスティングサービスの契約者名義とログイン情報
• 各種管理画面（CMS、顧客管理、会計連携等）のログイン情報一覧
• 保守契約の範囲と更新条件（自動更新か、解約通知の期限は何日前か）
• システムの仕様書・設計書・改修履歴
• 担当者の連絡先と、開発会社そのものの現在の存続状況
• 過去のトラブル対応履歴（誰が何をどう直したか）

「多くの中小企業では初回納品時のドキュメントしか存在せず、その後の改修は口頭やチャットのやり取りだけで進んでいることがほとんどです。ドキュメントが乏しいと、新ベンダーへの引き継ぎ費用が上振れする要因になります。」

この指摘は乗り換えを検討する開発会社側の記事からのものですが、承継直後の会社ほど当てはまりやすい構造です。先代の時代に改修を重ねたシステムは、初回納品書だけが手元にあり、その後の変更履歴は担当者の記憶と過去のメールの中に散らばっているのが実情です。

一つひとつの項目について、もう少し具体的に見ていきます。契約書・見積書・請求書は、経理上の証拠書類として保管されているケースが多いので、まず顧問税理士や会計事務所に確認するのが早道です。ドメインの登録者情報は、レジストラの管理画面にログインできれば自社で確認できますが、そのログイン情報自体が開発会社の手元にあることも珍しくありません。サーバー・ホスティングの契約者名義も同様で、契約者欄に開発会社の名前が入っている場合は、実質的にサービスの生殺与奪権を相手が持っている状態です。

各種管理画面のログイン情報は、担当者が個人のメモやパスワード管理ツールにしか記録していないことが多く、担当者の異動・退職で一気に失われるリスクがあります。保守契約の範囲と更新条件は、次の章で詳しく扱いますが、費用対効果を判断する上で欠かせません。システムの仕様書・改修履歴は、乗り換え先の見積もり精度に直結する情報です。担当者の連絡先と開発会社の存続状況は、意外と確認が漏れがちですが、法人番号公表サイトや国税庁の適格請求書発行事業者公表サイトで法人の存続状況を確認できる場合もあります。過去のトラブル対応履歴は、そのベンダーの技術的な信頼度を測る材料になります。

契約書がそもそも見つからない場合の動き方

引き継ぎ資料一覧を作ろうとして最初にぶつかる壁は、「契約書そのものが見つからない」という事態です。この場合に取るべき動きは次の順序になります。

1. 顧問税理士・会計事務所に確認する（保守費用を経費計上する際の証憑書類として、請求書や契約書の写しを保管しているケースがある）
2. 銀行口座の入出金記録から、支払先の開発会社名と支払頻度・金額を洗い出す
3. 開発会社に直接連絡し、契約書の写しの再発行を依頼する
4. 社内の古いメールボックス（先代が使っていたアカウントを含む）を確認する

税理士や会計事務所は、株式や登記の相談先として既に接点があるはずです。システムの契約書についても、経費の証拠書類という文脈であれば十分に相談できる相手です。「システムには相談先がいない」と感じている承継社長は多いですが、実は顧問税理士がその代替の窓口になれる場面は少なくありません。

ログイン情報の所在確認が最優先である理由

引き継ぎ資料一覧の中でも、最も緊急度が高いのはログイン情報とドメイン・サーバーの管理者名義です。専門記事でも「サーバーの契約者名義、ドメイン登録者情報、管理画面のログイン情報が開発会社名義になっていないかを確認することが重要」と指摘されており、「名義が開発会社のままだと、廃業や関係悪化と同時にサービス自体が止まるリスクがある」と警告されています。

これは架空のリスクではありません。ドメインの登録者情報は本来、レジストラのWHOIS情報や管理画面から自社で確認できるはずのものですが、開発会社が「代理で取得・管理」しているケースでは、自社側にその情報が一切残っていないことがあります。承継後にホームページを止められない、メールが突然使えなくなる、という事態を避けるためには、まずこの名義確認を最優先で行う必要があります。

確認すべき項目を整理すると次のようになります。

この表を作る作業だけでも、社内の総務担当や古参社員への聞き取りが必須になります。古参社員は先代の時代の経緯を知っている貴重な情報源ですが、同時に「昔からそうしているから」という理由だけで名義変更に抵抗を示すこともあります。ここは変更の是非ではなく、まず現状を正確に把握することだけを目的に聞き取りを進めるのが得策です。

名義がすべて開発会社側に集中している状態は、ベンダーロックインと呼ばれる典型的な構造です。契約を切ろうとした瞬間に、ホームページもメールも顧客管理システムも一斉に使えなくなるという最悪のシナリオを避けるためには、まずこの名義の実態を洗い出すことが欠かせません。名義が開発会社側に集中している実態を裏付ける具体的な確認方法は、「うちでしか分からない」を裏付ける、先代契約のシステム仕様の確認方法で扱っています。

保守契約の中身を読み解く

引き継ぎ資料一覧の中で見落とされやすいのが、保守契約の実際の範囲です。「毎月〇万円の保守費用」という請求だけが続いていて、その中に何が含まれているのかを誰も説明できない、という状態は珍しくありません。確認すべき点は次の三つです。

第一に、保守費用に何が含まれているか。サーバーの死活監視だけなのか、軽微な修正対応まで含むのか、年に数回の機能追加まで含むのかは契約によって大きく異なります。第二に、更新条件です。自動更新であれば、解約を申し出るタイミングを逃すと自動的に1年契約が延びてしまう契約書も存在します。第三に、解約通知の期限です。「解約希望日の3ヶ月前までに書面で通知」といった条件が入っている契約は多く、これを知らずに動くと乗り換えのタイミングがずれ込みます。

保守契約を確認する際には、次のような質問を担当者にぶつけてみるとよいでしょう。「この保守費用の中には、具体的にどの作業が含まれていますか」「今年一年で、実際にどんな対応をしてもらいましたか」「契約を解約する場合、何ヶ月前に連絡が必要ですか」。こうした質問に即答できるベンダーであれば信頼度は高く、話をそらされる、あるいは資料を出してもらえない場合は、そのこと自体が一つの判断材料になります。「うちでしか直せない」と言われて身動きが取れない場合の契約書チェックポイントは、先代の代からの開発会社に「うちでしか直せません」と言われたときに確認する契約書の項目にまとめています。

開発会社との関係を「決別」ではなく「整理」と捉える

このカテゴリのテーマは、古いベンダーとの決別と共存です。承継したばかりの社長にとって、先代の代からの付き合いのある開発会社を切ることは、感情的にも実務的にも簡単な選択ではありません。先代がその担当者を長年信頼してきた経緯があり、古参社員もその関係性の中で仕事をしてきました。ここで大切なのは、「乗り換える」か「継続する」かの二択で急いで結論を出すのではなく、まず関係を「見える化」して整理するという姿勢です。

角を立てずに関係を整理するためには、次のような進め方が有効です。まず、引き継ぎ資料一覧を作ったうえで、開発会社に対して「事業承継に伴い、契約関係とシステムの状況を確認させてほしい」という趣旨の連絡を入れます。これは乗り換えの通告ではなく、実務上必要な確認作業として伝えられる内容です。多くの開発会社は、顧客の代表者変更に伴う確認依頼には協力的に対応します。この段階で、相手の対応の速さや誠実さも、今後の関係を判断する材料になります。

先代の代からの付き合いがある会社であればこそ、感謝の気持ちを言葉にすることも忘れないほうがいいでしょう。「これまで長年お世話になりました。承継のタイミングで一度社内の体制を整理したいので、確認にご協力いただけますか」という一言があるだけで、相手の受け止め方は大きく変わります。関係を切る前提の連絡ではなく、整理をするための連絡だという姿勢を明確にすることが、角を立てない交渉の基本です。

一覧作成後に見えてくる3つの判断軸

引き継ぎ資料一覧が一通り完成すると、乗り換えるべきか継続すべきかを判断する材料が揃います。判断軸は大きく三つに分かれます。

一つ目は、名義・権利関係の健全性です。ドメインやサーバーの契約者名義が自社になっているか、ログイン情報が自社で保持されているかという点です。ここが開発会社側に偏っている場合は、乗り換えの検討以前に、まず名義を自社に戻す交渉が必要になります。

二つ目は、システムそのものの技術的な健全性です。使っている言語やソフトウェアが古く、EOL（サポート終了）を迎えている、あるいは近く迎える予定があるかどうかです。サポートが切れたシステムを保守し続けることは、セキュリティ上のリスクを積み増す行為になります。古くなったシステム自体が悪いわけではありませんが、改修のたびにコストが跳ね上がる、担当できる技術者が限られる、といった兆候が出ていれば、乗り換えの検討時期が近づいていると考えられます。

三つ目は、費用対効果です。保守費用に対して、実際に受けているサービスの内容が見合っているかどうかです。何年も機能追加のない「保守費用の名目だけの請求」が続いているケースもあれば、逆に相応の対応をしてもらっているケースもあります。これは一覧を作らなければ判断できない項目です。老朽化したシステムそのものの乗り換え判断をどう進めるかは、先代の代から使う古いパッケージシステムからの乗り換え判断で詳しく扱っています。

乗り換えを決めた場合の実務手順

引き継ぎ資料一覧を作り、名義関係の健全性・技術的な健全性・費用対効果の三点を確認したうえで乗り換えを決めた場合、実務手順は次のように進みます。

まず、現行ベンダーへの解約通知を、契約書に記載された期限を守って書面で送ります。次に、新しいベンダー候補への相談を始めますが、この際に引き継ぎ資料一覧そのものが提案依頼の土台になります。一覧がないまま「システムを作り直したい」と相談すると、新しいベンダーは現状把握からやり直すことになり、見積もりも引き継ぎ作業の分だけ膨らみます。逆に一覧が整っていれば、新しいベンダーは最初から的確な見積もりを出しやすくなります。

データ移行についても注意が必要です。専門記事が指摘するように、「同じメーカーの製品へ乗り換える場合は比較的スムーズに移行できますが、他社の製品を導入する際には、データ形式をあわせる必要があり、データの一部が移行できない可能性もある」とされています。長年使ってきたシステムの中にあるデータを、どういう形式でどこまで新システムに持ち込めるかは、乗り換え前に必ず確認すべき項目です。この確認ができるかどうかは、そのシステムがどれだけデータポータビリティを確保した設計になっているかに左右されます。独自形式でデータを閉じ込めるような設計だと、移行そのものが大きな障壁になります。

新しいベンダーを選ぶ段階では、複数社から見積もりを取ることも検討に値します。長年一社としか付き合っていなかった会社ほど、他社の提案内容や見積もり額の相場観を持っていないことが多いため、比較のための情報収集自体に価値があります。ただし、比較検討に時間をかけすぎて意思決定が遅れると、現行ベンダーとの契約更新期限を超えてしまうこともあるため、引き継ぎ資料一覧を作る段階で、次の契約更新日をあらかじめ確認しておくことが重要です。

段階的な移行という選択肢

すべてのシステムを一度に切り替える必要はありません。基幹システムのリプレイスに関する解説記事でも、複数のシステムを同時に切り替える場合は把握すべき内容が増大し業務停止リスクが高まるため、段階移行方式によって業務単位や機能単位で切り替え、リスクを分散し問題発生時の影響を限定するという考え方が紹介されています。

承継直後の会社であればなおさら、経営の他の課題（株式の整理、取引先への挨拶、社内体制の見直しなど）と並行して進める必要があるため、システムの入れ替えだけに全リソースを割くことは現実的ではありません。ホームページの刷新、基幹システムの入れ替え、会計ソフトの見直し、といった複数の課題があるなら、優先度をつけて一つずつ着手する方が、社内の混乱も少なく済みます。

優先順位のつけ方としては、リスクの高さと業務への影響度の二軸で考えるとわかりやすくなります。たとえば、ドメインやサーバーの名義変更は影響度が大きい割に作業自体は比較的小さく済むため、最初に着手すべき項目です。一方で基幹システムの入れ替えは影響度もリスクも大きく、十分な準備期間と予算を確保してから動くべき項目です。この優先順位づけそのものも、引き継ぎ資料一覧を作った後でなければ正確には行えません。

一社に全部任せるリスクと分散の考え方

先代の代からの開発会社との付き合いの中で、ホームページも、基幹システムも、サーバーも、ドメインも、すべて一社にまとめて任せてきたという会社は少なくありません。これは長年の信頼関係の証でもありますが、承継後の視点で見ると、依頼先を複数の会社に分けて持たせておくという考え方を知っておく価値があります。

すべてを一社に集約している状態は、担当者との関係が良好である間は効率的ですが、その会社が廃業したり、関係が悪化したりした瞬間に、会社の情報システム全体が機能停止するリスクを抱えています。乗り換えを検討する際、必ずしも「全部を一度に他社へ移す」必要はなく、リスクの高い部分（ドメイン管理やサーバー契約など、生命線となる部分）だけを自社管理に戻す、あるいは複数の窓口に分散するという選択肢もあります。

ただし、分散させることそのものが目的化してしまうと、管理の窓口が増えて社内の負担が逆に増える恐れもあります。従業員10〜100人規模の会社であれば、情報システムの専任担当者がいないことも多く、あまりに多くのベンダーと個別にやり取りする体制は現実的ではありません。自社の規模と管理体制に見合った範囲で、まずは「生命線となる部分だけは自社の管理下に置く」という最小限の分散から始めるのが実務的です。

古参社員との情報共有の進め方

引き継ぎ資料一覧を作る作業は、多くの場合、経営者一人では完結しません。総務や経理を長年担当してきた古参社員が、実際の契約や支払いの経緯を知っている場合がほとんどです。ここでの進め方として大切なのは、「先代の判断を否定する」という姿勢を取らないことです。

古参社員に対しては、「先代がどういう経緯でこの会社と付き合ってきたかを教えてほしい」という聞き方をすることで、防御的な反応を避けやすくなります。引き継ぎ資料一覧を作る目的は、先代の判断の良し悪しを評価することではなく、単純に「今、何がどこにあるか」を確認することだと明確に伝えると、協力を得やすくなります。

聞き取りの際には、いきなり「システムを見直したい」という結論から話すのではなく、「今、うちのシステムがどうなっているのか、一度全体を整理したい」という現状把握の話から入るとよいでしょう。古参社員にとっても、自分が長年関わってきた業務の記録を整理する作業は、決して悪い話ではありません。むしろ、自分しか知らない情報が言語化され、会社の資産として残ることを歓迎する社員も多くいます。

相談先がいないという孤独感への対処

株式の名義変更や登記の変更には、顧問税理士や弁護士、司法書士という明確な相談先がいます。ところがシステムやITベンダーとの関係については、多くの承継社長が「誰に相談すればいいのか分からない」という孤独感を抱えています。これは決して特殊な状況ではなく、非IT出身の経営者が中小企業を継いだ場合にほぼ共通して発生する課題です。

この孤独感に対する現実的な対処法は、まず引き継ぎ資料一覧という「共通言語」を作ることです。一覧があれば、それを顧問税理士に見せて経費関連の相談をすることもできますし、商工会議所や自治体のIT相談窓口に持ち込んで助言を求めることもできます。あるいは、新しい開発会社に相談する際も、この一覧があるだけで話が具体的に進みます。何もない状態で「システムのことが分からない」と相談するよりも、一覧を手に「この状態をどう評価すればいいか」と相談する方が、相談先にとっても答えやすい質問になります。

事業承継そのものについては、全国47都道府県に設置されている事業承継・引継ぎ支援センターという公的な相談窓口があり、経営全般の引き継ぎについて相談できます。システム単体の技術的な相談まではカバーしていないことが多いものの、経営全体の引き継ぎという文脈でまず相談してみる価値はあります。株式や登記の専門家に加えて、こうした公的窓口も含めて「相談先の一覧」自体を自分の手元に作っておくと、いざというときに動きやすくなります。

引き継ぎ資料一覧の運用を定着させる

一度作った引き継ぎ資料一覧は、作った時点で終わりではありません。承継後の経営において、この一覧を定期的に更新する仕組みを作ることが、次の代への引き継ぎをスムーズにする布石にもなります。理想としては、年に一度、保守契約の更新時期に合わせて一覧を見直し、契約内容や担当者の変更がないかを確認する運用が望まれます。

これは特別なシステムを導入する必要はなく、表計算ソフトの一枚のシートで十分に管理できます。重要なのは、その一覧の存在と更新責任者を、経営者だけでなく総務担当者にも共有しておくことです。経営者が変わっても、あるいは総務担当者が変わっても、システムの実態が引き継がれる仕組みを作ることが、今回の承継で得た教訓を次に活かすことになります。

一覧を作った後は、社内の誰かひとりに紐づける形ではなく、共有フォルダやクラウドストレージなど、複数人がアクセスできる場所に保管することも大切です。せっかく整理した一覧が、また特定の担当者の手元だけに残ってしまえば、その担当者が異動・退職した時点で同じ問題が再発します。今回の承継で得た「見えなくなっていた」という反省を、次の世代に繰り越さない仕組みづくりまでが、この作業の本当の完成形です。

承継直後にありがちな失敗パターン

引き継ぎ資料一覧を作らずに動いた結果、実際に起きやすい失敗パターンをいくつか紹介します。自社が同じ轍を踏んでいないか、確認の参考にしてください。

失敗パターン1：焦って解約通知を出し、契約違約金が発生した

先代の代からの付き合いに疲れ、「もう頼らない」という感情が先に立って解約通知を急いだ結果、契約書に記載されていた「解約は満了日の6ヶ月前までに通知」という条件を見落とし、違約金相当の費用を請求されたケースがあります。契約書を先に読んでから動くという、当たり前の順序が守られていなかったことが原因でした。

失敗パターン2：ドメインの名義変更を後回しにして、更新が切れた

乗り換え作業に集中するあまり、ドメインやSSL証明書の更新期限を見落とし、ホームページやメールが一時的に使えなくなったケースもあります。乗り換えの検討と並行して、名義や更新期限といった「生命線」の確認は独立して先に進めておく必要があります。

失敗パターン3：新しいベンダーへの引き継ぎ資料が不十分で、見積もりが跳ね上がった

引き継ぎ資料一覧を作らずに「とりあえず作り直してほしい」と依頼した結果、新しいベンダーが現状把握からゼロで始めることになり、当初の想定より大幅に高い見積もりが提示されたケースです。仕様書や改修履歴が手元にあるだけで、見積もりの精度と金額感は大きく変わります。

失敗パターン4：古参社員に事前相談せずに進め、社内の反発を招いた

経営判断として乗り換えを決めた後に古参社員へ事実だけを伝えた結果、「なぜ相談してくれなかったのか」という不満が噴出し、社内の協力を得づらくなったケースもあります。決定事項として伝えるのではなく、現状把握の段階から一緒に進めることが、後の反発を防ぐ鍵になります。

これらの失敗はいずれも、引き継ぎ資料一覧を先に作っておけば避けられたものばかりです。焦って結論に飛びつくのではなく、まず現状を正確に把握する順序を守ることが、承継直後のシステム整理における最大の防御策になります。

開発会社選びで後悔しないための視点

乗り換え先を選ぶ段階になったら、次のような視点を持っておくと後悔が少なくなります。

まず、見積もりの安さだけで選ばないことです。承継直後は費用に敏感になりがちですが、極端に安い見積もりは、保守や引き継ぎ資料の整備を後回しにする前提で組まれている場合があります。数年後にまた同じ「引き継ぎ資料がない」という問題を繰り返さないためには、見積もりの中に仕様書作成や運用ドキュメントの整備がどこまで含まれているかを確認すべきです。

次に、契約書に解約条件と成果物の権利関係を明記してもらうことです。かつての先代の代の契約が口約束や曖昧な条件で続いていたことの反省点を、次の契約で解消しておく好機でもあります。ソースコードや仕様書の権利が自社に帰属することを契約書に明記してもらえるかどうかは、次の乗り換えを検討する際の自由度を大きく左右します。

最後に、担当者一人だけに依存しない体制を持つ会社を選ぶことです。個人の技術力に依存した小規模な事業者では、その担当者が離脱した瞬間に対応が止まるリスクがあります。会社としての引き継ぎ体制、複数人での対応が可能かどうかも、選定時の確認事項に加えておくとよいでしょう。

まとめ

先代の代から付き合いのある開発会社との関係を整理する第一歩は、乗り換えの是非を考えることではなく、引き継ぎ資料一覧を作ることです。契約書、ドメインの登録者情報、サーバーの契約者名義、各種ログイン情報、保守契約の範囲、システムの仕様書、担当者の連絡先、トラブル対応履歴という8項目を洗い出す過程で、乗り換えるべきか継続すべきかの判断材料が自然と見えてきます。

名義や権利関係が自社に戻っていない状態を見つけたら、それは乗り換えの検討以前に、まず自社の管理下に戻す交渉を進めるべき課題です。技術的な健全性や費用対効果の面で問題が見つかれば、そこから初めて乗り換えの検討が始まります。角を立てずに関係を整理するためには、開発会社への連絡も「事業承継に伴う確認」という実務的な文脈で進めることが有効です。

株式や登記の引き継ぎには専門家という相談先がいますが、システムについては経営者自身が最初の一歩を踏み出す必要があります。その最初の一歩が、この記事で紹介した引き継ぎ資料一覧の作成です。一覧を作ること自体が、先代から受け継いだ会社の実態を初めて正確に把握する機会になります。