「以前退職した人がまだ社内のシステムにアクセスしているようです」 ヒヤリとする報告ですが、実際のご相談の場ではそこそこの頻度で遭遇します。
退職対応（オフボーディング）は、日々の業務の中で突発的に発生し、期限が厳格で、抜け漏れがそのままセキュリティリスクになる業務です。 それにもかかわらず、多くの会社では「その都度思い出しながらやる」運用になっています。
退職対応の難しさというと、消し忘れをどう防ぐかという技術的な話に聞こえるかもしれません。 たしかに、無効化や削除の操作そのものは難しくありません。 しかし実際にご支援していると、崩れるのは操作よりも、その手前の「誰が、いつ、何を知るか」という体制であることのほうが多いのです。
退職の連絡を受けた瞬間に、次にやることがすでに決まっている体制に近づくには、何から手をつければよいのでしょうか。
退職対応が事故りやすい理由
原因の多くは、退職が決まってから情シスに話が来るまでの遅さにあります。 退職の情報が人事から情シスに届くのは、最終出社日の直前、あるいは当日ということも珍しくありません。 準備の時間がないまま、対応だけが始まります。
連絡が来たとしても、今度は消すべきものの全量がわかりません。 アカウント台帳がなければ、この人が何を使っていたかを記憶と推測で洗い出すことになります。 貴社の台帳が最新の状態でなければ、この棚卸しは退職者が出るたびにゼロからのやり直しになります。
貸与物の回収も、同じように曖昧になりがちです。 PCは返却されていても、スマホのSIMやセキュリティキー、社外倉庫の入館証だけが手元に残っている、というパターンはよく見かけます。
そして、データを後任に引き継ぐのか、消してよいのかの区別が決まっていないと、アカウントは「とりあえず残す」対象になります。 この「とりあえず」が、数ヶ月続きがちです。
3つの時点で組み立てるタイムライン
オフボーディングは、「退職の連絡を受けた日」「最終出社日」「退職日以降」という3つの時点に分けると、設計しやすくなります。
退職の連絡を受けたら、できれば2週間以上前の時点で動き出したいところです。 やることは主に3つあります。 アカウント台帳から対象者が利用しているサービスや権限の一覧を出し、データの引き継ぎ先と保管期間を上長と決めます。 貸与物の一覧は端末台帳から出し、回収日を本人と合意しておきます。 管理者権限や共有アカウントのパスワードを本人が知っている場合も、ここで変更対象に加えておきましょう。
次に、最終出社日には、貸与物を回収して台帳のステータスを更新し、アカウントを無効化します。 ここで、即座に削除まではしません。 退職直後に消してしまうと、あとから引き継ぎ漏れに気づいても取り返しがつかないからです。 無効化にとどめておけば、必要になったときにデータを確認する余地が残ります。 私物スマホのメール設定など、業務データの削除（アカウント削除・選択的ワイプ）が必要な端末の処理も、この日のうちに済ませます。
最後に、退職日以降は、メールの転送やデータの引き継ぎを設定していた場合、期限を30〜90日など具体的に決めて解除します。 保管期間が過ぎたアカウントとデータは削除し、ライセンスも回収します。 共有アカウントやWi-Fi、VPNなど、本人以外も知り得た認証情報も、あわせて変更しておきましょう。 これらは退職者本人も知っている共有の認証情報であり、本人のアカウントを無効化しただけでは締め出せません。
この3つの時点でやるべきことを一枚にまとめたものが、退職対応のチェックリストです。
人事と情シスの連携を仕組みにする
チェックリストがあっても、起点の連絡が来なければ動けません。 まず決めておきたいのは連絡期限のルールで、「退職が確定したら、人事は◯営業日以内に情シスへ連絡する」を社内ルールにしておきます。 ◯の部分は、貴社の体制に合わせて具体的な日数に決めておきましょう。 逆に情シス側も「連絡を受けてからやることリスト」を人事に見せておくと、なぜ早い連絡が必要なのかが伝わりやすくなります。
ただ、ルールを決めただけでは、連絡は担当者の記憶と善意に頼ったままです。 人事の繁忙期や担当の交代が重なると、連絡が漏れやすくなります。 そこで、連絡そのものを人の運用ではなく、システムの流れに載せます。 ワークフローシステムや人事労務システムを使っているなら、退職手続きのフローに「情シスへの通知」を組み込み、退職の起票と同時に、情シス側へ通知が届き対応のタスクが起票される形にします。 専用のシステムがなければ、Slackのワークフローや申請フォームから始めても構いません。 目指すのは、人事が連絡を「覚えておく」必要のない状態です。
チェックリストも同じで、手元の手順書のままでは、やり終えたかどうかが残りません。 退職対応のチェックリストは人事と情シスで共有するフォーマットにし、退職者ごとに起票して、項目ごとの完了記録が残る形にします。 この記録は、ISMS（情報セキュリティマネジメントシステム）や監査で見せられる証跡になります。
自動化の入り口
連絡と起票の流れが固まれば、その先にある実作業の一部も自動化できます。 ただし、自動化の効きやすさを左右する土台は、一つではありません。
土台のひとつは、IDの一元化です。 Entra ID や Google Workspace にSSO（シングルサインオン）を寄せてあれば、本体アカウントを無効化するだけで、ぶら下がるほぼ全てのSaaSへのアクセスも同時に止まります。 SaaSごとに個別のアカウントが残っていると、この一括の無効化はできません。
もうひとつの土台が、権限の持たせ方です。 権限を個人ではなくグループに付与しておけば、グループから外すだけで権限をまとめて外せます。
この二つの土台があれば、退職日を起点にした無効化の自動実行も組みやすくなります。 人事システムやスプレッドシート上の退職日をトリガーに、アカウント無効化を自動で走らせる仕組みは、スクリプトやiPaaS（複数のクラウドサービスをつなぐ連携基盤）で比較的簡単に組めます。
オフボーディングの質を決めるもの
退職者のアカウントが「まだ生きていました」と言われる事態は、平時の備えがあれば起こりにくくなります。 オフボーディングの質は、平時に整えた台帳とルールで決まります。 退職が発生してからの頑張りに頼る場面は、そのぶん減ります。
「台帳から対象一覧が出せる」「人事からの連絡ルールがある」「チェックリストで記録が残る」。 この3点が揃っていれば、退職のたびに慌ただしくなる場面は減らせます。
前提となる台帳の整備は、3つの台帳の記事にまとめています。 入退社フローの整備からお手伝いしてほしいという方は、情シス伴走支援のページをご覧ください。 入退社にともなうPCやアカウントの手配は、日常的にご支援している領域です。