← エピソード一覧に戻る Episode 185 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 権限設計は管理画面だけの話ではない
タカシ
今日は SaaS デザインの権限別UIです。多くの会社では権限をセキュリティ設定だと思いがちですが、実際には『誰に何が見えて、押せて、申請できるか』という日々の体験そのものなんです。同じ画面を全員に見せると、そこから事故が始まります。
ミカ
ああ、それ分かります。メニューは見えるのに押したら権限エラー、逆に本当は必要な機能がどこにも見えない、みたいな体験ってありますよね。あれって単なる不便じゃなくて、設計の問題なんですね。
タカシ
その通りです。権限別UIは、バックエンドの認可を利用者が理解できる形に翻訳する仕事です。見せる、隠す、説明する、頼めるようにする、この四つが揃って初めて、権限が業務を止めずに安全性を守れるようになります。
ミカ
なるほど。つまり『admin だけ別画面』みたいな話ではなくて、利用者、管理者、外部パートナー、それぞれの仕事の流れを壊さないための UI 設計なんですね。今日はその勘所を具体例で知りたいです。
Chapter 2 原則 ― 役割、リソース、課金を混ぜない
タカシ
まず重要なのは、権限は一段ではないということです。Notion は workspace role と page や teamspace の access level を分けていますし、しかも broadest level、つまり最も広い権限が優先されると説明しています。複数レイヤーを前提にしないと、管理画面はすぐ分からなくなります。
ミカ
権限って一つの肩書きで決まる感じがしていましたけど、実際は『会社全体での立場』と『このページで何ができるか』が別なんですね。そこを混ぜると、見えている理由も説明できなくなりそうです。
タカシ
さらに Figma は、billing is separate from permissions と明記しています。つまり seat は課金の単位で、team や file の permission は作業権限の単位です。この二つを UI 上で混ぜると、『編集できないのは料金の問題か、権限の問題か』が誰にも分からなくなるんです。
ミカ
それは経営にも効きますね。承認したつもりが課金まで増えていた、とか、逆に無料の閲覧席で足りる人まで有料にしていた、みたいなズレが起きるわけですもんね。
Chapter 3 実務 ― GitHubとSlackに学ぶ仕事単位の権限設計
タカシ
GitHub の repository roles は好例です。Read、Triage、Write、Maintain、Admin の五段階があり、Maintain は『運用管理は必要だが、破壊的操作までは不要』な担当向けと位置づけられています。つまり役職名ではなく、任せたい仕事で権限を分けているわけです。
ミカ
ああ、開発していなくても、課題整理やリリース調整はやる人っていますよね。その人に Admin を渡すのは重すぎるし、Read だけだと仕事にならない。その間をちゃんと用意するのが権限別UIなんですね。
タカシ
Slack も面白いです。Enterprise では一人に one or many system roles を追加できますし、guest には single-channel や multi-channel があり、自動 deactivation や custom deactivation date も設定できます。良い権限UIは『どこまで』だけでなく『いつまで』も扱うんです。
ミカ
権限って固定の肩書きじゃなくて、期間限定の仕事にも対応しないといけないんですね。外部の業者さんや一時プロジェクトの参加者に、ずっと強い権限が残るのは、たしかに怖いです。
Chapter 4 設計 ― 権限不足の瞬間こそ、UIの質が出る
タカシ
権限別UIの差が最も出るのは、できない瞬間です。Notion では guest 招待をメンバーが申請すると、workspace owner に page、role、email が通知されますし、Figma でも visible team への request access や seat request の導線があります。行き止まりにしない設計なんですね。
ミカ
分かります。『権限がありません』だけだと、そのあと Slack で管理者を探して説明して、って手作業になりますもんね。プロダクト内で頼めるだけで、かなり運用が楽になりそうです。
タカシ
Google Cloud の permission error messages も参考になります。拒否画面に、対象 resource、足りない permissions、候補となる role や entitlement、さらに request の導線まで出します。業務 SaaS でも、『何が足りないか』を説明できる UI はサポート負荷を大きく下げます。
ミカ
なるほど。押せない理由が分かるだけじゃなくて、誰にどう頼めばいいかまで見えるわけですね。禁止そのものより、次の一手があるかどうかで、体験の印象がかなり変わりそうです。
Chapter 5 まとめ ― 権限は安全装置であり、導線でもある
ミカ
今日の失敗パターンをまとめると、admin と member の二択で済ませる、見えない理由を説明しない、seat と permission を混同する、UI だけで守った気になる、そして申請フローをプロダクト外に逃がす、このあたりですね。
タカシ
ええ。まずは自社の主要画面を一つ選び、利用者、管理者、外部協力者、閲覧専用の四つで見え方を棚卸ししてみてください。そのうえで、非表示、表示するが不可、申請可能、実行可能の四段階で整理すると、改善点がかなり見えてきます。
ミカ
権限設計ってセキュリティ担当の領域に見えていましたけど、実際は PM、デザイン、CS、管理者運用が全部つながるテーマなんですね。導入のしやすさにも、問い合わせ数にも、かなり効きそうです。
タカシ
その通りです。権限は安全装置ですが、同時に業務導線でもあります。皆さんの SaaS でも、最重要の設定画面か共有画面を一つ開いて、『この人は今なぜ見えているのか』『足りない時にどう頼めるのか』を、ぜひ今日確認してみてください。