「誰も触れないシステム」は、珍しくない
対象読者：社内にエンジニアがいない、または 1〜2 名で手一杯の事業会社の経営者・管理部門の方。作った会社や担当者がいなくなった業務システムを、これからどう扱えばいいか判断したい方に向けて書いています。
私たちに寄せられる相談で、いちばん多いのがこの状況です。
- 開発会社と契約が切れた、または連絡が取れなくなった
- 社内で唯一わかっていた担当者が退職した
- 仕様書がなく、どこを触るとどこが壊れるかわからない
- PHP や Laravel、Rails のバージョンが古く、更新するのが怖い
この状態は「放置されていた」のではなく、多くの場合「うまく動いていたから触る必要がなかった」結果です。誰かが悪いわけではありません。ただ、動いているうちに手を打たないと、障害が起きたときに初めて全体を調べることになる。それが一番高くつきます。
この記事では、私たちが「引継ぎ診断」として実際に行っている最初の 10 営業日の進め方をもとに、経営者・管理部門の方がまず確保すべき 5 つのものを整理します。エンジニアでなくても、ここまでは社内で確認できます。
最初に確保する 5 つのもの
調査を始める前に、次の 5 つが「誰の名義で、誰が管理しているか」を確認してください。技術的な中身よりも先に、所有と権限を押さえるのが順番です。
1. ソースコードの所在
GitHub や GitLab、Bitbucket などのリポジトリにあるのか、サーバー上にしかないのか、開発会社の手元にしかないのか。まずここです。
- リポジトリの所有者（Organization）が自社か、開発会社かを確認する
- サーバー上にしかない場合、今すぐコピーを取る（変更は加えない）
- 開発会社の手元にしかない場合、契約書の「成果物の帰属」条項を確認する
意外に多いのが「本番サーバーで直接コードを修正していた」ケースです。リポジトリと本番の中身が一致していない前提で、本番側を正として扱います。
2. データベースへのアクセス
業務データはシステムの中でいちばん価値があり、いちばん復元しにくいものです。
- DB の種類（MySQL / PostgreSQL / SQL Server など）と、接続情報を誰が持っているか
- バックアップが取られているか、取られているなら最後に復元テストをしたのはいつか
- 個人情報が含まれるテーブルの有無（調査時の取り扱いを決めるため）
「バックアップは自動で取っている」と聞いても、復元したことがなければ存在しないのと同じです。ここは必ず確認します。
3. サーバー・クラウドアカウントの名義
AWS、GCP、さくら、Xserver、Heroku。どこで動いていて、そのアカウントは誰の名義で、請求は誰に届いているか。
- 開発会社名義のアカウントで動いている場合、契約終了と同時に止まるリスクがある
- 個人名義（退職した担当者のクレジットカード）で動いているケースも実際にある
- root / 管理者権限を持つ人が社内にいるかを確認する
この段階で名義が自社でないとわかったら、調査より先に移管の交渉を始めてください。時間がかかるのはここです。
4. ドメインと証明書
見落とされがちですが、ドメインが失効するとシステムもメールも一斉に止まります。
- ドメインの登録事業者と、更新日、支払い方法
- DNS の管理画面にログインできるか
- SSL 証明書の有効期限と、自動更新の有無
5. 契約書と、依頼できる範囲
最後に、開発会社との契約書・利用規約を確認します。見るべきは 3 点です。
- 成果物（ソースコード）の権利が誰に帰属するか
- 第三者に改修を依頼することが制限されていないか
- 保守契約が生きているなら、その範囲と解約条件
ここが曖昧なまま第三者に調査を依頼すると、あとで揉めます。私たちも、調査を始める前に必ず「調査・改修を依頼できる権限をお持ちか」を確認し、法的な判断が必要な場合は弁護士への確認をお願いしています。
5 つが揃ったら：10 営業日の調査で何をするか
所有と権限が確認できたら、技術的な調査に入ります。私たちの引継ぎ診断では、資料とアクセスの受領後 10 営業日を標準としています。やることは決まっています。
| 日程 | やること | わかること |
|---|---|---|
| 1〜2 日目 | 構成の把握。ソース・DB・インフラの全体図を描く | 何がどこで動いているか。外部連携の有無 |
| 3〜5 日目 | コードとデータの読み解き。主要な業務フローを追う | 触ると危ない場所。放置されている不具合 |
| 6〜7 日目 | リスクの整理。バージョン、バックアップ、監視、費用 | 障害・保守性・費用の観点での優先課題 |
| 8〜10 日目 | 診断書の作成。経営者向けと技術者向けの 2 部 | 今すぐ直すもの、90 日で直すもの、当面触らないもの |
ポイントは、本番環境に一切変更を加えないことです。調査用の読み取り専用アカウントを発行してもらい、既存担当者のアカウントは共用しません。調査が終わったら失効してもらいます。
AI エージェントは、読み解きをどこまで速くするか
正直に書くと、ここ 1〜2 年で調査の速度は大きく変わりました。1,000 ファイルを超えるコードベースでも、AI エージェント（私たちは主に Claude Code を使っています）に「この画面の保存処理はどのテーブルを更新するか」「このバッチはどこから呼ばれているか」と聞けば、数分で当たりがつきます。以前は数時間かかっていた作業です。
ただし、2 つの前提があります。
- お客様のソースコードや機密情報を AI に入力する場合は、事前に合意する。利用するサービス、データが学習に使われない設定になっているか、入力してよい情報の範囲。合意のない情報は入力しません
- 最終的な判断は人がする。AI は「ここが怪しい」を速く出してくれますが、「この会社の業務にとって何が優先か」は、業務を理解した人間が決めます
速くなったのは「読む」部分です。「決める」部分は変わっていません。
診断書に書くこと、書かないこと
10 営業日の成果物は、経営者向けの診断書と技術者向けの調査結果の 2 部です。経営者向けには、次の 4 つだけを書きます。
- 現状：何がどこで動いていて、誰が管理しているか
- リスク：放置すると何が起きるか。障害・データ・費用・セキュリティの観点で
- 優先順位：今すぐ／90 日以内／当面不要、の 3 段階
- 次の 90 日の計画：何を、どの順で、止めずに直すか
逆に、書かないこともあります。「全部作り直すべき」とは、ほぼ書きません。動いているシステムには、動いている理由があります。壊さず、止めない方法を優先して、段階的に変える方が、ほとんどの場合は安く、速く、安全です。
また、セキュリティについては「調査範囲内で確認できたリスク」として書きます。網羅的な脆弱性診断やペネトレーションテストとは別のものなので、そこは正直に線を引きます。
まとめ：今日できること
✅ ソースコード・データベース・クラウドアカウント・ドメイン・契約書。この 5 つの「所有者と管理者」を、今日、社内で確認してください。それだけで、次に何を誰に頼めばいいかが見えてきます。
5 つのうち 1 つでも「わからない」があれば、それが最初に手を付ける場所です。技術の話はその後で構いません。
もし「確認したが、この先どう進めればいいかわからない」という段階でしたら、引継ぎ診断の内容をご覧ください。診断だけの依頼も受けていますし、その後の改修を他社に頼まれる場合も、引き継げる形で納品します。
