ここまで6回、離任時の整理と受任時の作法を扱ってきました。区切りとして、そもそも引き継ぎをイベントにしないという話をします。
離任が決まってから始める引き継ぎは、必ず間に合いません。理由は単純で、思い出す作業が必要になるからです。
1. イベントとして扱うと失敗する
典型的な流れはこうです。どの段階も、誰も悪くありません。それでも間に合わない。
- 1離任が1か月後に決まる
- 2残務の処理で手一杯になる
- 3最後の1週間で資料を書き始める
- 4思い出せた範囲だけが資料になる
- 5離任後、後任が詰まる。しかし聞く相手がいない
4番目が問題の核心です。EP.4 で書いたとおり、3か月前の判断理由は思い出せません。1か月あっても、思い出せないものは書けない。時間の問題ではなく、記憶の問題です。
計画的な離任でも間に合わないなら、急な離任には原理的に対応できません。病気、家庭の事情、突然の退職。「1か月の猶予がある」という前提自体が、実は保証されていません。
2. 日常に組み込む
解決策は一つで、引き継ぎのための作業を、日常の作業の中に入れてしまうことです。別枠の作業にすると、優先度が下がって実行されません。
| 日常の行為 | 組み込むもの | 追加の手間 |
|---|---|---|
| 設計を決めたとき | を1件書く | 5分 |
| 障害に対応したとき | 対応記録を残す | 対応の一部として |
| 手順を実行したとき | 詰まった箇所を追記する | 1行 |
| 権限をもらったとき | 受任記録に追記する（EP.2） | 1行 |
| 新しい人が入ったとき | 手順を試してもらう（EP.5） | 既に発生している作業 |
共通しているのは、その作業をしている最中に書くという点です。後からまとめて書くのではなく、判断した直後、対応した直後に1行。これなら思い出す必要がありません。書く内容も自然に絞られます。その瞬間に重要だと感じたことだけが書かれるので、後から読んで役に立つ密度になります。
5行目は特に効率が良い。 は既に発生している作業なので、そこに手順の検証を乗せるだけです。新しい枠を作る必要がありません。
3. 属人化を数値で見る
引き継ぎの準備は見えにくい作業なので、評価されにくく、後回しにされます。ここを議論の土台に乗せるには、数値化が有効です。
#!/usr/bin/env bash# 過去1年で、その領域を触った人数を数える# 人数が少ない領域ほど、抜けたときに止まりやすい
since="1 year ago"threshold=2
printf '%-45s %s\n' "領域" "触った人数"printf '%-45s %s\n' "---------------------------------------------" "----------"
git ls-tree -d --name-only HEAD | while read -r dir; do n=$(git log --since="$since" --format='%an' -- "$dir" | sort -u | wc -l | tr -d ' ') [[ "$n" -eq 0 ]] && continue mark="" [[ "$n" -lt "$threshold" ]] && mark=" ← 要注意" printf '%-45s %5s%s\n' "$dir" "$n" "$mark"done | sort -k2 -n「この領域は1人しか触っていません」という事実は、印象論より説得力があります。改善の優先順位を議論するときの共通の土台になります。「属人化している気がする」という主張は反論しやすいのですが、具体的な領域名と人数が並んでいれば、議論は「どこから手を付けるか」に移ります。
ただし数値には限界があります。EP.5 で書いたとおり、変更されていない領域は捕捉できません。数値は議論の入口であって、結論ではないという扱いにしてください。
4. 「1人しかできない」を減らす仕組み
属人化を構造的に減らす方法がいくつかあります。どれも引き継ぎのためだけの施策ではないのが利点です。
- レビューを必ず通す — 少なくとも2人がその変更を見ている状態になる
- 担当を定期的に入れ替える — 触ったことがある人が増える
- 障害対応を輪番にする — 手順が本当に使えるかが検証される
- 定期作業を持ち回りにする — 年1回の作業も複数人が経験する
1番目は既に多くの現場でやっていることです。レビュー文化があるだけで、 は自然に上がります。この観点は Claude Code 受託開発記 EP.09 でも扱っています。
3番目と4番目は負担が増えるように見えますが、手順書が実際に使えるかを検証する機会でもあります。使えない手順書は、書いた本人以外がやってみるまで分かりません。
担当を入れ替えると、短期的には効率が落ちます。これは事実です。ただし抜けたときに止まるリスクと比較してください。効率の低下は測れますが、止まったときの損失は測れないという非対称があるため、議論は効率を優先する方向に寄りがちです。
5. 記録が腐らないようにする
書いた記録も、放置すれば古くなります。古い記録は無い記録より悪いことがあります。信じて従った結果、間違った操作をするからです。
- 1コードと同じ場所に置く — 変更と一緒に更新される可能性が上がる
- 2使ったときに直す — 手順を実行して違っていたら、その場で直す
- 3日付を入れる — いつ時点の情報か分かれば、読む側が判断できる
- 4間違っていたら消す — 直せないなら、消したほうが安全
4番目は勇気が要りますが、正しい判断です。古くて間違っている手順書は、後任を誤った操作に導きます。「参考程度」と注記しても読まれません。直せないなら消す、が安全側の判断です。
2番目が最も現実的な保守方法です。使う人が直す。使われない記録は古くなっても実害が小さく、使われる記録は使うたびに直る ── という自然な形になります。ここで大事なのは、直すことへの心理的な障壁を下げておくことです。修正に承認が要る場所に置くと、気づいても直されません。
6. どこから始めるか
既存の未整理分に手を付けようとすると、量に圧倒されて始まりません。今日以降の分だけを対象にするのが、唯一続く方法です。
- 1今日から、判断したことを1行残す — 過去は遡らない
- 2次の障害対応から、記録を残す — 起きたときにやる
- 3次に人が入るとき、手順を試してもらう — 機会が来たらやる
- 4半年後、溜まった記録を見返す — その時点で整理する
過去を遡らないのが要点です。溜まった未整理分は、それ自体が「いつか整理する」という永久の宿題になります。今日以降の分だけなら、追加の負担はほぼゼロです。そして半年後には、それなりの厚みになっています。
引き継ぎは離任時の作業ではなく、日常の副産物として溜まっていくもの。
離任が決まってから始めると必ず間に合わない（時間ではなく記憶の問題）。解決は日常の作業の中に組み込むこと ── 判断した直後、対応した直後に1行。属人化は数値で示すと議論になる。レビューと担当の入れ替えは、引き継ぎのためだけの施策ではない。そして始めるときは過去を遡らず、今日以降の分だけにしてください。続編は読者リアクションに応じて随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。