業務システムの権限設計は、最初に曖昧なまま進めると、運用開始後に必ず見直しが必要になります。 「本当は見せたくない情報があるが、現場では確認できないと対応できない」「削除できないと困る場面はあるが、誰でも削除できる状態にはしたくない」。 こうした矛盾は、単純な「管理者／一般ユーザー／閲覧のみ」の分類だけでは扱いにくくなります。
権限を検討するときは、ロール（何ができるか）だけでなく、スコープ（どこまでできるか）と、例外承認（通常は禁止だが、承認があれば可能にする操作）を分けて考える必要があります。
この記事では、問い合わせ管理、予約管理、見積・受注管理など、複数部署が使う業務システムを前提に、現場運用に耐えやすい権限設計の考え方を整理します。
ロールだけで権限を決めると、最初はシンプルに見えます。 しかし、拠点・部署・担当者・案件種別が増えると、すぐに判断が難しくなります。
そこで、権限は次の3軸に分けて考えます。
閲覧、作成、編集、削除、承認、出力、設定変更など、操作そのものを定義します。
自分の案件、部署内、拠点内、全社など、操作対象の範囲を定義します。
代理対応、緊急対応、金額変更、削除などを承認付きで許可する仕組みを用意します。
この3軸を分けると、「一般ユーザーだが自部署の案件は編集できる」「管理者だが削除には承認が必要」「全社を閲覧できるが、個人情報は一部伏せる」といった現実的な設計がしやすくなります。
実務で問題になりやすいのは、削除権限です。 閲覧や編集と同じ感覚で削除を許可すると、誤操作や確認漏れが起きたときに復旧しにくくなります。
基本的には、物理削除ではなく「非表示」「アーカイブ」「無効化」を標準にする方が安全です。 どうしても削除が必要な場合は、削除権限だけでなく、削除理由、承認、監査ログをセットで設計します。
| 操作 | 通常ユーザー | 部門管理者 | システム管理者 | 設計時の注意点 |
|---|---|---|---|---|
| 閲覧 | 担当案件のみ | 部署内 | 全社 | 個人情報や金額情報は、閲覧範囲を別途制御する。 |
| 編集 | 担当案件のみ | 部署内 | 全社設定以外 | 金額・ステータス・担当者変更は個別に制御する。 |
| 削除 | 不可 | 承認付き | 限定的に可 | 原則はアーカイブ。削除時は理由とログを必ず残す。 |
| 承認 | 不可 | 部署内 | 全社 | 承認者本人の操作を承認できないようにする。 |
監査ログの前提が曖昧な場合は、監査ログ設計を先に決めておくと、権限の議論が進めやすくなります。 「誰に何を許すか」だけでなく、「後からどう確認できるか」を同時に考えることが重要です。
スコープは、見える範囲と操作できる範囲を分けて考えると設計しやすくなります。 「閲覧は部署内まで可能だが、編集は自分の担当案件のみ」といった分け方です。
問い合わせ管理ダッシュボードで担当者割当を扱う場合は、担当者割当ロジックとセットで「誰が、どの範囲の担当者へ割り当てできるか」を決めておく必要があります。 ここを後回しにすると、運用開始後に担当変更や代理対応の判断がぶれやすくなります。
権限を厳しくしすぎると、日常業務が止まる場面があります。 担当者不在、緊急対応、価格変更、他拠点の代理対応など、通常権限だけでは対応できないケースがあるためです。
このとき、個別に管理者へ依頼して手作業で権限を変える運用にすると、履歴が残りにくく、許可を戻し忘れることもあります。 例外承認は、申請・承認・期限付き許可・ログ記録までを一つの流れとして設計しておく方が安全です。
対象案件、必要な操作、理由、希望期限を入力します。
上長または管理者が、理由と対象範囲を確認して判断します。
24時間など、期限を決めて一時的に操作を許可します。
申請者、承認者、操作内容、期限、結果を記録します。
権限設計は、業種ごとの業務フローによって注意点が変わります。 同じ「編集権限」でも、見積金額を変える編集、作業ステータスを変える編集、顧客情報を修正する編集では、リスクが異なります。
卸売・商社では、見積、受注、分納、直送、バックオーダー、請求条件などが関係します。 営業担当は案件情報を更新できる必要がありますが、与信、掛率、請求条件、出荷指示まで自由に変更できると問題が起きやすくなります。
業務像を先に確認するなら、卸売・商社（BtoB企業）向けWebシステム活用アイデアのように、情報の出し分けを前提に考えると権限の境界が決めやすくなります。
自動車販売・整備・タイヤショップでは、受付、入庫、ピット割当、部品手配、作業記録、会計、引き渡しまで複数の工程があります。 現場スタッフには工程更新が必要ですが、請求金額や割引、作業実績の修正は別の権限として扱う方が安全です。
全体像は 自動車販売・整備・タイヤショップ向けWebシステム活用アイデア のような業務イメージから入ると、画面ごとの操作権限に落とし込みやすくなります。
権限設計は、「できる／できない」を表にするだけでは不十分です。 運用後に問題が起きたとき、誰が、いつ、何を見て、何を変更し、誰が承認したのかを確認できる必要があります。
レポートや出力の観点まで踏まえるなら、問い合わせ集計レポートの作り方のように、「集計に必要な権限」と「外部に出してはいけない情報」を先に分けておくと安全です。 画面上では見えない情報が、CSV出力では含まれてしまうケースもあるため、出力権限は閲覧権限とは別に確認します。
現場で扱いやすい権限設計は、ロールだけでは作れません。 ロール（何ができるか）、スコープ（どこまでできるか）、例外承認（通常外の操作をどう扱うか）を分けて設計し、削除や金額変更、CSV出力のような重要操作は個別に制御する必要があります。
閲覧、作成、編集、削除、承認、出力など、操作単位で分けます。
自分の案件、部署、拠点、全社など、対象範囲を明確にします。
代理対応や緊急対応を、申請・承認・期限付き許可で扱います。
最後に、監査ログと合わせて「後から説明できるか」を確認します。 誰が何をしたか、誰が承認したか、どの範囲まで許可されていたかが分かる状態にしておけば、権限のトラブルが起きたときも確認しやすくなります。
インテンスのように運用設計まで踏み込む場合、権限はリリース直前に足すものではなく、データ構造・画面設計・ログ設計と同じタイミングで検討する方が、後からの修正範囲を抑えやすくなります。