権限は役職名ではなく、業務上の役割・データの範囲・操作の種類で決めます。画面を見られることと、データを出力できることも分け、許可・禁止・未決定を表に残してから実装へ進みます。
権限を役職名だけで決めない理由
同じ役職でも担当業務が異なることがあり、反対に役職が違っても同じ作業を担当することがあります。「部長だから全部見られる」「担当者だから閲覧だけ」と一括りにすると、必要な情報まで隠れたり、不要な操作まで許したりします。
まずは業務の一場面を、次の三つに分けて書き出します。
- 誰が — 入力する人、確認する人、承認する人、全体を見る人
- 何を — 自分の担当、所属部署、全社、取引先など、対象となるデータの範囲
- 何ができるか — 見る、作成する、編集する、承認する、出力する、削除する
例えば申請業務なら、申請者は自分の下書きを作成・編集し、上長は担当範囲の申請を確認・承認し、管理担当は差し戻しや設定変更を行う、といった具合です。ここで重要なのは、実際の職名ではなく、業務上の役割として書くことです。組織変更があっても、役割と作業の対応を見直せば済むようになります。
設計表にして、判断を共有する
会議で口頭確認するだけでは、後から「そこまでできるとは思わなかった」というずれが起きます。最初は次のような表で十分です。
横幅が狭いときは左右にスクロールできます
| 役割 | データの範囲 | 閲覧 | 作成・編集 | 承認・出力 | 例外と確認者 |
|---|---|---|---|---|---|
| 入力担当 | 自分の担当分 | ○ | ○ | ― | 差し戻し後の再編集を許すか |
| 確認担当 | チームの担当分 | ○ | 必要時 | ○ | 承認後の変更を誰が行うか |
| 管理担当 | 全体 | ○ | ○ | ○ | 権限変更を記録するか |
| 閲覧担当 | 指定された範囲 | ○ | ― | ― | ダウンロードを許すか |
記号は仮置きで構いません。重要なのは、空欄を「禁止」と決めたのか、「まだ判断していない」のかを区別することです。とくに、画面を見られることと、データを出力できることは別の権限として扱います。業務上必要な操作だけを許し、不要な操作は後から追加できる状態にしておくと、仕様変更にも対応しやすくなります。
データの権限は「集めた後」まで考える
複数の部署やサービスからデータを集める場合は、集約した後の参照範囲も決めます。DEPARTUREのデータ活用・業務DXでも、データ基盤は集約して終わりではなく、部署や役割に応じて参照できる範囲を分ける設計まで含めて考えています。
このとき、次の点を確認します。
- 元データの所有者は誰か
- 加工後のデータを誰が見られるか
- 集計した数字と明細のどちらを見せるか
- ダウンロードしたファイルを誰が管理するか
- 退職・異動・委託終了時に、いつ権限を外すか
ダッシュボードの数字を見せるだけなら安全、とは限りません。表示の裏に明細が隠れていないか、出力機能から範囲外のデータを持ち出せないかも確認対象です。権限設計はシステムの完成直前ではなく、データの流れを決める段階で始めましょう。
実装前後の確認を段取りに入れる
権限は仕様書に書くだけでなく、実際の利用者の視点で確認します。次の順序で進めると、発注担当者と開発担当者の認識をそろえやすくなります。
- 要件整理：業務の開始から完了まで、登場する役割とデータを並べる
- 設計確認：役割ごとの許可・禁止・例外を表で確認し、未決定を残さない
- テスト：許可された操作だけで業務が完了するか、禁止した操作ができないかを試す
- 運用設計：権限申請、承認、変更、棚卸しを誰が行うかを決める
- 見直し：組織や業務が変わったとき、権限表と実装を照合する
テストでは「管理者で全部動く」だけを確認しないことがポイントです。入力担当、確認担当、閲覧担当など、実際の役割に近い利用者で画面を触り、業務が止まる箇所や見えてはいけない情報がないかを確認します。
権限設計は、機能一覧を作った後に付け足す項目ではありません。誰のどんな判断を支えるシステムなのかを整理し、必要な範囲から作ることで、使い始めてからの修正を減らせます。企業・ユーザー・ライセンス管理や認証・外部連携を含む構成の見方は、公開されている法人向けクラウドアプリ基盤のページも参考になります。要件が固まっていない場合も、作りたい仕組みの整理から相談することができます。