権限設計の実務ガイド｜ロール×スコープ×例外承認で破綻しない運用を作る

権限設計は、最初に適当に決めると後で必ず破綻します。
「本当は見せたくないが、現場は見ないと回らない」「削除できないと困るが、削除できると事故る」——この矛盾を解くには、権限をロール（役割）だけで考えないことが重要です。
本記事では、ロール×スコープ×例外承認の3軸で、現場運用に耐える権限設計の型を整理します。

1. 権限設計は「ロール」だけで決めない

ロール（例：管理者/一般/閲覧）だけで権限を決めると、次の問題が起きます。

• 拠点が複数あると「他拠点が見える/見えない」で揉める
• 部門横断対応（営業→技術→管理）で“触る必要”が増える
• 例外対応（代理対応、緊急対応）を想定していない

そこで、権限は次の3軸で整理すると一気に現実的になります。

• ロール：何ができるか（閲覧/作成/編集/削除/出力/設定）
• スコープ：どこまでできるか（自分の案件のみ/部署/拠点/全社）
• 例外承認：通常は禁止だが、承認があれば可能（上長/管理者承認）

2. ロール設計：まず「削除」を分離する

実務で事故が起きやすいのは削除です。まずは削除の扱いを切り出します。

• 削除ではなく「非表示（アーカイブ）」を基本にする
• 削除が必要な場合は、削除権限＋削除理由＋監査ログをセットにする
• 削除は“誰でもできる”にしない（運用で必ず事故る）

監査ログの前提が曖昧な場合は、監査ログ設計を先に固めておくと、権限議論が早く収束します。

3. スコープ設計：拠点/部門/担当の「境界」を明示する

スコープは“見える範囲”と“触れる範囲”を分けると設計が楽です。

3-1. よくあるスコープパターン

• 担当スコープ：自分が担当の案件のみ編集可（閲覧は部署まで）
• 部署スコープ：部署内の案件は編集可、他部署は閲覧のみ
• 拠点スコープ：拠点内は編集可、他拠点は不可（または匿名化閲覧）
• 全社スコープ：全件閲覧＋一部操作（例：重複統合、監査出力）

例えば、問い合わせ管理ダッシュボードで担当者割当を扱うなら、担当者割当ロジックとセットで「割当できる範囲」を決めないと、属人化と事故が増えます。

4. 例外承認：現場が回る“逃げ道”を設計に組み込む

権限を厳しくすると現場が止まります。そこで必要なのが例外承認です。
例外承認を設計に入れておくと、運用側は「ルールを破らずに回す」ことができます。

4-1. 例外承認が必要になりやすい場面

• 担当者不在（休暇/退職）で代理対応が必要
• 緊急対応で他拠点の案件を一時的に触る必要
• 価格や条件の変更など、承認が要る更新

5. 業種別に権限が揉めやすいポイント（例）

5-1. 卸売・商社（BtoB企業）

見積や受注が分納・直送・バックオーダーで複雑になり、「誰がどこまで編集できるか」が揉めやすい領域です。
業務像を先に揃えるなら、卸売・商社（BtoB企業）向けWebシステム活用アイデアのように“情報の出し分け”を前提に考えると、権限の境界が決めやすくなります。

5-2. 自動車販売・整備・タイヤショップ

受付→入庫→ピット割当→部品手配→会計→引き渡し、のように工程が多く、現場の手戻りも起こりやすい領域です。
「現場スタッフは工程更新はできるが、請求金額や割引は触れない」「管理者は金額変更できるが、作業実績の改ざんはできない」など、分離すると安全です。
全体像は 自動車販売・整備・タイヤショップ向けWebシステム活用アイデア のような業務イメージから入ると、権限設計が現場言葉に落ちます。

6. 権限とログはセット：最後に“説明できるか”で確認する

権限設計は「できる・できない」ではなく、後から説明できるかで合否が決まります。

• 誰が何をしたか、監査ログで追えるか
• 例外承認の記録（申請/承認/期限）を残せるか
• 閲覧制限がある情報が、CSV出力で漏れないか

レポートや出力の観点まで踏まえるなら、問い合わせ集計レポートの作り方のように「集計に必要な権限」と「情報漏えいしない出力」を先に決めておくと安全です。

まとめ

現場で壊れない権限設計は、ロールだけでは作れません。
ロール（何ができるか）×スコープ（どこまでできるか）×例外承認（逃げ道）で整理し、削除を分離し、監査ログとセットで“説明できる運用”に落とし込むことが重要です。
インテンスのように運用設計まで踏み込む場合、権限は「最後に足す」ではなく、データ構造と同時に決めるのが結局いちばん安いです。