アカウントは消したのに業務が止まる｜退職時の「権限の引き継ぎ」実務ガイド

なぜ引き継ぎだけ難しいのか

退職処理のツールは数多くありますが、そのほとんどが解決しているのは「閉める」側です。アカウントを止める、SaaS の席を解放する、デバイスを回収する。これらは比較的うまく自動化されています。

理由ははっきりしていて、遮断は本人の側から数えられるからです。誰を止めるかさえ決まれば、あとはアカウントを無効にすれば終わります。数えるべき対象は「その人ひとり」です。

ところが引き継ぎは逆向きの問題になります。退職者が触れていたグループ、ファイル、共有ドライブ、SaaS の席、承認者の役割をリソースの側から一つずつ数え上げ、そのうえで項目ごとに「誰が受け取るのか」を判断しなければなりません。数える対象は数十から数百に増え、しかも一つずつ人間の判断が要ります。

この非対称性が、多くのツールが遮断だけを提供している理由です。そして、退職の翌週に「あれが見られない」が続出する理由でもあります。

見落とされる5つの権限

実際に引き継ぎ漏れが起きやすいのは、次の5つです。いずれも「アカウントを消す」チェックリストには載っていません。

サービス別「どこまで渡せるか」

ここが実務で最も誤解されるところです。「引き継ぐ」という言葉は同じでも、サービスによって到達できる地点がまったく違います。各社の API 仕様を確認したうえで整理しました。

Google Workspace ― 唯一「移せる」

退職者が所有するファイルの所有権を、まとめて後任へ移す仕組みがあります。個別のファイルごとに渡す相手を変えることもできますが、こちらは権限設定の追加が必要になります。グループへの追加、受信箱の委任も可能で、4サービスの中では最も引き継ぎがしやすい構成です。

Microsoft 365 ― 「移す」のではなく「渡して動かしてもらう」

ここは Google と発想が違います。Microsoft のドキュメントが案内している退職者対応は、上長や後任が退職者の OneDrive にアクセスできるようにしたうえで、必要なファイルを自分の領域へ移動する、という流れです。所有者を付け替える操作ではありません。

実務上の影響は小さくありません。後任が移動を終えるまで、退職者のアカウントを止められないということです。Google と同じ感覚で「引き継いだから停止」と進めると、必要なファイルが取り出せなくなります。またアカウント削除後の OneDrive には保持期間があり、そこを過ぎると失われます。

Notion ― 担当者フィールドがあるかどうかで変わる

Notion のページには所有者という属性がありません。データベースのアイテムで「担当者」のような人物プロパティが設定されていれば、そこを後任に付け替えることで実質的な引き継ぎになります。一方、通常のページは共有設定を手動で変更するしかありません。「割り当てた」のに共有設定が変わっていないという誤解が起きやすいので、どちらの扱いになるかを分けて把握しておく必要があります。

Slack ― 引き継ぐのではなく、ゼロにする

Slack のチャンネルにもファイルにも所有者がいません。したがって「引き継ぐ」という操作は存在しません。現実的な目標は退職日までに所属をゼロにすることで、必要なチャンネルには後任を別途招待する、という進め方になります。

なお、非公開チャンネルは連携アプリが参加しているものしか把握できないため、確認できる数は実際より少なくなる可能性があります。また Workflow Builder の所有者を API から取得するには Enterprise プランが必要です。件数を見るときは、この2点を前提に置いてください。

実務の順番

引き継ぎの作業自体は、順番さえ守れば難しくありません。逆に、順番を間違えると取り返しがつかない箇所が一つだけあります。

まだ課金されている退職者

引き継ぎが途中で止まると、もう一つ見えにくい損失が発生します。退職者が保持したままの SaaS 席に、課金が続いているという状態です。

これは予算のどこにも計上されていない支出です。しかも退職処理が「完了」扱いになっていると、誰も気づきません。10名が退職して、1人あたり月3,000円分の席が残っていれば、年間で36万円になります。人数が増えれば当然その分だけ膨らみます。

裏を返せば、オフボーディングはやると支出が減る作業です。退職処理を「面倒な事務手続き」ではなく「解放した月額」と「まだ払っている月額」の2つの数字で見るようにすると、残作業を追いかける動機が生まれます。削除漏れそのものの防ぎ方は退職者のSaaSアカウント削除漏れを防ぐチェックリストに整理しています。

よくある質問

メールは転送設定をすれば引き継げますか？

転送は新しく届くメールだけを転送します。過去のやり取りは読めません。取引先との経緯を後任が追う必要がある場合は、転送ではなく受信箱そのものへの委任アクセスを設定します。委任はアカウントが有効なうちにしか設定できないため、停止より先に行う必要があります。

Microsoft 365 でもファイルの所有者を後任に変更できますか？

できません。Microsoft 365 には Google Workspace のような所有権移管の仕組みがなく、公式の手順は「後任にアクセス権を渡し、後任が必要なファイルを自分の OneDrive へ移動する」というものです。そのため、後任が移動を終えるまで退職者のアカウントを止められない点が Google と大きく異なります。

Slack のチャンネルやワークフローは引き継げますか？

Slack のチャンネルやファイルには所有者の概念がないため、引き継ぐという操作自体が存在しません。現実的な目標は「退職者の所属をゼロにする」ことです。なお Workflow Builder の所有者を API で取得するには Enterprise プランが必要です。

アカウント停止はいつ行うべきですか？

引き継ぎがすべて終わった後です。停止すると受信箱の委任は設定できなくなり、グループ経由で与えられていた権限も後任に渡せなくなります。ファイルが消えるわけではありませんが、所有者が停止済みアカウントのまま宙に浮きます。順番だけは後から取り返せません。

ツールを選ぶときに見るところ

退職処理のツールを比較するときは、「どのサービスを止められるか」だけでなく「引き継ぎ先を項目ごとに指定できるか」を見てください。1人にまとめて渡す方式しかないと、ファイルは部下に、案件は上長に、といった実際の分担に対応できません。

もう一つは、引き継ぎ先を提案してくれるかです。項目が数十あると、一つずつ人選するだけで作業が終わりません。部署・職種・上長といった組織情報を持っているツールであれば、「この権限は誰に渡すべきか」を既定値として出せます。人事データと同じ基盤で退職処理を扱う利点は、実はここにあります。製品ごとの違いはオフボーディング対応SaaS比較8選で整理しています。