属人化が厄介なのは、当事者に自覚がないことです。自分にとって当たり前だから記録しない。記録しないから他の人ができない。この循環が続きます。
この回は、何が属人化しているかを機械的に洗い出す方法と、どこから手を付けるかを扱います。
1. 自覚できない理由
属人化した知識は、手順としてではなく感覚として持たれています。「なんとなくこの数字がおかしい」「この時期はこの処理が遅い」といった形です。
- 判断の基準が言語化されていない — 「見れば分かる」
- 例外処理が身体化している — 毎月やっているので手が覚えている
- 前提の共有が省略されている — 説明しようとして初めて前提の多さに気づく
- 失敗の記憶が判断に効いている — 「前にこれで痛い目を見た」
4番目は特に伝わりません。なぜその手順を踏むのかが、過去の失敗にもとづいている場合、その失敗を知らない人には無駄な手順に見えます。そして省略され、同じ失敗が起きます。これを防ぐのが EP.4 で扱った の役割で、判断の理由を、判断と一緒に残すしかありません。手順だけを残すと、必ず「この工程は要るのか」と問われます。
は、何人が突然いなくなるとプロジェクトが止まるかを表す数です。1なら、その人が抜けた時点で止まります。属人化の度合いを一言で表せるため、優先順位をつける材料になります。
2. 機械的に洗い出す
自覚に頼らず、記録から炙り出す方法があります。誰が何を触っているかは、多くの場合データとして残っています。
#!/usr/bin/env bash# 過去1年のコミットから、ディレクトリごとの偏りを見る
since="1 year ago"
for dir in $(git ls-tree -d --name-only HEAD); do echo "=== $dir ===" git log --since="$since" --format='%an' -- "$dir" \ | sort | uniq -c | sort -rn | head -3done
# 1人しか触っていないファイルを探す（属人化の候補）echoecho "=== 過去1年、1人しか触っていないファイル ==="git ls-files | while read -r f; do n=$(git log --since="$since" --format='%an' -- "$f" | sort -u | wc -l) if [[ "$n" -eq 1 ]]; then who=$(git log --since="$since" --format='%an' -- "$f" | head -1) printf ' %-60s %s\n' "$f" "$who" fidone1人しか触っていない領域が、そのまま属人化の候補です。ただしこれは変更されたものしか捕捉できません。何年も変更していないが、壊れたら直せるのが1人だけ ── という領域は、この方法では見つかりません。
| 洗い出しの方法 | 見つかるもの | 見つからないもの |
|---|---|---|
| 変更履歴の偏り | 触っている人が偏っている領域 | 変更されていない領域 |
| 問い合わせの宛先 | 誰に聞けば答えが返るか | 誰も聞かない領域 |
| 手順書の有無 | 記録されていない作業 | 記録が古くて使えない作業 |
| 実際にやってもらう | 詰まる箇所が正確に分かる | 時間がかかる |
最下行が最も正確です。他の人に実際にやってもらうと、どこで詰まるかがその場で分かります。時間はかかりますが、推測ではなく事実が得られます。
3. 実際にやってもらう
最も確実な棚卸しは、手順書だけを渡して、別の人にやってもらうことです。横で見ていて、詰まったところが属人化している箇所です。
- 1手順書を渡す — 口頭の補足はしない
- 2横で見る、口を出さない — 助けたくなるが我慢する
- 3詰まった箇所を記録する — そこが不足している情報
- 4なぜ詰まったかを聞く — 書いてなかったのか、書き方が悪かったのか
- 5手順書を直す — その場で直す。後回しにしない
2番目が難しい。助けてしまうと、何が足りないか分からなくなります。詰まっている時間は無駄に見えますが、そこで得られる情報が棚卸しの成果です。口を出したくなったら、その内容こそ手順書に書くべきことだと考えてください。言いたくなった一言が、まさに欠けている情報です。
検証環境で構いません。重要なのは手順書だけで進めるかであって、実際に本番を操作することではありません。危険な操作は「ここで実行する」と読み上げてもらうだけでも、手順の不足は分かります。
4. 優先順位をつける
全部を文書化する必要はありません。止まったときの影響で順位をつけます。
| 作業 | 止まったときの影響 | 頻度 | 優先度 |
|---|---|---|---|
| 月次の請求処理 | 金銭に直結 | 月1 | 最優先 |
| 障害時の復旧手順 | サービス停止が延びる | 不定期 | 最優先 |
| 日次のデータ取り込み | 翌日の分析が止まる | 毎日 | 高 |
| 定期的な棚卸し作業 | しばらくは問題ない | 四半期 | 中 |
| 個人的な効率化スクリプト | その人が困るだけ | 日常 | 低 |
2行目に注意が必要です。頻度が低いものほど属人化しやすいという性質があります。毎日やる作業は誰かが見ていますが、年に数回の作業は、やったことがあるのが1人だけという状態になりがちです。
そして障害対応は、最も余裕がないときに必要になります。手順が頭の中にしかない状態で、その人が休みだったら ── という想定は、実際に起きます。 を用意する価値が最も高いのがこの領域で、しかも最も後回しにされやすい領域でもあります。平常時には必要性が実感できないためです。
5. 自動化は解決策になるか
「自動化すれば属人化しない」という考え方があります。半分正しく、半分間違いです。
| 観点 | 自動化で解消するか |
|---|---|
| 実行できる人が1人だけ | 解消する |
| 手順を覚えている人が1人だけ | 解消する |
| 壊れたとき直せるのが1人だけ | 解消しない |
| なぜその処理があるか知るのが1人だけ | 解消しない |
下2行が残ります。自動化したものにも説明が要るということです。むしろ自動化すると日常的に意識されなくなるため、壊れたときに誰も中身を知らないという状態になりやすい面もあります。
したがって、自動化と文書化はどちらかではなく両方です。EP.4 で扱った「なぜそうしたか」は、自動化したあとも残す必要があります。
6. 棚卸しを定期的にする
一度やっても、時間が経てば新しい属人化が生まれます。定期的な点検として組み込むのが現実的です。
- 半年に一度、変更履歴の偏りを出す — 機械的にできる
- 新しく入った人に手順を試してもらう — 最も正確な検出になる
- 障害対応の手順は、年に一度は通す — 使えることを確認する
- 「この作業は自分しかできない」と思ったら記録する — 気づいた瞬間が最も安い
2番目は一石二鳥です。新しく入った人にとっては になり、既存メンバーにとっては棚卸しになります。わざわざ棚卸しの時間を取る必要がないという点で、実行される確率が高い方法です。専用の時間を確保しないと実行されない施策は、たいてい実行されません。既にある機会に乗せられるかが、続くかどうかを分けます。
属人化は当事者に自覚がないため、記録から機械的に洗い出す。最も正確なのは他の人に実際にやってもらうこと（助けずに詰まらせる）。優先順位は止まったときの影響で決め、頻度が低いものほど属人化しやすい点に注意する。自動化は実行の属人化は解消するが、直せる人の属人化は解消しない。次回は受け取る側の作法を扱います。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。