業務システムの権限をどう決めるか ── 「誰に何を見せるか」を3段階で

「部長には全部見せて、営業は自分の担当分だけ。あ、でも単価は倉庫の人には見せたくないです」。権限の話は、たいてい画面ができ始めてから、こういう形で出てきます。どれも正しい要望です。ただ、思いついた順に足していくと、誰が何を見られるのかを説明できる人が社内にいなくなります。

この記事は、業務システムで「誰に何を見せ、何を変えさせるか」を決める手順の話です。通信の暗号化やパスワードの保存方法、バックアップといったセキュリティ全般は業務システムのセキュリティ、最低限どこまでやるかに6項目で書いたので、ここでは扱いません。決める順番は、役割、見せる範囲、変更できる操作の3段階です。

1. 役割を決める

最初に決めるのは、役割の数です。ここで人の名前や役職から入ると、役割がいくつあっても足りなくなります。分けるのは仕事のほうです。入力する人、確認する人、設定する人。課長でも毎日現場の報告を入れているなら、その課長は「入力する人」です。

数は2つか3つから始めます。私たちが想定例として公開している構成でも、現場報告は管理者とスタッフの2つ、取引先ポータルは運営と顧客企業の2つに絞っています。自社で運用している研修事業の業務コンソールは、使うのが3人で全員が同じ業務をするので、担当者ごとの権限分けはあえて作りませんでした。

役割を書き出して5つを超えたら、一度疑ってください。たいていは役割が違うのではなく、同じ役割の中で見せる範囲が違うだけです。「東京の営業」と「大阪の営業」は別の役割ではなく、同じ営業で範囲が違う。これを役割で分けると、拠点が増えるたびに役割も増えていきます。使う人を役割で分ける考え方そのものは、開発会社に相談する前に、決めておくと話が早い3つのことの1つ目にも書きました。

2. 見せる範囲を決める

範囲は、行と列の2方向で考えると整理しやすくなります。行は「どのデータを見られるか」で、全件、自分の部署の分、自分の担当分、取引先なら自社の分。列は「その中のどの項目を見られるか」で、単価や原価、個人の連絡先のような項目だけを隠す、という決め方です。

受発注の架空の想定例で考えると、倉庫の人は出荷に必要な注文だけが見えればよく、単価の列は要りません。営業は自分の担当する取引先の注文と単価、事務は全件。役割は4つでも、範囲を行と列で言えれば、表にしたときに1行で済みます。

ここで抜けやすいのが、画面以外の出口です。一覧から単価の列を消しても、CSV出力に単価が入っていれば見えてしまいます。検索や集計の画面から、隠したはずの行が数字として出てくることもあります。見せる範囲は画面ごとではなく、データの側で決めておくのが確実です。業務コンソールでも、データベース側で行ごとのアクセス制御を有効にして、画面の作りが変わっても見えてよい範囲が崩れないようにしています。

「この人は、この行だけ」という範囲が増えてくると、ノーコードの道具では設定が込み入ってきます。その線はノーコードで作るか、開発するかの4つ目の形として書きました。

3. 変更できる操作を決める

見られることと、変えられることは別です。操作は、登録、編集、状態を進める（確定や承認）、確定後の修正、CSV出力、利用者の追加と停止、くらいに分けて考えます。

私たちがまず提案するのは、削除をどの役割にも渡さないことです。間違えて入れた注文は「取り消し」の状態にして、データとしては残す。消えたものは、誰が何をしたのかを後から追えません。

確定後の修正も、管理者だけに絞ることが多いです。月次で締めた数字を誰でも直せると、締めた意味がなくなります。直すときは、誰がいつ何を変えたかが履歴に残るようにします。

CSV出力は、見落とされがちですが「見る」より強い操作です。画面で見られる人と、ファイルにして社外に持ち出せる人は、分けて考えたほうがいい。最初は事務と管理者だけにして、必要な人が出てきたら足す順番にしています。

取引先や現場の人が使う場合

社内の事務所だけで使うシステムと、取引先や現場の人が触るシステムでは、権限で気をつける場所が変わります。

使う人	見せる範囲の基本	操作の基本	気をつけること
社内の事務所	全件、または部署の分	登録・編集・出力	出力できる人を絞る
現場・外回り	自分の担当分、今日の分	入力と、自分の履歴の確認	端末を共有しても、ログインは1人ずつ
取引先	自社の分だけ	依頼や発注の登録、状況の確認	会社単位で範囲を決める。招待と停止を誰がするか

取引先の場合、行の制限は絶対の条件です。他社の名前や単価が一度でも見えれば、それだけで信用の問題になります。取引先の中に担当者が何人もいるなら、人ではなく会社の単位で範囲を決め、その会社の担当者を招待する形にします。受発注のように社内の業務へ取引先の画面を足す場合、社内なら口頭で済むことを全部画面に載せる必要があるので、私たちは別の業務フローとして数えています。

現場で気をつけるのは、共有のアカウントです。事務所のタブレットを3人で使うから、ログインも1つで、という形にすると、誰が入れた報告なのかが残りません。端末は共有でも、ログインは1人ずつにします。

退職者と異動のアカウント

辞めた人のアカウントは、削除ではなく停止にします。削除すると、その人が登録した注文や報告から「誰が入れたか」が追えなくなるからです。停止ならログインだけができなくなり、履歴は残ります。止める手順そのものを誰が持つかは、セキュリティの記事の6つ目に書いたとおりです。

設計の側で決めておきたいのは、担当の付け替えです。「自分の担当分だけ見える」設計にしていると、辞めた人が担当していた取引先や案件は、付け替えるまで誰の一覧にも出てきません。管理者が担当者をまとめて別の人に移せる操作を、最初から用意しておきます。異動も同じで、役割を付け替えたときに前の部署の範囲が残っていないかを確かめる手順が要ります。

最初から細かく分けすぎない

権限は、細かくしようと思えばいくらでも細かくできます。ただ、分けた分だけ画面の分岐とテストが増え、使い始めてから「この画面が見えなくて仕事が止まる」が起きやすくなります。最初は役割を2〜3つ、範囲は全件と自分の担当分、削除はなし、出力は管理者だけ。そのかわり、誰が何を変えたかを履歴に残す。細かく制限する代わりに、追えるようにしておく考え方です。

ひとつだけ、最初にやっておくことがあります。データに担当者と部署を持たせておくことです。これがあれば、あとで「部署ごとに見える範囲を変えたい」となっても、変更は小さく済みます。逆に開発の途中で権限の階層を深くするのは、触る画面が多くなるので、仕様変更が追加費用になる線引きのとおり見積もりを出し直す側に入ります。

ログインと権限の設定は、私たちの初期費用に標準で含まれています。業務を2つ以上入れる場合は、利用者と権限を管理する画面を1枚として数えます。誰に何を見せるかは、初回のお打ち合わせ（60分・オンライン可）で役割を書き出すところから一緒に決め、3営業日以内にお出しする画面構成のラフに反映します。ここまで費用はいただきません。