はじめに

業務改善や自動化の現場では、次のような言葉がよく使われます。

「この人しか分からない」
「作った本人にしか直せない」
「詳しい人がいるから大丈夫」

これらは一見すると
スキルが高い・頼りになるという評価に見えますが、
業務システムの文脈では 明確な危険信号 です。

本記事では、
どこまでの属人化が許され、どこからが許されないのか
その判断基準を整理します。

結論を先に

属人化が 許されるかどうか は、
技術力や人柄の問題ではありません。

判断基準は次の一点です。

その人が不在になっても、業務が成立するか

成立しないなら、
その業務・仕組みは すでに破綻寸前 です。

属人化が許される業務

次の条件をすべて満たす場合、
属人化は大きな問題になりません。

一時的・補助的な業務
作業結果が参考情報に留まる
不在時は「やらなくてもよい」
失敗しても影響が限定的

つまり、

無くなっても業務全体は回る

この状態であれば、
個人の工夫やスキルに依存していても許容範囲です。
ですが実際、そのような業務は稀です。

属人化が許されない業務

次のいずれかに当てはまる場合、
属人化は明確なリスクになります。

① 定常業務として回っている

毎日／毎週必ず発生する
実行しないと業務が止まる
結果が次工程に渡る

これはすでに
個人作業ではなく業務プロセスです。

② 業務結果が公式なデータになる

報告資料に使われる
数値が意思決定に使われる
顧客・取引先に影響する

この場合、
「詳しい人がいるから大丈夫」は通用しません。

③ 引き継ぎが現実的でない

説明に数日～数週間かかる
口頭説明が前提
ドキュメントが存在しない

これは
引き継ぎ不能＝属人化の完成形です。

なぜ属人化は危険なのか

理由① 退職・異動・休職は必ず起きる

予告なく異動が決まる
急病で長期離脱する
退職

属人化は、 時間の問題で必ず顕在化するリスクです。

理由② 改善も修正も止まる

本人以外が触れない
触ると壊れる恐怖
結果として放置される

この状態では、
業務は静かに劣化していきます。

理由③ 責任が個人に集中する

属人化された業務では、

トラブル＝その人の責任
不具合＝その人のミス

となりがちです。

これは
業務設計の失敗を個人に押し付けている状態です。

ありがちな油断

❌「スキルの高い人がいれば問題ない」

→ 問題が起きた時点で、その人が詰む

業務は個人を守りません。

❌「マニュアルを書けば解決する」

→ マニュアル化できない構造が問題

内容ではなく、構造を疑うべきです。

❌「忙しいから分業できない」

→ 忙しい業務ほど属人化してはいけない

止まった時の影響が大きすぎます。

判断のためのチェックリスト

以下に1つでも当てはまれば、
属人化は許されない業務です。

特定の人がいないと回らない
修正できる人が限られている
説明なしでは理解できない
業務停止のリスクが個人に集中している
「その人が辞めたら終わり」という認識がある

対策

属人化が許される範囲
→ 個人ツール・裁量に任せてよい
属人化が許されない業務
→ 仕組みとして分離・標準化する

これもまた、システム開発の前段階で考慮すべきことです。

まとめ

属人化の是非はスキルの問題ではない
判断基準は「不在でも業務が回るか」
定常業務・公式データは属人化不可
個人に依存する設計は必ず破綻する