物流SaaSを個人アカウントで運用しないための権限移管表

何を分けて考えるか

SaaSの管理者権限と利用者権限を分離する。

認証情報の共有ではなく、割当権限と復旧手順を整備します。

最初に確かめる範囲

このケースで使う記録は、管理者メール、権限の付与理由、異動時の移管日です。共有アカウントをやめ、管理責任者と副管理者で定期点検する。

管理ログイン以外の移管を確かめる

実績を説明する

新任はログインできても、旧担当に請求・認証復旧・連携設定が残る。

条件が変わると何が変わるか

旧権限を先に外して連携が切れると業務停止。個別アカウントで操作を監査できるようにする。

誰がどこを確認するか

旧担当の退職を想定し、新任が請求先を確認でき、予備の管理者が外部連携を復旧できるか試す。権限を外す時刻も記録する。

権限移管を一日かけて確認する

新任者が管理画面に入れても、請求通知や障害時の復旧先が旧担当のメールに残れば、移管は途中です。管理、支払い、認証復旧、外部連携の四つを台帳に分け、実際に確認できた画面や操作名を控えます。通常操作と、認証端末を失った場合の手順を別に試します。

外部連携が旧担当の権限にひも付く場合は、その設定を移してから旧権限を停止します。その結果として連携データが欠けていないか確かめます。個人のパスワードを共有する方法を取らず、誰が操作したかを確認できる個別の権限と代替担当を設けます。

条件が変わるときの判断

社内管理の個別アカウントで権限と復旧経路を移管し、新担当で一件の管理操作を検証する。

1. 管理対象を分類する：ログイン、請求、契約、二要素認証、外部連携を見る
2. 代替を検証する：担当が不在でも復旧できる仕組みと責任者を持つ
3. 旧権限を棚卸しする：移管後に古い担当の操作と請求アクセスを確認する

記録と処理を設計する

契約者、管理者、請求、復旧連絡先、退職時停止、監査ログを棚卸しし、移管前後に管理操作を試します。

試す作業　共有アカウントをやめ、管理責任者と副管理者で定期点検する。

現場で先に確認する条件

管理者アカウントを作る前に、契約、請求、データのエクスポート、管理者の追加、復旧方法の権限を棚卸しします。名義だけを変えても請求や復旧が古い連絡先に残る場合があります。

退職・異動時の停止を試し、勤務先が管理するアカウント、復旧用連絡先、役割ごとの権限を確認します。操作ログと代替の管理者も、月次で点検する対象にします。

移行前後の開始点

切替時は棚の数字だけでは足りず、未完了、移動中、保留、未承認の作業を持ち越す必要があります。終了と開始の時刻を示し、計数を終えた後に例外出荷した明細も扱えるかを検証します。

記録に残す項目

• 管理者メール
• 権限の付与理由
• 異動時の移管日

改善の結果を確かめる

改善の前後で「無効・不要アカウント数」を比較します。集計の対象、期間、観測できなかった件数も残します。無効・不要アカウント数です。改善前後で件数や時間を比較する場合は、対象利用者と対象レコード数を固定することが必要です。担当や物量が変わると単純な件数比較は誤解につながるため、対象条件も併記します。

記録には「対象期間／分母／改善前／改善後／増減の理由／現場負担の変化」を設けます。数値が改善しても、そのために別部署へ転記や問い合わせが移動していないかを確認してください。

試行で確かめる落とし穴

確認したいのは「退職者の個人メールに唯一の管理権限を残す」という状態が残るかどうかです。

読み合わせと実地確認

再現する場面

管理者の異動と、認証手段の紛失を想定する

確認する範囲

運用、契約、請求、復旧のアクセスを別々に検証する

判断できる状態

個人の端末や私用アカウントへ依存せず事業を継続できる。

運用を選ぶときの追加の論点

復旧試験では、ログインできる場合と端末・認証手段を失った場合の両方を考えます。新管理者でメンバー追加ができても、請求メールや外部連携の認証が旧担当へ残ることがあります。引継ぎには、管理画面で確認できる権限、契約者の連絡方法、旧アカウントの停止を別行で持ち、操作を確認した日を記録します。

社内で説明して引き継ぐ

管理、契約、請求、復旧、外部連携ごとに実施者・代替・停止確認を説明する。

同僚に聞く

異動者の権限を外す日までに所有者を誰へ引き継ぐか？

関連する判断　物流SaaS導入後にExcelへ戻る現場をどう立て直すか / 新しいSaaS導入後のExcel二重運用をやめる手順と検収項目

参照できる一次資料

• IPA「中小企業の情報セキュリティ対策ガイドライン」

  管理者の把握、アクセス管理、退職時・事故時の対応の確認に使う。

重要一次ソース一覧