退職者の引き継ぎで最初に棚卸しするものは何ですか？

顧客、進行案件、定例・例外業務、承認役割、データ、アカウント、連携、端末・鍵・書類を所有単位で並べる。ツール一覧だけでなく、退職者が判断していた仕事を拾う。

引き継ぎ完了は誰が判断しますか？

退職者の提出だけで完了にせず、後任の受諾と業務責任者の確認を必要にする。アクセスできる、次回行動を説明できる、承認権限が正しい、顧客への案内が済んだことを対象別に確認する。

アカウント停止はいつ行いますか？

会社の情報セキュリティ方針と雇用・契約条件に基づき、人事、業務、ITの責任者が停止時点を決める。一律の法的期限をこの記事では示さず、事前に一覧と実行順を承認して記録する。

退職者の業務引き継ぎ設計｜顧客・案件・アカウント・資産の所有者を移す

退職日までに貸与端末を返却し、メールを止めても、業務は引き継がれない。顧客との約束、止まっている案件、月に一度だけ行う処理、個人が管理者になったSaaS、共有されていないデータが残れば、退職後に社長や管理職が探索することになる。

この記事は退職に伴う会社全体の所有権移転を扱う。AIや内製ツールの保守継続はAIツールの引き継ぎリスク、社内ツールと管理者の棚卸しは内製ツール棚卸しで詳しく扱う。ここでは顧客・案件・業務・アカウント・資産を一つの退職台帳でつなぐ。

退職チェックリストを所有権移転台帳へ変える

一般的なチェックリストは、書類提出、端末返却、アカウント停止など管理部門の作業が中心になりやすい。必要なのは「誰が持っていたか」だけでなく、「誰が次に持つか」「後任が受け取れたか」を対象ごとに記録することだ。

移転対象	引き継ぐ内容
顧客・取引先	窓口、約束、注意事項、次回連絡、後任案内
案件・見積・契約	現在工程、未決事項、期限、決定者、関連文書
定例・例外業務	発生条件、入力、判断基準、完了、代行者
アカウント・権限	利用目的、管理者、認証経路、共有・個人、停止方法
データ・連携	保管場所、所有者、共有範囲、自動処理、出力先
物理資産	端末、記録媒体、鍵、カード、原本、保管物

一件ごとに、現所有者、後任候補、業務責任者、移転方法、期限、受諾日、確認結果を持つ。後任が決まらない場合は空欄にせず、部門責任者を暫定所有者にし、採用や配置の判断へ上げる。

人名から探さず業務の入口から棚卸しする

本人への聞き取りだけでは、無意識に行っている確認や例外処理が抜ける。カレンダー、メールの宛先、顧客・案件台帳、承認経路、共有フォルダ、請求・入出金、利用サービス、貸与品台帳など複数の入口から照合する。

毎日・毎週・毎月・四半期・年次に繰り返す作業
特定の条件でだけ発生するクレーム、取消、返金、障害対応
本人だけが承認者、管理者、通知先になっているもの
個人メールや端末へ通知・認証が届く業務
顧客や協力会社が本人へ直接依頼している仕事
自動化され、普段は意識されない連携や定期処理

「担当業務一覧を出してください」だけでは粒度がそろわない。発生条件、入力、判断、出力、完了、例外、関連する相手を共通項目にし、別の人が実行できる単位へ分ける。

顧客と案件は次回行動まで移す

項目	後任が確認すること
関係者	顧客窓口、社内責任者、協力会社、決定者
現在地	案件工程、合意済み事項、未決事項、停止理由
約束	提出物、回答、日付、期待値、注意事項
次回行動	誰が、誰へ、何を、いつ行うか
原本	契約、見積、議事録、連絡履歴、成果物の場所

顧客名と連絡先だけ渡しても、後任は過去の約束を知らない。退職者、後任、業務責任者で案件ごとの短い確認を行い、後任が次回行動を自分の言葉で説明できることを受諾条件にする。顧客への担当変更案内も、送信者、送信日、相手の確認を記録する。

アカウントは停止だけでなく管理権限を移す

退職者の利用権限を無効化しても、その人が唯一の管理者、請求連絡先、外部連携の所有者なら業務が止まる。利用者アカウント、管理者権限、請求、ドメイン、API・自動処理、回復手段、通知先を分けて確認する。パスワードを引き継ぐのではなく、会社の正規手順で所有者と権限を変更する。

利用サービスと業務目的を特定する。
個人用、共有用、機械用のアカウントを区別する。
後任管理者を追加し、必要な操作を確認する。
連携、通知、請求、回復先を会社管理へ移す。
承認済みの時点で退職者権限を無効化する。
ログや設定で実行結果を確認し、例外を記録する。

具体的な停止時点と保管方法は、自社の情報セキュリティ方針、契約、業務影響に基づいて決める。IPAは中小企業向けに情報セキュリティ対策のガイドラインと実践資料を公開している（公式ページ）。最新資料を確認し、自社の責任者が手順を承認する。

権限の削除とデータの移転を別工程にする

早く権限を消すことだけを優先すると、個人領域にある必要データへアクセスできなくなる。逆にデータ移転を待って権限を残し続けると、不要なアクセスが継続する。対象ごとに移転、確認、停止の順を決め、例外承認を記録する。

会社が保持すべきデータと、保持してはいけない私的情報を区別する
共有先、後任所有者、保管期間を会社の規程で確認する
ファイル名だけでなく検索できる顧客・案件IDを付ける
自動処理が個人フォルダや個人アカウントを参照していないか調べる
移転後に後任が閲覧・更新・出力できるか確認する
不要権限の無効化を別の確認者が照合する

権限の残存を日常運用から防ぐ設計は社内ツールの権限漏れ対策も参考になる。退職時だけでなく異動、兼務終了、外注契約終了にも同じ所有権移転の考え方を使う。

引き継ぎ資料は判断例を中心にする

操作手順だけでは、通常と違う依頼が来たときに後任が止まる。よくある判断、判断に必要な情報、誰へ確認するか、してはいけない処理、過去の例外を記録する。画面のスクリーンショットだけに頼らず、業務の目的と完了条件を先に書く。

確認段階	合格条件
説明	後任が目的、入力、判断、完了を説明できる
実行	後任が実データまたは安全な例で一巡できる
例外	迷った場合の停止条件と相談先が分かる
受諾	後任と責任者が未解決事項を認識して引き受ける

退職日当日と退職後の確認を分ける

当日は本人確認が必要な返却、権限、連絡先を中心にし、退職後は自動転送、定期処理、顧客からの連絡、請求通知など残存を確認する。退職後の監視期間を一律に決めるのではなく、業務周期と次回発生日を台帳に記録する。

当日：貸与資産、認証手段、権限変更、後任窓口を照合する
次回業務日：後任が定例を実行し、通知と承認経路を確認する
次回月次・季節業務：低頻度の処理が個人依存していないか確認する
残存発見時：対象、影響、暫定所有者、恒久対応を台帳へ戻す

担当変更を組織の設計データに変える

毎回同じ種類の抜けが出るなら、退職者の責任ではなく日常の台帳が不足している。顧客や案件に次回行動がない、SaaSに副管理者がいない、定例業務に代行者がいない、資産台帳と利用者が一致しない、といった問題を通常運用へ戻す。

引き継ぎ状況を本人だけに報告させず、対象別の受諾率と未解決理由を見る。後任未定、権限準備待ち、顧客確認待ち、資料不足、専門判断待ちを分け、退職日までに解けないものは暫定所有者と次回行動を置く。「未完了だが誰が持つかは決まっている」状態と、誰も持たない状態を区別する。

急な退職や長期不在にも同じ台帳を使えるよう、平時から顧客・案件・業務に主担当と代行者を持たせる。すべてを二人で作業する必要はないが、保管場所、管理者、次回発生日、停止条件を責任者が見られる状態にする。退職が決まってからゼロから棚卸しするのではなく、日常の所有者台帳を退職工程で確認する形が理想だ。

退職予定を起点に対象者と業務責任者を確定する。
複数の入口から所有物を棚卸しし、後任候補を置く。
顧客・案件、業務、アカウント、データ、資産の順に移す。
後任の受諾と責任者の確認を対象ごとに記録する。
残存した個人依存を日常の管理台帳へ反映する。

オフボーディングの目的は、退職者を締め出すことではなく、会社が担うべき顧客との約束、判断、データ、資産の所有者を切れ目なく移すことだ。所有者不在を一覧で見つけられれば、社長が退職後に一件ずつ思い出して割り振る状態を防げる。