このユニットの結論
権限は、人ごとに1つずつ決めるのではなく、仕事の種類（役割）ごとに決め、人には役割を割り当てるように設計します。
こうすると、入社・異動・退職のたびに一から考えなくて済み、「誰が何をできるか」を説明しやすくなります。ただし、役割を細かく作りすぎると、かえって管理できなくなります。
1. 何の話か
このユニットは、役割にもとづく権限の設計の話です。英語では Role-Based Access Control（RBAC）と呼ばれます。
数十人ならともかく、利用者が非常に多いシステムで、1人ずつ権限を決めていては、管理が追いつきません。そこで、「案件の担当」「案件の承認者」「経理の担当」のような役割を作り、役割に権限をまとめます。
2. なぜ必要か
人ごとに権限を決めると、
- 同じ仕事をしている人どうしで、権限がばらばらになる
- 異動のたびに、前の権限を外し忘れる
- 監査で「この人はなぜこの権限を持っているのか」を説明できない
- 権限の組み合わせを確かめられず、1人で登録から承認までできてしまう人が出る
ということが起きます。
3. このユニットで分かること
- 役割の作り方
- 1人に持たせてはいけない役割の組み合わせ（職務の分離）
- 入社・異動・退職と役割の管理
- 役割の設計で、AIに任せてよいことと人間が決めること
4. 役割の作り方
一般的には、次の手順で作ります。
- 業務の流れを見て、仕事の種類を洗い出す（人の名前や役職からではなく、仕事から）
- 仕事の種類ごとに、必要な操作とデータの範囲を決める（08-02）
- 似た役割はまとめ、違いが大きいものは分ける
- 役割に名前と説明を付ける（誰が見ても、どんな仕事の人か分かるように）
- 業務の責任者に確かめてもらう
役割の数は、少なすぎると権限が広くなり、多すぎると管理できなくなります。「1人のための役割」が増えてきたら、設計を見直すサインです。
5. 1人に持たせてはいけない組み合わせ
誤りや不正を1人で完結できないように、一緒に持たせない役割を決めます。これを「職務の分離」と呼びます。
| 組み合わせの例（教材上の例） | 持たせない理由 |
|---|---|
| 登録する役割 と 承認する役割（同じ対象） | 自分で登録したものを、自分で承認できてしまう |
| 権限を設定する役割 と 業務の役割 | 自分に権限を足して、業務の操作ができてしまう |
| 支払いを登録する役割 と 支払先を登録する役割 | 架空の支払先を作り、支払いを登録できてしまう |
組み合わせのルールは、役割を割り当てるときに確かめる仕組みにします。
6. 入社・異動・退職と役割
- 入社：仕事に合わせた役割を割り当てる。申請と承認の記録を残す
- 異動：新しい役割を割り当てると同時に、前の役割を外す（「足すだけ」にしない）
- 退職：すべての役割とアカウントを止める
- 定期的な見直し：上司が、部下の役割が今の仕事に合っているかを確かめる
人事の情報（在籍・所属）と役割の割り当てが連動していると、外し忘れが減ります。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 従業員 約4,000名
- SYS-05 人事マスターシステム、SYS-08 認証・ID基盤
- IF-03 社員・組織マスター連携：人事 → 新基幹、IF-10 認証・ID → 新基幹
- 社員・組織のデータの正本は人事マスター
- Vendor B の担当範囲に IAM が含まれる
アステリア案件の役割の一覧、職務の分離のルール、人事の情報と役割の割り当ての連動のしかたは、正本に記載がありません。未確定 従業員数は、システムの利用者数ではありません。
7. THINK — 「部長だけの特別な役割」
役割の設計の打ち合わせで、ある部長から要望がありました。
「私は部長なので、部下が見られるものは全部見られるようにしたい。部長専用の役割を作ってほしい。ついでに、急ぎのときは私が代わりに登録もできるようにしてほしい。」
問題
この要望のとおりの役割を作ってよいでしょうか。
判断例を開く
判断
そのまま作る前に、分けて考えます。
確認すること:
- 部長の仕事として、見る必要があるのはどの範囲か（部下が見られるものすべてが必要か）
- 「代わりに登録する」ことと、部長として承認することを、同じ人が持ってよいか
- 同じような要望が、ほかの部長からも来たときに、同じ役割で足りるか
- 急ぎのときの代わりの登録は、役割ではなく、一時的な権限の手続きで扱えないか
役職ごとに役割を作ると、職務の分離が崩れたり、役割の数が増えすぎたりします。仕事の種類から考えます。
8. よくある失敗
- 人の名前や役職ごとに役割を作り、役割の数が増えすぎる
- 異動のときに、新しい役割を足すだけで、前の役割を外さない
- 職務の分離のルールを決めても、割り当てのときに確かめる仕組みがない
- 役割の説明がなく、何ができる役割なのかが分からない
9. 成果物との接続
- SEC-002 権限設計表：役割の一覧と、役割ごとの権限、持たせない組み合わせ
- PRG-004 役割・責任分担表：プロジェクトの中の役割と責任（システムの権限とは別のものですが、「役割で考える」点は共通しています）
10. AI WORKFLOW — 役割の割り当ての点検を手伝わせる
AIは、役割の割り当ての一覧を、ルールに照らして点検する下書きに役立ちます。
指示例:
「次の役割の割り当ての一覧と、持たせてはいけない役割の組み合わせのルールを比べ、①ルールに反する組み合わせを持つ人、②所属が変わったのに前の部署の役割が残っている可能性がある人、を挙げてください。役割を外すかどうかは判断しないでください。」
11. REVIEW — AIの指摘を確認する
- AIが挙げた人を、人が元の一覧で確かめたか
- ルールの例外として正式に認められたものが、誤って挙げられていないか
- 一覧を AI に渡してよいか（個人の情報の扱い）を、事前に確かめたか
12. 人間が判断すること
- どんな役割を作り、それぞれに何を許すか
- 持たせてはいけない組み合わせのルール
- ルールの例外を認めるか
セキュリティ例外承認は、AIへ最終委任しない事項です（正本の方針）。
13. 判断演習
あなたは、役割の設計の担当です。
「案件を登録する」「案件を承認する」「案件の原価を確認する」という3つの仕事があります。役割をいくつ作り、どの組み合わせを1人に持たせないか、理由とともに書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
権限は、仕事の種類（役割）ごとに決め、人には役割を割り当てます。
1人に持たせてはいけない組み合わせを決め、異動・退職のときは役割を外すところまでを管理します。