「誰がどの操作をできるか」を定義する。権限設定の要件漏れが招く、運用後の混乱
システム開発の要件定義において、「機能」の議論は盛り上がりますが、意外と後回しにされがちなのが 「権限（認可）設定」 です。「誰がそのボタンを押せるのか」「誰がそのデータを見られるのか」というルール作りです。
しかし、プロジェクトの終盤になって「実はこのデータは課長以上しか見せてはいけなかった」「営業事務は入力はできるが、削除はできないようにしてほしい」といった要望が追加されると、プログラムの根本的な修正が必要になり、多額の追加費用が発生します。
1. 権限定義を「マトリクス（表）」で可視化する
言葉だけで「適切に制限する」と決めても意味がありません。要件定義の段階で、以下のような 「権限マトリクス」 を作成し、現場リーダーと合意することが必須です。
| 役割（ロール） | 閲覧 | 作成・編集 | 削除 | 承認 |
|---|---|---|---|---|
| システム管理者 | 〇 | 〇 | 〇 | 〇 |
| 部長・課長 | 〇 | 〇 | 〇 | 〇 |
| 一般社員 | 〇 | 〇 | × | × |
| パート・アルバイト | 〇 | × | × | × |
このように「誰が（WHO）」「何を（WHAT）」「どうできる（HOW）」を一覧表にすることで、要件の漏れや矛盾が一目でわかるようになります。
2. 組織図の「例外」をどこまで許容するか
権限設計を複雑にする最大の要因は、「〇〇さんだけは特別に……」という個人に紐づいた例外処理です。
- 「本来は課長権限だが、ベテランの Aさん には全ての操作をさせたい」
- 「B店だけは特別に、他店の在庫も見られるようにしたい」
こうした例外をそのままシステムに反映しようとすると、プログラムのロジックが複雑怪奇になり、将来の組織変更や人事異動に対応できなくなります。 ITリーダー は、 「権限は個人ではなく、役割（役職）に紐づける」 という原則を死守し、現場のわがままを「運用のルール」で解決するよう誘導すべきです。
3. セキュリティと利便性のトレードオフ
ガチガチに権限を縛りすぎると、現場の利便性が著しく低下します。「上司が不在なので、データの修正ができず業務が止まった」という事態は、 IT化 の本末転倒です。
- 参照権限は広めに: 社内の情報共有を促進するため、機密情報（個人情報や給与データ等）以外は、できるだけ全社員が見られるように設定する。
- 更新・削除権限は厳めに: ミスによるデータの損失を防ぐため、取り消しのきかない操作は特定の職職のみに制限する。
まとめ：権限は「後から増やす」のが正解
最初から複雑な権限要件を盛り込みすぎると、テスト工程が膨大になり、バグの温床になります。 要件定義の段階では 「必要最低限のシンプルな役割」 からスタートし、運用しながら「どうしても不都合がある部分」だけを細分化していく。
この「足し算の設計」を意識することで、保守性が高く、かつ現場がストレスなく使える「身の丈に合ったシステム」を実現できます。