権限設計は、管理システムで最も誤りやすい部分です。着手時には単純に見えるからです。役割がいくつか、画面がいくつか。問題は後から来ます。拠点が増え、承認段階が増え、そして「なぜこの部長が別部署の給与を見られるのか」と誰かが尋ねたときです。

混ぜてはいけない三層の問い

どの権限設計も、性質の異なる三つの問いに答えています。これを混ぜることが混乱の元です。

• どこに入れるか — この人はどの画面を開けるか。
• 何ができるか — 参照、追加、編集、削除、承認、出力。
• どのデータに対してか — 自分の分だけか、自部署か、自拠点か、全社か。

前の二つは最初から作られます。三つ目は忘れられがちで、後から足すと最も高くつきます。システム中のすべてのデータ取得に手を入れることになるからです。

役割か、細かい権限か

最も長持ちするのは二層構造です。システムが理解するのは細かい権限だけで、役割はそれを束ねた設定の入れ物にすぎません。

• コード内の判定は常に「伝票の承認権限を持つか」であり、「経理課長かどうか」では判定しません。
• 新しい役職ができたら、対応する権限の集合を持つ役割を作るだけ。コードの修正は不要です。
• 役割の外で個別に権限を付与できるようにします。例外は必ず存在するからです。ただし、誰がどの個別権限を持っているか一覧できることが条件です。

データ範囲の四段階

複数拠点を持つ会社では、いま一段階しか使わないとしても、範囲の段階を最初から設計しておきます。

• 自分 — 本人が作成した、または担当するレコード。
• 自チーム・自部署 — 組織ツリーに沿って。下位部署を持つ場合も扱えること。
• 自拠点・自事業所。
• 全社。

技術面で重要な点がひとつあります。範囲の絞り込みは画面ではなく、データ取得の層で行うこと。ボタンを隠しても、APIを直接呼べる人は止められません。

権限が漏れやすい場所

確認方法：同僚のURLを自分のブラウザに貼り付けたとき、システムは拒否しなければなりません。ボタンが見えないからではなく、サーバーが断るからです。

• 帳票と出力。一覧画面は正しく絞られているのに、Excel出力だけ別の問い合わせを使い、絞り込みが抜けている。
• 横断検索。全社検索の入力欄は、閲覧権限のない取引先名やファイル名を非常によく漏らします。
• 通知とメール。通知文に、受信者がシステム上では見られない情報が含まれてしまう。
• 添付ファイルのURL。保管庫のパスが推測でき、ダウンロード時に権限を確認していない。
• 異動後に残る権限。部署を移った人が、誰も回収しないため古い権限を持ち続ける。

後から検証できる設計にする

権限は遮ることだけが目的ではなく、説明できることも目的です。最初から用意すべきものです。

• 利用者別の権限照会画面：いま何の権限を持ち、それはどの役割から来ているか。
• 権限変更の履歴：誰が、いつ付与したか。漏えい時に最初に求められる記録です。
• 機微データへのアクセス記録：誰が給与を開き、誰が取引先一覧を出力したか。
• 重要ルールの自動試験：主要な権限ルールごとに、権限のない利用者が拒否されることを確認する試験を置きます。

運用上の原則

• 既定は拒否。権限は明示的に与えるもの。権限属性を付け忘れた新しいエンドポイントは、全員が入れるのではなく、誰も入れない状態が正解です。
• 役割は少なく、仕事の名前で。「役割3」より「買掛担当」のほうが伝わります。
• 定期的に棚卸しする。四半期ごとに最高権限の利用者一覧を出し、上長に再確認します。
• 共用アカウントは死角。複数人がひとつのIDを使う瞬間、すべての記録は価値を失います。

最初に正しく設計すれば数日の追加で済みます。稼働後に作り直すと、これまで書いたすべての問い合わせを見直すことになり、費用ははるかに大きくなります。