発注・外注の進め方
社内ツールの権限設計｜小規模でも最初に決めておくべきアクセス権限
「社内の人しか使わないから、全員が全部見られれば十分」――小規模な社内ツールでは、権限の設計が後回しにされがちです。ところが運用を始めてから、「給与に関わる情報が全員に見えていた」「誰かが誤ってデータを削除した」といった問題が起き、慌てて権限を追加することになります。小規模なツールでも最初に決めておきたい権限の考え方を、権限表の例とあわせて紹介します。
権限は3つの組み合わせで考える
権限は、次の3つの組み合わせで整理すると考えやすくなります。
| 要素 | 例 |
|---|---|
| 誰が（役割） | 管理者、一般利用者、承認者、経理担当、外部の委託先 |
| 何を（データ） | 顧客、案件、見積、請求、社員情報、設定 |
| どうできるか（操作） | 閲覧、登録、編集、削除、出力（CSVなど）、承認 |
役割は、役職ではなく業務上の役割で考えるのがおすすめです。役職で分けると、兼務や異動のたびに権限の見直しが必要になります。
小規模なツールは「2種類」から始める
最初から細かく権限を分けると、設計とテストの量が増え、運用も複雑になります。小規模な社内ツールでは、まず次の2種類から始め、必要が出てきたら細かくするのが現実的です。
- 管理者：すべてのデータの閲覧・編集・削除、利用者の管理、設定の変更
- 一般利用者：業務に必要なデータの閲覧・登録・編集（削除や設定の変更はできない）
そのうえで、次のような要件があれば、最初から伝えておきます。
- 特定の人にしか見せてはいけない情報がある（給与、原価、個人情報など）
- 担当者は自分の担当分だけ見られればよい
- 承認が必要な操作がある
- 社外の人（取引先、委託先）も使う
権限表のひな形
役割とデータの組み合わせを表にすると、関係者の間で認識を揃えやすくなります。
| データ | 管理者 | 一般利用者 | 経理担当 |
|---|---|---|---|
| 顧客 | 閲覧・登録・編集・削除・出力 | 閲覧・登録・編集 | 閲覧 |
| 案件 | 閲覧・登録・編集・削除・出力 | 担当分のみ閲覧・編集 | 閲覧 |
| 請求 | 閲覧・編集・出力 | なし | 閲覧・登録・編集・出力 |
| 設定・利用者管理 | すべて | なし | なし |
上の表は書き方の例です。すべてのマスを埋める必要はなく、「ここは見せてはいけない」「ここは編集させたくない」という部分が分かれば十分です。
見落としやすい3つのポイント
削除の権限
誤操作による削除は、取り返しのつかない事故につながります。削除は管理者だけにする、削除ではなく「無効」にする、削除の前に確認を挟む、といった方法で守ります。
データの書き出し（出力）の権限
CSV出力は便利な反面、データをまとめて持ち出せる機能でもあります。顧客情報などを含むデータの出力は、必要な人に限るのがおすすめです。
退職者・異動者のアカウント
退職した人のアカウントが使える状態のまま残っていると、情報漏えいのリスクになります。アカウントを停止する手順と、担当者を決めておきます。担当していたデータの引き継ぎ方法もあわせて考えておきましょう。
権限の細かさと費用の関係
権限は、開発費とテストの量に直結します。権限の種類が増えるほど、画面ごと・データごと・操作ごとに「誰ができるか」を作り込み、確認する必要があるためです。
| 権限の細かさ | 作業量の目安 |
|---|---|
| 全員が同じ権限 | 小さい |
| 管理者と一般利用者の2種類 | 比較的小さい |
| 担当者ごとに見える範囲を分ける | 中程度 |
| 部署・役割・取引先ごとに細かく制御する | 大きい |
方針だけでも早めに決めておくと、見積もりがぶれにくくなります。費用の決まり方全体は業務用Webアプリ開発の費用はどう決まる？で解説しています。管理画面の設計は管理画面の開発で決めるべきこと、ログインやパスワードなどの基本的な対策は小規模な社内Webアプリのセキュリティをご覧ください。
権限を決めるときの進め方
- 使う人の役割を書き出す：入力する人、確認する人、承認する人、閲覧だけの人、社外の人
- 扱うデータを書き出す：顧客、案件、見積、請求、設定など
- 見せてはいけない組み合わせに印をつける：給与、原価、個人情報など、限られた人だけが見るべきもの
- 権限表にまとめる：役割とデータの組み合わせごとに、できる操作を書く
- 運用のルールを決める：権限を付与・変更・停止する担当者と手順
最初から完璧な権限表を作る必要はありません。「ここは見せてはいけない」「ここは削除させたくない」という部分が明確になっていれば、残りは開発会社と相談しながら決められます。
運用を始めてから権限を変えるとき
運用を始めると、「この人にも見せたい」「この操作は担当者にも許可したい」といった変更が出てきます。権限の変更は、利用者の画面や操作に直接影響するため、次の点に気をつけましょう。
- 権限を変更できる人を、管理者に限定しておく
- 誰の権限を、いつ、なぜ変えたかを記録しておく
- 新しい役割を追加する場合は、既存の役割との違いを明確にする
- 一時的に付与した権限（休暇中の代理など）は、期間が終わったら元に戻す
権限の種類を後から増やす可能性があるなら、最初の版の段階でその見込みを開発会社に伝えておくと、変更しやすい作りにできます。
社外の利用者がいる場合の注意
取引先や委託先など、社外の人にも使ってもらう場合は、権限の設計をより慎重に行う必要があります。社外の利用者には、自社に関係するデータだけを見せる、操作できる範囲を必要最小限にする、アカウントの発行と停止の手順を明確にする、といった点を最初に決めておきます。社内向けの権限と同じ考え方で後から追加すると、意図しない情報が見えてしまうおそれがあります。社外の利用者がいる可能性があるなら、最初の版に入れなくても、最初の相談の段階で伝えておきましょう。
権限の考え方は、顧客向けのマイページを作る場合にも同じように役立ちます。顧客ごとに見える情報を分ける設計については、顧客向けマイページ・ポータルを作るには？で解説しています。
権限表のたたき台づくりから手伝います
「この情報は経理だけ」「削除は管理者だけ」といった方針が一つでも決まっていれば、そこから権限表のたたき台を作れます。Tailboneでは、誰がどのデータを扱うかを伺いながら、最初の版で必要な権限と、後から細かくする部分を分けて整理します。
よくあるご質問
役職ごとに権限を分ける必要がありますか？
必ずしも役職ごとに分ける必要はありません。権限は役職ではなく、業務上の役割（入力する人、確認する人、承認する人など）で考えるほうが、運用の変化に対応しやすくなります。役職と役割が一致する場合は、同じ分け方でも構いません。
担当者ごとに、自分の担当分だけを見られるようにできますか？
できます。データごとに担当者を記録し、担当者は自分の分だけ、管理者は全員分を見られる、といった制御が可能です。ただし、担当の変更や、休暇中の代理の扱いなど、運用のルールもあわせて決めておく必要があります。
誰がいつ何を変更したかを記録できますか？
操作の履歴を残す仕組みを作れます。どの操作を、どの程度の詳しさで残すかによって作業量が変わるため、特に重要なデータ（金額、ステータス、個人情報など）から優先して検討するのがおすすめです。