部署ごとにバラバラな退職者アカウント削除フローを統一する方法

営業部の退職者はメールと社用スマホだけ止めればいい。開発部の退職者はそれに加えて、GitHubやサーバーのアクセス権も止めなければならない。経理部の退職者は会計ソフトの権限も忘れずに——。部署が3つ、4つと分かれてきた30人未満の会社では、退職者アカウントの削除が「各部署の責任者がそれぞれ自分の判断で対応する」という、暗黙のフローに落ち着いていることがよくあります。誰かが意図的にそう決めたわけではなく、部署が増えるたびに自然発生的にそうなってしまった、という会社がほとんどです。

この状態は、10人未満の会社であれば大きな問題になりません。社長や総務担当が全アカウントを把握しているため、退職の連絡を受ければ、その場で頭の中にあるチェックリストに沿って一通り対応できます。しかし部署が分かれ、それぞれが独自にツールを契約するようになると、状況は一変します。総務が把握しているのは全社共通のメールと勤怠システムだけで、各部署が個別に契約しているSaaSやクラウドサービスは、総務の目が届かない場所で運用されています。退職の連絡が来たとき、「誰が」「何を」「いつまでに」削除すべきかを一元的に把握している人がいない状態です。

このガイドでは、退職者アカウント削除の個別チェックリストそのものではなく、部署ごとにバラバラになった削除フローを「誰が最終的に確認するか」という連携の一本化によって統一する方法を解説します。個々のアカウント削除の手順や具体的なチェック項目は退職者アカウントの削除漏れを防ぐチェックリストで詳しく扱っているため、このガイドでは、そのチェックリストを「複数部署にまたがる組織でどう機能させるか」という一段上の仕組みに焦点を当てます。

10人未満の会社であれば、退職者対応は社長や総務担当が1人で完結できる作業でした。しかし部署が生まれ、それぞれの部署が独自の判断で業務を進めるようになると、退職者対応もまた「各部署が自分たちの範囲で対応する」という分散した形に変わっていきます。この変化自体は組織の成長に伴う自然な流れですが、対応が分散しているにもかかわらず、それを俯瞰して見る役割が誰にも割り当てられていない状態が、削除漏れという実害を生みます。

なぜ「部署任せ」だと必ず漏れるのか

部署ごとに退職者対応を任せる運用が破綻しやすい理由は、単純な構造にあります。それは、各部署の責任者が「自分の部署が契約したツールのことしか把握していない」という前提そのものにあります。

例えば、開発部のリーダーが退職者のアクセス権限を止める際、頭にあるのは自部署で契約したクラウドサーバーやソースコード管理ツールだけです。その退職者が全社共通の経費精算システムで承認者権限を持っていたことや、営業部が契約した名刺管理ツールに個人アカウントで招待されていたことまでは、開発部のリーダーの視界に入りません。逆もまた同様で、総務が把握しているのは全社共通システムだけで、各部署のローカルなツール群は見えていません。

この「誰も全体像を把握していない」状態こそが、部署任せの運用が漏れを生む根本原因です。個々の部署責任者がどれだけ真面目に自分の担当範囲を確認しても、そもそも担当範囲の外にあるアカウントの存在を知らなければ、確認のしようがありません。

部署任せの退職者対応で起きる漏れは、担当者の怠慢ではなく「誰も全体を見ていない」という設計上の欠陥から生まれます。個人の注意力を上げても解決しません。

さらに厄介なのが、退職の連絡が複数の経路から個別に伝わることです。人事から総務へ、総務から各部署へ、あるいは部署の責任者が個人的に本人から直接聞いて対応を始めるなど、情報の伝達経路が一本化されていないと、「誰かが対応しているだろう」という思い込みのもと、実際には誰も対応していないアカウントが発生します。

解決の方向性: 「削除の実行」ではなく「削除の連携先」を一本化する

部署ごとにバラバラな削除フローを統一しようとするとき、多くの会社が「全アカウントの削除作業を総務や情シスが一手に引き受ける」という方向に進みがちです。しかし、これは30人未満の兼務担当者にとって現実的ではありません。各部署が個別に契約しているツールの管理画面の操作方法まで、総務担当が把握し続けるのは負荷が大きすぎます。

このガイドで提案するのは、削除の「実行」は引き続き各部署の担当者に委ねながら、削除の「連携先」だけを一本化するという方向性です。つまり、「退職が決まったら、まずどこに連絡が集まるか」という入口を1つに固定し、そこから各部署への削除依頼を漏れなく振り分ける仕組みを作ります。実行は分散、把握と指示は集約という役割分担です。

具体的には、次の3つの要素で構成します。

1. 退職連絡の一本化: 人事・上司・本人からの退職連絡は、必ず総務（または情シス兼務者）の1箇所に集約する
2. 部署横断のアカウント一覧: 各部署が契約しているツールを事前に一覧化しておき、退職者ごとに「どの部署のどのツールに影響するか」を機械的に洗い出せるようにする
3. 削除依頼の可視化: 総務から各部署の担当者へ削除を依頼し、完了報告までを記録に残す

この3要素が揃って初めて、「部署任せ」から「部署横断で把握された上での分担」に変わります。

部署任せの運用が具体的にどう失敗するか、シナリオで見る

抽象的な説明だけでは、この問題の深刻さが伝わりにくいかもしれません。ここで、実際に起こりがちなシナリオを1つ示します。

営業部のAさんが退職することになりました。人事担当は退職手続きと最終出社日の調整を進め、直属の上司である営業部長には退職の連絡をしています。営業部長は、Aさんが使っていた社用スマートフォンの回収と、営業部内で共有しているCRMツールのアカウント削除を自分の責任範囲だと考え、最終出社日に対応を済ませました。

一方、総務はAさんの退職を人事から聞いてはいたものの、「営業部の中で完結する話だろう」と考え、深く関与しませんでした。しかし実際には、Aさんは入社時に全社共通のグループウェアの承認者権限を持っており、また、以前一時的に手伝っていた経理部の請求書発行システムにも、部署異動が正式に記録されないまま個人アカウントでアクセスできる状態が残っていました。営業部長はこの2つの存在を知らず、削除の対象にすら含まれませんでした。

数ヶ月後、経理部の棚卸しで請求書発行システムのアカウント一覧を確認したところ、退職済みのはずのAさんのアカウントがアクティブなまま残っていることが発覚します。誰も悪意を持って放置したわけではなく、「自分の部署の範囲では対応した」という部分最適の積み重ねが、全体としての漏れを生んだ典型例です。

このシナリオが示しているのは、個々の部署責任者の対応そのものは決して間違っていなかったという点です。問題は、誰も「Aさんが全社でどこにアクセスできたか」という全体像を把握していなかったことにあります。

ステップ1: 退職連絡の入口を1箇所に固定する

最初に取り組むべきは、退職の情報が最初にどこへ届くかを1箇所に固定することです。30人未満の会社では、退職の連絡が人事、直属の上司、時には本人から総務へ直接、といった複数の経路でバラバラに伝わりがちです。経路が複数あること自体は問題ではありませんが、「最終的に必ずここへ集約される」という1つのゴールが決まっていないと、伝達漏れが起きます。

現実的な進め方は、退職の意思確認や退職日の確定といった人事的なプロセスの中に、「総務（アカウント管理担当）への通知」を必須ステップとして組み込むことです。退職届の提出フローや、労務手続きのチェックリストに「アカウント削除担当への連絡」を1行加えるだけでも、伝達漏れは大きく減ります。人事労務の手続きと、アカウント削除の手続きを別々の担当者が別々のタイミングで動かしていると、どうしても情報の受け渡しにタイムラグや抜けが生じます。

このとき重要なのは、「退職が決まった時点」で連絡が来るようにすることです。最終出社日になってから連絡が来るのでは、削除作業の準備期間がほとんど取れません。退職の意思確認から最終出社日までの間に、削除すべきアカウントの洗い出しと各部署への依頼を済ませておくのが理想です。

ステップ2: 部署横断のアカウント一覧を事前に整備する

退職連絡の入口を一本化しても、総務側に「その退職者がどの部署のどのツールに関わっていたか」を把握する材料がなければ、結局は各部署に「何か止めるものはありませんか」と個別に聞いて回ることになります。これでは部署任せの状態とあまり変わりません。

ここで必要になるのが、部署ごとに契約しているツールを横断的に一覧化した台帳です。システム管理台帳の考え方を、退職者対応に特化した形で応用します。台帳に最低限含めるべき項目は次の通りです。

この一覧は、最初から完璧を目指す必要はありません。まずは各部署の責任者に「今使っているツールを教えてください」と聞き取り、分かる範囲で埋めていくところから始めてください。台帳の作り方そのものについてはひとり情シスが全社員のアカウント・端末を1人で把握する台帳の作り方でも詳しく扱っています。

聞き取りの際は、「全社共通のツール」と「部署固有のツール」を区別して記録しておくと、後の作業が楽になります。全社共通のツールであれば、退職者が誰であっても必ず削除対象になるため、確認の手間を省けます。一方、部署固有のツールについては、退職者の所属部署に応じて削除対象を絞り込む必要があるため、「利用部署」の列が特に重要な意味を持ちます。

台帳が整備されていれば、退職者が決まった時点で「この人はどの部署に所属し、どのツールにアクセスできたか」を照合するだけで、削除すべき対象のリストがほぼ機械的に導き出せます。これが、部署任せの運用から一歩進んだ「把握された上での分担」の土台になります。

ステップ3: 削除依頼と完了報告を記録に残す

台帳をもとに削除すべき対象が洗い出せたら、次はその依頼と完了報告のプロセスです。ここでも、総務がすべてのツールを自分で操作する必要はありません。各部署の担当者に「このアカウントを削除してください」と依頼し、対応が完了したら報告してもらう、という流れを作ります。

このとき重要なのが、口頭やチャットの一言だけで済ませず、記録が残る形で依頼と完了報告を行うことです。具体的には、次のような簡易フォーマットで十分機能します。

• 退職者名・退職日
• 削除対象のツール一覧（部署ごとに整理）
• 各ツールの削除担当者
• 依頼日・期限
• 完了報告日（担当者からの返信をそのまま記録として残す）

このフォーマットは、専用のツールを新たに導入する必要はなく、共有スプレッドシートやチャットツールのチェックリスト機能でも十分に運用できます。重要なのは、「依頼した」という事実と「完了した」という事実の両方が、後から振り返って確認できる状態になっていることです。記録が残っていれば、数ヶ月後の棚卸しで「あの退職者のアカウントは本当に全部消えているか」を確認する際にも、記憶に頼らず記録で答えられます。

「頼んだつもり」「やったつもり」のすれ違いを防ぐには、依頼と完了報告を必ず記録に残す運用にすることが最も効果的です。口頭だけのやり取りは、忙しい時期ほど記録に残らず流れてしまいます。

兼務異動・複数部署にまたがるメンバーへの対応

30人未満の会社では、1人のメンバーが複数の部署の業務を兼務しているケースが珍しくありません。営業と経理を兼務している、開発と総務を兼務している、といった状況です。こうしたメンバーが退職・異動する場合、削除の連携先を一本化する仕組みが特に効果を発揮します。

単一部署にしか所属していないメンバーであれば、その部署の責任者に確認するだけで削除対象がある程度見えてきますが、複数部署を兼務しているメンバーの場合、どちらか一方の部署責任者だけに確認しても、もう一方の部署で使っていたツールが漏れてしまいます。部署横断のアカウント一覧が整備されていれば、「この人はどの部署に紐づいているか」を機械的に確認できるため、兼務者特有の見落としを防げます。

同様に注意が必要なのが、部署異動があったメンバーです。異動前の部署で使っていたツールのアクセス権限が、異動後も削除されずに残っているケースは非常によく見られます。退職時だけでなく、異動時にも同じ削除フローを適用することをお勧めします。異動は退職と違って「アカウントを完全に削除する」わけではなく、「異動前の部署のアクセス権限だけを削除し、異動後の部署のアクセス権限を新たに付与する」という作業になりますが、基本的な考え方（連携先を一本化し、記録を残す）は同じです。

業務委託・パートタイム・インターンのアカウントも対象に含める

退職者アカウントの削除フローを設計する際、正社員だけを対象にしてしまうと、業務委託の外部スタッフやパートタイム、インターンといった雇用形態の異なるメンバーが漏れてしまうことがあります。特に業務委託のメンバーは、契約終了のタイミングが人事の管理する退職手続きのフローに乗らないことが多く、「気づいたら契約終了していたが、アカウントは残ったまま」という事態が起きやすい典型的な盲点です。

部署横断のアカウント一覧を整備する際は、正社員に加えて、業務委託・パートタイム・インターンなど、すべての雇用形態のメンバーを対象に含めてください。契約終了の連絡経路も、正社員の退職連絡と同じく、総務（アカウント管理担当）への一本化を徹底することが重要です。契約を管理する部署（多くの場合、業務委託であれば発注元の部署）が、契約終了時に必ず総務へ連絡する、というルールをあらかじめ定めておいてください。特に開発を外部の業務委託に依頼している会社では、ソースコード管理ツールやサーバーへのアクセス権限が委託先メンバーに付与されたままになりやすく、契約終了時の削除漏れが実害に直結しやすい領域です。

部署の責任者を巻き込む際の伝え方

削除の連携先を一本化する仕組みを導入する際、各部署の責任者から「総務にいちいち報告するのは面倒」という反発が出ることがあります。この反発を避けるためには、単に「ルールだから従ってください」と伝えるのではなく、なぜこの仕組みが必要かを具体的なリスクとともに説明することが効果的です。

例えば、退職者のアカウントが放置された場合に起こりうる不正アクセスのリスクを、抽象的な「セキュリティが大事」という言葉ではなく、「退職者が知っていたパスワードが第三者に渡り、それが不正アクセスに使われる事例が実際に一定数報告されている」という具体的な事実として伝えると、納得を得やすくなります。国家公安委員会・総務省・経済産業省が公表している統計でも、識別符号を知り得る立場にあった元従業員等による不正アクセスが、検挙件数の中で無視できない割合を占めていることが示されています。

また、各部署の責任者にとって、この仕組みは負担を増やすものではなく、むしろ「自分の部署のアカウント管理の抜け漏れを、総務がダブルチェックしてくれる仕組み」だと捉え直してもらうことも有効です。責任者一人がすべてを記憶しておく必要がなくなり、台帳と依頼記録が代わりに覚えていてくれる、というメリットを強調してください。実際に、この仕組みを導入した後に「自分では気づかなかったアカウントを総務から指摘してもらえて助かった」という反応が返ってくることも少なくありません。

小規模な会社ならではの「言いにくさ」への配慮

部署が複数に分かれ始めたとはいえ、30人未満の会社では、退職者と削除担当者が日常的に顔を合わせる距離感で働いていることがほとんどです。この距離の近さは、時として仕組みの導入を妨げる要因になります。「あの人はきちんとした人だから、わざわざアカウントを確認しなくても大丈夫だろう」といった、人間関係に基づく安心感が、仕組みの徹底を鈍らせるのです。

しかし、退職者アカウントの削除は、退職者本人の人柄や信頼度とは無関係に、一律のルールとして運用すべき性質のものです。信頼していた人物のアカウントが、退職後に第三者の手に渡ったパスワードによって悪用される可能性は、本人の意図とは関係なく存在します。総務や情シス担当者は、この点を「あなたを疑っているわけではない」という前提で、退職者本人にも丁寧に説明できるようにしておくとよいでしょう。

また、円満退職ではないケース、例えば会社側からの解雇や、労使間でトラブルを抱えたままの退職の場合は、通常以上に迅速な対応が必要です。こうしたケースでは、最終出社日を待たずに、退職の意思確認が取れた時点でアクセス権限を一時的に制限する、といった踏み込んだ対応も検討してください。ただし、こうした対応は労務上の配慮も必要になるため、人事担当者と連携しながら進めることが前提です。通常の円満退職と、慎重な対応が必要なケースとで、あらかじめ対応の分岐点を決めておくと、いざというときに迷わず動けます。

統一フローが機能しているかを定期的に確認する

仕組みを作った後、それが実際に機能しているかを定期的に確認することも欠かせません。次のような簡易チェックを、四半期に1回程度実施することをお勧めします。

1. 過去の退職者について、削除依頼と完了報告の記録が残っているか確認する: 記録が抜けている退職者がいれば、そのツールのアクセス権限が今も有効なままである可能性が高いです
2. 部署横断のアカウント一覧を見直し、新しく契約されたツールが漏れていないか確認する: 台帳は放置すると古くなります。半年に1回程度、各部署に「新しく契約したツールはありますか」と確認する機会を設けてください
3. 退職連絡の入口が実際に機能しているか確認する: 「最近の退職者は、総務への連絡が退職日ギリギリになっていないか」を振り返り、伝達のタイミングに問題がないか確認します

この定期確認は、仕組みを作った直後は形骸化しにくいものですが、時間が経つと徐々に緩みがちです。カレンダーにリマインダーを設定しておくなど、確認自体を仕組み化しておくことをお勧めします。四半期に1回の確認を「総務の定例業務」の一つとして明文化しておけば、担当者が変わった場合でも引き継がれやすくなります。

統一フローの運用を支える最小限のツール選び

ここまで紹介してきた仕組みは、専用の高価なシステムを導入しなくても、既存のツールの組み合わせで十分に運用できます。30人未満の会社が現実的に選べる選択肢としては、次のようなものがあります。

• 共有スプレッドシート: 部署横断のアカウント一覧、削除依頼、完了報告のすべてを1つのスプレッドシートで管理する最もシンプルな方法です。列を「退職者名」「対象ツール」「削除担当者」「依頼日」「完了日」で構成するだけで機能します
• チャットツールの専用チャンネル: 「退職者対応」専用のチャンネルを作り、依頼と完了報告のやり取りをすべてそこに集約する方法です。会話の流れとして記録が残るため、後から振り返りやすい利点があります
• タスク管理ツール: 退職者ごとに1つのタスクカードを作り、削除対象のツールをチェックリストとして紐づける方法です。進捗が視覚的に分かりやすく、完了していない項目が一目で分かります

どの方法を選ぶかは、既に社内で使い慣れているツールに合わせるのが現実的です。新しいツールを導入すること自体が目的化してしまうと、かえって運用の負担が増えます。まずは今ある道具で仕組みを回し始め、運用が定着してから、必要に応じて専用ツールへの移行を検討する順番をお勧めします。運用が軌道に乗り、退職者対応の件数がある程度の規模になってきた段階で初めて、専用のオフボーディング管理ツールの導入を検討すれば十分です。

個々のアカウント削除の実務は別記事を参照

このガイドでは、複数部署にまたがる組織で削除フローをどう統一するかという「仕組みの設計」に焦点を当てました。実際に1人の退職者に対して、どのアカウントから優先的に削除すべきか、削除のタイミングはいつが適切か、といった実務的なチェックリストは退職者アカウントの削除漏れを防ぐチェックリストで詳しく解説しています。このガイドで作った「連携先の一本化」という土台の上に、そのチェックリストを乗せて運用することで、部署が増えても削除漏れが起きにくい体制を作れます。

まとめ: 削除作業は分散、把握と指示は集約

部署が複数に分かれた30人未満の会社で退職者アカウントの削除漏れが起きるのは、担当者の不注意ではなく、「誰も全体像を把握していない」という設計上の欠陥が原因です。すべての削除作業を総務が一手に引き受ける必要はありません。退職連絡の入口を1箇所に固定し、部署横断のアカウント一覧を整備し、削除の依頼と完了報告を記録に残す。この3つを組み合わせることで、削除の「実行」は各部署に分散させたまま、「把握」と「指示」だけを一本化できます。

この仕組みは一度作れば終わりではなく、部署が増えたり、新しいツールが契約されたりするたびに更新が必要になります。定期的な見直しをセットで運用してこそ、組織が成長しても機能し続ける仕組みになります。まずは自社の退職者対応の抜け漏れがどの程度あるかを確認したい場合は、退職者アカウントの削除漏れを防ぐチェックリストを使って過去の退職者を1人ずつ棚卸ししてみることから始めてください。

組織が30人を超え、部署の数がさらに増えていくと、退職者対応の仕組みもより体系的なものへと発展させていく必要が出てきます。その段階では、単発の仕組みづくりではなく、日頃からのアカウント管理そのものを見直す取り組みが求められます。ひとり情シスが全社員のアカウント・端末を1人で把握する台帳の作り方では、より本格的な棚卸しと記録の仕組み化について扱っているので、この記事で作った土台の先にある課題として、あわせて目を通しておくことをお勧めします。

最後に強調しておきたいのは、この仕組みが「一度作れば自動的に回り続ける」ものではないという点です。総務や情シス担当者が、部署の責任者と地道にコミュニケーションを取り続けることで、初めて機能し続けます。仕組みと運用の両方を維持する意識を持って、退職者対応に取り組んでください。地味な作業の積み重ねに見えるかもしれませんが、この積み重ねこそが、部署が増えても崩れない体制を作る唯一の方法です。