ロールベースでSaaSの権限設計を考える
この記事はGoodpatch Design Advent Calendar 2021 15日目の記事です。
デザイナーとしてサービスを作っていく中では、UIだけでなくサービスのルールを含め最適なものはなんなのか考えていく必要があります。
その中でもSaaS系のプロダクトなどでは権限の構造の設計はとても重要な部分の一つです。
権限設計の重要性は以下のような部分からくるでしょう。
権限のルールはそのサービスを使ってユーザーができることを制御するものなので、ローンチしてから拡張、変更していくことにリスクが大きく容易でない。
サービスを実際に使用する組織に権限のルールがフィットするかプロダクトの成功の鍵となる可能性がある。特に規模の大きい組織などではからサービス自身の価値よりも会社での統制運用の価値評価される可能性がある。運用コストの高さは脆弱性と相関がある。
つまり、後から変えられないけど、サービス導入の大きな判断基準になる部分なのです。
UIをデザインする上でも権限のルールを理解し、ユースケースにあったものにしていくことが重要です。
今回はそんな権限設計について私が考えたことをシェアします。
前提
本記事で考慮するのは、ワークスペースのような概念があり、その中に複数のユーザーが所属していて、特別な権限を持ったユーザーのみがスペース自体の管理を行うという構造のサービスです。
具体的にはZoom、Slack、Discordなどのコミュニケーションツールをはじめ、Miro、Figmaのようなコラボレーションツール、Google Driveなどの共有ストレージ、Notionなどのプロジェクトマネジメントツールなども含まれます。
※記事タイトルはSaaSの権限設計としていますが、記事の内容はSaaSのみに当てはまるものではありませんし、SaaSなら全て当てはまる訳でもありません。
オブジェクトとアクション
OOUIの考え方に従うと、ソフトウェア内で行われることは全て、オブジェクトへのアクションだと説明できます。それはワークスペースのような概念のあるサービスでも同じです。
ただし、組織で利用されるSaaSなどではできるアクションが各ユーザー間で異なっている必要がある場合があります。
ワークスペース内で勝手なことをされると困るので、管理者に当たるユーザーが各ユーザーが各オブジェクトに対して行えるアクションを制御したいというニーズがあるからです。
この時対象になるオブジェクトは管理画面内のものだけでなく、表側にあるオブジェクトに対するアクションもふくまれます。
ロールとは何か
スペース型のサービスではよく、ユーザーにアドミン、メンバー、ゲストなどなどのようなロールを与えることが多くあると思います。このロールというものがある意義を考えて見ると、対象にさまざまなアクションを許可したい管理者が逐一アクションの設定をせずともアクション権限が束になったロールというものを与えるだけで設定が完了するためのショートカットのようなものだと考えられます。
なのでアクションの束がユースケースを網羅できるようにロールを設計する必要があります。
このようにサービス内でユーザーができることをロールという概念を付与して制御するという考え方をRole-Based Access Control（ロールベースアクセス制御 / RBAC）というようです。
ロールベースアクセス制御（RBAC）システムは、システム内のユーザーのロールに応じてアクセスとアクションを割り当てます。同じロールを付与されたすべてのユーザーは、同じ権限セットを持ちます。異なるロールを付与されたユーザーは、異なる権限を持ちます。
私たちデザイナーが使っている言葉で考えてみるとRBACの"A"は”Action”だと考えてみてもいいかもしれませんね。
権限モデルで構造を図示
権限の設計はなかなか複雑に感じてしまうことがあります。
もちろんそれは考慮するべきことがたくさんあることも一因でしょうが、もう一つ大きな要因として、権限設計を行う際に使う言葉のややこしさがあると思います。
例えば
デフォルトでメンバーはユーザーリストを閲覧する事ができる
アドミンはメンバーのユーザーリストの閲覧権限を有効化/無効化できる
アドミンはメンバーのユーザーリストの編集権限を有効化/無効化できる
のような言葉が使われたりしますが、こういったものは直感的に理解しにくい言葉にどうしてもなってしまいます。
そこで私は、このような言語を理解しやすい形にするために図示してみています。（私はこれを権限モデルと呼んでいます）
この図はOOUI的な考え方に基づいています。縦軸にロールを並べ、横軸はオブジェクトを置いています。各オブジェクトへのアクションが横に伸び、どのロールが各オブジェクトのどのアクションにアクセスできるのかが示されています。
紫や赤の網がけ部分は設定によって変動する部分です。クラスの左に出ている矢印がその変動がどの設定項目（これもオブジェクト）からきているのかを表しています。
少し理解をしやすいように例で説明します。
Slackの管理画面にあるメッセージング設定を写真のような設定内容にした場合、権限モデル図にはこのように表せます。
チャンネルというオブジェクトにおいて誰でもメッセの送信はできますが、@channelと@hereはゲストには許されていません。
＃generalというチャンネルのインスタンスにおいてはオーナーと管理者のみに@everyoneが許可されています。
そして、このスクショのメッセージング設定は管理画面にあるので管理者以上のユーザーのみが変更できます。
次にこのメッセージング設定の項目が変更可能なものであることを踏まえて考えてみます。
すると@channelと@hereの使用は管理者、一般、ゲストにとって可能であったり不可能になったりと、設定内容によって変動するようになります。（@everyoneも同様）
なので管理者以上がいじれるメッセージング設定によって変動が生まれるので、メッセージング設定からチャンネルと#generalに矢印をつけて依存関係を示します。
これをサービス上の全ての機能に対して行うことで、設定の依存関係が一枚の表で見れる状態になります。（サービスの複雑さによっては分けた方がいいかもしれませんが。）
縦軸で見ると各ロールができること、そしてそれをどのように変動できるのかが網羅されて理解できます。この図を使用して、各ロールが持つパーミッションを一覧しながら、ユースケースに当てはめてどんなユーザーにどんなロールを与えるべきなのかを議論することができるので、UXにもとずいた構造設計に役立ちます。
こんな考え方も
先ほどRBACを『管理者が逐一アクションの設定をせずともアクション権限が束になったロールというものを与えるだけで設定が完了するためのショートカット』と説明しましたが、サービスを利用するユーザー数がさらに増えると管理者が各ユーザーに逐一ロールの設定をするのも面倒になってきます。
そこで、今度はユーザーを束にしてユーザーグループのような概念を作り、そのグループにロールを割り当てるという考え方も出てきます。
他には、管理の権限を束ねたロールと他のアクションを束ねたロールを別で用意しているサービスもあります。
例えばデザインのバージョン管理ツールAbstractです。Editor(Contributor)/Viewerとは別にAdmin権限が存在しています。つまりViewerかつAdminのユーザーもいれば、EditorだけどAdmin権を持たないユーザーもいるような状態を作れます。これはこのツールを使っている組織のIT管理者が必ずしもデザインファイルの編集などをする必要がないことを考えてみると理にかなっているかもしれません。
このようにロール設計は必ずしも相互に上位下位が一つの軸で判断できる形である必要はなく、ユースケースに合わせて柔軟に作ることが大切です。
（シンプルさを保つことも大事なので、バランスを考えるのが難しいところです）
いろんなサービスを観察して引き続き研究していこうと思います。