社員が退職したら、アカウントと仕事はどうなる？

誰かが退職するときは、アクセス権を停止する担当者と、未完了の仕事を引き継ぐ担当者を決めてください。この二つは別々に確認が必要です。アカウントを削除しても、翌日の顧客問い合わせが適切な人に届くか、同僚が共有レポートを更新できるかは分かりません。

まず、続ける必要がある仕事を確認する

顧客からの問い合わせに対応し、週次レポートを作成する同僚を想像してください。予定された退職の前に、マネージャーは未対応の問い合わせ、次回レポートの期限、引き継ぐ人を確認します。後任者は、自分に付与された正規のアカウントで必要な業務にアクセスします。

どの仕事に新しい担当者が必要かはマネージャーが決めます。人事部門などが、承認された時期や関連する制約を確認します。各システムの担当者は、アクセス権の変更方法や必要な資料を保持・移管する方法を決めます。小さな会社では一人が複数の役割を担う場合もあります。その場合も、決定事項を明確にしてください。

セキュリティ上、緊急の対応が必要な場合は、組織で承認された手順に従ってください。引き継ぎを整えるために、リスクの封じ込めを遅らせてはいけません。

アクセス権の停止と仕事の引き継ぎは別の作業

サインインのブロック、アカウントの削除、記録の保全、他の人へのアクセス付与では、それぞれ結果が異なります。必要な結果、サービスの仕様、状況に合わせて、操作と順序を決めてください。

たとえば Microsoft の退職者向けガイダンスでは、サインインの防止、メールボックス資料の保全、メールの継続、後任者のアクセス、ライセンス、削除を別々に扱っています。これは Microsoft 365 の手順です。「ユーザーを削除する」という一言だけでは大切な決定が抜けてしまう理由が分かります。

顧客問い合わせについては、後任者が必要とするやり取りと、新しい問い合わせの転送先を決めます。レポートについては、保存場所、担当者、更新に退職者のアカウントがまだ必要かを確認します。初めからメールボックス全体をコピーするのは避けてください。プライバシー、保存期間、調査、雇用上の義務が判断に関わる場合、担当者は実際の状況に応じた助言を受けてください。

一元ログインに連携するサービスも確認する

一元ログインはアクセス管理に役立ちますが、これを無効にしたとき、関連する各サービスで何が変わるか確認してください。アプリによっては別に管理するアカウントがあります。既存のセッション、アクセストークン、自動処理を使っている場合は、システム担当者に確認しましょう。適切な操作はサービスによって異なります。

英国の国家サイバーセキュリティセンター（NCSC）のSaaSを安全に利用するためのガイダンスは、社内外のユーザーのライフサイクル、管理されたIDソース、可能な場合の自動化を扱っています。直接認証を使うアプリについても触れています。これを参考に実際のアプリを確認し、一度のログイン設定変更ですべて解決すると考えないでください。

確認できる簡潔な記録を残す

関連する各サービスについて、担当者、アクセス権の操作、必要な業務の承認済みの引き継ぎ先、実施時期、完了を示す証拠を記録します。未解決の決定事項と、その解決担当者も記載してください。パスワードなどの認証情報は記録に含めないでください。

GitLab が公開する退職手続きハンドブックでは、人事オペレーションの調整、マネージャーによる引き継ぎの話し合い、システムアクセスの担当を分けています。完了記録では、アクセス権を削除したことと、そもそもアクセス権がなかったことの確認も区別しています。ツールや期限は GitLab 固有のものです。ここで参考になるのは、各項目を誰が確認するか明確にすることです。

各システム担当者に、合意した変更を示す管理上の証拠を求めます。その後、後任者本人が自分のアカウントで通常の作業を行います。たとえば割り当てられた問い合わせを探したり、レポートを開いて更新したりします。退職者になりすましてサインインしたり、パスワードを共有したりして確認してはいけません。

人事情報の更新や自動処理の完了は参考になりますが、それだけですべてのアプリの状態が確認できるわけではありません。担当者が確認するまで、未解決の項目を見える状態にしておきます。

既存システムでは担当者やアクセス権の整理が難しい場合、そのシステムと引き継ぎたい業務についてご相談いただけます。サービスでは、ソフトウェア、インフラ、メールを扱っており、具体的な範囲は状況に合わせて合意します。

アカウントと引き継ぎに関する質問