本文へ移動
実践IT

← 記事一覧へ

個人所有データの退職

個人アカウントが業務データを所有したまま退職する場合

従業員個人のクラウドアカウントが業務データや共有設定の所有者になっている場合に、退職前にデータ所在を確認し、会社管理領域へ移す順序を整理します。

公開: アカウント・権限共有・クラウド

この状態なら読む

次のような会社を対象にします。

  • 従業員個人のMicrosoft、Google、Apple、LINE等のアカウントを業務でも使っている
  • その個人アカウントがファイル、写真、共有フォルダ、予定、連絡先等の所有者になっている
  • 会社からそのアカウントを直接停止したり、設定を変更したりできない
  • 退職後も会社で使う必要がある業務データが残っている

会社管理の個別IDと会社端末だけで運用できている場合は、通常の退職日手順の方が適しています。

このページでは、個人アカウント自体を会社のものにするのではなく、会社に必要な業務データ・共有・管理関係を会社管理領域へ移すことを扱います。

最初に分ける: アカウントと業務データは同じものではない

個人アカウントに業務データが入っていると、退職時に「そのアカウントのパスワードを会社へ渡せばよい」と考えがちです。

しかし、移したいものは通常、アカウントそのものではありません。

会社側で継続して管理したい対象を分けます。

  • 業務ファイル
  • 写真、動画、スキャンデータ
  • 共有フォルダや共有アルバム
  • 顧客・取引先との共有リンク
  • カレンダー、予定、連絡先
  • フォームやアンケート
  • 自動処理や外部サービス連携
  • Webサイト、SNS、広告等の管理権限
  • MFAや復旧先として使われている連絡先

個人アカウントには私的なメール、写真、連絡先等も存在し得ます。したがって、個人アカウント全体をコピーするのではなく、会社に必要な対象を特定して移す方が境界を整理しやすくなります。

会社管理IDとの違いを確認する

サービスによって仕組みは異なりますが、個人向けアカウントと組織管理アカウントは管理主体が異なる場合があります。

Microsoftでは、職場または学校アカウントは管理者によって組織内に作成されると説明されています。

ここで重要なのは特定製品を使うことではなく、今後の業務データについて次を会社側で実行できる状態にすることです。

  • 利用者を追加・削除できる
  • 退職者だけアクセスを止められる
  • 管理者を会社側で変更できる
  • 共有範囲を会社側で確認できる
  • 復旧先を会社側で管理できる

個人アカウントから退職者本人を切り離せない場合でも、会社管理領域へ必要なデータを移しておけば、退職後の継続運用を本人のアカウントに依存しにくくなります。

退職前に「どこに何があるか」を一覧にする

最初に移動作業を始めるのではなく、所在を確認します。

1. 利用しているサービスを挙げる

本人への確認だけでなく、会社側で把握できる範囲も照合します。

  • クラウドストレージ
  • メール
  • 写真・動画共有
  • チャット
  • カレンダー
  • オンライン会議
  • Webサイト管理
  • SNS
  • 広告管理
  • 会計、勤怠、顧客管理等のSaaS
  • フォーム、アンケート
  • パスワード管理や認証アプリ
  • 外部業者との共有領域

「個人アカウントを何個持っているか」より、会社に必要な情報や権限がどこにあるかを見ます。

2. データごとに移行先を決める

移行先は、会社が継続管理できる場所にします。

対象 移行先の例として確認するもの
文書・表計算 会社管理の共有領域
写真・動画 会社管理の保存領域
予定 後任者や共通カレンダー
連絡先 会社の顧客管理、共有連絡先等
共有リンク 会社管理領域から作り直せるか
フォーム 所有者や管理主体を移せるか
SaaS管理 会社管理IDへ管理者を追加できるか
復旧先 会社管理の連絡先へ変更できるか

「全部同じ場所へコピーする」と決める必要はありません。対象ごとに管理先を決めます。

「共有されている」と「会社が管理できる」は違う

退職者の個人アカウントから会社アカウントへファイルが共有されていても、そのままでは元データの所有者が退職者側に残る場合があります。

サービスの機能に応じて、少なくとも次を区別します。

共有

元データはそのままで、別の利用者が閲覧・編集できる状態です。

共有元が消えたときの挙動や、共有解除権限が誰にあるかを確認します。

ダウンロード・コピー

会社側へ別のデータとして複製します。

元の共有設定、更新履歴、コメント、リンク、所有関係等がそのまま引き継がれるとは限らないため、必要な情報が何かを確認します。

所有者変更・管理者変更

サービスが対応している場合は、データや管理対象の所有者・管理者を会社管理IDへ変更します。

変更可能な対象、同一組織内だけで変更できるか等はサービスごとに確認します。

エクスポート

サービスからデータを取り出します。

エクスポートできることと、別サービスへ同じ状態で復元できることは別です。再利用に必要な形式か確認します。

移行は重要度の高いものから行う

全データを完全に整理する時間がない場合は、退職後に事業が止まるものから処理します。

優先度を上げやすい例は次です。

  1. 会社やサービスの管理権限
  2. 顧客対応中の案件
  3. 契約・請求・会計に関するデータ
  4. 取引先との共有領域
  5. Webサイト、SNS、広告等の公開管理
  6. 継続利用する業務ファイル
  7. 過去資料・参考データ

重要なのは「ファイル数」ではなく、退職後に会社側だけで継続・復旧できるかです。

退職者本人と連絡できるうちに確認する

会社側で管理できない個人アカウントは、退職後に本人と連絡が取れなくなると確認手段が減ります。

退職前に、少なくとも次を本人と確認します。

  • 業務で使った個人アカウントの種類
  • 会社に必要なデータの所在
  • 共有相手
  • 本人しか管理者になっていないサービス
  • 本人しか把握していない共有リンク
  • 自動転送、自動保存、自動処理
  • API連携や外部サービス連携
  • MFA、SMS、認証アプリ、復旧先への依存
  • 会社の支払い情報が登録されているサービス
  • 会社のドメインや公開サイトに関係する設定

この一覧を本人の記憶だけで終わらせず、会社側の引継ぎ記録に残します。

パスワードを受け取ることを移行完了にしない

個人アカウントの資格情報を会社が受け取っても、管理主体の問題は解決しません。

たとえば次が残ります。

  • 本人の私的データと業務データが混在している
  • 本人の電話番号や認証アプリに依存している
  • サービス上の本人確認が本人情報に結び付いている
  • 本人が別の場所から復旧できる可能性がある
  • 利用規約やサービス設計上、他者への資格情報移転を前提としていない場合がある

したがって、パスワードの受け渡しではなく、必要な業務データ・管理権限を会社管理領域へ移すことを完了条件にします。

退職当日は個人アカウントではなく会社側の権限を確認する

通常の会社管理アカウントであれば、退職者アクセスの削除を会社側で行います。NCSCもSaaS利用者のアクセス追加・削除にJoiners, Movers, and Leaversの手順を適用することを示しています。

個人アカウントが残るケースでは、会社から個人アカウント自体を停止できないことがあります。その場合でも、会社側で管理できる対象について次を確認します。

  • 会社管理領域への移行が完了している
  • 退職者への会社側共有を外した
  • 会社管理SaaSから退職者を外した
  • 会社管理のグループから外した
  • 会社管理の管理者権限を外した
  • 会社端末を回収した
  • 会社側の共有リンクを見直した
  • 会社側の復旧先やMFAから本人依存を外した

個人アカウントを消せないことと、会社側のアクセスを残すことは別です。

退職後に確認すること

残存している共有

会社管理領域から退職者個人アカウントへの共有が残っていないか確認します。

移行漏れ

後任者が業務を始めて初めて不足に気付くことがあります。

  • 開けないファイル
  • 更新できない共有領域
  • 本人だけに通知が届くサービス
  • 本人だけが管理できる公開ページ
  • 本人認証が必要な自動処理

が出た場合は、どの管理主体に依存しているかを確認します。

元の個人領域に残った業務データ

会社側へ必要なデータを移しても、個人アカウント側に複製が残る場合があります。

削除可否や保持の必要性は、データの性質、契約、社内ルール、利用サービスの仕様等を確認して判断します。本人の私的データまで会社が確認・取得することを前提にしません。

本人と連絡が取れなくなった場合

退職後に初めて個人アカウント依存へ気付いた場合は、まず会社側で確認できる情報を整理します。

  • 何のデータが不足しているか
  • そのデータが本当に個人アカウントにしかないか
  • 他の共有先や端末に複製がないか
  • 会社側の管理者機能で回収できないか
  • サービス提供者の正規の復旧・管理手段があるか
  • バックアップやエクスポートが残っていないか

本人の資格情報を推測したり、本人になりすまして復旧したりする方法は前提にしません。

会社側で回収不能なら、それ自体を今後の設計課題として記録します。

再発防止は「個人サービス禁止」だけで終わらせない

個人アカウント利用が生じた理由を確認します。

  • 会社IDが発行されていなかった
  • 会社の保存場所が分かりにくかった
  • 現場から使えなかった
  • スマートフォンから使う方法がなかった
  • 外部共有の正式手順がなかった
  • 容量や機能が不足していた
  • 急ぎの仕事で個人サービスの方が簡単だった

理由を確認せず禁止だけを追加すると、別の個人サービスへ移る可能性があります。

次の状態を作る方が運用しやすくなります。

  • 業務開始時に会社管理IDを発行する
  • 正式な保存場所を決める
  • 現場・外出先からの利用方法を用意する
  • 外部共有の方法を決める
  • 退職時に会社側で利用者を外せる
  • データ所有・管理者を会社側で継続できる

最小の移行手順

時間が限られている場合は、次の順序から始めます。

  1. 個人アカウントにある業務対象を一覧にする
  2. 会社管理の移行先を決める
  3. 管理権限・重要案件・顧客データから移す
  4. 共有だけで済ませず、所有・管理主体を確認する
  5. 会社側で退職者を外せる状態にする
  6. 退職当日に会社側の残存アクセスを止める
  7. 退職後に移行漏れを確認する
  8. 今後は会社管理IDから業務を始める

この状態を目標にする

退職後の理想は、次の状態です。

  • 会社に必要な業務データが会社管理領域にある
  • 退職者の個人アカウントへ業務継続を依存していない
  • 会社側で利用者と管理者を変更できる
  • 共有先とデータ所在を確認できる
  • MFAや復旧先が退職者個人へ依存していない
  • 後任者が本人の協力なしで通常業務を継続できる

個人アカウントを使ったこと自体を責めるより、業務データの管理主体を会社側へ戻し、次回は同じ回収作業をしなくて済む構成へ変えることが目的です。

根拠・一次情報

外部事実は、資料トップではなく実際に確認した原典内の位置へ戻れるようにしています。リンク先が対応している場合は該当文言を直接表示します。

  1. Microsoftの職場または学校アカウントは、管理者によって組織内に作成される。

  2. NCSCはSaaS利用において、利用者アクセスの追加・削除へJoiners, Movers, and Leavers (JML) processを適用し、不要になったアクセスを外すことを示している。