前任者退職後のシステム引き継ぎで最初にやること

「唯一の開発担当者が辞めた」「外注先と急に連絡が取れなくなった」——プロダクトの中身を知っているのがその人だけだった、という状況は、実際に起きるとかなりの緊急事態です。ソースコードはどこにあるのか、サーバーは誰名義か、ドメインの更新は誰がやっていたのか。分からないことだらけのまま、日々のサービス運用だけは待ってくれません。

このような状況では、パニックになって闇雲に手を動かすより、まず何が失われかけているか(知識・アクセス権)を特定し、優先順位をつけて保全することが重要です。この記事では、非エンジニアの経営者・事業責任者でも実行できる、引き継ぎ初動の具体的な手順を整理します。

最優先: 「誰にも渡っていない」アクセス権を今すぐ確保する

退職・契約終了の直後に最もリスクが高いのは、アクセス権の喪失です。前任者個人のアカウントに紐づいたままのものがないか、以下を確認してください。

• ドメイン: 登録レジストラのアカウント、Whois情報の管理者連絡先。前任者個人のメールで登録されていないか
• DNS: どのサービス(お名前.com、Cloudflare、Route53等)で管理しているか、ログイン情報
• サーバー・クラウド: AWS/GCP/Vultr/さくら等のアカウント所有者。個人契約になっていないか、支払いカードは誰名義か
• ソースコード管理: GitHub/GitLabの組織アカウントか個人アカウントか。個人アカウントなら退職と同時にリポジトリごと消える可能性がある
• CI/CD・デプロイ: 自動デプロイの認証情報がどこに保存されているか
• 外部サービス連携: 決済(Stripe等)、メール送信(SendGrid等)、認証(Auth0等)、分析(GA4等)のAPIキー・管理画面ログイン
• 社内で使っている管理画面(admin): URLとログイン情報

これらが会社名義のアカウントに集約されていれば安心ですが、個人メールアドレスで登録されているケースは想像以上に多いです。連絡が取れるうちに(在職中・業務委託契約が切れる前に)確認するのがベストですが、既に連絡が取れない場合は、各サービスのサポート窓口に会社としての所有権を証明して移管を依頼する動きを並行して進めます。

次に: ソースコードとインフラの「今の状態」を保全する

アクセス権が確保できたら、次はコードとインフラのスナップショットを取ります。ここでの目的は「これ以上失われないようにする」ことです。

• ソースコードの最新版がリポジトリに全て push されているかを確認する。ローカルにしかない未pushの変更がないか、本番で動いているバージョンとリポジトリの内容が一致しているか
• 本番環境の環境変数・設定ファイルをバックアップする(.env やRails credentialsなど、リポジトリに含まれない秘密情報は特に紛失しやすい)
• データベースのバックアップが定期的に取られているか、直近のバックアップがいつのものか確認する
• デプロイ手順が手順書やスクリプト(CapistranoやGitHub Actions等)として残っているか、それとも前任者が手作業でSSHして起動していた属人運用か

この段階では「動いているものを触って壊す」リスクを避けるため、機能追加や改善には手を出さず、現状をそのまま複製・保存することに徹します。特にデプロイが属人化していた場合、次に本番を再起動・再デプロイする必要が生じたときに手順が分からず詰まるケースが多いため、早めに実際の起動手順を再現して確認しておくと安心です。

並行して: 知識が失われる前に「棚卸し」する

前任者と連絡が取れる、あるいは引き継ぎ期間がまだ残っている場合は、この期間を最大限使って知識の棚卸しをします。連絡が取れなくなってからでは復元できない情報です。

• なぜこの技術構成にしたのか、過去に検討して却下した設計判断は何か
• 外部サービスとの連携で、ドキュメント化されていない「お作法」(例: この処理は特定の順序で呼ばないとエラーになる、等)
• 障害が起きたときの復旧手順、過去に起きた障害と対処法
• 顧客・取引先とのやり取りで生じた個別対応・特殊仕様

これらは口頭やSlackのDMに散らばっていることが多く、退職後は基本的に復元不可能です。可能であれば、画面共有をしながらコードベースを一緒に見てもらい、録画を残すだけでも大きな資産になります。

外部チームに引き継ぐ場合の進め方

自社にエンジニアがいない、あるいは新しい開発体制を立ち上げるまでのつなぎとして外部チームに引き継ぐ場合、上記のアクセス権・コード・知識の棚卸しがどこまで済んでいるかによって、外部チームが着手できるスピードが大きく変わります。

外部チームが最初にやるのは、動かせるか・デプロイが再現できるか・テストがあるかといった技術的な健全性の確認です。この観点は既存プロダクトの改善、外部チームが最初に見る観点で詳しく解説しているので、引き継ぎ後の次のステップとして参考にしてください。また、開発会社そのものを乗り換える場合の引き継ぎ実務については開発会社を変更するときの引き継ぎも参照してください。

引き継ぎを依頼する外部チームには、前任者から聞き出せた情報・保全したアクセス権をできる限りそのまま渡すことが重要です。情報が薄い状態からのスタートでも対応は可能ですが、「動かして観察する」調査に時間がかかる分、初期費用や期間は増えます。

まとめ

• 最優先はドメイン・サーバー・リポジトリ・外部サービスなど、前任者個人に紐づいたアクセス権の確保。連絡が取れるうちに動く
• 次にソースコード・環境変数・DBバックアップ・デプロイ手順の「今の状態」を保全し、これ以上の情報喪失を防ぐ
• 設計判断や障害対応の経緯など、ドキュメント化されない知識は連絡が取れる期間内に棚卸しする。外部チームへの引き継ぎ後は既存プロダクト改善の初動観点を参考に技術的な健全性を確認する

torcheees では、前任者退職後のような緊急度の高い引き継ぎ案件にも対応しています。まずは1〜4週間の「要件整理・開発診断」で、現状のコード・インフラ・アクセス権の状態を一通り確認し、保全すべき箇所と改善の優先順位をご提示します。モダナイゼーション・保守・運用のサービスとしてもご相談いただけます。まずはお問い合わせフォームからご連絡ください。