先代の代からの開発会社と連絡が取れなくなったとき、まず確認すべき3つのこと

先代の代からシステムを任せていた開発会社と、ある日を境に連絡が取れなくなる。電話をしても出ない、メールを送っても返事がない、会社のサイトはいつの間にか閉鎖されている——。事業承継を機にIT周りを見直そうとした二代目・三代目経営者が、最初にぶつかる壁のひとつがこれだ。

結論から言う。連絡が取れなくなったときにまず確認すべきは、次の3つである。

1. 契約書と請求書一式が社内に残っているか（保守契約の有無・範囲、支払い履歴）
2. ドメイン・サーバー・ソフトウェアライセンスの契約者名義が誰になっているか
3. ソースコードや設計書、管理者アカウントの所在と、それらの著作権の帰属

この3つを押さえられているかどうかで、その後の対応スピードとコストは何倍も変わる。逆に言えば、この3つが曖昧なまま「とりあえず新しい業者を探そう」と動き出すと、二重に費用を払うことになったり、最悪の場合はシステムそのものを作り直す羽目になる。

本記事では、先代の時代に契約された開発会社と疎遠になった、あるいは廃業していたことが後から発覚した、という状況を想定し、承継したばかりの経営者が実務としてどう動けばよいかを整理する。

こんな状態に心当たりはないか

以下のような状態に一つでも当てはまるなら、この記事は今のあなたに関係がある。

• 先代が個人的に付き合っていた「昔からの業者さん」がいたが、名刺も契約書も見当たらない
• 経理担当や古参の総務担当に聞いても「先代が全部やり取りしていたので分からない」と言われる
• 販売管理システムや基幹システムの調子が悪くなったが、誰に連絡すればいいか分からない
• 会社のホームページやメールサーバーの更新期限が近づいているらしいと聞いたが、契約者情報が分からない
• 数年前に一度だけ担当者から「会社をたたむことになりました」という挨拶メールが来た記憶がうっすらある

こうした状態は、経営として特別ずさんだったからではない。先代が創業した当時、月商が今よりずっと小さかった時代に「知り合いのよしみで安く作ってもらった」システムが、会社の成長とともに基幹業務に組み込まれ、気づけば誰も全体像を把握していない——という経緯を辿るケースが非常に多い。属人化の典型例であり、承継のタイミングでその歪みが表面化するのはむしろ自然な流れだ（システムそのものの調査手順は「触ると壊れる」と先代に言われ続けたシステムを調査する順番を参照してほしい）。

なぜ「連絡が取れない」が起きるのか

まず前提として、システム開発会社が忽然と消えることは、決して珍しい話ではない。地域の中小Web制作会社やシステム開発会社が、代表者の高齢化・後継者不在・受注減少によって廃業するケースは各地で報告されている。ホームページ制作会社の廃業に伴うトラブル相談を専門に扱うサービスがいくつも存在すること自体が、この問題の広がりを物語っている（TOL.jp、kumidiaなど）。

原因は大きく3つに分類できる。

連絡不通の3類型

- 廃業・倒産型：会社そのものが法人格を失っている。代表者に連絡がつくこともあれば、完全に消息不明のこともある

- 担当者退職・異動型：会社自体は存続しているが、あなたの会社を担当していた人物が辞めており、社内に引き継ぎ情報がない

- 契約終了・放置型：保守契約が数年前に切れており、先方も「契約が切れた顧客」として扱っている（悪意ではなく単なる業務整理）

先代経営者の時代は、月々の顧問料や保守料を「担当者との人間関係」で払い続けているケースが多く、契約書自体が更新されていない、あるいは最初から口約束に近い状態だったということも珍しくない。この場合、法的な保守義務があるかどうかを確認する以前に、そもそも「今どういう契約状態にあるのか」が分からないという状態からスタートすることになる。

確認すべきこと1：契約書と請求書一式

最初にやるべきは、社内に残っている紙とデータをかき集めることだ。具体的には次を探す。

• システム開発委託契約書、保守契約書（原本・控えいずれでも）
• 発注書・見積書・請求書・領収書（過去数年分）
• 先代や担当者とのメールのやり取り（社用メールサーバーに残っていないか）
• 銀行口座の振込履歴（毎月一定額を振り込んでいる先がないか）

このうち特に重要なのが保守契約書の有無とその範囲だ。保守契約が現在も有効なのか、すでに満了しているのか、満了している場合は自動更新条項があったのかによって、開発会社側に対応義務が残っているかどうかが変わってくる。

もし契約書が一切見当たらない場合でも、諦める必要はない。振込履歴から「毎月いくら、どの口座に払っていたか」が分かれば、その口座名義から会社の現況（登記が生きているか、代表者が変わっていないか）を国税庁の法人番号公表サイトや法務局の登記情報で調べる手がかりになる。

確認すべきこと2：契約者名義の確認

次に致命的になりやすいのが、ドメイン・サーバー・各種ライセンスの契約者が誰の名前になっているかという問題だ。

中小企業では、ホームページやメールサーバーの契約・更新業務を制作会社やシステム会社に「丸投げ」しているケースが非常に多い。効率的である一方、担当者が退職・異動したり会社そのものが対応できなくなったりした途端に、ログイン情報や契約内容が分からなくなるリスクを抱える（e-zy.jp「業者丸投げに潜む罠」）。

具体的に確認すべき項目は次の通りだ。

もしドメインの契約者名義が開発会社自身になっていた場合、それは重大なリスクである。会社が消滅した場合、更新料の支払いが途絶えてドメインが失効し、第三者に取得されてしまう可能性がある。取引先や顧客に送るメールアドレスがそのドメインに紐づいている場合、事業への影響は決して小さくない。

経済産業省の「中小企業の情報セキュリティ対策ガイドライン」でも、業務の一部を外部委託する際は委託先においても自社と同等の対策が行われるよう、契約書に責任範囲を明記して合意しておくことの重要性が示されている（経済産業省 中小企業の情報セキュリティ対策ガイドライン 第3版）。逆に言えば、こうした取り決めがなされていない契約は中小企業では珍しくなく、承継時にその不備が顕在化するのは構造的な問題だと理解しておいてよい。

確認すべきこと3：ソースコードと著作権の所在

3つ目が最も専門的で、かつ経営判断を左右する論点になる。そのシステムのソースコード・設計書は誰が持っていて、著作権は誰に帰属しているのかという問題だ。

日本の著作権法上の原則として、システム開発を外部のベンダーに委託した場合、契約書に特段の定めがない限り、プログラムの著作権は創作者である受託側（開発会社）に原始的に帰属する。委託者である発注企業に著作権を移転させるには、契約書に「著作権の全部を譲渡する」といった明文の規定が必要になる（参考：IT法務.COM「ソフトウェア開発委託契約におけるベンダのソースコード提供義務」、賢誠総合法律事務所「著作権条項について」）。

つまり、先代の時代に交わされた契約書に著作権譲渡の条項がなければ、法的には「システムの中身を作ったのは向こうの会社であり、自社にはソースコードを自由に改変・複製する権利がない」という状態に置かれている可能性がある。開発会社と連絡が取れなくなったということは、この権利関係を今さら交渉し直す相手すらいなくなったということでもある。

契約書に著作権譲渡の条項が明記されていない場合、プログラムの著作権は原則として開発会社側に残る。連絡不通の相手が権利者のままになっている状態は、将来の改修や乗り換えの障害になり得る。

とはいえ、ここで悲観しすぎる必要はない。ソースコードが手元になくても、あるいは著作権の所在が曖昧なままでも、現行システムの挙動を調査した上で新しいシステムを再構築することは技術的に可能だ。実際に、開発会社の廃業や連絡不通によってソースコードなしでのリプレイスを支援する事業者も存在する（ctsys「開発会社が廃業・連絡不通でシステムが放置状態に」）。ただし、その場合は要件を洗い出すための調査工数が別途発生するため、費用と時間は当然かさむ。だからこそ、着手前にこの3点を確認しておく価値がある。なお、こうした連絡不通・資料なしの状態からの調査や保守引き受けを専門に行う会社もあり、運営会社ゼットリンカーもシステム引き継ぎ・レスキューという受託メニューでこの種の相談を受けている。

3つを確認した後にやるべきこと

3つの確認が終わったら、次のステップに進む。

1. 現行システムの利用者（現場の社員）に業務フローをヒアリングする——先代の頭の中にしかなかった仕様は、現場の使い方から逆算するしかない
2. 管理者アカウント・データベースへのアクセス権を今すぐ確保する——契約者名義が判明したら、パスワードリセットも含めて自社管理に切り替える
3. 緊急度を仕分ける——「今すぐ止まると事業が止まるもの」と「多少不便でも耐えられるもの」を分け、後者は焦って発注しない

ここで陥りがちな失敗が、不安のあまり「とにかく早く」と焦って新しい業者に丸ごと発注してしまうことだ。連絡が取れないという事実そのものはトラブルだが、現行システムが今この瞬間に停止しているとは限らない。まずは現状を正確に把握し、それから次の一手を検討する順番を守ってほしい。

古参社員の記憶を軽視しない

先代のもとで長年経理や総務を担当してきた古参社員は、契約書や台帳が残っていない場合の最も有力な情報源になる。「あの人がよく来ていた」「年に一度、更新の書類にハンコを押していた」といった断片的な記憶が、開発会社を特定する手がかりになることは多い。

一方で、古参社員自身もシステムの詳細までは把握していないことがほとんどだ。先代が「システムのことは全部あの業者に任せている」というスタンスを取っていた会社ほど、社内の誰もブラックボックスの中身を知らないという状況に陥りやすい。これも属人化の一形態であり、業務が特定の社員に依存していたのではなく「外部の一業者」に依存していたというパターンである。この違いに気づけるかどうかで、次に打つべき対策(社内マニュアル整備ではなく複数業者との関係構築)が変わってくる。

古参社員に聞き取りをする際は、次のような問いかけが有効だ。

• 「毎月または毎年、決まった時期に払っている外部業者の請求書に見覚えはないか」
• 「先代が『あの会社に頼んでいる』と話していたのを聞いたことはないか」
• 「システムの調子が悪いとき、誰に電話していたか覚えているか」こうした聞き取りは、経理システムのデータだけでは復元できない「人の記憶」に依存する部分が大きい。承継直後のタイミングだからこそ、古参社員の記憶が鮮明なうちに聞いておく価値がある。

二重発注という落とし穴

連絡が取れない開発会社に代わって新しい業者を探す際、最も避けたいのが「重複する範囲に二重で費用を払ってしまう」ことだ。

たとえば、実は保守契約がまだ生きていて、単に担当者の異動連絡が漏れていただけだったというケースもある。この場合、新しい業者に同じ範囲の保守を発注してしまうと、旧契約を解除しない限り二重払いになる。逆に、保守契約が正式に終了しているのに「まだ有効かもしれない」と誤解して放置し、セキュリティパッチが長期間当たっていないまま使い続けてしまうケースもある。

いずれのリスクも、最初の契約書確認を丁寧に行っていれば避けられるものだ。「連絡が取れない」という事実に動揺し、確認作業を飛ばして次の一手に進んでしまうと、後になって思わぬ二度手間が発覚する。

システムが古すぎて、そもそも対応できる業者が限られる場合

先代の代に作られたシステムが古い言語やフレームワークで書かれている場合、そもそも「そのシステムを読める技術者が今では少ない」という別の壁にぶつかることもある。いわゆるレガシーシステムの問題だ。

さらに、システムが動いている基盤ソフトウェア（OS・ミドルウェア・データベース）自体がEOL（サポート終了）を迎えていることもある。この場合、たとえ開発会社と連絡が取れたとしても、そもそも延命が技術的・コスト的に見合わないという判断に至ることも少なくない。連絡不通という事態は、実は「そろそろ寿命が近いシステムを、これを機に見直しなさい」というサインである場合もあると捉えておくとよい。

台帳がなかったことを教訓にする

今回、契約書やドメイン名義がすぐに分からず苦労した経験は、そのまま今後の資産管理の教訓にできる（退職者のPCやアカウントの棚卸しと合わせて進めると効率がよい。先代の退職者PCとアカウント、承継前にやる棚卸しの手順を参照）。経済産業省の「中堅・中小企業等向けDX推進の手引き2025」でも、紙やブラックボックスで管理していたIT資産情報をデジタル化し、可視化することの重要性が指摘されている（経済産業省 中堅・中小企業等向けDX推進の手引き2025）。

今回の調査で判明した情報——契約先、契約内容、ドメイン・サーバーの名義、管理者アカウントの所在——を、そのまま捨ててしまうのは非常にもったいない。システム管理台帳として一枚のシートにまとめておけば、次に自分が引退して会社を譲るとき、あるいは次に別の業者と連絡が取れなくなったときに、同じ苦労を繰り返さずに済む（台帳化の具体的な手順は属人化した先代システムを防ぐ、承継後の管理台帳の作り方にまとめている）。

最低限、次の項目だけでもExcelやスプレッドシートに書き出しておくことを勧める。

• システム名・用途
• 開発会社名・連絡先・契約状況
• ドメイン・サーバーの契約者名義とログイン情報の保管場所
• 保守契約の有無と更新時期
• 著作権・ソースコードの所在

これは特別なITツールを導入しなくても、今日から始められる作業だ。

相談先がないという孤独感について

株式や登記といった経営の根幹に関わる引き継ぎには、税理士や司法書士という明確な相談先がいる。だが、システムや業者との契約関係については「誰に相談すればいいのか分からない」という孤独感を抱える承継社長は少なくない。

顧問弁護士がいたとしても、著作権や委託契約の細部まで踏み込んで相談したことがある会社は多くないだろう。ITに詳しい社員が社内にいなければ、そもそも何を質問すればいいのかすら分からない、という状態からのスタートになる。

この記事で挙げた3つの確認事項は、専門知識がなくても今日から着手できるものばかりだ。契約書を探す、名義を確認する、著作権条項の有無を見る——これらは特別なITスキルではなく、書類を読む根気があればできる作業である。まずはここから始めて、専門的な判断が必要になった段階で弁護士やIT専門家に相談する、という順番で十分間に合う。

実際にどこから手をつけるか——初動1週間のロードマップ

「言いたいことは分かったが、では月曜の朝、何から始めればいいのか」という声が聞こえてきそうなので、初動1週間のおおまかな進め方を示しておく。あくまで目安であり、自社の状況に応じて前後してよい。

1〜2日目：社内の書類とデータをかき集める

経理担当者に過去5年分の請求書ファイルを出してもらい、「システム」「保守」「ホームページ」「サーバー」といったキーワードで検索をかける。会計ソフトの仕訳データからも、毎月・毎年決まった額を払っている取引先を洗い出せることが多い。並行して、会社のメールサーバーに残っている過去のやり取りも「開発」「保守」「更新」などのキーワードで検索する。

3日目：現場ヒアリング

経理・総務・営業など、実際にシステムを日常的に使っている社員に声をかけ、「困っていること」「昔から変わらない挙動」「以前業者が来ていた記憶」をヒアリングする。この段階では技術的な深掘りよりも、記憶の断片を集めることを優先する。

4〜5日目：契約者名義の確認

ドメインは誰でもWHOIS情報の照会サービスで登録者情報の一部を確認できる（登録者名が非公開設定になっている場合もある)。サーバーやホスティングサービスについては、請求書に記載された会社名から直接問い合わせるのが早い。契約者が開発会社名義になっている場合は、この時点でその会社に連絡を試みる(郵送・電話・メールの複数チャネルで)。

6〜7日目：緊急度の仕分けと次の一手の決定

集まった情報をもとに、「今すぐ止まると困るもの」「多少不便でも当面は耐えられるもの」に仕分ける。前者については代替策(新しい保守業者への暫定契約、パスワード管理の自社移行など)を優先的に進め、後者は焦らず腰を据えて次の業者選定に取り組む。

新しい業者を選ぶときに聞くべきこと

現行の開発会社と連絡がつかないことが確定し、新しい業者に相談する段階に進んだら、次の質問を投げかけてみてほしい。これらへの回答の質で、その業者が「丸投げされる前提」で仕事をしているか、「自社に権利や情報を残す前提」で仕事をしているかが見えてくる。

• ソースコードや設計書の著作権は、契約時点でどちらに帰属する取り決めになるか
• ドメイン・サーバー・各種アカウントの契約名義は、自社名義にできるか
• 保守終了後も、自社が別の業者に乗り換えられる状態を維持してもらえるか
• 開発に使うライブラリやフレームワークのサポート期限が切れた場合の対応方針について、事前に説明があるか
• 担当者が異動・退職した場合の引き継ぎ体制はどうなっているか

こうした質問に淀みなく答えられる業者であれば、少なくとも「また同じことが繰り返されるリスク」は低いと判断してよい。逆に、これらの質問に曖昧な回答しか返ってこない場合は、契約前に条件を明文化するよう強く求めるべきだ。

属人化していたのはシステムではなく「委託関係」そのもの

ここまで読んで気づいた方もいるかもしれないが、今回のトラブルの本質は、システムそのものの複雑さや古さだけではない。「委託先とのやり取り」という業務プロセス自体が、先代個人に強く依存していたという点にある。

先代がどの業者と、どんな条件で、どんな頻度でやり取りをしていたか。それは業務マニュアルにも引き継ぎ資料にも残らない、経営者の頭の中だけにあった情報だった可能性が高い。株式の引き継ぎには株主名簿があり、登記の引き継ぎには登記簿謄本という公的な記録がある。しかし、外部委託先との関係性には、そうした公的な台帳が存在しない。これが「経営の承継ではきちんと専門家がつくのに、システムの承継だけ相談先がない」と感じる理由のひとつでもある。

だからこそ、今回の調査で判明した情報は、単なる緊急対応の記録で終わらせず、次の承継や次の担当者交代に備えた資産として残しておく価値がある。

まとめ：3つの確認は「時間を買う」行為である

先代の代からの開発会社と連絡が取れなくなったとき、慌てて新しい業者を探し始める前に、まず立ち止まって次の3つを確認してほしい。

1. 契約書・請求書一式が社内に残っているか(保守契約の有無・範囲)
2. ドメイン・サーバー・ライセンスの契約者名義が誰になっているか
3. ソースコード・設計書の所在と、著作権の帰属がどうなっているか

この確認作業は、一見遠回りに見えるかもしれない。しかし、確認を怠って走り出すと、二重発注・名義不明による更新失念・著作権未整理による再構築コストの増大など、後になってより大きな時間とお金を失うことになりかねない。3つの確認は、いわば「後からかかる時間を今のうちに買い戻す」行為だと考えてほしい。

そして、この調査を通じて集まった情報は、そのまま今後のIT資産管理の土台になる。二度と同じ孤独感を味わわずに済むよう、今回の経験を社内の資産として残すところまでを、ひとつのゴールに設定してほしい。

「今のシステムを使い続けたい」場合の注意点

新しいシステムへの全面的な入れ替えは避けたい、できれば今のシステムをそのまま使い続けたい、と考える経営者も多いだろう。長年使ってきたシステムには、現場の慣れや、細部まで作り込まれた自社独自の業務ロジックが詰まっている。全面刷新には抵抗感があって当然だ。

その場合でも、まず確認すべきなのは「誰も保守できない状態のまま使い続けることのリスク」を正しく認識することだ。保守してくれる相手がいないシステムは、次のような形で徐々にリスクが蓄積していく。

• 業務端末のOSやブラウザがアップデートされた際に、突然動作しなくなる
• セキュリティパッチが当てられないまま外部と通信する箇所があると、攻撃の標的になりやすくなる
• 唯一動いているサーバーが物理的に故障した場合、代替機への移行作業ができる人がいない

こうした状態は、システムが「動いている」ことと「安全に運用できている」ことが別問題であるという点を経営者に突きつける。特に、顧客の個人情報や取引先の機密情報を扱うシステムであれば、保守されていない状態を放置すること自体が経営リスクになり得る。

現行システムを維持する決断をするにしても、「誰かが最低限、異常時に対応できる体制」を新たに整えることは避けて通れない。連絡が取れなくなった開発会社の代わりに、現行システムの調査・保守だけを引き受けてくれる業者を探す、という選択肢も検討に値する。フルリプレイスではなく、まずは「延命のための保守契約」を新しい相手と結び直すという段階的なアプローチだ。

承継直後だからこそ得られるメリットもある

ここまでリスクの話を中心にしてきたが、承継直後のこのタイミングだからこそできることもある。

先代が現役の間は、「今のままで回っているのだから、わざわざ触らなくていい」という空気が社内に流れがちだ。既存のやり方を変えることに慎重にならざるを得ない事情も理解できる。しかし、経営者が交代するタイミングは、社内的にも「体制を見直す」ことへの心理的ハードルが最も下がる瞬間でもある。

古参社員も、代替わりのタイミングであれば「実はこのシステム、前から不安に思っていました」といった本音を話しやすくなる。取引先や顧客に対しても、「代替わりに伴って業務システムを見直しています」という説明は自然に受け止められやすい瞬間だ。

つまり、開発会社と連絡が取れなくなったという出来事は、望ましい形ではないにせよ、承継直後に自社のIT環境を棚卸しする良いきっかけとして活用できる。ピンチをそのまま放置せず、体制整備のスタート地点として捉え直すことをおすすめしたい。

「もっと早く気づけたのでは」と自分を責めなくていい

ここまで読んで、「先代が生きているうちに、あるいは承継のタイミングで、なぜもっと早く確認しておかなかったのか」と自分を責めたくなる経営者もいるかもしれない。しかし、これは特に責められるべき失敗ではない。

株式承継や登記の引き継ぎには、税理士・司法書士という専門家が入り、チェックリストに沿って粛々と手続きが進む。一方でシステムまわりの引き継ぎには、そうした標準化されたプロセスが存在しない企業がほとんどだ。特に従業員数十人規模の中小企業では、専任の情報システム部門を持たず、総務や経理の担当者が片手間でIT関連の窓口を担っていることが一般的であり、契約の詳細まで把握しきれていないのはむしろ普通のことだと言える。

先代の側にも悪意があったわけではないケースがほとんどだろう。日々の経営判断に追われる中で、「システムの契約書を整理して残す」という作業の優先順位がどうしても後回しになっていた、というだけの話だ。過去を悔やむよりも、今この瞬間から3つの確認を始め、次の世代に同じ苦労をさせない仕組みを作ることに意識を向けたほうが建設的である。

顧問税理士・顧問弁護士への相談タイミング

3つの確認を自社で進める中で、法的な判断が必要になる場面も出てくる。たとえば、開発会社の代表者と連絡が取れたものの支払いや契約条件を巡って見解の相違が生じた場合や、著作権の帰属について契約書の解釈が曖昧な場合などだ。こうした局面では、顧問税理士よりも顧問弁護士、あるいはIT分野に明るい弁護士への相談が適している。ただし、最初から弁護士に丸投げするのではなく、この記事で挙げた3つの確認(契約書の有無、名義の確認、著作権の所在)を自社で済ませた上で相談する方が、相談の質もスピードも上がる。弁護士に「まず何が分かっていて、何が分かっていないか」を整理した状態で持ち込めれば、それだけ的確なアドバイスを得やすくなるからだ。

顧問税理士については、直接システムの契約内容に関与することは少ないものの、過去の経費精算データから開発会社への支払い履歴を横断的に確認してもらえる場合がある。特に、月次や年次で決算書を作成する過程で「システム関連費」として計上されている取引先の一覧を洗い出してもらうと、社内の記憶だけでは辿れなかった業者が見つかることもある。日頃から数字を見ている顧問税理士だからこそ気づける手がかりがあることも、覚えておいて損はない。

FAQ

Q1. 開発会社が廃業していることが登記情報で分かった場合、もう何もできませんか。

いいえ、法人が解散・清算されていても、契約関係を示す書類（契約書・請求書・メールのやり取り）が残っていれば、少なくとも自社がどのような契約状態にあったかは把握できる。ソースコードが入手できない場合でも、現行システムの挙動を調査した上で新しいシステムを再構築することは可能だ。ただし要件の洗い出しに相応の工数がかかる点は踏まえておきたい。

Q2. ドメインやサーバーの契約者が開発会社の名義になっていることが分かりました。今すぐ何をすべきですか。

まずはドメインレジストラやサーバー会社に直接連絡し、契約状況（有効期限・支払い方法）を確認する。契約者名義の変更手続きには本人確認や委任状が必要になることが多いため、開発会社の代表者と連絡が取れるかどうかで対応方針が変わる。並行して、更新期限が迫っている場合は失効を防ぐための緊急対応(支払いの立て替えなど)を優先させる。

Q3. 保守契約書が見当たらないのですが、法的に開発会社に対応義務はないのでしょうか。

契約書が見当たらない場合、口頭合意や黙示の契約が成立していた可能性はあるが、証明は難しいのが実情だ。振込履歴やメールのやり取りが間接的な証拠になり得る。いずれにせよ、連絡不通の相手に法的対応義務を追及するより、現状を正確に把握した上で次の一手(現行踏襲での引き継ぎか、再構築か)を判断する方が現実的な進め方になることが多い。

Q4. こうした事態を防ぐために、承継前にできることはありますか。

先代が元気なうちに、システムに関する契約書・請求書・ログイン情報を一箇所にまとめてもらうことが最も効果的だ。すでに承継してしまった後であっても、今回のような調査を機に管理台帳を作成しておけば、次の担当者交代時に同じ苦労を繰り返さずに済む（台帳化はどこまでやればよいかの目安は台帳化はどこまでやればいいか。承継1年目の管理台帳の作り方も参照してほしい）。

連絡が取れない開発会社との保守契約が実質的に切れている場合のリスクは、保守契約が切れたまま動いている先代システムのリスクと再契約の判断で詳しく解説している。