担当者が退職してシステムが分からない 属人化したシステムを引き継ぐ最初の30日
要約： システムを一人で見ていた担当者が退職し、誰も中身を説明できなくなったときは、最初の30日を次の順で使います。アクセス権とID・パスワードの確保、システムの棚卸し、すぐ起きうる事故の予防、現行仕様書の作成（AIによるソースコードの読み取りを活用）、業務担当者との突き合わせ、そして「残す・直す・作り替える」の判断です。この段階で作り直しには進まないでください。
目次
- システムの担当者が退職したとき、最初に何をすればよいのか
- 最初の30日は、どの順番で進めるのか
- 1週目：アクセス権の確保と棚卸しは、どう進めるのか
- 仕様書がないとき、現状はどこから把握するのか
- AIが作った現行仕様書も、なぜ業務担当者に確認するのか
- 残す、直す、作り替える。何を基準に決めるのか
- この進め方が向かないのは、どんな場合か
- よくあるご質問
1. システムの担当者が退職したとき、最初に何をすればよいのか
最初にやるのは、アクセス権の確保です。直すことも、全体を理解することも、まだ先で構いません。動いているシステムは、動いたままにしておきます。担当者と一緒になくなるのは、ソースコードよりも、コードの外にあるものだからです。個人名義で契約したアカウント、本人のスマートフォンに紐づいた二段階認証、毎月手作業でやっていて、どこにも書かれていない作業がそれにあたります。
中小企業では、決して珍しい話ではありません。数年前に一人でシステムを作った方がいて、問題なく動いていたので、誰も中身を気にしなかった。その方が退職する日になって初めて、サーバーがどこにあるのか、ドメインをどこで更新しているのか、エラーの通知メールを誰が受け取っているのかを、社内の誰も知らないことに気づく、という流れです。
退職前でまだ連絡が取れるなら、1〜2時間だけ時間をもらってください。長い引き継ぎ資料よりも、次の質問のほうが役に立ちます。「このシステムは、どこで止まりやすいですか。止まったとき、どう対応していましたか」。すでに退職されている場合も、以降の手順はそのまま使えます。時間が少しかかるだけです。
2. 最初の30日は、どの順番で進めるのか
最初の30日は、6つの作業を「失ってしまうリスク」から「誤解するリスク」の順に進めます。下の表は、そのまま使えるチェックリストです。前半の行は、エンジニアがいなくても社内で進められます。
| 期間 | 作業 | 成果物 | 見落としやすい点 |
|---|---|---|---|
| 1〜3日目 | アクセス権の確保 | アカウント一覧、名義人、復旧方法 | 個人のスマートフォンに紐づいた二段階認証、退職者のカードで払っているクラウド費用 |
| 3〜7日目 | 棚卸し | サーバー、ドメイン、データベース、外部サービス、定期実行の一覧（簡単な構成図） | 自動実行されるジョブ（cron、タスクスケジューラ）、期限が近いSSL証明書 |
| 1〜10日目 | 事故の予防 | 復元を試したバックアップ、通知の受け取り先、「分かるまで変更しない」というルール | 取得はしているが、一度も復元を試していないバックアップ |
| 8〜18日目 | 現行仕様書の作成 | システムが今していることの記述、画面とデータの一覧 | システムの外で行われる手作業（Excel、マクロ、手動のメール送信） |
| 15〜25日目 | 業務担当者との確認 | 各項目に「合っている」「違う」「もう使っていない」の印 | 普段は問い合わせてこないが、月に一度だけ使う人（経理、期末の棚卸し） |
| 26〜30日目 | 残す・直す・作り替えるの判断 | 理由とリスクを書いた1枚の判断書 | 残した場合に実際にかかる費用（待機する人の負担を含む） |
期間は重なっています。それで構いません。アクセス権の確保と事故の予防は、互いを待たずに進められるからです。
3. 1週目：アクセス権の確保と棚卸しは、どう進めるのか
1週目は、管理者権限をすべて取り戻し、重要そうに見えないものも含めて、システムの構成要素を洗い出します。仕組みを理解する必要はまだありません。何でできていて、誰が鍵を持っているかが分かれば十分です。
次の4つに分けて進めます。
- アカウントと権限。 サーバーまたはクラウド、ソースコードの管理場所、ドメインの管理画面、自動送信メールのサービス、監視ツール。それぞれについて、名義人と復旧方法を書き出します。退職者の個人名義になっているものは、連絡が取れるうちに会社名義へ移してください。
- 期限。 ドメイン、SSL証明書、ソフトウェアのライセンス、サーバーの契約。何年も動いてきたシステムは、コードの不具合より、誰も覚えていない期限切れで止まることのほうが多くあります。
- 定期実行されるもの。 月末の帳票出力、夜間のデータ同期、バックアップ。これらは、ソースコードではなくサーバーの設定に書かれていることが多く、コードを読んでも見つかりません。
- 他システムとの連携。 会計ソフト、決済サービス、取引先のシステム、FTPでやり取りしているファイル。
並行して、ルールを1つ決めます。分かるまで、誰もシステムに手を入れないこと。構造が分からないまま「ちょっと整理しておこう」と手を入れたことが、動いていたシステムを、誰も触れないシステムに変えてしまいます。
4. 仕様書がないとき、現状はどこから把握するのか
仕様書がないときは、システムが何をしているかを示す唯一の確かな記録がソースコードです。AIにコードを読ませると、人が手で読むよりずっと早く、現行仕様書の下書きができます。Claude Codeのようなツールは、プロジェクトのコード全体を読んで質問に答えられると、Anthropicの公開ドキュメントに書かれています。
現行仕様書づくりでは、AIに具体的な質問をします。どんな画面と機能があるか。どのデータをどこに保存しているか。計算のルールはどのファイルにあるか。外部のどのサービスを呼び出しているか。出てくるのは、人が確認するための下書きであり、完成版ではありません。
VAONは、実際のプロジェクトで、ソースコードから現行の姿を書き起こしてから、直すか作り替えるかを決める進め方をしてきました。時間の短縮を測った数字はまだないため、数字は載せません。確かに言えるのは順番です。現行の姿が先にあれば、費用や範囲の話を、根拠をもって進められます。これは、VAONの仕様確定フェーズの入口A（ソースコードの読み取り、運用担当者へのヒアリング、実測）の中身でもあります。
AIにコードを渡す前に、1つ確認してください。社内の規程や契約で、それが許されているかどうかです。VAONも、お客様の許可がない限り、お客様のコードをAIツールには入れません。
5. AIが作った現行仕様書も、なぜ業務担当者に確認するのか
ソースコードから作った仕様書が示すのは「何をしているか」であり、「なぜそうしているか」ではありません。そのため、すべての項目を、普段そのシステムを使っている業務担当者に確認する必要があります。担当者が頼りにしているのは、コードだけではないからです。
コードから起こした仕様書が、実際とずれやすい箇所は5つあります。
- 理由。 コードには「50万円を超える注文は上長の承認が必要」と書かれていても、なぜ50万円なのかは書かれていません。
- すでに使われていないルール。 業務ではとうにやめた処理が、コードには残っています。AIはそれを、今も動いているものとして書きます。
- コードの外にある仕組み。 データベースのマスタ、本番環境だけにある設定、手作業、外部の他社システム。
- 長年残っている不具合。 何年も放置された不具合が、「仕様」として書かれることがあります。使う側もそれに慣れていて、それが正しい動きだと思っています。
- 誰も開かない画面。 コードにはあるが、誰も使っていない画面。
確認の仕方はシンプルです。実際の利用者を2〜3人選び、仕様書の項目を1つずつ開いて、「この作業は今もしていますか。この手順で合っていますか」と聞きます。答えは項目の横に、「合っている」「違う」「使っていない」で残します。業務を回している人との60分は、ソースコードからは決して見えないことを、よく浮かび上がらせます。
6. 残す、直す、作り替える。何を基準に決めるのか
残す、直す、作り替えるの判断は、確認できる3つの事実に基づきます。今の業務に合っているか。このまま使い続けるリスクは何か。そのままにしたときの費用はいくらか。「コードが古そうだ」という感覚だけで、作り替えは決めないでください。
| 選択肢 | 向いている場合 | 受け入れること |
|---|---|---|
| 残す（仕様書と運用手順を整える） | 業務が安定し、システムも問題なく動いていて、困りごとは「誰も分からない」ことだけ | 古い技術のまま使い続ける。仕様書を管理する人が要る |
| 部分的に直す・刷新する | 中核は今も正しく、一部が古い、または安全でない | 新旧を並行して動かす期間と、部分ごとの確認が必要 |
| 新しいシステムに作り替える | 業務が大きく変わった、技術のサポートが終わった、直す費用が作り直す費用を超える | 新システム向けに仕様を固める必要がある。データ移行の期間もかかる |
規模の大きいシステムを止めずに部分ごとに入れ替える進め方は、レガシーCMSを無停止で刷新した事例で紹介しています。作り替えをオフショア開発で進める場合は、ブリッジSEに頼りきらないオフショア開発もご覧ください。現行仕様書をつくる工程は、AIでソースコードから現行仕様書を起こす手順で詳しく説明しています。
7. この進め方が向かないのは、どんな場合か
この進め方が向かないのは、システムがいま壊れている場合、ソースコードがもう手元にない場合、コードをAIに渡してはいけない場合です。それぞれ、対応が変わります。
- システムが止まっている、またはデータが壊れている。 まず復旧です。仕様書づくりは後に回します。
- ソースコードがない。 ビルド済みのものしか残っていない、または個人のパソコンにあったコードが消えている場合です。動いているシステムとデータから組み立て直すことになり、時間がかかり、確かさも下がります。
- コードをAIに渡せない。 AIによる読み取りの工程は行わず、エンジニアが手で読みます。できますが、時間は長くなります。
また、30日は中規模までのシステムを想定した目安です。モジュールが多く、何年分もの履歴があるシステムでは、業務担当者との確認に、もっと時間がかかることがあります。その工程を短くせず、時間をかけてください。
8. よくあるご質問
担当者が退職しました。初日に何をすればよいですか。 システムに関わるアカウント（サーバー、ドメイン、ソースコードの管理場所、メール、監視）をすべて書き出し、誰の名義かを確認してください。前任者と連絡が取れるなら、本人のアカウントが閉じられる前に、名義の移行か復旧方法の共有を依頼します。
すぐにシステム全体を作り直したほうがよいでしょうか。 おすすめしません。現行の仕様書がない状態では、システムが何をしているか全部は分かっていません。作り直すと、使う人には必要なのに、誰も覚えていない機能が抜け落ちやすくなります。先に仕様書をつくり、業務担当者と確認してから決めてください。
AIがソースコードから書いた仕様書は、信頼できますか。 下書きとしては十分ですが、完成版としては使えません。AIは「何をしているか」は分かりますが「なぜか」は分からず、長年残る不具合を仕様として書くこともあります。各項目を、業務担当者が「合っている」「違う」と確認する必要があります。
ソースコードをAIに渡せない場合は、どうなりますか。 作業はできます。AIによる読み取りは行わず、エンジニアが手で読むため、時間は長くなります。VAONは、お客様の許可をいただいた場合に限り、コードをAIツールに入れます。
VAONは、どの工程で力になれますか。 現行仕様書の作成と、残す・直す・作り替えるの判断です。仕様確定フェーズの入口Aで行います。期間は1〜2週間、固定価格を事前にお伝えし、このフェーズの後に止めていただくことも可能です。
システムの中身が、すでに退職された方の頭の中にだけある状態ではありませんか。 最初の60分は代表が同席し、資料の準備は不要で、契約の義務もありません。現状を伺い、最初に取るべき一歩をお伝えします。無料相談（60分）
参考資料
- Anthropic「Claude Code overview」（Claude Codeはプロジェクトのコードを読み、ファイルを編集し、コマンドを実行する）：https://code.claude.com/docs/en/overview （2026年10月17日確認）