その日、経理担当のBさんは月次の給与処理を終え、何気なく社内ポータルの画面を眺めていた。すると、先月入ったばかりのアルバイトのCさんから声をかけられた。「あの、この画面、私も見えるんですけど、これって見ていいものなんですか」。Cさんが指したのは、全社員の月給・賞与・扶養家族の人数までが一覧で並ぶ、給与管理システムのトップ画面だった。入社してまだ3週間、勤怠入力用のIDを発行されただけのはずのCさんが、経営陣ですら滅多に開かないはずのその画面に、なぜかアクセスできてしまっていた。
Bさんは血の気が引いた。原因を辿ると、システム導入時に「とりあえず全員に同じ権限を付与しておこう」という判断がされたまま、3年間一度も見直されていなかったことがわかった。誰かが悪意を持って情報を盗み見たわけではない。ただ、権限という鍵が、最初から社内の誰の手にも渡っていたのだ。もしCさんが指摘してくれなかったら、この状態はあと何年続いていただろうか。
この記事を読んでいるあなたも、心当たりがあるかもしれない。全社員が同じ権限で全データにアクセスできる状態に、うっすらとした不安を抱えたまま日々の業務を回している。あるいはこれからシステムを導入するにあたり、権限設計をどう決めればいいのか見当がつかない。そんな担当者に向けて、この記事では権限設計の考え方と、実際の設計手順を具体的に解説する。
なぜ権限設計は後回しにされやすいのか
業務システムを導入するとき、多くの現場では「まず動くこと」が最優先される。見積書が発行できるか、勤怠が集計できるか、在庫が管理できるか。機能が動くかどうかのテストに時間を使い切り、権限は最後の最後に「とりあえず全員閲覧可、編集も一部の人以外はできないようにしておけばいいか」という程度で片付けられる。
これは怠慢ではない。むしろ現場感覚としては自然な優先順位だ。導入プロジェクトには納期があり、予算があり、現場は日々の業務を止められない。権限設計は目に見える成果物ではないため、経営者にもベンダーにも「後回しにしていい項目」に見えてしまう。誰も見せてはいけないものを隠す作業より、誰もが使える機能を作る作業のほうが、達成感も評価もわかりやすい。
さらに厄介なのは、権限設計の甘さは平時には何の問題も起こさないという点だ。給与データが全員に見える状態でも、誰も覗かなければ何も起きない。だからこそ発見が遅れる。Bさんのケースのように、誰かが偶然気づいて指摘してくれるまで、その状態は静かに社内に居座り続ける。壁を越えて働く人たちを支えるはずのシステムが、いつの間にか壁そのものを溶かしてしまっているのに、誰も気づかないまま時間だけが過ぎていく。
権限設計が甘いことの具体的なリスク
権限がずさんな状態を放置すると、実際にどのようなリスクが顕在化するのか。抽象論ではなく、起こりうる具体的な場面で考えてみたい。
情報漏洩のリスク
顧客の個人情報、取引先の見積単価、社員の評価データ。これらが本来アクセス権のない人の目に触れる機会が増えるほど、外部への漏洩リスクも比例して高まる。悪意がなくても、退職者が私物のスマートフォンで社内システムに触れた記憶を頼りに、転職先で似たような業務フローを再現してしまう、というだけでも情報は流出したことになる。閲覧できる状態そのものが、すでにリスクの入り口なのだ。
誤操作の連鎖
編集権限が必要以上に広く配布されていると、業務に不慣れな担当者が誤って受注データを削除したり、承認済みの見積を書き換えたりする事故が起きやすくなる。しかも1人の誤操作が、後工程の担当者の作業にも連鎖する。経理が処理した後の請求データを製造部門の誰かが誤って上書きし、月末になって数字が合わないと大騒ぎになる、という光景は決して珍しくない。
内部不正のハードルの低さ
権限が細かく分かれていれば、不正を働くには複数人が結託する必要がある。しかし全員が同じ権限を持っていれば、たった1人の判断だけで不正が完結してしまう。発注データを1人で作成し、1人で承認し、1人で支払処理まで進められる環境は、性善説に頼りきった危うい設計だと言わざるを得ない。権限設計とは、社員を疑うための仕組みではなく、誰にも不必要な責任やリスクを背負わせないための仕組みでもある。
権限設計の基本的な考え方
権限設計と聞くと複雑な専門知識が必要に思えるが、基本となる考え方は驚くほどシンプルだ。軸は主に3つ、そこに1つの原則を組み合わせるだけでいい。
部署別の軸
営業部は営業データに、製造部は生産データに、経理部は財務データにアクセスできる。他部署のデータは基本的に見えない。これが最も基礎的な線引きだ。ただし部署をまたぐ業務、たとえば製造部が営業の受注情報を見て生産計画を立てる場合など、業務上必要な横断アクセスは個別に許可する設計にしておく必要がある。
役職別の軸
同じ営業部でも、一般社員が見られる範囲と、部長が見られる範囲は異なるべきだ。個人の売上実績は本人と上長のみ、部全体の実績は部長以上、全社の実績は経営層のみ、といった階層構造をつくる。役職が上がるほど閲覧範囲が広がるのは自然な設計だが、編集・削除権限まで無条件に広げる必要はない。見える範囲と、変更できる範囲は分けて考えるべきものだ。
機能別の軸
部署や役職とは別に、システムの機能そのものに対する権限も設計する必要がある。データを見るだけの閲覧権限、データを入力・修正できる編集権限、データを削除できる削除権限、そして稟議や発注を最終確定させる承認権限。この4つは性質がまったく異なるため、同じ人物に自動的にセットで与えるべきではない。
最小権限の原則
これら3つの軸を貫く共通の原則が「最小権限の原則」だ。業務を遂行するために本当に必要な権限だけを付与し、それ以外はすべて閉じておく。便利だからという理由で権限を広く配ってしまうと、その便利さは将来のリスクとして跳ね返ってくる。迷ったら狭く設定し、業務上の必要が具体的に発生した時点で個別に広げる、という順序を徹底したい。
実際の設計手順
考え方を理解しても、実際にどう手を動かせばいいかがわからなければ設計は進まない。ここでは、システム担当者が自分の会社で実践できる具体的な手順を示す。
ステップ1 業務フローの棚卸し
まず、そのシステムを使う業務が、誰から始まり誰で終わるのかを紙に書き出す。たとえば見積作成であれば「営業担当が見積を作成する→営業所長が確認する→本部の承認者が最終承認する→経理が請求書を発行する」というように、業務の起点から終点までの登場人物を洗い出す。この時点で、思っていたより多くの部署や役職がその業務に関わっていることに気づくケースが多い。
ステップ2 閲覧・編集・削除・承認を分けて考える
棚卸しした業務フローの各工程について、それぞれの立場の人に「見るだけでいいのか」「入力・修正が必要なのか」「削除する必要があるのか」「承認する立場なのか」を一つずつ当てはめていく。先ほどの見積作成の例であれば、営業担当は編集権限、営業所長は閲覧と確認のみ、本部承認者は承認権限、経理担当は確定後のデータの閲覧権限、といった具合に分解できる。全員に編集権限を配る必要はどこにもない。
ステップ3 例外対応のルール化
設計をどれだけ緻密にしても、必ず例外は発生する。担当者が急病で休み、代理の人が一時的にデータを確認する必要がある場合や、監査のために普段アクセスしない範囲を一時的に見る必要がある場合だ。こうした例外は、その場しのぎで権限を緩めるのではなく、あらかじめ「誰の承認があれば一時的な権限付与が可能か」「付与した権限はいつ自動的に失効するか」というルールを決めておくことが重要だ。例外を例外のまま扱えるルールがあってこそ、原則としての最小権限が長期的に守られる。
ステップ4 定期的な棚卸しをスケジュール化する
権限は一度設計して終わりではない。人は異動し、退職し、昇格する。半年に一度、あるいは年度の節目に「今、誰がどの権限を持っているか」を一覧で確認し、業務内容と照らして不要な権限が残っていないかをチェックする機会を、あらかじめカレンダーに組み込んでおきたい。この地道な確認作業こそが、冒頭のCさんのようなケースを未然に防ぐ最も確実な方法だ。
よくある失敗パターン
権限設計に取り組もうとした企業が、実際につまずきやすいポイントをいくつか紹介する。
- 役職が上がった人にとりあえず全部の権限を付与してしまい、その人が本来見る必要のないデータまでアクセスできる状態になる。役職と権限は連動させつつも、必要な範囲に絞る意識が抜け落ちやすい。
- 退職者や異動者のアカウントを削除・変更し忘れ、使われないはずの権限がシステム内に残り続ける。人事異動の連絡フローに、システム権限の変更手続きが組み込まれていないことが原因になりやすい。
- 権限設計を一度に完璧にしようとして、プロジェクトが止まってしまう。まず主要な業務フローだけでも最小権限で設計し、細部は運用しながら調整していくほうが現実的だ。
- システム管理者だけがすべての権限を持ち、その管理者が退職や休職をした瞬間に社内の誰も権限変更ができなくなる。管理権限そのものも、複数人でバックアップできる体制にしておく必要がある。
- 「うちは全員が家族のような会社だから」という理由で権限設計自体を不要と判断してしまう。信頼関係と、システム上のリスク管理はまったく別の話だ。信頼している相手だからこそ、余計な責任を背負わせない設計が誠実だとも言える。
まとめ
権限設計は、社員を縛るための仕組みではない。それぞれの立場で必要な情報に迷わずたどり着き、余計な責任やリスクを背負わずに、自分の役割に集中して働けるようにするための土台だ。部署・役職・機能という3つの軸で線を引き、閲覧・編集・削除・承認を分けて考え、例外にはルールで応える。この積み重ねが、壁を越えて働く人たちの信頼を守る仕組みになる。
もし今、自社のシステムで権限が「とりあえず全員に同じもの」で運用されているなら、それは決して珍しい状態ではない。多くの会社が同じところから出発している。大切なのは、今日この記事を読んだことをきっかけに、まず一つの業務フローだけでも棚卸しを始めてみることだ。Bさんの会社のように、誰かの指摘で気づく前に、自分たちの手で気づける会社でありたい。