担当者退職で露見する属人化リスク——引き継ぎが機能しない組織の共通欠陥と解消ステップ

担当者の退職が「組織の地雷」になる理由

「退職の話が出るまで、まさかこれほど一人に依存していたとは気づかなかった」——こうした声は、BtoB企業の情報システム部門や経営企画の現場で珍しくありません。担当者の退職は突発的な事故ではなく、長年にわたって積み上がった属人化リスクが一気に表面化する「起爆」に過ぎないのです。

退職前は問題に見えない——属人化が「隠れる」仕組み

属人化は、業務が回っている間は問題として認識されにくい構造になっています。担当者が在籍している限り、業務は滞りなく進みます。周囲から見れば「頼りになる人材がいる」という安心感にすら映ります。

しかし実態は、業務の継続がその一人の存在に依存しているだけです。システムの設定変更、取引先との交渉、イレギュラー対応の判断——これらが「あの人に聞けば解決する」という形で日常化していると、組織はいつの間にかその個人なしでは動けない状態になっています。

問題が隠れたまま維持されるのは、誰も意図的に情報を囲い込んでいるわけではないからです。担当者自身も、求められるから答えているだけです。組織側も、業務が回っているから改善の優先度を上げません。こうして属人化は、退職という外部イベントが来るまで「存在しない問題」として放置されます。

引き継ぎ期間が短いほど露見する、知識の3層構造（手順・判断軸・人脈）

退職が決まった後、多くの組織は引き継ぎ期間を設けます。しかし1〜2か月の引き継ぎで移転できる知識には、明確な限界があります。その理由は、担当者が持つ業務知識が次の3層に分かれているからです。

• 手順の知識：マニュアル化しやすい操作手順や定型業務のフロー。引き継ぎ書に記載されることが多い層。
• 判断軸の知識：「このケースはどちらで対応すべきか」という判断の根拠。過去の経緯や失敗の蓄積から形成されており、文書化されていないことがほとんど。
• 人脈の知識：「この件はあの担当者に直接連絡すれば早い」といった社外・社内の関係資産。担当者が退職すると、そのまま消失するケースが少なくない。

引き継ぎ書に書かれるのは、たいてい最初の「手順の知識」だけです。判断軸と人脈は、短期間の口頭説明では十分に伝わりません。結果として後任者は、退職後に初めて遭遇する状況の連続に直面し、組織はその都度対応が止まります。

担当者の退職が「地雷」と呼ばれるのは、踏んだ瞬間（退職後）に初めてどれだけのリスクが埋まっていたかがわかる——この構造そのものにあります。

引き継ぎが機能しない組織に共通する5つの欠陥

「引き継ぎ書を作る」という対策は、多くの組織がまず思いつく手段です。しかし、引き継ぎ書を用意しても担当者交代後に業務が滞るケースは少なくありません。問題はドキュメントの有無ではなく、引き継ぎが成立するための構造そのものが欠けている点にあります。以下の5つの欠陥は、引き継ぎができない組織に共通して見られるパターンです。

欠陥①：業務手順が「頭の中」にしか存在しない

日常業務が円滑に回っている組織ほど、手順の文書化が後回しになりがちです。担当者が長年同じ業務を担っていると、判断基準や操作手順が暗黙知として蓄積され、どこにも記録されない状態になります。退職が決まった段階で初めて言語化を試みても、抜け漏れが生じやすく、引き継ぎを受ける側が実務で初めて「知らなかった手順」に直面することになります。

欠陥②：引き継ぎ書があっても「なぜそうするか」が書かれていない

作成された引き継ぎ書の多くは「何をするか（What）」の手順にとどまり、「なぜその手順なのか（Why）」が省かれています。例外対応の判断基準や、過去のトラブルを踏まえた運用ルールが記載されていないため、引き継ぎを受けた担当者は想定外の状況で判断できなくなります。手順書が形式的に存在していても、実務の文脈が伝わらなければ機能しません。

欠陥③：システム権限・アカウント管理が担当者個人に紐づいている

社内システムやSaaS（Software as a Service）のアカウントが担当者個人のメールアドレスで登録されているケースは多く見られます。退職後にパスワードが不明になる、二段階認証の受信先が個人のスマートフォンになっている、といった状況は実際に起きています。権限管理が個人に集中していると、担当者の離席と同時に業務へのアクセス自体が遮断されるリスクがあります。

欠陥④：引き継ぎを受ける側の理解確認プロセスがない

引き継ぎは「伝えた側」が完了を判断しがちです。しかし、受け取った側が本当に理解しているかを確認するプロセスが設けられていない組織では、認識のズレが退職後に表面化します。引き継ぎ期間中に実際の業務を試行し、疑問点を洗い出すような検証ステップを組み込まない限り、ドキュメントを渡しただけで終わるリスクがあります。

欠陥⑤：属人化がリスクとして経営層に認識されていない

現場レベルでは属人化の危うさを感じていても、経営層が「業務が回っている状態」を正常と判断しているケースがあります。担当者交代リスクが経営上の課題として議題に上がらない組織では、文書化や権限整理に対して予算も工数も割り当てられません。属人化の解消は、現場の努力だけでは限界があります。経営層がリスクとして認識し、対策を意思決定のアジェンダに乗せることが、構造的な改善の前提となります。

属人化が組織にもたらす定量・定性の損失——なぜ今すぐ対処が必要か

属人化を「なんとなく良くない状態」と認識しながらも、対処を後回しにしている組織は少なくありません。しかし退職リスクと属人化が重なったとき、損失は想像以上の規模で顕在化します。以下では定量・定性の両面から損失を整理します。上位者への稟議や社内説得の根拠としても活用できます。

業務停止コストと引き継ぎ対応工数——見えにくいが大きい直接損失

担当者が退職した直後、最初に発生するのが「業務の一時停止」です。たとえば、社内の受発注管理システムの操作方法を一人しか把握していなかった場合、退職後に処理が滞り、顧客対応の遅延や取引機会の損失につながるケースがあります。

引き継ぎ対応にかかる工数も見過ごせません。後任担当者が業務を把握するまでの期間、上長や周囲のメンバーが補填対応に追われます。1人あたりの引き継ぎ期間が1〜2ヶ月に及ぶ場合、複数人分の稼働が実質的に失われます。この「見えないコスト」は財務諸表には現れにくいため、経営層が過小評価しやすい損失です。

属人化担当者の『人質化』——退職交渉・評価への影響

属人化が進むと、担当者の退職交渉や評価において組織が不利な立場に置かれます。「この人に辞められたら業務が回らない」という状況が続くと、給与・待遇交渉で過度な譲歩を迫られたり、パフォーマンス評価が実態より甘くなったりする歪みが生じます。

これは個人の問題ではなく、組織設計の問題です。情報が一人に集中している限り、その担当者は意図せず「組織の人質」になります。結果として、健全な人事運営が難しくなります。退職 属人化 対策を後回しにするほど、この構造的歪みは深くなります。

退職後アカウント残存というセキュリティリスク

退職リスクと情報共有の問題に並んで深刻なのが、退職後のアカウント管理です。属人化が進んだ環境では、退職者がどのシステムにアクセス権を持っていたか、組織全体で把握できていないケースがほとんどです。

その結果、退職後もクラウドサービスや社内システムへのアカウントが残存したまま放置される事態が起こります。悪意の有無にかかわらず、退職者アカウントが不正アクセスの入口になるリスクは実在します。情報セキュリティの観点から、これは「気づいたときには手遅れ」になりかねない問題です。

属人化の解消は、業務効率だけでなくセキュリティ統制の観点からも、経営判断として優先されるべき課題です。

属人化を解消する4ステップ——引き継ぎが機能する組織への移行

属人化の解消は「意識改革」や「引き継ぎ書の整備」だけでは完結しません。業務の実態把握から、ドキュメント設計、システムの権限管理、そして引き継ぎの品質検証まで、段階的に取り組む必要があります。以下の4ステップは、担当者退職という有事のタイミングでも、平時の体制整備においても適用できる実践的な設計図です。

ステップ1：業務の棚卸しと属人化リスクのスコアリング

最初に行うべきは、現状の業務を網羅的に可視化し、どの業務にどの程度のリスクが潜んでいるかを数値化することです。「なんとなくあの人に頼んでいる」という感覚を、組織として共有できる形に変換するプロセスです。

主導者：情報システム部門責任者または経営企画担当者

成果物：業務一覧表（業務名・担当者・頻度・難易度・代替可能人数を記載）＋リスクスコア

スコアリングは複雑にする必要はありません。以下の3軸で評価するだけでも、優先順位が明確になります。

• 代替可能性：その業務を遂行できる社内人員が何人いるか（1人＝高リスク）
• 業務頻度・重要度：止まったときの事業影響がどの程度か
• ドキュメント化の有無：手順書・マニュアルがすでに存在するか

この棚卸しで「1人しか対応できない×事業影響が大きい×ドキュメントなし」に該当する業務が、最優先で対処すべき属人化リスクです。担当者交代リスク対策の起点として、このスコアリングを四半期に一度見直す運用に組み込むことが理想的です。

ステップ2：手順だけでなく「判断軸」を記述するドキュメント設計

多くの組織が「引き継ぎ書を作ったのに後任が使いこなせなかった」という経験を持っています。原因の大半は、ドキュメントに「何をするか（手順）」しか書かれておらず、「なぜそうするか（判断軸）」が抜け落ちていることです。

主導者：現担当者（退職予定者または業務保有者）＋上長・業務レビュー担当者

成果物：業務手順書＋判断基準ドキュメント＋想定QA集

効果的なドキュメントには、以下の要素を盛り込む必要があります。

• 手順の記述：操作ステップ・使用ツール・関連するシステムや連携先
• 判断軸の記述：「例外が発生したときに何を優先するか」「承認が必要になるケースの条件」など、経験知をルール化した内容
• 想定QA：後任が迷いやすいポイントをQ＆A形式で整理したもの

たとえば、取引先ごとに対応ルールが異なる与信管理業務であれば、「この取引先はこの条件で決裁権限を下げてよい」という判断のロジックまで文書化しなければ、後任は毎回エスカレーションを余儀なくされます。手順書の整備は「業務を移転する」ための道具であり、判断軸の記述は「意思決定を移転する」ための道具です。この二層構造を意識することが、引き継ぎの品質を根本から変えます。

ステップ3：システム・権限管理の個人依存を組織管理へ切り替える

業務手順と並行して対処が必要なのが、システムや情報へのアクセス権限が個人に紐づいている状態の解消です。担当者退職後に「パスワードがわからない」「そのアカウントでしかログインできない」という事態は、担当者交代リスクの中でも即座に業務停止につながる深刻なケースです。

主導者：情報システム部門担当者

成果物：システム・アカウント台帳＋権限管理ポリシーの文書化

具体的には、以下の対応が必要です。

• システム台帳の整備：社内で利用しているすべてのシステム・SaaSのアカウント、管理者情報、契約情報を一元管理する
• 個人アカウントの廃止と組織アカウント化：特定個人のメールアドレスで契約・管理されているサービスを、組織共有のアカウントに切り替える
• 権限の役割ベース管理（RBAC）への移行：「誰に」ではなく「どの役割に」権限を付与する設計にすることで、担当者交代時の権限移管が属人化しなくなる

この整備は退職対応の文脈だけでなく、情報セキュリティの観点からも優先度が高い取り組みです。退職 属人化 対策として語られる場面が多いですが、実際には在職中の体制設計として着手するほうが、対応コストは大幅に抑えられます。

ステップ4：引き継ぎ品質を担保する確認・テスト運用の仕組み化

ドキュメントを整備し、権限を整理しても、「実際に後任が業務を回せるか」を確認しなければ引き継ぎは完了しません。引き継ぎ書の存在と引き継ぎの成功は別物です。最後のステップでは、引き継ぎの品質そのものを担保する仕組みを設けます。

主導者：業務レビュー担当者または上長

成果物：引き継ぎチェックリスト＋テスト運用の記録＋フィードバック反映後のドキュメント最終版

推奨するのは、以下の3段階による確認プロセスです。

1. ドキュメントレビュー：第三者（後任候補または業務未経験者）がドキュメントだけを読んで業務の全体像を把握できるかを確認する。理解できない箇所を洗い出し、ドキュメントを修正する
2. 並走期間の設定：現担当者と後任が一定期間（最低2〜4週間）同一業務を並走し、後任が実際に判断・操作する場面を現担当者が確認する。この段階で「ドキュメントに書いていなかった判断」を拾い、追記する
3. 単独運用のモニタリング：後任が単独で業務を遂行する期間を設け、問い合わせ・エスカレーションの発生状況を記録する。一定水準を下回るまでレビューを継続する

このプロセスを経ることで、「引き継いだつもりが実際には引き継げていなかった」という事後的なトラブルを大幅に減らすことができます。また、このテスト運用のデータは、次回以降の引き継ぎ設計を改善するための根拠にもなります。業務引き継ぎの属人化解消は、一度で完成するものではなく、組織としてのPDCAを回すことで精度が上がっていくものです。

再発させないための仕組みづくり——属人化は個人の問題ではなく設計の問題

属人化の解消に取り組んだにもかかわらず、数年後には同じ問題が繰り返される組織は少なくありません。その原因は担当者個人の意識や努力の問題ではなく、組織の設計そのものに再発を生む構造が残っていることがほとんどです。「退職 属人化 対策」として一時的な引き継ぎ作業を済ませるだけでは、根本的な解決にはなりません。

ドキュメントを「生きた状態」に保つ更新フローの設計

ドキュメントは作成した瞬間から陳腐化が始まります。業務手順書やシステム仕様書が「最後に更新されたのは3年前」という状態では、実態との乖離が大きくなり、引き継ぎできない属人化を招く温床になります。

再発を防ぐには、更新を「誰かの善意」に頼らず、フローに組み込むことが必要です。具体的には以下のような設計が有効です。

• 四半期ごとにドキュメントオーナーがレビューする日程をカレンダーに固定する
• システムやフローに変更が生じた際に、ドキュメント更新をチケット管理ツールのタスクとして必須化する
• 更新履歴を残し、「いつ・誰が・何を変えたか」を追跡できるようにする

更新の負担を下げるために、記載粒度を「誰が読んでも業務を再現できる水準」に絞ることも重要です。網羅性より再現性を優先した設計が、継続的な更新を現実的なものにします。

オンボーディングに属人化チェックを組み込む

新しいメンバーが業務を引き継ぐタイミングは、属人化の実態が最も見えやすい瞬間でもあります。このタイミングを「チェックポイント」として設計に組み込むことで、属人化の早期発見と是正が習慣化されます。

たとえば、オンボーディング完了の条件として「引き継ぎ先のメンバーが既存ドキュメントだけで業務を再現できたか」を評価項目に含めます。再現できなかった箇所が即座にドキュメント更新タスクに変換される仕組みにすることで、引き継ぎが属人化解消の継続的な機会になります。

システム発注・構築時に属人化リスクを設計に反映させる視点

多くの企業が見落としているのが、システムを発注・構築する段階での属人化設計という視点です。業務フローやドキュメントの整備に意識が向く一方で、システム自体が属人化の温床になっているケースは少なくありません。

発注側の意思決定者が確認すべき観点として、以下が挙げられます。

• 権限設計の透明性：誰がどの操作を行えるかが明文化・可視化されているか。管理者アカウントが退職者に紐づいたままになっていないか
• ログ管理の設計：操作履歴や変更履歴が自動で残り、後から参照できる構造になっているか
• 運用引き継ぎの想定：ベンダーへの依存度が高すぎず、自社側で設定変更・運用対応ができる設計になっているか

システム構築の要件定義段階でこれらを明示的に盛り込まない限り、完成したシステムが新たな属人化の起点になります。CLANEがシステム開発支援に関わる際には、こうした属人化リスクを要件定義の段階から議論するアプローチを取っています。退職による属人化対策は、業務フローの整備と同時に、システム設計の見直しとセットで進めることが、再発を防ぐ上で不可欠です。

CLANEが支援した事例から見る——属人化解消の実際

属人化の解消は、方針を決めるだけでは進みません。実際には「誰が何を判断するか」「その根拠をどこに記録するか」という設計レベルの介入が必要です。CLANEが関与した2つの事例をもとに、具体的なアプローチを紹介します。

事例①：担当者退職を機に基幹業務の属人化を可視化——業務フロー整備とシステム権限再設計

ある流通系BtoB企業では、受発注管理システムの運用を長年1名の担当者が担っていました。その担当者の突然の退職が決まったことで、後任候補が業務を把握できていないことが発覚。引き継ぎ期間もわずか2週間しか確保できない状況でした。

CLANEが最初に着手したのは、業務フローの棚卸しです。担当者へのヒアリングを通じて、システム操作の手順だけでなく「どの条件のときに誰に確認するか」という判断分岐を可視化しました。その結果、社内ドキュメントには存在しなかった17件の例外処理ルールが確認されました。

次に行ったのが、システム権限の再設計です。それまで担当者1名に集中していた管理者権限を、業務ロール（役割）単位に分割し直しました。具体的には、マスタデータの編集・承認・閲覧の3段階に権限を分離し、それぞれの権限に対応する担当者と承認フローをドキュメントとして整備しました。権限設計とドキュメントを連動させることで、「誰がどこまで操作できるか」が後任者にも一目でわかる状態になっています。

退職後の3ヶ月間、後任担当者からのシステム関連の問い合わせは大幅に減少し、引き継ぎによる業務停滞もほぼ発生しませんでした。

事例②：引き継ぎ書が形骸化していた製造業のケース——判断ロジックの言語化と確認プロセス導入

中堅製造業の企業では、生産管理システムの担当者交代が定期的に発生しているにもかかわらず、そのたびに現場が混乱していました。引き継ぎ書は存在していましたが、内容は画面操作の手順書にとどまっており、「なぜその操作をするのか」「例外発生時にどう判断するか」が一切書かれていませんでした。

CLANEが課題として特定したのは、判断ロジックが言語化されていない点です。ベテラン担当者は経験則で判断していましたが、その根拠が引き継ぎ書に反映されていなかったため、後任者が同じ状況に直面しても対処できない状態が続いていました。

解決策として、CLANEは以下のアプローチを実施しました。

• 業務上の判断が発生するシーンを洗い出し、「条件・判断内容・根拠・確認先」の4項目でドキュメント化
• 例外発生時のエスカレーション先と確認フローを、システム上のアラート設定と連動させて整備
• 引き継ぎ完了の基準を「操作ができる」から「判断ができる」に再定義し、確認テストを導入

この対応により、担当者交代後の現場からの問い合わせ件数が従来比で約6割減少しました。引き継ぎ書の形骸化は、記載内容の問題ではなく「何を引き継ぐべきか」の定義が曖昧だったことが根本原因でした。

2つの事例に共通するのは、システム設計の段階で権限・ドキュメント・判断ロジックを一体として設計するアプローチです。属人化の解消は、ツールの導入や手順書の整備だけでは完結しません。「誰が何をどのように判断するか」という構造そのものを設計し直すことが、担当者交代リスクへの実効性ある対策になります。

まとめ——担当者退職を『属人化を直す機会』に変える

担当者の退職が組織に混乱をもたらすとき、その原因はほぼ例外なく属人化にあります。しかし、属人化は「その人が抱え込んでいた」という個人の問題ではありません。業務の可視化を怠り、ナレッジを共有する仕組みを持たず、システムのアクセス権や操作手順をドキュメント化してこなかった、組織設計・システム設計の問題です。

本記事では、次の論点を順に整理しました。

• 引き継ぎが機能しない組織に共通する欠陥——ドキュメント不在・属人的なツール管理・後継者育成の欠如など
• 属人化が生む損失——業務停止リスク、採用・教育コストの増大、意思決定の遅延
• 属人化を解消する4ステップ——業務の棚卸し・可視化・標準化・システムへの実装という順序の重要性
• 再発を防ぐ仕組みづくり——属人化は設計の問題であり、個人の善意や努力では根本解決しない

重要なのは、退職という出来事を「損害」として捉えるのではなく、組織の設計を見直す契機として活用することです。担当者が抜けてはじめて「何が属人化していたか」が可視化されます。この状況は、改善のための診断材料がそろった瞬間でもあります。

次の行動として着手すべき3点

1. 退職予定者（または直近の退職者）の業務を棚卸しする——担当業務・使用ツール・アクセス権・判断基準を一覧化することが起点になります。
2. 「誰かしか知らない情報」の所在を確認する——特定の人物に問い合わせが集中している領域は、次の属人化リスクが潜む場所です。優先的に標準化対象として特定してください。
3. 業務フローとシステムを連動させる設計に着手する——手順書だけでは形骸化しやすく、システムの構造として属人化を排除する設計が長期的に有効です。

属人化の解消は、一度対処すれば終わりではありません。組織が成長し、メンバーが入れ替わるたびに設計を見直す文化と仕組みを持つことが、担当者退職による業務引き継ぎの失敗を繰り返さない唯一の方法です。