アカウントが増え、管理者は知らない——DXが生む権限の空白をどう埋めるか

IDと権限は、ツールの数だけ増える

SaaSツールを1本追加するたびに、新しいIDと権限の組み合わせが生まれる。

経費精算、プロジェクト管理、チャット、ファイル共有、会計連携——それぞれのサービスに管理者と利用者が設定され、それぞれに権限レベルが存在する。ツールが5本あれば、組み合わせは単純に5倍ではなく、各ツールの権限設定が絡み合って複雑になっていく。

導入した直後は把握できていても、1年、2年と経つうちに「誰が何にアクセスできるか」の全体像は誰の頭にも収まらなくなっていく。退職者のアカウントが残ったまま、業務委託先に必要以上の権限が付与されたまま、部署異動した社員が旧部署のデータを閲覧できたまま——こういった状態は、意図的に放置されたものではない。ただ、管理が追いつかなかっただけだ。

ツールが増えるほど、この問題は加速する。DXが進むほど、管理の空白も広がる。

「後から整備すればいい」が成立しない理由

ガバナンスを後回しにする判断は、多くの現場で起きている。ツールを導入して業務を回すことが先決で、管理体制はある程度定着してから考えればいいという論理だ。

しかし実際には、動き始めたシステムにガバナンスを後から乗せることは、建物を建ててから耐震補強をするより難しい。

なぜか。業務が、権限の例外に適応してしまうからだ。

「Aさんしかこの操作ができない」「このフォルダは全員が見られる設定になっている」——そういった状態が前提として業務に組み込まれると、それを変えることは業務そのものを変えることになる。ガバナンスの整備が「制度の整備」ではなく「業務の再設計」を意味するようになる。非効率に見える業務が守っているものについての考察でも整理したように、現場の手順は理由なく存在しているわけではない。

加えて、人は動く。異動、退職、役割の変更。これらのたびに権限も見直す必要があるが、後から整備しようとする段階では「誰が、いつ、何にアクセスできるようになったか」を遡るコストが膨大になる。変更の積み重ねが、整備そのものを困難にする。

整備のコストは時間とともに増える。ガバナンスに最もコストがかからないタイミングは、設計の初期だ。

このことは、システムの構造的な問題にも通じる。ITの柔軟性と経営の自由度で整理したように、後から変えにくい構造は経営の自由を奪う。権限設計も同様で、最初に「変えにくい状態」を作ってしまうと、組織の変化に追いつけなくなる。

DXと同時に走らせる3つの設計

では、何から考えればいいか。完璧なガバナンス体制を最初から構築する必要はない。ただし、次の3つは新しいツールを導入するのと同じタイミングで決めておくべきだ。

1. IDのライフサイクルを決める　誰がアカウントを作り、誰が停止するか。入社・退職・異動のタイミングで何をするかを手順として書いておく。
2. 権限は最小から始める　必要になってから広げる、という設計にする。最初から広い権限を与えて「後で絞る」は機能しない。現場が権限の縮小に抵抗するため、実際には絞れなくなる。
3. データの所在を記録する　どのツールに何のデータが入っているかを書いておく。ツールの契約終了や切り替えのとき、データの行方が不明になるリスクを防ぐ。

これは厳格な管理体制を構築することが目的ではない。変化に対応できる構造を、最初から意図して作っておくことだ。

---

DXの効果は、業務の可視化と効率化にある。しかしそのデジタル化が積み重なるほど、「誰が何を見られるか」の地図は白紙に近づいていく。ガバナンスは、DXが成熟した後に整備するものではなく、DXと同時に設計の一部として組み込むべきものだ。

伴走しながら設計を見直したい場合は、DX伴走支援「しぼる」をご覧ください。