
Conclusion
この記事の結論
サービスごとのアクセス停止を確認し、給与・勤怠の締めに影響する機能は個別に扱いました。
退職時の「削除」はサービスによって意味が違います。サインインする権限、個々の業務機能を使う権限、締め処理に必要な過去の記録は別々に扱います。すべてを一括処理すると、不要なアクセスが残るか、必要な業務記録を早く消しすぎるかのどちらかが起こり得ます。
今回の対応
11月8日、Microsoft 365とJira Service Managementで対象が削除済みになったことを確認し、freeeではサービスごとに権限解除を確認しました。給与・勤怠の締めに影響する機能は、依存関係を確認できるまで保留としました。
権限と業務データの二つの軸
例えば会計サービスの操作権限を外せても、給与の締めや勤怠の確定には過去の記録が必要な場合があります。アカウントの状態だけを記録するのではなく、どのサービスでアクセスの停止を見たか、どの業務機能について判断を保留したかを分けて記録します。
状況別の判断と次の対応
| 観察した状態 | そこから判断できること | 次に確認すること |
|---|---|---|
| Microsoft 365・JSMの削除済み表示 | そのサービスの管理状態を確認 | 対象と確認日時を記録する |
| freeeのサービス権限を解除 | その機能のアクセスを整理 | 他のfreeeサービスも個別に確認する |
| 締めに必要な機能が残る | 業務データとの関係を確認する必要 | 保留理由・判断する担当・再確認条件を記録する |
「保留」で終わらせない
保留欄には、次に何が確認できたら処理するかを書きます。「給与締め後に、必要な記録を維持してアクセスを停止できる方法を確認する」という書き方なら、後任が作業を再開できます。停止済みのアクセスとの区別もつきます。
- 01サービスと権限を棚卸しする
- 02停止結果をサービスごとに読み戻す
- 03締め処理への依存を保留理由とともに引き継ぐ
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認
