実践 B2B SaaS 設計

前提

想定読者

複数のデジタルサービスを開発・展開していこうとしている企業の方

記事内の用語

記事の目的

スーパーアプリ構想を筆頭とした複数のアプリケーションサービスを展開する上で、技術的な根幹にあるのは B2B SaaS 基盤 (上記用語欄参照) と言っても過言ではありません。とはいってもシステムの裏側の要素が多く、どうにかなるだろうと後回しにされがちで、なかなかイメージしにくい部分でもあります。

※ そもそもなぜ複数のウェブサービスを展開する際に、基盤(プラットフォーム)を作る必要があるのかというところは今回割愛しています。

この記事を最後まで読むことで B2B SaaS 基盤に関する理解が深まり、複数のデジタルサービス開発を進めた先に待ち構えるモヤが少し晴れ見通しが良くなるはずです。

まずは B2B SaaS を構成する重要なポイントの概要を説明し、その一つである “組織” を考慮することがどれだけサービスを複雑にしてしまうかを見ていきます。そうすることで、基盤の上に乗る各アプリに対してどういった制約を設けなければならないか、どのような共通機能を提供すれば各アプリの設計、実装が楽になるかといった観点が想像しやすくなることを目指します。

Note
B2B SaaS を一から作れる知識や経験のある人は実はあまり存在しません。というのも、B2B SaaS が活発に提供されるようになったのがここ十年程度のことで、B2B SaaS を支える様々な規格やサービスなどのエコシステムもまだまだ発展途上です。さらにその B2B SaaS を複数束ねる「基盤」となると尚更です。

B2B SaaS の要点

B2B SaaS における重要なポイントを3つに絞ると概ね以下の3つに集約できるのではないかと思います。

1. 組織

企業に閉じた形で、部門や役職ごとに利用権限を制御したり、操作ログなどの保存も必要になります。また、各サービス利用状況確認やアクセス制御などを一元的に行える設計が求められます。 (つながるビジネス価値例: サービス形態の柔軟性、課金の仕組みの導入、決済者・利用者の分離などへの対応)

2. 外部連携

サービスを利用する企業は既存システムや他のSaaSと連携するケースが多いため、それらとの連携がスムーズに行えるよう互換性や拡張性を意識したアーキテクチャ設計が求められます。 (つながるビジネス価値例: 既存のCRMへ顧客情報を格納、会計システムと連携し今までと同様に顧客の請求・支払い管理を行う)

3. セキュリティ

ビジネスに関連したデータを多く扱うためセキュリティには十分注意を払う必要があります。例えば企業間のデータを疎結合にしておくなど初期のアーキテクチャ設計も後のセキュリティリスクに大きく影響を与えます。 (つながるビジネス価値例: 情報漏洩やセキュリティ障害などによるサービスの知名度への悪影響最小化)

この3点を背景に、要件整理を以下のような流れで詰めていくと漏れのない設計になっていくと考えています。

この内、組織(※)の切り口から B2B SaaS を分解してみると、多くのサービスは共通的に以下のような機能を提供していることがわかります:
※ ここでいう組織はテナントとも呼ばれます。

• 組織管理者が利用者(組織メンバー)の招待をする
• 組織管理者が利用料の支払いをする
• 組織管理者が利用者の権限をコントロールする
• etc…

Note
これらがあるから B2B SaaS ということでもありません。例えばC向けアプリケーションに家族アカウントを管理する要件が追加されれば、上に列挙した機能が必要となるでしょう。
技術的な視点から見ると、SaaS を提供するためには利用する全企業のデータを管理する必要があるため、必然的に複数組織(マルチテナント※)向けのロジックやデータ管理を考慮しなければならないことがわかります。また、B2B SaaS は直接の取引先である企業だけでなく、その先の消費者を含めたサービスを提供することが多く、初めのうちから B2C (B2B2C) 観点も考慮した設計になっているとトータルで見たコストを大幅に削減できる可能性があります。

※ マルチテナントにおけるシステム設計の基本的な要点を知りたい方はこちらの記事(AWS Blog)が参考になります。

次に、”組織” を意識することがどれだけソフトウェアを複雑にするかを具体的に見ていきます。

組織を考慮した設計の観点

「SNS (ソーシャルネットワーキングサービス) 」のUIデザイン と「企業内だけで使える SNS」のUIデザインをそれぞれ具体的に想像しようとすると、”特定の企業内だけで使える” という制約がついただけで、SNSのコア機能に関心を向けにくくなってしまう (それが最も重要であるにもかかわらず) ことがわかります。これだけでも組織を考慮すると複雑になってしまうと感覚ではわかりますが、実際に組織を考慮した場合にどういったことを考えないといけないか、いくつか具体例をご紹介します。

ユーザーは自身の組織をどこで選択するのか

Case A. ログイン前に組織を選択する

以下のようなことを検討するでしょう。

• 組織名をユーザーが忘れてしまったらどうするのか。
• 組織を選択形式にするとした場合、どんな組織がサービスを利用しているのか第三者に知られてしまうリスクがある。
• 組織ごとに認証情報(クレデンシャル)が異なるのか。同じならログイン後に選択した方がUXが良いのではないだろうか。

Case B. ログイン後に組織切替え機能で選択する

ユーザーが現在選択している組織はどのように判断するのか。

例えばドメイン名 ( abc.example.net ) で判断するとしたら、組織のIDを変えたときにドメイン名が変わるとブックマークが変わってしまう。さらにランダムなIDを採番しドメイン名の一部にするとしたら、URLの視認性が悪くなってしまう。

もしくはURLパス  ( example.net/abc ) で判断する場合、ドメイン同様組織のIDを変えたときにブックマークが変わってしまう。さらにパスが違うことで組織間で共有の静的リソースのキャッシュが重複して保持されることになってしまう。

そうなると、Cookie や LocalStorage に選択した組織IDを持つと良いのだろうか。ブラウザのタブごとに組織を切り替えたい場合に不都合はないだろうか。

ユーザーが投稿したメッセージを組織外の人にも閲覧可能とするか

Case A. 組織外のユーザーが閲覧することはない

1年後にはその限りではないとしたら、開発コストを上乗せしてでもそれを考慮した実装にしておくべきか。

Case B. 組織外のユーザーがメッセージを閲覧できるように、ゲストとして組織に招待する

別の組織にいるユーザーをゲストで招待したとき、ユーザーの名前を使いまわして問題ないだろうか。

Case C. 組織内外問わずメッセージごとに柔軟に可視範囲を制御できる

組織のサービス利用契約が切れた際に、組織外に送信されたメッセージを消す必要はないだろうか。

組織の新規登録方法にはどのようなものがあるか

Case A. ウェイティングリストに登録してもらい、後からシステム管理者がその組織を招待をする

• ウェイティングリストに登録されたタイミングで、管理者にメールやSlackで通知を飛ばす必要はないか。
• エンドユーザーには見えないウェイティングリストの管理機能に対してどこまで開発コストを費やすことができるだろうか。

Case B. セルフサインアップで組織を登録する

• 組織情報入力途中の離脱率を計測して入力項目を削ったりできると登録率が上がるが、コア機能ではないので後回しにするしかないだろうか。
• 悪意のある第三者が他組織の名前で登録申請してしまうことを防ぐにはどうしたら良いだろうか。

Case C. システム管理者が組織を招待する

• 招待した組織の履歴管理と、間違って招待した場合の取消し機能があったほうが良いかもしれない。
• 招待メールの開封確認をすることはできないだろうか。
• 招待メールの内容を国や地域ごとに変えたいので、テンプレート化して使い回せるようにできないだろうか。

Case D. システム管理者が組織を直接登録する

• 組織管理者のクレデンシャル(e.g. ID/パスワード)を、組織管理者に安全に渡せるだろうか。
• ランダムなパスワードを発行して組織管理者にメール送信し、初回ログイン時にパスワードを強制変更させるフローで問題ないだろうか。
• 登録に必要な情報を集めるために組織管理者とシステム外でやりとりするのはUXが悪いため、管理者のメールアドレスと組織名だけで登録を済ませておき、あとは組織管理者が初回ログインした際に補完してもらうことはできないだろうか。

ユーザーの新規登録方法にはどのようなものがあるか

Case A. 個人利用(組織に所属しない)プランでセルフサインアップする

• 組織に属さない状態でもサービスが利用可能な場合、各機能はその分余計な実装を強いられコストがかさむのではないだろうか。
• ユーザーの重複チェックの仕方によっては第三者にサービスを利用しているかが知られてしまう脆弱性は防げているだろうか。

Case B. ユーザーがセルフサインアップする際に組織を選択し、組織管理者がユーザーの参加を承認する

組織名をサインアップ前のユーザー自身が知っているということは、組織の誰かが事前に教えている可能性が高い。それなら既存の組織メンバーが新メンバーに対して招待メールやリンクを送る方がUXが良いかもしれない。

Case C. 組織の既存メンバーが新メンバーを招待する

• 別の組織に既に所属しているユーザーを招待可能とすべきか。
• 誰でも招待できるようにし、権限がなければ権限のあるメンバーによる承認を要するようにできないだろうか。
• 課金プランの参加人数上限に達していたら招待できないようにすべきだろうか。それとも招待は可能とし権限のあるメンバーが課金プランを更新するよう促した方が良いだろうか。

Case D. 組織の管理者がユーザーを直接登録する

• 悪意のある組織管理者が、別人のメールアドレスを騙ってユーザー登録することができてしまう。どのように本人確認すべきだろうか。
• 仮にメールの送信確認をするとしたらどのタイミングでメールを送れば良いだろうか。登録直後だとしたら登録された側からすれば何の連絡もなく突然メールが送られてきて不審に思うのではないだろうか。

Case E. 一度組織を抜けたユーザーが再度組織に招待される

• その人が過去に投稿したメッセージとこれから投稿するメッセージの投稿者を同じにするか。別人扱いにするか。
• メールアドレスが同じならば同じユーザーであると判断する場合、退職した社員のメールアドレスを新入社員が再利用する可能性はないだろうか。

例を挙ればキリがありませんが、ここに記載したものは要件レベルの想定問答で、さらにここからシステム設計、実装と詳細化されていくと、一つ一つの課題がより複雑に絡み合ってきます。ここまでサービスのコアドメインに関する要件にほぼ触れてこなかったにも関わらず、組織を意識した要件にするというだけで相当な期間とコストがかかってしまうことが容易に想像できます。

また、システム設計についても例があったほうが良いかと思いますので次に少しだけ触れておきます。

組織内のユーザーを部署でグルーピングする機能があるとき、それは組織となにが異なるのか

組織も部署も、どちらも人をグルーピングする単位と考えれば機能的に大差はなく、そこまで苦労せずに組織の概念を追加できるのではないかと考えるのが自然だと思います。逆に部署の概念も組織同様に複雑なのだとすれば、それにしては過去にソフトウェアを作ったときはそんなに苦労した記憶がなかったと思うかもしれません。

組織とはただの「請求支払をまとめる単位」でしかなく複数組織を跨いだ機能も多くある、ということであれば部署というグループと大差はなく、組織は単なる請求支払が可能なグループと捉えられるかもしれません。実際にそれで十分なサービスも存在します。

ですがここで一つ考慮しなければならないのは、SaaS 以前のソフトウェアにおいて、ソフトウェアは各企業(組織)のサーバーにインストールして使っていたということです。組織がサービスの利用をやめたとき、その組織のデータを安全に全て削除することが可能でしょうか？GDPRのような法令も絡んでくると、これを意識した作りになっていないとそもそも導入してすらもらえないかもしれません。例えばアプリケーションの監査ログが全組織を跨いで全て同じファイルに吐き出される作りになっていた場合、対象組織のログだけを閲覧不可とする要件を実現することは可能でしょうか？

こういったことを考慮し、組織とは「データを隔離する単位」と考えるのであれば部署のグループとは扱い方が変わってきます。

「データを隔離する単位」とは

• その範囲内であれば万が一データが漏洩してもリスクが少なくなったり
• その範囲外とのデータの繋がりのある機能を作ることが難しい (おかげで実装の不備によるデータ漏洩事故が起こりにくい)
• 範囲外のデータと粗結合になっているため、その単位でデータのリカバリーができる

といった特性を持っています。

さらに複数サービスの運用を考慮すると

ここまで一つのサービスを想像していましたが、本来実現したい複数サービスの運用を考慮すると、さらに複雑になってきます。

共通機能を個別開発してしまうコスト

例えば上記のようにセルフサインアップで組織を登録する場合では、

1. サービスAではセルフサインアップOK
2. サービスBではNGとし、代わりに招待制

としたいケースが考えられます。この場合、もちろんサービスB側で個別に招待の仕組みを作ることはできますが、サービスC、Dも招待制にしたいとなったときにそれぞれのサービスで再度設計・実装・テストをするのは無駄が大きそうです。

既存サービスが前提にしていた仕様が崩れてしまうリスク

上記にて「別の組織に既に所属しているユーザーを招待可能とすべきか」を検討事項として挙げましたが、例えば

1. サービスAでは複数組織への参加がNG
2. 後から開発したサービスBでは複数組織への参加がOK

というケースがでてきた場合どうなるでしょう。

この場合、後から複数組織への参加がOKなケース #2 が出てきてしまったため、もしサービスBの要件を通そうとすると、サービスAの前提が崩れてしまいデータ不整合が起き、予期せぬ障害へ発展しかねません。

新しいニーズに追随していけなくなるリスク

これは最近のサービスに多い要件ですが、自社サービスのリソースを活用したアプリケーション(例. SlackのGoogle Calendarアプリ)を、第三者が作れる仕組みを提供したいとなったら、その第三者が作ったアプリケーションが安全に組織やユーザー情報にアクセスする仕組みを作る必要が出てきます。

最後に

ここでは触れませんでしたが、企業向け課金の仕組みやCDP連携など B2B SaaS ならではの機能もサービス共通で必要となってきます。こうした観点で B2B SaaS 基盤が作られていると、各サービス開発者が個々のコアドメインにフォーカスできたり、統合された顧客情報をマーケティング等に有効活用できるようになったりと価値の高いものになります。一方で、下手をしてしまうとこれだけでサービス数個分の開発コストとメンテナンスコストがかかってしまうものでもあります。そうであるならば最初は各サービスを完全に独立して作っておき、本当に必要になったときに改修、データ移行をする選択肢も存在します。どちらを選択するにしてもメリットデメリットがあり、事業のフェーズや今後のロードマップと照らし合わせて決めていくものです。