属人化は誰の問題なのか – 専門性と独占性を分け、依存関係を設計する

組織では、しばしば「属人化を排除すべきだ」と言われます。

特定の担当者が休むと業務が止まる、退職すると引き継げない、障害が起きるとその人を呼ぶしかない。このような状態が業務継続上のリスクになることは確かです。

しかし、人に依存している状態をすべて属人化として否定すると、専門職や管理職まで不要だという話になります。専門職は、他の人にはない知識や経験、判断能力を持っているから専門職です。管理職も、権限と責任を持ち、不確実な状況で優先順位を決める役割を与えられています。

誰が担当しても同じ仕事ができ、誰が判断しても同じ結論になり、誰が責任者でも何も変わらないのであれば、専門職や管理職を置く意味は薄くなります。極端に言えば、最終責任者だけを残し、その他の人をすべて交換可能な作業者にすればよいことになります。

もちろん、現実の組織はそのようには成立しません。属人化を考えるには、まず専門性と独占性を分ける必要があります。

専門性と独占性は別である

専門性とは、高度な知識、経験、判断能力を持っていることです。独占性とは、その人以外が業務を実行できず、判断の根拠も確認できず、不在時の代替手段も存在しないことです。

専門性は組織にとって価値です。一方、独占性は業務継続上のリスクになります。

たとえば、経験のある技術者が、ログやメトリクスのわずかな変化から障害原因を推測できることは専門性です。他の人が同じ速度や精度で判断できないからといって、直ちに問題になるわけではありません。一方で、通常の再起動手順、設定変更の方法、監視項目、既知障害への対応まで、その技術者しか知らないのであれば、それは独占性の問題です。

管理職についても同じです。不確実な状況で優先順位を決め、人員や予算を配分し、結果に責任を持つことは、管理職に求められる能力です。しかし、その管理職しか承認できず、不在時の代行ルールもなく、判断理由も記録されていないのであれば、権限が独占されています。

属人化対策で減らすべきなのは、専門性ではありません。知識、作業、判断、権限が、代替手段のないまま一人へ集中している状態です。

問題は人への依存ではなく、未設計の依存である

組織から人への依存をなくすことはできません。設計、交渉、創造、例外処理、優先順位の決定、責任の引き受けは、最終的には人が行います。

したがって、目指すべき状態は、誰にも依存しない組織ではありません。誰に何を依存しているのか、その人が不在の場合に何が止まるのか、どこまで代替できるのかが明確になっている状態です。

システム設計では、一つの機器が故障しただけでサービス全体が停止する構成を、単一障害点があると考えます。組織でも同様です。特定の人が不在になっただけで、通常業務、障害対応、承認、意思決定が停止するのであれば、その人は組織上の単一障害点になっています。

ただし、ここでは二つの問題を分けて考える必要があります。一つは、なぜ知識や業務がその人へ集中したのかという形成原因です。担当者が情報を共有しなかったのか、組織が一人だけに任せ続けたのかを確認する必要があります。

もう一つは、その業務をどこまで代替できるのかという業務特性です。再現性の高い作業なのか、例外判断が必要なのか、完全な代替が現実的ではない高度な判断なのかを見極めます。

業務が高度であることは、担当者または組織と並ぶ「第三の原因」ではありません。高度さや不確実性は、代替方法と対策の限界を決める業務側の属性です。形成原因と業務特性を混同すると、組織が作った集中構造を「高度な仕事だから仕方がない」と正当化したり、逆に高度な専門判断まで単純な手順書へ落とそうとしたりします。

属人化を分析する四つの段階

属人化を実務上の問題として扱うには、次の順序で分析します。

1. 一人へ集中した原因を確認する。
2. 業務の再現性と不確実性を分類する。
3. 担当者が不在になった場合のリスクを評価する。
4. 原因、業務特性、リスクに応じて対策を選ぶ。

ここからは、この四つの段階に沿って考えます。

一人へ集中した原因を確認する

業務が特定の人へ集中する原因は一つではありません。担当者が意図的に情報を隠し、自分にしか仕事ができない状態を維持している場合もあります。一方で、組織が一人しか配置せず、育成や文書化の時間も与えず、長期間その人へ任せきりにした結果として、独占性が生じる場合もあります。現実には、両方の要因が混在していることもあります。

担当者が独占性を維持している場合

担当者がレビューを拒み、情報を共有せず、手順の説明も避け、自分にしかできない状態を意図的に維持しているのであれば、本人にも責任があります。専門性を持っていることと、知識を隠すことは別です。

自分にしかできない状態を維持すれば、組織内での発言力や雇用上の優位性を得られる場合があります。「自分がいなければ困る」という状態が、担当者側の自己保身として利用される可能性はあります。

ただし、それは専門家であることの必然ではありません。専門性を持ちながら、定型作業を共有し、判断理由を記録し、他の人が学習できる状態を作ることは可能です。

組織が一人へ集中させた場合

一方、次のような状況では、独占性の原因を担当者だけに求めることはできません。

• その業務に一人しか配置していない。
• 増員や後任育成の要求を認めていない。
• 日常業務を過剰に与え、文書化や教育の時間を確保していない。
• 設計や変更をレビューする仕組みを設けていない。
• 担当者以外が実作業を経験する機会を作っていない。
• 担当者が常に対応できることを前提として運用している。

この状態で、担当者が退職を表明してから急に「属人化が問題だ」と言い始めるのであれば、順序が逆です。問題は、その人が知識を持っていることではありません。組織が、その人の知識や稼働へ無制限に依存する状態を放置していたことです。

担当者に手順書の作成を命じるだけでは、人員不足、過大な業務範囲、レビュー不在、育成計画の欠如といった原因は解消されません。むしろ、既に業務が集中している人へ、さらに文書作成の負担を加えることになります。

属人化という言葉は双方にとって便利になり得る

管理職や担当者の内心を、外部から断定することはできません。しかし、その言葉が組織内でどのような働きをしているかは、観察できます。

たとえば、後任育成のための人員や時間が確保されず、設計レビューも行われていなかったにもかかわらず、退職時になって「担当者が知識を抱え込んでいる」と説明されるのであれば、属人化という言葉は、結果として人員配置や育成計画の問題を見えにくくします。

転職や人材移動が珍しくない環境では、担当者に辞められることで業務が回らなくなり、管理責任を問われることへの不安も生じます。業務継続を心配すること自体は、管理職として当然です。しかし、その対策を担当者の文書化義務だけに置き換えるなら、管理上の問題は残ったままです。

反対に、担当者がレビューを拒み、構成変更を記録せず、認証情報を個人で保有し、「自分以外には理解できない」と繰り返しているのであれば、独占性を自ら維持していると判断できます。

重要なのは、管理職と担当者のどちらが悪いかを、先に決めることではありません。情報を組織から確認できるか、レビューが行われているか、育成時間が確保されているか、担当者以外が作業を経験しているか、不在時の代替経路があるかといった、観察可能な事実から原因を判断することです。

業務の再現性と不確実性を分類する

集中した原因を確認した後は、その業務がどのような性質を持っているのかを分類します。すべての業務を「誰でもできるようにする」という方針では、高度な専門判断まで無理に手順化する一方、本来は自動化できる定型作業が残されることがあります。

分類	内容	考え方
再現性の高い業務	同じ入力に対して、同じ手順を行い、同じ結果を期待できる業務	標準化、自動化、手順化の対象にする
例外の境界を定義できる業務	通常時は定型的に処理できるが、一定の条件を超えると専門判断が必要になる業務	通常処理、中止条件、エスカレーション条件を分ける
不確実性の高い業務	入力情報が不完全で、複数の目的が衝突し、一つの正解が存在しにくい業務	判断過程、制約、リスク、見直し条件を記録する

定型的なサーバー構築、決められた条件でのアカウント発行、既知障害への復旧処理などは、再現性の高い業務です。実行者の経験によって多少の速度差は生じても、何を行うべきかはあらかじめ定義できます。このような業務を長期間「専門家にしかできない仕事」のまま残す合理的な理由は、基本的にはありません。

通常の障害復旧は手順化できても、想定した状態へ戻らない場合には、原因分析や変更判断が必要になります。この種の業務では、すべてを専門家へ任せる必要はありません。一方で、すべてを手順書だけで完結させることもできません。

システム設計、投資判断、重大障害時のサービス継続判断、組織間の利害調整などは、不確実性の高い業務です。性能、信頼性、コスト、運用性、納期をすべて同時に最大化することはできません。そのため、何を優先し、何を諦めるのかを判断する必要があります。

この領域では、結論そのものを完全に標準化することは困難です。標準化できるのは、前提条件の整理、選択肢の比較、制約とリスクの記録、レビュー方法といった判断過程です。

なお、権限の有無は、この三分類とは別の問題です。一定金額以下の経費承認のような再現性の高い業務にも権限はあります。重大障害時のサービス停止判断のような、不確実性の高い業務にも権限があります。したがって、権限は第四の業務分類ではなく、すべての業務を横断する属性として、不在リスクの中で確認します。

担当者が不在になった場合のリスクを評価する

業務の性質を分類した後は、その業務が一人へ集中していることで、実際にどの程度のリスクが生じているのかを評価します。定型業務であっても、数分の停止も許されないのであれば、強い対策が必要です。一方、高度な専門判断であっても、発生する機会が少なく、必要になった時点で別の支援を得られるのであれば、どこまで社内で代替能力を維持すべきかは別途検討する必要があります。

業務の高度さだけで、属人化対策の優先順位や投資額を決めることはできません。評価する軸は、次の六つです。

評価軸	確認する内容
不在許容時間	担当者が不在になった場合、どの程度まで業務停止を許容できるか
発生頻度と予見可能性	その業務や判断がどの程度の頻度で発生し、事前に予定できるか
代替可能範囲	他の人が日常業務、既知障害、未知障害、設定変更、設計変更のどこまで対応できるか
判断の追跡可能性	現在の構成や手順が、どのような前提と理由で選ばれたのかを本人以外が確認できるか
学習可能性	後任者が、資料、検証、レビュー、訓練などを通じて必要な能力を獲得できるか
権限の継続可能性	責任者が不在の場合、誰がどの範囲まで実行、承認、暫定判断を代行できるか

この六つは、それぞれ別の問題を表しています。操作手順が存在していても、承認権限が一人に集中していれば業務は止まります。権限を複数人へ与えていても、判断理由を誰も確認できなければ、形式上は代行できても適切な判断はできません。資料が大量にあっても、実際に作業できる環境や訓練機会がなければ、後任者は能力を獲得できません。

また、発生頻度が低い業務では、引き継ぎ資料を作っただけでは能力が維持されないことがあります。数年前に一度読んだ手順を、本番で直ちに実行できるとは限らないためです。したがって、「手順書があるか」だけで属人化の解消を判断することはできません。

人が辞めたとき、何が失われ、何が残るのか

高度な専門家が辞めれば、長年の経験、問題を早期に発見する能力、複数の事象を関連付ける判断力など、その人が持っていた能力を組織が直接利用することはできなくなります。

ただし、その専門家が構成をコード化し、設計理由を記録し、他の人を育成し、再現可能な仕組みを作っていたのであれば、業務上の損失は小さくできます。

損失が小さいことは、その専門家に価値がなかったことを意味しません。その人の専門性が、個人の能力だけにとどまらず、組織の仕組みや他の人の能力へ変換された結果です。

優れた専門家の価値は、自分にしかできない仕事を増やすことだけではありません。既に理解した領域を仕組みや他者へ移し、自分は次の難しい問題へ進める状態を作ることにもあります。

原因、業務特性、リスクに応じて対策を選ぶ

属人化対策は、すべての業務について複数人を配置し、手順書を作ることではありません。原因、業務特性、不在リスクの組み合わせによって、必要な対策は変わります。

担当者が情報共有やレビューを拒んでいるのであれば、本人の善意だけに依存して解消しようとしても、構造は変わりません。設計や変更を複数人でレビューする、作業をペアで実施する、構成や成果物を組織管理の場所へ保存する、個人だけが利用できる認証情報を廃止する、情報共有や後継者育成を役割として明確にするといった対策が必要です。

一方、組織が一人しか配置していないのであれば、担当者に追加の手順書作成を求める前に、人員配置や業務量を見直す必要があります。複数人を配置する、育成と引き継ぎの時間を業務計画へ組み込む、定型作業を削減する、管理職が業務の範囲と重要性を把握するといった、組織側の変更が先になります。

再現性の高い業務は、標準化と自動化の対象です。システム運用であれば、Infrastructure as Code で構成を管理し、変更内容と変更理由を Git へ残し、定型確認を自動テストへ移し、Runbook に実行手順と完了条件を記載します。

例外の境界を定義できる業務では、通常手順だけでなく、中止条件とエスカレーション条件を設計します。どの状態までは手順どおり進めてよいのか、どの状態で処理を止めるのか、専門家へ相談するときにどの情報を揃えるのかを明確にします。

不確実性の高い業務では、専門家の判断そのものを排除するのではなく、その判断を検証可能にします。前提条件、比較した選択肢、制約、リスク、採用しなかった案、見直し条件を記録し、他の専門家によるレビューを行います。

評価結果	主な対策
不在許容時間が短い	複数人による対応、オンコール体制、自動化、代行権限、外部支援の即時利用
発生頻度が低い、または事前予測が難しい	定期訓練、判断記録の維持、外部支援先の確保、発生時の招集手順
代替可能範囲が狭い	日常業務、既知障害、初期切り分け、設定変更の順に段階的に育成する
判断の追跡可能性が低い	前提、選択肢、採用理由、変更理由、見直し条件を記録する
学習可能性が低い	検証環境、ペア作業、担当交代、レビュー、障害訓練を用意する
権限の継続可能性が低い	代行者、委譲範囲、緊急時の暫定権限、事後レビューを定義する

不在許容時間が短い業務を、一人の善意や即時連絡だけで維持することはできません。代替可能範囲が狭い場合も、最初から設計判断まで完全に代替させる必要はありません。まず日常業務と既知障害を移し、その後に未知障害の初期切り分けや設定変更へ対応範囲を広げます。高度な領域については、別の専門家や外部支援へ切り替える境界を決めます。

判断の追跡可能性が低い場合は、操作手順を増やすだけでは不十分です。現在の構成がなぜそうなっているのかを追跡できなければ、後任者は過去の前提が失われた後も、古い判断をそのまま引き継ぐことになります。

学習可能性が低い場合も、資料の作成だけでは解決しません。資料を読めることと、実際に業務を実行できることは同じではないためです。発生頻度が低く、不在による停止も一定期間許容できる業務では、常に複数人の専門家を社内で維持するより、判断記録、招集手順、外部支援先を確保する方が合理的な場合があります。

属人化対策にもコストがあります。したがって、目標は人への依存をゼロにすることではなく、依存によるリスクを把握し、業務の重要性に応じて許容可能な範囲へ抑えることです。

関連する記事

まとめ

属人化という言葉は、専門性と独占性を混同しやすい言葉です。専門家が存在することや、特定の役割を特定の人が担うこと自体が問題なのではありません。

問題なのは、知識、作業、判断、権限が一人へ集中し、その依存範囲、不在時の影響、代替手段が設計されていないことです。また、その状態が生じた原因は、担当者だけにあるとは限りません。担当者が独占性を自己保身に利用する場合もあれば、組織が人員、時間、育成、レビューを用意せず、一人へ依存する構造を作っている場合もあります。

必要なのは、「属人化を排除せよ」という標語を繰り返すことではありません。一人へ集中した原因と、業務そのものの不確実性を分けて考え、不在時のリスクを評価し、その結果に応じた対策を選ぶことです。

定型業務は仕組みへ移す。例外処理には境界とエスカレーション経路を設ける。高度な判断は専門家へ残しつつ、その前提と理由を検証可能にする。権限には代行経路を設ける。

属人化は一律に排除するものではありません。専門性を維持しながら、不要な独占性と単一障害点を減らすように、人と組織の依存関係を設計する問題です。