判断の出発点
リポジトリは所有と引き継ぎの一部です。別の担当チームが個人アカウントに依存せず、ビルド、公開、監視、復旧できる状態を目指します。契約上の権利は別途明確に合意する必要があります。
具体例で考える
架空の予約アプリならコード、ドメイン、サーバー、データベース、メール、決済、監視を一覧にします。それぞれに事業上の所有者、管理者、請求先、復旧方法を記録し、提供元の正式な手順で権限を移します。旧担当に不要となる認証情報は更新します。
動いている製品全体を棚卸しする
顧客の一操作が通るサービスをすべて追います。予約確認ならキュー、メール、定期削除、監視通知も関わります。アカウントの所有者と用途を記し、開発と本番のアクセスを別に確認します。ビルド手順、実行環境、ライセンス、設定の場所を含めますが、秘密情報や顧客記録をコードを読める全員へ開示しないようにします。
受け取る側で手順を実演する
新担当が何もない環境から説明に従い、ビルド、検証、使い捨てDBへの移行、安全なバックアップ復元を行います。記載されていない回答が必要になった箇所を直し、関係する手順を再確認します。元の開発者のデプロイを見ることと、新担当が運用できる証明は違います。事故時に元担当が不在なら、この差が効きます。
確認後に旧アクセスを閉じる
所有権の移行、確認、認証情報更新、不要権限削除の順番を合意します。早すぎる削除は引き継ぎを妨げ、無期限に残すと責任が曖昧です。事業者管理の復旧方法と自動処理が機能するか確認し、更新通知と警報の受信者を決めます。最後の記録に実演、受容した制約、契約義務、移行中の支援先を残します。未解決事項は担当者と解消条件を必要とします。
選択肢とその負担
文書だけでは手順漏れが残ります。録画した説明は背景理解を助け、立ち会いでの再構築と復元は運用の証拠になります。隔離した環境と安全なデータで実施してください。
見落としやすい点
個人契約のライセンス、定期実行、環境変数、特定のパソコンだけで動く手順が抜けがちです。秘密情報を文書へ貼らず、保管先を示し、新担当が利用できるか確認します。
依頼前に確認すること
無害な変更の公開、エラーの発見、テスト用バックアップの復元を新担当が実行できますか。継続費用と支援範囲は明確ですか。権利の合意とともに、これらを引き継ぎの受入条件にします。