「あの人が辞めたら、この業務は誰にもできなくなる」と分かっていながら、日々の業務に追われて引き継ぎに手をつけられずにいませんか。
退職の連絡は、会社にとって都合のよいタイミングで来るとは限りません。
人手不足で転職市場が動きやすくなったこの数年は、突然の退職の連絡を受けてから慌てて引き継ぎ資料を作る会社が増えています。
この記事では、退職という具体的なイベントを起点に、日頃から引き継ぎの土台を作っておく3層の仕組みと、退職の兆候が出てからの動き方を整理しています。
なお、属人化そのものをどの業務から解消していくかという優先順位づけは、別の記事で扱っています。
本記事は、退職イベントが実際に起きたとき、あるいは起きる前提で何を準備しておくかに絞って扱います。
引き継ぎが失敗する構造
引き継ぎが失敗する会社には共通する構造があります。
引き継ぎが口頭のメモと最終出社日前の数時間の説明だけで完結し、担当者の頭の中にある暗黙知が文字にも仕組みにも残らないまま退職を迎えることです。
退職者本人に悪意はなく、むしろ最後まで丁寧に説明しようとする人が大半ですが、数年分の経験を数時間で伝えきることは物理的に不可能です。
引き継ぎ資料を作る時間は、通常業務が忙しい退職直前の数週間にしか確保されません。
このタイミングでは、退職者は残務処理と有給消化の調整に追われ、後任は通常業務を覚えながら引き継ぎを受けるという二重の負担を抱えます。
結果として引き継ぎ資料は表面的な操作手順だけになり、例外処理や取引先ごとの調整といった経験に基づく判断は伝わらないまま業務が止まります。
暗黙知が多い業務ほど、この構造の影響を強く受けます。
判断の理由を担当者に聞いても、長年の勘としか答えられない業務は、短期間の説明では後任に移せません。
例えば、特定の取引先だけに適用している独自の値引きルールや、繁忙期だけ変える発送順序のような調整は、マニュアルに載らないまま担当者の判断に委ねられていることが少なくありません。
退職後に同じ調整ができず、取引先からの信頼を落として初めて、その業務が属人化していたことに会社が気づくケースもあります。
退職が決まってからでは遅い理由
退職の連絡を受けてから引き継ぎの仕組みを作り始めるのでは、時間的に間に合いません。
記録を自動化する仕組みや手順書のひな形を退職の連絡後に一から設計すると、設計と検証だけで数週間かかり、実際に引き継ぎに使える状態になる前に退職日を迎えます。
退職の申し出から最終出社日までの期間は、法律上の最短ルールでも1か月に満たないことがあり、この短い期間で仕組みそのものを作ることは現実的ではありません。
後任の採用や配置転換にも数週間から数か月を要するため、後任が決まらないまま退職日を迎え、既存の担当者が業務委託として一時的に対応を続ける会社も出てきます。
引き継ぎの土台は、退職の予定がまったくない平常時から作っておく必要があります。
土台さえできていれば、退職の連絡を受けた時点でやることは、すでにある仕組みへの追記と確認だけに絞れます。
逆に土台がない状態で退職の連絡を受けると、資料作成という重い作業を退職者と後任の両方に負わせることになり、双方の負担が引き継ぎの質を下げる悪循環に陥ります。
日頃から作る3層の仕組み
退職に備える土台は、記録の自動化、手順の文書化、複数人アクセスという3つの層で構成します。
この3層は独立した対策ではなく、記録が自動で残る状態を土台にして手順を文書化し、その手順とデータに複数人がアクセスできる状態を作るという積み上げの関係にあります。
どれか1つだけを整えても、残り2層が欠けていれば引き継ぎは機能しません。
記録の自動化
記録の自動化とは、担当者が意識して書き残さなくても、業務の実行内容がシステム上に自動で残る状態を作ることです。
メールでのやり取りや電話での確認内容を担当者個人の記憶やメモ帳に依存させず、業務システムやワークフローツールのログとして残せば、担当者が変わっても過去の経緯を追えます。
例えば、取引先からの問い合わせ対応をスプレッドシートやチケット管理ツールに記録する仕組みを組んでおくと、担当者が退職しても過去の対応履歴を後任がそのまま参照できます。
記録が担当者の頭の中だけにある状態から、記録がシステム上に残る状態に変わるだけで、引き継ぎで失われる情報量は大きく減ります。
記録の粒度は、後任が過去の対応を見て同じ判断を再現できるかを基準に決めます。
対応した日時と相手、実施した処理の3点さえ残っていれば、担当者に聞かなくても大半の経緯は追えます。
手順の文書化
手順の文書化は、業務の流れと判断基準を言葉として残す作業です。
記録の自動化だけでは、何のためにその操作をしているかという目的や、例外が起きたときにどう判断するかまでは残りません。
手順書には、通常時の操作手順に加えて、過去に実際に発生した例外とそのときの対応をセットで書いておくと、後任が同じ状況に遭遇したときに参照できます。
文書化した手順とナレッジをどこに集約し、どう検索できる形にするかという基盤の作り方は、以下の記事で扱っています。
複数人アクセス
複数人アクセスとは、業務に必要なデータやツールへのアクセス権限を、担当者1人だけでなく複数人が持てる状態にしておくことです。
担当者しかログインできないアカウントや、担当者個人のパソコンにしか保存されていないファイルがある業務は、退職と同時にその業務そのものが止まります。
権限やアカウントの持ち方は、社内で使っているシステムを移行するタイミングでも見直しの機会になります。
例えば、Google WorkspaceからMicrosoft 365へ基盤ツールを切り替える場面を考えます。
このとき、個人アカウントに紐づいた自動化の仕組みを、組織アカウントベースに作り直す作業が発生します。
この作業は手間がかかる一方で、複数人アクセスを実現する好機でもあります。
退職の兆候が出たときの優先度判定
3層すべてを全業務に一律で整備する余力がある会社は多くありません。
どの業務から手をつけるかは、業務の発生頻度と退職までに残された猶予期間の組み合わせで判断します。
| 象限 | 業務の発生頻度 | 退職までの猶予 | 優先度と打つ手 |
|---|---|---|---|
| 象限1 | 高い（毎日〜毎週） | 短い（1か月未満） | 最優先。聞き取りと記録の自動化を同時に進める |
| 象限2 | 高い（毎日〜毎週） | 長い（3か月以上） | 優先。記録の自動化から順番に3層を整備する |
| 象限3 | 低い（月次・年次） | 短い | 発生する場面だけ聞き取り、簡易メモを残す |
| 象限4 | 低い（月次・年次） | 長い | 通常のペースで手順の文書化を進める |
象限1に該当する業務は、退職までの猶予が短いにもかかわらず日々の発生頻度が高いため、放置すると引き継ぎ不全が即座に業務停止につながります。
この象限では、3層をゼロから作る時間はないため、担当者への聞き取りを最優先に行いながら、聞き取った内容を記録として残す仕組みを並行して作ります。
象限2から象限4は、猶予期間に応じて記録の自動化から手順の文書化へと順番に進める通常の進め方で対応できます。
例えば、経理担当者が1人で経費精算から支払処理まで担っている会社では、この業務は発生頻度が高く象限1か象限2に入りやすい典型例です。
退職の予定がまだない段階で象限2として記録の自動化に着手しておけば、実際に退職の連絡が来た時点で象限1相当の緊急対応に切り替える必要がなくなります。
引き継ぎの進め方
3層の判定ができたら、実際の引き継ぎ作業を次の順番で進めます。
順番が決まっているのは、記録が残っていない状態で手順書だけを先に作っても、書くべき内容が担当者の記憶頼りになり、聞き取りの負担が退職直前に集中するからです。
記録の自動化を土台に置き、その上に手順の棚卸しと権限移譲を重ね、最後に後任が1人で実行できるかで完了を判定します。
こうすると、各段階の作業が前の段階の成果をそのまま使えるため、短い猶予期間でも手戻りが減ります。
Step1. 退職の有無に関わらず記録の自動化から着手する
退職者が出ていない平常時から、業務の実行記録がシステム上に自動で残る仕組みを整えます。
先に記録が残る状態を作っておくことで、退職の連絡を受けた時点で手順書に書くべき内容がすでに揃っている状態になります。
Step2. 退職の連絡を受けたら手順を棚卸しする
退職の連絡を受けたら、既存の記録をもとに手順書の内容が現状の業務と一致しているかを確認します。
記録が残っていれば、この棚卸しは更新作業だけで済み、短い猶予期間でも対応できます。
棚卸しの際は、記録に残っていない判断だけを担当者に個別で確認し、確認事項を絞ることで短時間の聞き取りでも抜け漏れを減らせます。
Step3. 権限移譲は退職前に完了させる
業務に必要なアカウントや権限の移譲は、退職の連絡を受けた早い段階で完了させます。
最終出社日にまとめて実施しようとすると、パスワードの確認や権限申請の承認待ちが重なり、退職日までに完了しない事態が起こります。
移譲の対象は、業務システムのログインアカウントだけでなく、取引先とのやり取りに使っている個人端末のアプリやクラウドストレージのフォルダも含めて洗い出します。
Step4. 引き継ぎ完了の基準を後任と合意する
引き継ぎが完了したかどうかを、後任が実際に1人でその業務を実行できるかという基準で確認します。
説明を受けただけの状態と、実際に手を動かして完了できる状態は別物であり、後任に実際にやらせてみて初めて引き継ぎの抜け漏れが見つかります。
基準を事前に決めずに引き継ぎを進めると、退職者は主観で完了と判断し、後任は不安を抱えたまま業務を任されるという認識のずれが残ります。
担当者の退職に備えた引き継ぎ体制について相談してみませんか？
「急な退職の連絡が来て何から手をつければいいか分からない」「引き継ぎ資料を作る時間が確保できない」「退職者しか知らない業務がどれだけあるか把握できていない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、退職を起点にした業務の引き継ぎに関するお悩みをお伺いする 無料の個別相談 を実施しています。
よくある質問
Q. 退職の連絡を受けてからでは、もう手遅れですか？
手遅れではありません。
ただし、記録の自動化や手順書のひな形作りといった土台部分は退職の連絡後には間に合わないため、その場合は担当者への聞き取りを最優先にして対応します。
聞き取った内容をその場で記録として残しておけば、次の退職からは同じ苦労を繰り返さずに済みます。
Q. 小規模な会社でも3層すべてを整備する必要がありますか？
必要です。
ただし小規模な会社では人員に余裕がないため、判定基準表の象限1に該当する業務から1件ずつ着手し、無理に全業務を一度に対象にしない進め方が現実的です。
Q. 手順書を作っても更新されなくなるのを防ぐにはどうすればいいですか？
更新のきっかけを、業務の担当者が変わったとき、システムの画面が変わったときのように具体的な出来事で決めておきます。
記録が自動化されていれば、更新の判断材料は担当者の記憶に頼らず記録として残るため、更新漏れに気づきやすくなります。
Q. 権限移譲は退職者本人に任せてよいですか？
任せきりにはしないほうが安全です。
退職者本人による移譲だけに頼ると、忙しさで対応が後回しになったり、移譲漏れのアカウントが残ったりする可能性があるため、後任か管理者が移譲状況を最終出社日前に確認する工程を挟みます。
Q. 複数人アクセスにすると情報漏洩のリスクは上がりませんか？
アクセスできる人数を増やすことと、誰でも見られる状態にすることは別です。
複数人アクセスは、業務に必要な範囲の担当者や管理者に限定して権限を付与する設計であり、無制限に公開する仕組みではありません。
誰がどの範囲にアクセスできるかを一覧化しておけば、退職や異動のたびに権限設定を見直す際の判断も速くなります。
Q. 退職者と関係が悪化していて聞き取りが難しい場合はどうすればいいですか？
聞き取りに頼れない前提で、既存の記録とシステムのログだけから業務を再現できるかを確認します。
記録の自動化が整っていれば聞き取りへの依存度は下がりますが、整っていない場合は退職者本人ではなく周囲の関係者や取引先への確認で情報を補う方法も検討します。
