先代が契約していた開発会社が倒産していた。ソースコードがない場合の選択肢
「システムの調子が悪いので、開発をお願いした会社に連絡してほしい」——先代からそう引き継がれた電話番号にかけたら、繋がらなかった。ホームページも消えている。法人番号で検索してみると、数年前に破産手続きが開始され、すでに清算結了していた。手元にあるのは、先代が大事に保管していた分厚い契約書のファイルと、動いているけれど中身が全く分からない受発注システムだけ——ソースコードも、開発時の仕様書も、担当者の連絡先も、どこにもない。
事業承継後にこの状況に直面する二代目・三代目経営者は、決して少なくありません。株式や登記の引き継ぎには税理士や司法書士という「相談できる専門家」がいますが、システムの引き継ぎには相談先がいないまま、先代が生きていた頃の人間関係と信頼だけで動いていたシステムが、ある日突然「誰のものでもない、直せないブラックボックス」として残されます。
結論から言うと、ソースコードがない状態でも打てる手はあります。優先順位は次の3段階です。
- 契約書の再確認（著作権譲渡条項・ソースコード開示義務の有無）
- 破産管財人・清算人への開示請求（清算結了前なら間に合う可能性がある）
- 現行システムの解析・再構築の見積もり（上記が不発でも、動いている実物から作り直す方法はある）
この記事では、この3段階を承継特有の事情——古参社員の記憶、先代の口約束、契約書の所在すら分からない状況——を踏まえながら、実務的な順序で解説します。
まず落ち着いて確認すべきこと：システムは今、動いているか
ソースコードがないと分かった瞬間にパニックになる前に、確認すべきことがあります。それは「そのシステムは今この瞬間、業務を止めずに動いているか」です。
動いているなら、緊急対応の必要はありません。ソースコードの有無は「将来、改修や障害対応ができるかどうか」の問題であって、「今日明日に止まるかどうか」の問題ではないケースがほとんどです。慌てて高額な再構築を発注する前に、まずは現状を正確に棚卸しすることが先決です。
逆に、すでに動作が不安定、エラーが頻発している、Windowsやサーバーの更新でいつ止まってもおかしくない状態であれば、話は別です。この場合は本記事の「3. 現行システムの解析・再構築」を急いで検討する必要があります。
なぜ承継後にこの問題が発覚しやすいのか
先代の時代は、開発会社の担当者と月に一度は顔を合わせ、電話一本で「あの機能ちょっと直して」と頼める関係が成立していました。契約書を交わしていても、実際の運用は「信頼関係」で回っていたケースが大半です。ソースコードの受け渡しや著作権の扱いについて、契約書に明記されていない、あるいは契約書自体が見当たらないという状態は、中小企業では珍しくありません。
承継の場面でこれが表面化する理由は主に3つあります。
- 先代が引退・逝去し、開発会社との人的なつながりが切れる（電話番号を知っていたのは先代個人であって、会社の資産として引き継がれていなかった）
- システムに不具合が出て、初めて「誰に連絡すればいいのか」を探すことになる（平時は誰も連絡先を必要としていなかった）
- 先代の代からシステムの契約書・仕様書を保管している場所が、後継者に共有されていない（属人化していたのは開発会社側だけでなく、自社の管理体制も同じだった）
属人化という言葉がありますが、これは社内の業務が特定の社員にしか分からない状態を指すことが多い一方で、実は「委託先との関係」自体が先代個人に属人化しているケースも同じくらい多いというのが実務上の実感です。
1. まず契約書を探し、読み直す
最初にやるべきは、開発会社との契約書一式を探すことです。先代の書斎、経理担当者の保管庫、顧問税理士に預けている書類の中など、思いつく場所を古参社員にも聞きながら総当たりで確認してください。契約書が見つかった場合、特に次の3点を確認します。
契約書で確認すべき3つのポイント
1. 著作権（プログラムの著作権）の帰属を定めた条項があるか
2. ソースコードの開示・納品義務を定めた条項があるか
3. ソースコードエスクロー（第三者機関への預託）の取り決めがあるか
システム開発の著作権について、法律事務所の解説では次のように整理されています。
ソフトウェア開発委託契約において著作権の帰属について何ら規定がない場合、創作者であるベンダに著作権が帰属するというのが原則となる
出典: IT弁護士 大阪「システム開発取引に伴い発生する権利は誰に帰属するのか」
つまり、契約書に著作権譲渡の条項がなければ、たとえ開発費を全額支払っていたとしても、プログラムの著作権はデフォルトで開発会社側に残っている可能性が高いということです。これは承継社長にとって重要な事実です。「うちのお金で作ったシステムなんだから、うちのものだろう」という素朴な感覚と、法律上の扱いは一致しないことがあります。
さらに、著作権の帰属とソースコード開示の可否は別の問題である点も要注意です。同記事では次のように述べられています。
著作権の帰属とソースコードの開示は別問題であり、著作権の帰属とは別にソースコード開示の有無についてもシステム開発契約書等に定めておく方が無難
出典: IT弁護士 大阪「システム開発取引に伴い発生する権利は誰に帰属するのか」
つまり、仮に著作権が自社に譲渡されていたとしても、契約書に「ソースコードを納品する」という条項が別途なければ、開発会社（あるいはその破産管財人）にソースコードの引き渡しを法的に強制することは難しい場合があるということです。逆に、著作権がベンダー側にあっても、ソースコード開示義務の条項があれば入手できる可能性が出てきます。この2つを分けて契約書を読むことが重要です。
ソースコードエスクロー契約があれば、最も安全に解決する
契約書の中に「ソースコードエスクロー」という言葉、あるいは第三者機関へのソースコード預託に関する条項があれば、これは非常に幸運なケースです。ソースコードエスクローについて、専門メディアでは次のように説明されています。
ソースコードエスクローは、ソースコードを第三者機関（信託会社や認定機関）に預ける仕組みで、ベンダーが倒産した場合、事業譲渡した場合、または契約が終了した場合など、あらかじめ定めた条件が成立したときに、発注者がソースコードを取り出せるよう担保する
まさに「開発会社が倒産した場合」を想定した制度であり、これが契約に組み込まれていれば、預託機関に連絡するだけでソースコードを正規に取得できます。ただし、中小企業が発注する規模のシステム開発でエスクロー契約まで結んでいるケースは、正直なところ多くはありません。この制度自体は1980〜90年代の米国で生まれ、日本では主に大手企業の基幹システム調達で使われてきた経緯があるためです。先代の時代の中小企業の発注では、まず期待できないと考えておいた方が現実的です。見つからなかった場合は、次のステップに進みます。
2. 破産管財人・清算人への開示請求というルート
開発会社がすでに破産・清算していた場合でも、諦めるのはまだ早い場合があります。ポイントは「清算手続きが完全に終わっているかどうか」です。
会社が破産すると、裁判所によって破産管財人が選任され、会社の財産（債権も含む）を換価して債権者に配当する手続きが進みます。ソースコードなどの知的財産も会社財産の一部として扱われるため、清算結了前であれば、破産管財人に対して開示や譲渡を請求できる可能性があります。
知的財産権を保有する会社が破産した場合、裁判所から選任された破産管財人が、当該知的財産権を処分することになる
実務的な進め方としては、以下のような手順になります。
- 法人番号や商業登記から、破産手続きの状況（開始決定・進行中・結了済み）を確認する
- 進行中であれば、選任されている破産管財人（多くは弁護士）に連絡し、契約関係にあった発注者として開示・譲渡を打診する
- すでに清算結了している場合、法人格自体が消滅しているため、この経路での解決は基本的に難しくなる
ここで承継社長がつまずきやすいのは、「破産管財人」という存在自体を知らない、あるいはどこに問い合わせればよいか分からないという点です。これは司法書士や弁護士に相談すれば案内してもらえる領域なので、顧問弁護士がいない場合でも、商工会議所や中小企業支援機関を通じて紹介を受けることができます。「株式や登記なら専門家に相談できるのに、システムだけ相談先が分からない」という孤独感を覚える場面ですが、破産管財人への対応自体は法律の専門家の通常業務の範囲内であり、決して特殊な相談ではありません。
3. ソースコードなしで動いているシステムを「解析」する方法
契約書もなく、開発会社も清算結了済みで、エスクローもない——この状態でも、システム自体が今も動いているなら、そこから情報を取り出す方法が残っています。これが最終手段であり、多くの承継社長が最終的にたどり着く現実的な選択肢です。
実行ファイルからの逆コンパイル・リバースエンジニアリング
Windows上で動く実行形式のソフトウェアであれば、逆コンパイル（リバースエンジニアリング）によって、ある程度のロジックを推測・復元できる場合があります。この手法の適法性について、2018年・2019年の著作権法改正で整理が進んでいます。
2019年の著作権法改正で、研究開発目的（脆弱性の発見や互換性の確認など）で行うリバースエンジニアリングには違法性がないことが明確化された
出典: 弁護士 野溝夏生「リバースエンジニアリングと改正著作権法」
つまり、自社が使い続けるために現行システムの仕様を解析すること自体は、違法性を問われる可能性が低い行為です。ただし、これは「調べること」が適法だという話であって、そこから得た情報の使い方によっては別の問題が生じ得る点には注意が必要です。たとえば、解析して得たロジックをそのまま模倣して、開発会社が持つ著作権を侵害するような形でシステムを複製すれば、話は変わってきます。実務上は、解析結果を土台にしつつ、自社の業務要件に合わせて新規にシステムを組み直す（作り直す）形を取るのが安全です。
データベースの構造から仕様を推測する
実行ファイルの逆コンパイルよりも取り組みやすいのが、データベースの中身を調べる方法です。受発注システムであれば、顧客マスタ・商品マスタ・受注データなどがテーブルとして保存されています。テーブル名やカラム名、データの入り方を見れば、システムがどんな業務ロジックで動いているかをかなりの精度で推測できます。
社内にAccessやExcelで管理された補助的な台帳が残っている場合、それも重要な手がかりになります。本体システムでは表現しきれない例外処理を、現場の担当者が独自にこうしたツールで補完しているケースは中小企業では非常に多く、この「裏の運用」を含めて解析することで、システムの本当の仕様が見えてくることがあります。
古参社員へのヒアリングが最大の情報源になる
技術的な解析と並行して、実は最も価値が高いのが「このシステムをずっと使ってきた古参社員へのヒアリング」です。ソースコードには「なぜこの計算式になっているのか」「なぜこの画面でこの入力を求めているのか」という業務背景までは書かれていません。しかし、経理担当のベテラン社員や、先代の右腕として長年現場を回してきた社員は、「このボタンを押すと在庫が引き当てられる」「この項目は税理士さんの指示で追加した」といった経緯を体で覚えていることが多いのです。
承継したシステムの解析は、コードを読む作業である以上に、それを使い続けてきた人の記憶を聞き取る作業でもある
この視点を持てるかどうかで、再構築の精度は大きく変わります。技術者だけに任せず、後継者自身が同席してヒアリングに立ち会うことを強くおすすめします。先代が大事にしてきた業務のクセや、古参社員が慣れ親しんだ画面の使い勝手は、コードのどこにも書かれていない「暗黙知」だからです。
パソコン本体・サーバーの中も一緒に確認する
ソースコードの捜索に気を取られがちですが、忘れてはならないのがハードウェアそのものです。開発会社が自社に納品したサーバーやPCの中には、ソースコードのバックアップ、開発時に使っていたツール、過去のバージョンのプログラム一式が、そのまま眠っていることがあります。特に、先代の代からずっと同じサーバーやPCを使い続けている場合、社内の誰も中身を確認したことがない「隠れフォルダ」が存在する可能性は十分にあります。
具体的には、次の場所を一通り確認してみてください。
- サーバー内の共有フォルダ、特に「backup」「old」「archive」といった名前のフォルダ
- 経理担当者や先代秘書のPCに残る、開発会社とのメールの送受信履歴（添付ファイルにソースコード一式が残っていることがある）
- 社内で使っているクラウドストレージ（Dropbox・Google Drive等）に、過去のやり取りの中でファイルが共有されていないか
- 開発会社から納品された際の記録media（CD-R、USBメモリなど）が保管されていないか
これは技術的な難易度が低い割に見落とされやすいポイントです。IT専門家に依頼する前に、まず社内で総当たりの捜索をしておくと、後の交渉や見積もり取得がぐっとスムーズになります。
保守契約と「バックアップ取得の有無」を切り分けて考える
もう一つ整理しておきたいのが、「保守契約があったかどうか」と「バックアップが取得されていたかどうか」は別問題だという点です。先代の代に月額いくらかの保守費用を支払っていた記録が経理データに残っている場合、それは「システムに何かあったときに対応してもらう契約」であって、必ずしも「ソースコードを自社側にも保管しておく契約」ではありません。
実際、中小企業のシステム開発案件では、保守契約はあってもソースコードの提供義務までは明記されていないケースが多く見られます。保守費用を払い続けていたという事実だけでは、ソースコードの権利関係は解決しないという点を押さえておいてください。逆に言えば、契約書の中に「保守」の条項しか見当たらなくても、それだけで諦める必要はなく、著作権やソースコード開示に関する条項がどこかに別途あるかもしれない、という前提で捜索を続ける価値はあります。
「作り直す」という選択肢を現実的に検討する
ソースコードの復元や解析を尽くしても、完全な再現は難しいことがほとんどです。むしろ、この機会に現行システムを土台にしながら、業務に合わせて作り直すという発想に切り替えた方が、結果的に安く早く済むケースも少なくありません。
理由は単純です。先代の時代に作られたシステムは、当時の業務フローに最適化されています。しかし承継後、取引先や商流、扱う商品、法規制（インボイス制度対応など）は少しずつ変化しているはずです。ソースコードを完全復元できたとしても、それは「今の会社に必ずしも合わない古い仕様」を復元するだけかもしれません。
作り直しを検討する際の判断材料を整理すると、次のようになります。
| 状況 | 推奨される対応 |
|---|---|
| システムは安定稼働中、当面の実害なし | 契約書探索・破産管財人への問い合わせを進めつつ、並行して見積もりだけ取っておく |
| エラーが増えている、動作が不安定 | 解析と再構築の見積もりを急ぎ複数社から取る |
| OSやサーバーが古く、更新サポートが切れかけている | 再構築を前提に、移行スケジュールを組む |
| 事業内容・商流が承継後に変化した | ソースコード復元よりも、新しい業務要件での再設計を優先する |
いずれの場合も、現行システムがどんな状態にあるかを正確に把握してからでないと、正しい判断はできません。なお、ソースコードや仕様書がない状態からの現状調査・引き継ぎ・保守を専門に引き受ける開発会社もあり（システム引き継ぎ・レスキュー、運営会社ゼットリンカーの受託メニュー）、自社での対応が難しい場合は相談先の一つになります。ここで重要になるのが、システムの現状を一覧できる「台帳」を作ることです。
システム管理台帳を作ることが、次の承継トラブルを防ぐ
今回の問題が起きた根本原因は、ソースコードがなかったこと自体よりも、「このシステムが何で動いていて、誰が作って、契約書がどこにあるか」という情報が、会社の資産として整理されていなかったことにあります。先代個人の頭の中にしかなかった情報が、先代の引退や逝去とともに失われてしまったわけです。
これを防ぐには、社内で使っているシステム・ソフトウェアを一覧化した管理台帳を作ることが有効です。台帳には最低限、次の項目を記載します。
- システム名・用途
- 開発会社名・連絡先・契約書の保管場所
- 著作権の帰属・ソースコード開示義務の有無
- 稼働しているサーバー／OS／ソフトウェアのバージョン
- 保守契約の有無と更新時期
- そのシステムに詳しい社内の担当者（属人化している場合は特に明記）
この台帳自体が、次に会社を継ぐ人（あるいは自分の後継者）への最大の贈り物になります。今回のようなトラブルに二度と直面させないための、最もコストの低い予防策です。
個別の業務ツールが「単一障害点」になっていないか点検する
もう一つ、承継後に見落とされがちな観点があります。倒産した開発会社が作ったシステムが、実は会社の業務全体を支える単一障害点（SPOF）になっていないかという点です。受発注、在庫管理、請求処理など、複数の業務がこの一つのシステムに依存している場合、万が一システムが完全に停止すれば、会社の業務そのものが止まりかねません。
今回のようにソースコードがなく、修正も改修もできない状態のシステムは、まさにこの単一障害点のリスクを抱えたまま放置されている状態です。解析や作り直しを検討する優先順位を決める際には、「このシステムが止まったら、どの業務がどれくらいの期間止まるか」を基準に考えると、経営判断としての緊急度が明確になります。毎日使う基幹的な部分ほど、優先的に手を打つべきだということです。
先代の代からの「口約束」をどう扱うか
先代の時代、開発会社の社長と先代が個人的に親しく、「何かあったら面倒見るから」という口約束だけで長年運用してきたというケースも少なくありません。契約書自体が形式的なもので、実際の取り決めは口頭で交わされていた、というのは中小企業の商習慣として珍しくない話です。
しかし、開発会社が倒産・消滅した以上、口約束を頼りにすることはもうできません。承継社長がここで意識すべきなのは、「先代の人間関係に依存した運用は、代替わりのタイミングで必ず一度リセットされる」という事実です。これは開発会社との関係に限らず、税理士や取引先との関係にも共通することですが、システムの分野はとりわけ専門的で、後継者自身が判断しづらいために問題が長く放置されやすい領域です。
株式の名義変更や登記の変更であれば、司法書士に相談すれば型どおりに進みます。しかしシステムについては「誰に相談すればいいか分からない」まま数年が経過し、ある日突然システムが不調になって初めて事の重大さに気づく、というパターンが実際に多く見られます。この記事を読んでいる時点で、すでにその一歩を踏み出せているということでもあります。
「そもそも先代はなぜ気づかなかったのか」を責めない
ここまで読んで、「先代はなぜこんな大事なことを契約書に残しておかなかったのか」と感じる後継者もいるかもしれません。しかし、これは先代個人の落ち度というより、日本の中小企業とシステム開発会社の関係に共通して見られる構造的な問題です。
経済産業省のDXレポートでは、発注企業とベンダー企業の間にできあがった、長期にわたる依存関係を「低位安定モデル」と呼び、次のように指摘しています。
ユーザー企業が既存業務の効率化を目指してデジタル投資を委託し、ベンダー企業が受託による低リスク・長期安定ビジネスを行ってきた結果、両者は「低位安定」の関係に長らく固定されてきた
出典: 経済産業省「DXレポート2.1（DXレポート2 追補版）」概要資料
先代が開発会社に全幅の信頼を置き、契約の細部まで詰めなかったのは、当時としてはごく自然な経営判断でした。開発会社側も長年の付き合いの中で「悪いようにはしない」という関係を築いていたはずです。それが崩れたのは、開発会社の経営が傾いたという、先代にもコントロールできない外部要因によるものです。ここで先代を責めても状況は好転しません。むしろ、この構造自体が中小企業全体に共通する課題だと理解したうえで、自社の代で仕組みとして手を打つことが、後継者としての建設的な向き合い方だと言えるでしょう。
今の開発会社選びで、同じ失敗を繰り返さないために
作り直す、あるいは新しい開発会社に保守を依頼する際には、今回のような事態を二度と招かないための条件を契約に盛り込むことが重要です。最低限、次の点を発注前に確認・合意しておくことをおすすめします。
- ソースコードの著作権を発注者側に譲渡する条項があるか
- 契約終了時・保守終了時にソースコード一式の納品を義務付ける条項があるか
- 開発会社の連絡先・担当者情報を、個人ではなく会社としての正式ルートで保管しているか
- 定期的にソースコードのバックアップを自社側でも保有できているか
これらは特別に高度な要求ではなく、システム開発の商習慣としてはごく標準的な内容です。むしろ、これを渋る開発会社であれば、その時点で慎重に検討する材料にもなります。
見積もりを比較するときに聞くべき質問
複数の開発会社から解析・再構築の見積もりを取る段階になったら、金額だけを比較するのは危険です。IT分野に不慣れな承継社長ほど、提示された総額の大小だけで判断してしまいがちですが、次のような質問を各社に投げかけることで、提案の質を見極めやすくなります。
見積もり比較で確認すべき質問例
- 現行システムの解析には、具体的にどんな作業（データベース調査・逆コンパイル・古参社員へのヒアリング同席など）が含まれているか
- 段階的な移行（一部の業務から先に切り替える）は可能か、それとも一括移行前提か
- 開発後、ソースコードの著作権は自社に譲渡されるか、契約書に明記してもらえるか
- 保守終了時・契約終了時に、ソースコード一式を確実に受け取れる取り決めがあるか
特に3つ目・4つ目は、今回の教訓を踏まえて必ず確認すべき項目です。金額の安さだけで選び、また同じ轍を踏むことのないよう、契約条件そのものを比較の軸に加えてください。
古参社員との合意形成も忘れずに
システムを作り直すとなると、現場で長年そのシステムを使ってきた古参社員にとっては、使い慣れた画面や操作が変わることへの心理的な抵抗が生まれやすいものです。特に、先代の時代からそのシステムに愛着や誇りを持っている社員がいる場合、「なぜ今のままではダメなのか」という反発が起きることもあります。
ここで重要なのは、後継者が「ソースコードがないから仕方なく作り直す」という消極的な説明で終わらせず、「今回を機に、次の代に困らないよう整理する」という前向きな位置づけを社内で共有することです。古参社員の記憶や知見は、再構築における最大の資産でもあります。彼らを「使いにくくなる被害者」ではなく、「新しいシステムの設計に欠かせない協力者」として巻き込むことが、円滑な移行のカギになります。
レガシーシステム化を放置しないための定期点検
新しく作り直したシステムであっても、時間が経てば技術は古くなっていきます。今回のようにソースコードを失い、身動きが取れなくなったレガシーシステムを再び生み出さないためには、「今のシステムがいつまで安全に使えるか」を定期的に点検する習慣が欠かせません。
具体的には、年に一度程度、次のような点をチェックすることをおすすめします。
- 使用しているソフトウェア・ミドルウェアのサポート終了時期は把握できているか
- 開発会社との契約書・ソースコードの保管場所は、後継者や複数の社員が把握しているか
- システムに詳しい社員が一人しかいない状態（属人化）になっていないか
- 保守契約は継続しているか、開発会社の経営状態に大きな変化はないか
こうした点検を怠ると、次の代替わりで再び同じ問題が繰り返されます。今回の教訓を、単発のトラブル対応で終わらせず、会社としての管理ルールに落とし込むことが、長期的には最も効果の大きい対策になります。
まとめ：焦らず、順番に手を打てば道は残っている
先代が契約していた開発会社が倒産し、ソースコードが手元にない——この状況に直面すると、目の前が真っ暗になるような不安を覚えるかもしれません。しかし、実際には打てる手が複数残っています。
- まず契約書を探し、著作権とソースコード開示義務の条項を確認する
- エスクロー契約があれば、預託機関から正規に取得する
- 破産手続きが清算結了前であれば、破産管財人への開示請求を検討する
- それでも入手できなければ、動いているシステムを解析し、古参社員の記憶も借りながら作り直す
そして何より重要なのは、この経験を教訓に、システムの契約情報・技術情報を「先代個人の記憶」から「会社の資産としての台帳」に移し替えることです。株式や登記と同じように、システムについても、いつか誰かに引き継ぐ前提で情報を整理しておく——それが、次の代の経営者を今回のような不安から守る、最も確実な方法です。
よくある質問
Q1. 開発会社が倒産したことすら分からず、連絡が取れません。どこから調べればいいですか？
まずは契約書に記載された会社名・法人番号で、国税庁の法人番号公表サイトや商業登記情報を確認してください。破産手続きが開始されている場合、官報に破産手続開始の公告が掲載されます。すでに清算結了している場合は、法人格が消滅しているため、破産管財人への問い合わせという経路は使えなくなります。その場合は本記事の「3. ソースコードなしで動いているシステムを解析する」に進むことになります。
Q2. ソースコードを勝手に解析（逆コンパイル）しても法律上問題ありませんか？
2018年・2019年の著作権法改正により、研究開発目的（互換性の確認や脆弱性の発見など）でのリバースエンジニアリングは違法性がないと整理されています。ただし、解析自体が適法でも、そこで得た情報の使い方によっては著作権侵害などの問題が生じ得るため、そのまま複製・模倣するのではなく、自社の業務要件に基づいて新規に設計し直す形を取るのが安全です。不安がある場合は、着手前にIT分野に詳しい弁護士に一度相談することをおすすめします。
Q3. 契約書自体がどこにあるか分かりません。それでも打つ手はありますか？
あります。まず経理担当者や顧問税理士・顧問社労士に契約書の保管先の心当たりがないか確認してください。それでも見つからない場合、契約書がない状態は「著作権の帰属についてもソースコード開示義務についても、原則としてベンダー側にあるものとして扱われる」ことを意味します。この場合、破産管財人への交渉材料は乏しくなりますが、システム自体が今も動いているなら、解析・再構築という選択肢は変わらず残っています。並行して、今後は契約書を後継者を含む複数人で管理する体制に切り替えることをおすすめします。
Q4. 作り直すとなると、費用も期間もかなりかかりそうで不安です。
規模や複雑さによりますが、いきなり全体を作り直す必要はありません。まずは業務への影響が大きい部分（受発注・請求など）から優先順位をつけ、段階的に移行する方法もあります。複数の開発会社から見積もりを取り、現行システムの解析にどの程度の工数がかかるか、作り直しにどの程度かかるかを比較したうえで、経営判断として進め方を決めることをおすすめします。焦って一社だけの提案を鵜呑みにせず、複数社の意見を聞くことが、結果的にコストを抑える近道になります。
