管理段階の始まりは、人数ではなく「会社として決める必要」が出たとき
共同作業までは、「みんなで同じ仕事を触れるか」が主な問題でした。管理段階に入ると、問題は「誰が使ってよいか」「誰が管理するか」「人が抜けたとき何を残すか」「会社としてどこまで記録を残すか」へ変わります。
退職や異動が発生した。社外共有が増えて定期的な棚卸しが必要になった。管理者権限を一人へ集中させたくない。会社PCや私物端末からのアクセスを管理したい。監査ログや保持期間を求められた――こうした出来事が管理段階への入口です。「10人を超えたら管理ツール」ではありません。権限・所有者・引継ぎ・統制を個人判断ではなく組織ルールとして決める必要が出たときが境目です。
まず新しい管理ツールを足すより、Google／Microsoftの管理機能を使う
管理段階へ進んでも、最初に別の管理サービスを追加する必要はありません。Google WorkspaceやMicrosoft 365を仕事の基盤にしているなら、ユーザー、グループ、管理者ロール、端末、外部共有、監査、退職者処理など、まず基盤側で管理できる範囲を確認します。役割の詳細はGoogle Workspaceの役割を確認するで確認できます。
管理機能が増えるほどよいのではなく、今必要になった管理ルールを既存基盤のどこで実現するかから始めます。
退職処理は、「削除」ではなく「アクセス停止」から始める
管理段階で最も重要な運用の一つが、退職・異動時の処理です。退職日にいきなりアカウントを削除すると、顧客とのメール、ファイル、予定、所有していたデータまで失う危険があります。
原則は、アクセス停止 → メール・ファイル・予定・所有データの引継ぎ → 必要な保持 → ライセンス／アカウント整理です。削除は最後の工程にします。基盤側の具体的な役割はMicrosoft 365の役割を確認するでも確認できます。
管理者を増やすことと、強い管理者権限を増やすことは別
利用者が増えると、ユーザー追加、グループ管理、請求、セキュリティ設定などを一人で抱え続けることが難しくなります。このとき、全員へ強い権限を与えるのではなく、日常業務に必要な限定ロールを委任します。
管理者の属人化を避けることと、過剰権限を増やさないことを同時に満たします。管理者アカウントも、普段の一般作業用アカウントと同じ感覚で使わない方が安全です。
社外共有は、作る管理より「閉じる管理」が重要になる
共同作業の段階では、取引先へファイルやページを共有できることが重要でした。管理段階では、誰に何を共有しているかを後から確認し、案件終了時に確実に閉じることが重要になります。共有リンクを削除しても、特定ユーザーへの直接アクセスや、親フォルダ・共有ドライブから継承した権限が残ることがあります。
案件終了時の手順として、ゲスト、共有リンク、フォルダ／サイトのメンバーなどを棚卸しします。共有を始めるときに、誰が終了時の解除責任者かも決めるのが管理段階です。具体的な運用は取引先とファイルを共有したいで確認できます。
監査ログと、メール・文書そのものの保持を分ける
「ログを残す」「データを残す」という言葉は、管理段階では分けて考えます。監査ログは、誰がいつ何をしたかという操作記録です。一方、メールや文書そのものを削除されても保持したい、電子情報開示や長期保存へ備えたいという要求は別です。
操作ログの保持と業務データの保持を、同じ機能として説明しないようにします。
チャットや会議にも、「監査」と「アーカイブ」と「記録の正本」がある
管理対象はメール・ファイルだけではありません。チャットサービスによって、メッセージ保持、監査、エクスポートは同じ仕組みではありません。会議でも、録画や文字起こしの保存先はサービスごとに分かれます。
「記録が残るか」を一つの○×にせず、操作履歴、会話本文の長期保存、録画・文字起こしの正本を別に決めます。会議記録が増えたら、どこを後から探す場所にするかも会社ルールにします。詳細はLINE WORKSの役割を確認するでも確認できます。
端末・SSO・条件付きアクセスは、具体的なリスクが出てから強化する
会社PCを配る、私物スマートフォンから業務データへアクセスする、拠点外アクセスを制限したい、といった要求が出ると、アカウント管理だけでは足りなくなります。上位プランでは高度なエンドポイント管理やSSO、端末・IP制限が追加されることがあります。
ただし小規模な段階から「一番強いプラン」を選ぶ必要はありません。どの端末から、誰が、どの条件で入れるべきかという要求が出た時点で上位管理機能を比較します。
社内予定・施設・申請が散らばったら、内部グループウェアを検討する
管理段階では、情報セキュリティだけでなく、社員の日常運用も管理対象になります。予定はCalendar、会議室は別表、稟議は紙、全社周知はメールやチャット、と入口が分散すると、予約重複や承認滞留、周知漏れが起こります。既存のGoogle／Microsoft環境でまとまるならそのままで構いません。
現場スタッフが日常的に使うツールで申請まで寄せる選択肢もあります。サイボウズ Officeの役割を確認するのように、スケジュール・施設予約・掲示板・ワークフロー等を一体化するサービスもあります。管理ツールを増やすのではなく、社員が見る内部運用の入口を減らせるかで判断します。
データを持ち出せるかは、導入時から確認する
会社として使うサービスが増えるほど、「やめるときに何を持ち出せるか」も管理項目になります。エクスポートがあることをバックアップと同じ意味にせず、どのデータが会社の正本で、終了前に何を取り出す必要があるかを決めます。
まだ上位プランや新しいグループウェアを足さなくてよい場面
管理段階の記事でも、追加しない判断を残します。退職や権限変更がなく、一人の管理者で無理なく運用でき、社外共有も少なく、監査・保持要件もないなら、上位の統制機能を先回りして契約する必要はありません。
管理段階とは、何でも高度化する段階ではなく、会社として決める必要が生じた運用だけを仕組みに変える段階です。
管理段階で確認する7項目
管理が必要になったら、次の7項目を確認します。
- 退職・異動時はアクセス停止から始められるか
- メール・ファイル・予定・所有データを誰へ引き継ぐか
- 管理者権限を必要最小限に分担できているか
- 社外共有を誰が定期的に棚卸しするか
- 監査ログと業務データ保持を分けて要件化しているか
- 端末・SSO・条件付きアクセスが本当に必要か
- 社内予定・施設・申請の入口が分散しすぎていないか
ここまで決めてもツールの数が増え続け、同じ予定・チャット・ファイル・タスクが複数の場所へ存在するようになったら、次は削減と正本整理へ進みます。