引き継ぎ資料は、前任者の知識を網羅する文書ではなく、次の担当者が現在地を確認し、安全に作業を再開するための入口です。 結論は、機能説明よりも「何が動くか、何が未完了か、どう確認するか、何をしてはいけないか」を優先することです。
なぜ引き継ぎが必要か
コードだけでは、採用しなかった案、期限による妥協、運用上の注意、外部サービスの担当範囲は分かりません。口頭説明だけでは、担当交代後に検索できず、時刻や細部も失われます。文書と実演を組み合わせることで、暗黙知を検証可能な手順へ変えます。
良い引き継ぎの基準は文書量ではなく、受け手が前任者の代行なしで次の安全な一手を選べることです。
登場人物と対象
渡す人、受ける人、システム所有者、運用・セキュリティ担当、必要に応じて外部サービスの窓口が関わります。渡す人は事実と未確認事項を分け、受ける人は手順を自分で実行します。所有者は権限移管と責任範囲を承認します。
対象にはコード、Issue、設計判断、デプロイ、監視、定期作業、アカウント、契約・更新期限を含めます。ただし、パスワードやAPIキーなどの秘密値は文書へ記載しません。
作成の流れ
- 引き継ぐ責任範囲と期限を決める。
- 現在動いている範囲と未完了を分ける。
- 起動・確認・リリース・障害対応の入口を結ぶ。
- 危険操作、必要権限、承認先を書く。
- 受け手が実際に操作し、不足を記録する。
- 所有権とアクセス権の移管を確認する。
必要な項目
対象と目的:
現在動いている範囲:
未完了・既知の問題:
ローカル実行と確認方法:
主要なディレクトリ・処理:
重要な設計判断:
危険な操作・権限:
監視・障害時の手順:
次に着手する候補:
質問先:
最終更新日:
「現在動いている範囲」には、正常系だけでなく既知の制限を書きます。「未完了」には次の操作、完了条件、関連Issueを付けます。「重要な設計判断」には結論だけでなく、制約と採用しなかった案を短く残します。
文書の主要パターン
| 文書 | 目的 | 更新の契機 |
|---|---|---|
| 引き継ぎ概要 | 現在地と責任を移す | 担当交代 |
| README | 開発環境と全体像を共有 | 起動方法変更 |
| ADR・設計記録 | 判断理由を残す | 重要な設計判断 |
| ランブック | 定型の運用操作を再現 | 手順・画面変更 |
| Issue | 未完了作業を追跡 | 状態・優先度変更 |
引き継ぎ資料へ全情報を複製すると、更新漏れが増えます。詳細は正本へリンクし、引き継ぎ資料には「どこを見ればよいか」と現在の状態を書きます。
具体例：未完了機能を渡す
悪い記述は「メール通知は未完成」です。次の担当者は、どこから始めるか判断できません。
対象: 課題提出時の講師通知
現在地: 通知イベント生成まで実装済み、メール送信は未接続
確認: notification.test.tsの対象テストは成功
次の操作: サンドボックス環境で送信アダプターを接続
完了条件: 成功・一時失敗・恒久失敗を記録できる
対象外: 文面の多言語化
関連: Issue #123、設計記録 ADR-007
この形式なら、実装済み部分を壊さず、残作業の境界を確認できます。
秘密値を書かない
APIキーやパスワードそのものではなく、保管場所と取得手続きを書きます。
秘密管理システム名、必要な権限、申請先、ローテーション責任者は書けます。値をチャット、Issue、READMEへ貼る手順にしてはいけません。退任者の個人アカウントに依存している連携があれば、組織管理のアカウントへ移す計画を明記します。
一緒に操作する
文書を渡すだけでなく、次の人に環境構築や主要操作をしてもらいます。説明者が代わりに操作すると、不足を発見できません。
実演では、受け手が画面共有し、渡す人は詰まった時だけ補足します。コマンドの出力、権限不足、古いリンクをその場で文書へ反映します。危険な本番操作は実行せず、検証環境または読み取り専用の確認で代替します。
よくある誤解
「コードに全部書いてある」は誤りです。運用責任や外部制約はコード外にあります。「長い文書ほど丁寧」でもありません。正本が重複すると食い違います。「会議を録画すれば十分」でもなく、動画は検索と更新が難しいため、入口・時刻・結論を文書化します。
注意とベストプラクティス
- 事実、推測、未確認を明示する。
- 日付だけでなく、対象バージョンやコミットを記す。
- 個人名だけに依存せず、チームや当番の連絡経路を書く。
- 削除、DB更新、権限変更には承認と戻し方を付ける。
- 古い資料を残す場合は「廃止」と後継リンクを明示する。
権限の付与だけでなく、不要になった前任者の権限を外す確認も引き継ぎの一部です。
デバッグ・確認方法
リンク切れ、存在しないコマンド、権限不足を機械的・手動で確認します。新しい環境でREADMEどおりに起動し、主要な読み取り操作を行い、テストと監視の入口を開きます。未完了項目はIssueの状態と一致するか照合します。
完了条件
次の人が、起動、主要機能の確認、変更箇所の発見、困った時の相談先確認を自力で行えれば引き継ぎ完了です。
加えて、必要な権限が組織管理下で付与され、不要な権限が解除され、所有者が変わったことを関係者が確認できる状態にします。
実践演習：受け手だけで再開する
引き継ぎ資料を一度閉じ、受け手に「環境を起動する」「未完了Issueを一件選ぶ」「変更候補のテストを見つける」「困った時の連絡先を示す」の四つを実行してもらいます。渡す人は操作せず、止まった位置と不足情報だけを記録します。文書へ追記した後、新しい作業ディレクトリでも同じ入口へ到達できるか確認します。
アクセス権は、リポジトリ、CI、ホスティング、監視、秘密管理を一覧にし、「必要」「付与済み」「利用確認済み」「前任者から削除済み」を別々に管理します。付与通知だけでは利用可能とは限らないため、受け手が読み取り操作を行って確認します。
ケーススタディ：月次請求バッチを引き継ぐ
毎月一日に請求候補を作るバッチを別担当へ渡す場面では、リポジトリの場所だけでは再開できません。対象期間の決まり、締め時刻、再実行時の重複防止、失敗した顧客の扱い、会計担当へ渡す成果物までが責任範囲です。まず「候補作成」と「決済確定」を別操作として書き、どちらが自動で、どちらに承認が必要かを明示します。
判断手順は、平常時、部分失敗、全面停止の三経路で作ります。平常時は実行開始と終了を何で知るか、部分失敗では対象顧客だけを再実行できるか、全面停止では誰が継続か中止を決めるかを整理します。件数、合計額、失敗件数、ジョブID、前月との差を観測項目にすると、「成功ログが出た」だけより業務結果を確認できます。金額の許容差や締め後の修正方法は、コードから推測せず所有者へ確認します。
悪い記述は「毎月バッチを実行し、エラーなら再実行する」です。二重請求の危険と承認境界が分かりません。良い記述は「候補作成は検証環境で件数を比較後、当番が実行する。決済確定は会計担当の承認後に一度だけ行う。途中失敗時は同じジョブIDを用い、未処理分だけが対象になることを確認する」のように、前提、操作、判定、停止条件を分けます。
引き継ぎを完了できない条件は、個人アカウントでしか実行できない、前任者しか復旧判断を説明できない、直近の手順と実際の画面が一致しない、受け手が読み取り結果を確認できない場合です。実演では本番決済を行わず、検証環境かdry runで候補件数まで確認します。受け手が異常値を見て停止し、正しい連絡先と復旧手順を選べるかも試します。手順を最後まで進められることだけでなく、危険な状況で進めない判断ができることが良い引き継ぎの証拠です。
まとめ
引き継ぎは説明会ではなく、責任と作業再開能力の移管です。現在地、未完了、確認方法、危険箇所、正本へのリンクを揃え、受け手自身の操作で検証します。 文書の最終更新日と所有者を残し、担当交代後も更新できる状態で完了です。
