「誰がどの操作をできるか」を定義する。権限設定の要件漏れが招く、運用後の混乱

権限設定は要件定義で後回しにされやすい項目です。しかし「実はこのデータは課長以上しか見せてはいけなかった」という要件が開発後半に追加されると、プログラムの根本的な修正が必要になり、多額の追加費用が発生します。要件定義の段階で権限要件を固めるための考え方を整理します。

権限マトリクスで「誰が・何を・どうできるか」を可視化する

言葉だけで「適切に制限する」と決めても要件として機能しません。要件定義の段階で、以下のような「権限マトリクス」を作成し、現場責任者と合意することが必要です。

役割（ロール）	閲覧	作成・編集	削除	承認
システム管理者	○	○	○	○
部長・課長	○	○	○	○
一般社員	○	○	×	×
パート・アルバイト	○	×	×	×

このように「誰が（WHO）」「何を（WHAT）」「どうできるか（HOW）」を一覧表にすることで、要件の漏れや矛盾を早期に発見できます。また、ベンダーにとっても設計の根拠となる資料になります。

権限マトリクスを作る際は、業務単位で考えることが重要です。「受注管理」「在庫管理」「売上レポート」のように業務ごとに表を作り、それぞれの操作権限を定めることで、漏れを防げます。

権限は「個人ではなく役割（ロール）に紐づける」原則

権限設計を複雑にする最大の要因は、「○○さんだけは特別に」という個人に紐づいた例外処理です。

「本来は課長権限だが、ベテランのAさんには全操作を許可したい」「B店だけは特別に他店の在庫も見られるようにしたい」——こうした要望をそのままシステムに反映しようとすると、プログラムのロジックが複雑になり、人事異動や組織変更に対応できなくなります。

権限設計の原則は「役割（ロール）単位で設定し、個人の例外を作らない」ことです。特定の人物だけに特別な操作を認めたい場合は、「その業務上の必要性が永続的かどうか」を問い直してください。一時的な必要性であれば、運用上のルール（承認を得た上で上司が操作するなど）で対応することで、システムの複雑さを抑えられます。

セキュリティと利便性のバランス

権限を厳しく制限しすぎると、現場の利便性が下がり「業務が回らない」という問題が起きます。「上司が不在で承認できず、処理が止まった」という状況は、IT化によって業務が逆に非効率になる典型例です。

バランスを取るための考え方として、以下を参考にしてください。

閲覧権限は広めに設定する：機密情報（個人情報・給与データ・財務情報など）を除き、社内情報は広く参照できるようにします。情報共有のスピードが上がり、意思決定の質が高まります。

変更・削除権限は絞る：一度行ったら取り消しにくい操作（削除・承認・確定処理など）は、特定の職種のみに制限します。ミスによるデータ損失を防ぐことが目的です。

代理権限の仕組みを検討する：担当者の長期休暇や急病に備えて、「臨時の代理権限をどう付与するか」のルールも要件定義の段階で考えておく必要があります。個人への例外権限ではなく、「代理申請・承認のプロセス」として設計することで、原則を守りながら柔軟性を確保できます。

権限変更の運用手順も要件に含める

権限設定は一度作れば終わりではありません。人事異動・退職・新入社員の入社・組織変更といったイベントのたびに、権限の追加・変更・削除が発生します。

「誰が権限変更を申請し、誰が承認し、誰がシステムに反映するか」という運用プロセスを要件定義の段階で決めておかないと、リリース後に「このアカウントを削除するにはどうすればいいのか誰もわからない」という状況になりがちです。

退職者のアカウントが放置されてしまうケースは、実際の現場でよく起きる問題です。「退職発令と同時にアカウント無効化する」「権限変更は申請書ベースで処理する」といった運用ルールを、システムの要件定義と合わせて定めておくことで、リリース後の運用が安定します。

最初はシンプルな設定から始める

要件定義の段階から複雑な権限要件を盛り込みすぎると、テスト工程が膨大になり、バグの原因にもなります。最初は「必要最低限のシンプルな役割設定」からスタートし、実際に運用してみて「どうしても不都合がある部分」だけを追加していくアプローチが現実的です。

権限の細分化は後から追加できますが、一度複雑に作ったものを整理するのは難しくなります。「足し算の設計」を意識することで、保守性が高く現場が使いやすいシステムに仕上がります。

まとめ

権限設定は要件定義の早い段階で権限マトリクスを作成し、「誰が・何を・どうできるか」を可視化することが重要です。権限は個人ではなく役割単位で設計し、運用手順も含めて定義しておくことで、リリース後の混乱を防げます。最初はシンプルな設計から始め、運用の中で必要な部分だけを追加していくアプローチが、長期的に安定したシステム運用につながります。