B2B SaaSにおけるテナントとは？

おはようございます。信田です。
今回は、B2B SaaSにおけるテナントについて考えてみようと思います。私は、2002年に社会人になり、SIerでキャリアを始めて、コンサルティングファームで働き、その後、SaaS企業で働いているため、これまでほぼ全てのキャリアを、ITにささげてきました。

その中でも、エンタープライズ企業のご支援をすることが多かったため、今でこそ、B2B SaaSに向き合う日々を過ごしていますが、キャリアの前半では、SIとして、1社の企業のシステム作りに携わることが多かったです。その際には、『テナント』という言葉に触れることはなかったです。世の中でも多くのソフトウェアに関わる方が、『テナント』という言葉に馴染みが少ないのではないかと思います。

本題に入りますが、B2B SaaSにおける『テナント』とは、SaaSアプリケーションを利用する個々の顧客企業や組織のことを指します。『テナント』という言葉を聞いて、一番馴染み深いのは、商業ビルなどではないでしょうか？商業ビルでは、一つ一つの入居者のことを『テナント』と呼びますが、想像しやすいので、まずはそちらと比較して考えてみましょう。

いかがでしたでしょうか？？

比較して考えてみるとわかりやすかったのではないでしょうか？B2B SaaSにおいても、商業ビルと同様に、複数の企業に対して、汎用的にサービスを提供しており、SaaSアプリケーションの契約の単位を『テナント』と言い換えることができるかもしれません。

商業ビルとB2B SaaSにおいて、両方に言えることですが、『テナント』という概念を使うことによって、利用企業や組織を個別に捉えるのではなく、『仮想の想定顧客組織』と捉えることによって、”汎用的なサービス”が効率的に提供できるようになります。

では、ここからは、B2B SaaSにおける『テナント』について考えていきます。

B2B SaaSを提供する企業において、『テナント』という概念にどのように向き合っていくべきかについて取り扱います。

『想定のテナント単位』を考える

前述しましたが、『テナント』とは、SaaSアプリケーションの契約の単位となります。つまり、『テナント』の単位をSaaS提供事業者側で考えたとしても、本来、それは利用者側で決めることなので、コントロールできるものではありません。そういった意味で、『”想定の”テナント単位』と書きましたが、提供事業者としては、プロダクトを企画する上で、ペルソナが誰かを捉える意味でも、どんな単位で契約をされるのかを想定していくことが重要と考えています。

例えば、小売の店舗向けの業務をSaaSとして提供する場合に、店舗単体の業務にフォーカスする(想定のテナントは店舗)のか？店舗を横断的に管理することにフォーカスする(想定のテナントは店舗を複数管理する企業)のか？によって、プロダクトの機能提供スコープが変わってくるため、このあたりを考えていくことが肝要と考えます。

テナントへの共通的なサービス提供内容を考える

B2B SaaSでは、顧客を『テナント』と捉えるとお伝えしましたが、その大きな意味合いとして、特定の顧客へのサービスではなく、将来顧客となりうる対象(=テナントとなりうる対象)に対して、どのようなサービスを提供すべきなのかを考えます。ここが、SIのビジネスとの大きな違いになるかなぁと思います。特定の顧客へのサービスであれば、その顧客のやりたいことをヒアリングして、それを、その顧客に最適化して実現すれば良いのですが、『将来顧客となりうる対象』に対してサービスを考える場合、それは、その業務領域における「ベストプラクティス」を考えていく必要が出てきます。つまり、特定の機能を定義する際に、いくつかある選択肢の中から、『将来顧客となりうる対象』に対して汎用的にベストなものを選びつつ、検討を進めていく必要があります。これは非常に負荷がかかることですが、『テナント』を意識してサービス設計しておくことで、ビジネスを効率的に拡大させる可能性(スケーラビリティ)を持つことができます。

テナント戦略の決定

B2B SaaSを提供する際に、必ず出てくる言葉が、「マルチテナント」です。

マルチテナントにおけるテナント戦略とは、「1つのシステム基盤を複数の顧客企業（テナント）で共有する」という前提のもとで、事業の収益性、拡張性、運用効率を最大化するための計画と言えます。特に、技術的な設計（アーキテクチャ）の話になりがちですが、「どの顧客に、どのような価値を、どうやって届け、いかにして収益を上げるか」というビジネスモデルそのものを支える経営戦略と捉え、ビジネスも技術も総合的に考えていくことが重要となります。

a.  技術的な考慮

「マルチテナント」という言葉が出てくる際に、「シングルテナント」との対比として、アーキテクチャのデプロイモデルのプールモデルとサイロモデルがイメージされることが多いですが、我々、アンチパターン社では、プールモデルでもサイロモデルでも、「テナント」を意識して効率的に運用できるように考慮されたアーキテクチャを「マルチテナント」と呼ぶことが多いです。

マルチテナントアプリケーションの設計における、代表的な部分では、デプロイモデルを決めることです。

サーバーやストレージのリソースを複数テナントで共有するプールモデルなどを採用していくことで、テナント数の増加に伴う、開発・運用負荷を高めすぎない状態を作り出し、事業の拡大に寄与できます。

一方で、プールモデルを選択すると、ノイジーネイバーと呼ばれる特定の激しい利用をする「テナント」の影響を別の「テナント」が受けてしまう問題にぶつかる可能性があります。同一リソースで複数の「テナント」を運用するわけですから、リソースをうまく配分できない可能性などが発生します。

つまり、提供する業務の特性や利用者としての「テナント」の特性などを考慮して、デプロイモデルを決めます。

b.  ビジネス的な考慮

さて、「テナント」という言葉は、ビジネス面においても、顧客を特定してその顧客に独自に個別のサービスを提供しないということを意識していく上で、重要な概念になってくると考えます。

特定の顧客を意識しないとするならば、明らかに属性が違う顧客へのサービス提供をどのように対処すべきなのでしょうか？SaaSでは、この明らかに属性が違う顧客を「ティア（階層）」の考え方を使って、顧客をいくつかもまとまりで捉えることによって、あくまでも、特定の顧客へのサービス提供ではなく、同じ階層の「テナント」にまとめてサービス提供することを実現していきます。

その場合、「ティア（階層）」毎に、アーキテクチャや料金プランや提供機能への差分が出てくることになりますが、その際には、どの「テナント」が、どの「ティア（階層）」に所属するのかを紐付けながら、それらを機械的に管理することによって、スケーラビリティーを担保しつつ、ビジネスターゲットを広げていくことができます。

さらに、同じ階層であっても、利用状況に応じて課金したいなどの際には、各「テナント」がどのくらいの利用量かを把握していくためのメータリングなどの考え方も必要となってきます。このメータリングについても「テナント」毎に実施していく必要があります。

また、オプションという概念を準備しておくことで、特定の「テナント」に対してのみ提供するサービス内容を準備することもあります。

このようにビジネス面においても、あくまで「テナント」に対してサービス提供していく意識で、ビジネス展開を考えていく必要があります。

c.  運用的な考慮

テナント戦略を考える際には、運用の視点においても、「テナント」の意識は必要となってきます。まず最初に、「テナントオンボーディング・オフボーディング」の概念となります。アーキテクチャで仮にサイロモデルを選択した場合には、新規「テナント」の契約開始が発生した場合に、その契約に対応して新しいリソースを準備していく必要があります。どの階層の「テナント」が契約開始した場合には、どんなアーキテクチャを準備するべきかを管理していく必要があります。また、それを自動化しておくことによって、新規契約が発生した際の、負荷やリードタイムを軽減し、顧客体験をスムーズにします。

次に、「テナント」毎のモニタリングも必要になってきます。各テナントがどんな利用状況なのか？などの情報を取得することによって、それ以降の「ティア（階層）」設計におけるプライシングや機能開発への有益な判断材料とすることができます。

d.  セキュリティ的な考慮

SaaSのテナント戦略において、最も重要な点ともいえますが、セキュリティへの考慮が必要となります。「マルチテナント」で設計していく際には、「テナント」を同一リソースで集約していくことを考慮しますが、その際に、確実にそれぞれの「テナント」を分離していく必要性があります。テナント分離には、「データベースレベル分離」、「スキーマレベル分離」、「行レベル分離」など、さまざまな手法がありますが、どの手法を選択するにせよ、「テナント」と「テナント」の境界線をクリアに設計していく必要があります。境界線がどのように担保されているのかを意識した設計をすることで、「テナント」を跨いで情報が参照できてしまうなどのセキュリティ事故を防いでおく必要があります。

テナントコンテキストを考えておく

ここまで、考えてきたように、「テナント」として汎用的にソフトウェアサービスを提供していくとはいえ、「テナント」によって、若干振る舞いを変えながら、動作していく状態を作る必要があります。例えば、契約している「料金プラン」によって、使える機能が違ったり、特定の「テナントID」を持つテナントに対しては、パフォーマンスの高い特別なリソースで準備してサービスを提供する必要があるかもしれません。

汎用的にソフトウェアサービスを作りながら、若干の振る舞いを変えていくためのパラメータに当たる部分をテナントコンテキストと呼びます。

・料金プラン

・所属するテナントのID

・利用者の役割

・利用者の属性

などです。

汎用的にソフトウェアを開発しながらも、何によって、アプリケーションの振る舞いを変える必要があるのかを考えて、現在利用しているユーザーには、一体、どのようにサービスを提供（アプリケーションの振る舞い）が必要なのかをコントロールする要素を、一元的に管理しておくことが重要になります。

さて、ここまでさまざまな視点で「テナント」という概念を中心に、B2B SaaSに向き合ってきましたが、「テナント」という概念の重要性について感じていただくことができましたでしょうか？？

この記事で、「テナント」が何か？ということの解像度が少しでも上がっていたら嬉しいです。

ここからは宣伝となります。

我々、株式会社アンチパターンは、B2B SaaSにフォーカスして事業推進する会社です。さまざまな、コンテンツを準備しておりますので、こちらもぜひご参照頂けますと幸いです。

・SaaS開発ガイド【テナント編】

https://saasus.io/resource/e-book/saas-dev-guide-tenant

-> SaaSについてまとまったドキュメントがなかったのでまとめてみました。

・SaaS開発運用を支援するSaaSus Platform

https://saasus.io/

-> 上記で触れた、テナントコンテキストなどを効率的に管理できたりします。

B2B SaaSに向き合う、多くの方と、何かしらの関わりを持っていけたら嬉しいなと考えているので、我々、株式会社アンチパターンにお気軽にコンタクトしてもらえるとさらに嬉しいです。