こんにちは、きむたかです。ナビタイムジャパンで店舗管理事業者様向けサービスの開発・マネジメントをしています。

私が現在開発・運用に携わっている『NAVITIME Location Cloud』というサービスは、多店舗の運営を行う事業者向けのデータ管理SaaSサービスです。
管理ツール(Location Cloud Manager)を通じて管理したデータを用いて、

• オウンドメディアを構築 (Location Cloud Media)

• Googleビジネスプロフィールといった各種メディアへの情報連携 (Location Cloud Sync)
  といった機能を利用することができます。

こういったBtoB(法人向け)サービスでは、特に実際にクライアントが利用するツールにおいて、各クライアントの業務フローにフィットしたものを提供できるよう、機能を柔軟にカスタマイズできることが求められます。
それを実現するために、機能を汎用的に作ることはもちろんですが、クライアントによって できること・できないことを制御するための機構 も持ち合わせている必要があります。

今回は、上記を実現するためのBtoBサービスにおける権限管理に関する話を少しお伝えしたいと思います。

権限制御で考えること

権限制御においては「制御を行う単位」と「制御を行う対象」の2つの観点を考えます。これらを組み合わせることにより、柔軟な機能提供を実現することが可能になります。

以下で、それぞれについて説明していきます。

権限制御の単位

まず、クライアントが利用するツールは、必ずと言っていいほど利用ユーザーのログイン機能が備わっていますので、「ユーザー」単位での制御は必須となります。こちらは容易に想像がつくかと思います。

• aさん: 機能X, Y, Zを利用可能な権限を与える

• bさん: 機能X, Yを利用可能な権限を与える

次に、同じ会社でツールを利用するユーザーが複数いるパターンを想定してみます。こうなった場合、同じ会社のユーザーに同じ権限を与えればよいのですが、ユーザーが多く存在する場合に権限付与の操作が煩雑になることがあります。
こういった場合を想定し、「グループ」のような単位を用意し、そのグループに属するユーザーに同等の権限を付与する、というものを用意しておく必要があります。

このグループを用いれば、会社やその中の部署ごとに権限制御を行う、ということが用意になります。
ただ、会社によっては様々な部署での利用が想定され、その部署ごとに権限制御を行いたい、というケースも生じます。そのため、このグループについても「会社」とそれに属する「グループ」のように最低で2つの階層を考慮できるのが理想です。

◆ここまでのまとめ

• 権限を制御する単位

  • 階層構造をとる

    • 最低でも「会社」「グループ」「ユーザー」の3つがあるとよい

  • 下位の階層では上位の権限設定を踏襲する設計とする

(例)

会社A
├─ 全メンバー
│  ├─ aさん
│  ├─ bさん
│  └─ cさん
会社B
├─ 販売部
│  ├─ dさん
│  └─ eさん
├─ 営業部
│  ├─ fさん
│  ├─ gさん
│  └─ hさん
├─ 管理部
│  └─ iさん
会社C
└─ 営業部
   └─ jさん
...

権限制御の対象

続いて、権限で制御をする対象について考えてみます。
一般的には「フィーチャーフラグ」を利用して、何ができる・できないを制御する、というイメージがわかりやすいかなと思います。

対象については、大きくは以下の2つに分類されます。

1つめは 「利用可能な機能」 についての制御です。こちらは先程の権限制御の単位の話では、機能X, Y, Zというように表現していました。
会社によっての契約内容の違い、各グループや各アカウントで利用が想定される機能の違いがあるため、それらに対して利用できる機能のON/OFF制御が行えることは必須となります。

そして2つめは「利用可能なデータ」についての制御です。A社はA社の管理データのみを、B社はB社の管理データのみを操作できるようにする制御になります。さらに細かく、A社の部署Sでは全データを、部署Tでは特定データのみ操作可能、という制御も想定されます。さらに細かいレベルだと、データのうち特定の項目のみ操作可能にする、ということも考えられます。(例:店舗データのうち営業時間の情報だけ変更可能、など)

前者と後者の大きな違いは、操作対象の状態が変動するかどうか？という点にあります。
私が携わっている『NAVITIME Location Cloud』の機能を例にとって考えてみましょう。
管理ツールである Location Cloud Manager には、店舗データを管理する機能がありますが、そこに対して上記2つの観点をあてはめると、以下のようになります。

• 利用可能な機能　= 全クライアントに共通するもの

  • 店舗情報を閲覧・検索する

  • 店舗情報を新規追加する

  • 店舗情報を編集する

  • 店舗情報を削除する

• 利用可能なデータ　= クライアントごとに変動するもの

  • 会社A

    • 〇〇ストア　新宿店

    • 〇〇ストア　渋谷店

    • …

  • 会社B

    • △△銀行　東京支店

    • △△銀行　千葉支店

    • △△銀行　さいたま支店

機能については、ツールを提供する側である我々は把握できる範囲なので、個々の機能(場合によってはある機能の特定の操作まで)に対してON/OFFを制御することは比較的容易です。
一方、データについてはクライアントによってデータの追加・変更・削除が起こりうるものになります。そのため、利用可能なデータの制御は「この条件にマッチするもの」という考え方が適していることがわかります。
こういった制御を行うために、扱うデータ側で「条件によるフィルタリングが行えること」も要件となってくることが想像できると思います。

◆ここまでのまとめ

• 権限を制御する対象

  • 機能の制御

    • どのような機能がつかえるか

    • どのような操作が行えるか

  • データの制御

    • 許可された機能において、どのデータが対象になるか

ユースケースで考える

ここまで、SaaSサービスで必要になる権限制御の考え方として「単位」「対象」があるということについて説明してきました。
ここからは、実際にそれらをどう適用していくか、店舗管理ツールを題材として具体例を考えて行きたいと思います。

【Case 1】会社Xが持っているブランドAという業態の店舗情報の編集は、本部で集中して行う以外に全国の各エリアマネージャーにも任されています。各エリアマネージャーが編集できる情報は、管理するエリア内の店舗だけです。編集した内容は、本部の承認が必要です。

まず、権限の単位に必要なものを考えていきましょう。今回のケースでは「X社」という会社に対し、本部のメンバーと各エリアマネージャーのアカウントが紐づく状態になります。さらに、本部・エリアマネージャーで利用可能な操作が異なることから、それぞれのグループを準備しておくのが良いでしょう。

続いて、権限制御の対象です。今回エリアマネージャーには店舗情報の編集が行えることになっていますが、編集した内容を反映するためには本部の承認が必要になるということで、許可する機能(操作)は以下の2つであると想像できます。

• 本部: 店舗情報の編集、編集内容を適用

• エリアマネージャー: 店舗情報の編集

また、許可するデータについては、エリアマネージャーは自エリアの店舗に限定されるという制約がありますので、以下のような設定となります。

• 本部: すべての店舗

• エリアマネージャー: 自エリアの店舗

以上をまとめると、Case1で必要な権限設定は以下のようになります。

【Case 2】本部の部署に、広報部門を新設しました。広報部門は、全店舗のデータのうち「お知らせ」の項目だけ編集することができます。広報部門によるお知らせの更新は、本部の承認は不要というルールになっています。

まず単位ですが、Case1で作成した権限構成に、新たに「広報」というグループを用意すれば良いことは想像がつくかなと思います。

一方で、対象については、すべてのデータを扱うことができますが、 「お知らせのみ編集可」という制約があるため、新たに制御対象に項目を考慮する 必要があります。

これらをCase1の構成に追加で考慮するようにすると、以下のようになります。

【Case 3】社内で新たな業態の店舗を新規でオープンしていくことになりました。(これまでの業態をブランドA、今回オープンしていく業態をブランドBとします。)ブランドBはスモールスタートのため、ブランドAの東京1エリア内での出店からスタートする計画になっており、ブランドAの東京1エリアのマネージャーにデータ管理が一任されています。

今回は新しいブランドが誕生するというシチュエーションです。これまで扱っていた店舗データとは業態が異なるため、まず対象のデータについて業態を区別できる状態を設定しておく必要があります。(例: カテゴリの設定)
そのうえで、既存の店舗データ運用をしていたメンバーについては、ブランドAのデータのみ操作可能としておきます。

権限適用の単位については、今回あらたにブランドB管理用のグループを新設するのがわかりやすいですね。
もし「1つのアカウントは複数のグループに所属できる」設計になっている前提であれば、東京1エリアMgrを作成したグループに所属させればOKです。
一方「1つのアカウントは1つのグループにしか所属できない」という設計になっているケースも考えられます。その場合は、東京1エリアMgr用のアカウントをもう1つ作り、ブランドA/Bのデータを扱う場合でそれぞれアカウントを切り替えてもらう運用になります。
利用する側からすると少々煩雑ですが、セキュリティ観点で権限最小化すべきという観点ではこちらのほうが適切と言えるケースもあります。

まとめ

ここまでの例を見てもわかるように、権限管理は各クライアントの業務フローに合わせた機能提供をする上で重要な要素であることが理解頂けたのではないかと思います。
みなさんが普段利用されているサービスでも、こういった制御が行われている部分は多々あると思います。
ここは権限制御できる部分なのかな？などと考えながらサービスを利用していると、もしかしたら新しい発見があるかもしれません(笑)

最後に、私が開発に携わっている『NAVITIME Location Cloud』は、こういった権限管理も取り入れており、他店舗運営されている事業者様のデータ管理の課題を解決できるサービスとなっています。
興味のある方はぜひお問い合わせください。