B2B SaaS (MTWA) でのアカウントモデルの検討事項

MTWA SaaS

この記事は、SmartHR Advent Calendar 2019 の 9日目の記事です。

SmartHR に入社してから、その殆どの時間で、アカウント周りの改修やらなんやらを行っているのですが、 B2B SaaS におけるアカウントモデルの検討事項を洗い出してみました。

検討する上でのユースケース

  • B2B
    • 担当者が扱うアカウントで良い場合
  • B2E
    • 従業員のアカウントが必要な場合

一つのテナントに紐づくアカウントでよいか

  • サービス全体でアカウントを共有するモデル

    • GitHub
      • EMAIL などで一意のアカウントが発行される
      • org には招待などで紐づけ

  • テナントごとにアカウントを作成するモデル

    • Slack
      • テナントごとにアカウントが発行される
      • テナントの切り替え = アカウントの切り替え
      • テナントの切り替えが簡単にできるUIをつくるだけで良いかも

  • 複数のテナントにまたがってログインができる機能は必要か

    • サービスの特性によって、必要な場合もある

アカウントを作成するのは誰か

  • 招待の概念が必要か
    • サービスの特性による
      • 従業員も使うサービスであるならば、従業員アカウントを管理者権限のアカウントが招待をする必要があるかもしれない
      • もしくは、社員番号などと連動した従業員アカウントの発行などが必要かもしれない

従業員それぞれのアカウントが必要なのか

  • 従業員がサービスにアクセスする必要があるならば、必要
    • 勤怠管理システムなど

権限設定が必要か

  • 任意の権限を設定できる必要があるか
  • 従業員がアクセスできるサービスの場合は必須
    • 見えてはいけないものを見えないように

認証は独自でやるのか IdP と連携するのか

  • 認証基盤を運用するのは大変
    • できれば IdP と連携するものをリリース当初から持っておいたほうが楽
      • そもそも IdP に投げる仕組みにしてあるほうが好ましいかも
    • 退職したら、アクセスできないようにする必要があるかも

セッションの管理はテナントごとになっている必要があるか

  • 複数のテナントにまたがったアカウントがなければ不要かも
  • MTWA のアーキテクチャとしてテナントの切替方法がどの様になっているか
    • サブドメインベースでテナントがきりかわるのか
    • 同一ドメインで PATH にテナント情報が付与されているのか
    • Slack の web 版が最近、サブドメから PATH 方式に切り替わっていてなぜなのかが気になるところです。

おわりに

サービスの成長や、方向性などで、無限に考えることが多くなりがちですが、 つどつど見極めつつ、検討するのがいいかと思います。

SmartHR でのアカウント周りについて、悲喜こもごももあるのですが、 書けない話も多いので、気になる方は、どこかで直接あったときにでも。