はじめに
業務改善や自動化の現場では、次のような言葉がよく使われます。
- 「この人しか分からない」
- 「作った本人にしか直せない」
- 「詳しい人がいるから大丈夫」
これらは一見すると
スキルが高い・頼りになるという評価に見えますが、
業務システムの文脈では 明確な危険信号 です。
本記事では、
どこまでの属人化が許され、どこからが許されないのか
その判断基準を整理します。
結論を先に
属人化が 許されるかどうか は、
技術力や人柄の問題ではありません。
判断基準は次の一点です。
その人が不在になっても、業務が成立するか
成立しないなら、
その業務・仕組みは すでに破綻寸前 です。
属人化が許される業務
次の条件をすべて満たす場合、
属人化は大きな問題になりません。
- 一時的・補助的な業務
- 作業結果が参考情報に留まる
- 不在時は「やらなくてもよい」
- 失敗しても影響が限定的
つまり、
無くなっても業務全体は回る
この状態であれば、
個人の工夫やスキルに依存していても許容範囲です。
ですが実際、そのような業務は稀です。
属人化が許されない業務
次のいずれかに当てはまる場合、
属人化は明確なリスクになります。
① 定常業務として回っている
- 毎日／毎週必ず発生する
- 実行しないと業務が止まる
- 結果が次工程に渡る
これはすでに
個人作業ではなく業務プロセスです。
② 業務結果が公式なデータになる
- 報告資料に使われる
- 数値が意思決定に使われる
- 顧客・取引先に影響する
この場合、
「詳しい人がいるから大丈夫」は通用しません。
③ 引き継ぎが現実的でない
- 説明に数日～数週間かかる
- 口頭説明が前提
- ドキュメントが存在しない
これは
引き継ぎ不能＝属人化の完成形です。
なぜ属人化は危険なのか
理由① 退職・異動・休職は必ず起きる
- 予告なく異動が決まる
- 急病で長期離脱する
- 退職
属人化は、 時間の問題で必ず顕在化するリスクです。
理由② 改善も修正も止まる
- 本人以外が触れない
- 触ると壊れる恐怖
- 結果として放置される
この状態では、
業務は静かに劣化していきます。
理由③ 責任が個人に集中する
属人化された業務では、
- トラブル＝その人の責任
- 不具合＝その人のミス
となりがちです。
これは
業務設計の失敗を個人に押し付けている状態です。
ありがちな油断
❌「スキルの高い人がいれば問題ない」
→ 問題が起きた時点で、その人が詰む
業務は個人を守りません。
❌「マニュアルを書けば解決する」
→ マニュアル化できない構造が問題
内容ではなく、構造を疑うべきです。
❌「忙しいから分業できない」
→ 忙しい業務ほど属人化してはいけない
止まった時の影響が大きすぎます。
判断のためのチェックリスト
以下に1つでも当てはまれば、
属人化は許されない業務です。
- 特定の人がいないと回らない
- 修正できる人が限られている
- 説明なしでは理解できない
- 業務停止のリスクが個人に集中している
- 「その人が辞めたら終わり」という認識がある
対策
-
属人化が許される範囲
→ 個人ツール・裁量に任せてよい -
属人化が許されない業務
→ 仕組みとして分離・標準化する
これもまた、システム開発の前段階で考慮すべきことです。
まとめ
- 属人化の是非はスキルの問題ではない
- 判断基準は「不在でも業務が回るか」
- 定常業務・公式データは属人化不可
- 個人に依存する設計は必ず破綻する