B2B SaaSの地図とコンパス(ホリゾンタル/バーティカルの「2軸」の整理では不十分なSaaSの世界)
自称日本一B2B SaaSに詳しい経営者の小笹です。というのは冗談なのですが、そうありたいと思ってはいるので、今回は自らがB2B SaaS起業家として活動し、深く実態も理解しているからこそ書ける業界の網羅的な知見を喧伝したく筆をとった次第です。なんと1万文字超え！
では、早速始めます。
B2B SaaSを2軸で整理して地図を作る
現時点で一般的な軸(Horizontal / Vertical)
現状、B2B SaaSを語る際にはこの軸を使って整理されることが多いかと思います。
Horizontal SaaSは業界を問わず行われる業務に対して価値を提供します。例えば、人事や会計などが一般にこれにあたります。
Vertical SaaSは業界特化の業務に対して価値を提供します。例えば、建築業界向けのSaaSなどがこれにあたります。(Vertical SaaSについてより詳しく知りたい方は神前さんのnoteを参照ください。 )
つまり、この軸を分けるのは業界という概念であると言えます。
この軸があるだけでも、TAM(Total Available Market)を捉えるのには一定有効ではありますが、市場を解像度高く捉えるという意味でいうと粗さが目立ちます。特に外資系SaaSを含めたコンペティターとのポジショニングを整理する上では、この軸だけで捉えている人はいないでしょう。
かといって、そのSaaSが提供するドメインを深堀り、整理をすると俯瞰した視点が欠如します。そこで新しい軸を用いることになるのです。
今回追加を提案したい軸(Global / Local)
SaaSを整理する上で、新しい軸として提案したいのが「Global / Local」です。
先に書きますと、この軸を分けるのは国という概念であり、実質的には法制度のようなルールがどの範囲で存在するか？です。
これらは日本国内で発展をしているSaaSについて、その成長理由を分析した際に理解しました。
Local SaaSが分かりやすいですが、Local SaaSは各国の規制や慣習に適合するように設計されており、国内市場に特化しています。
会計で言えば、税制の変更なども行われますし、インボイス制度・電子帳簿保存法対応は記憶に新しいところです。
人事労務の分野でも、労働基準法や社会保険関連法規の改正は行われるものですし、マイナンバーやストレスチェックも対応が必要になってきます。
これらの日本国内のルールがあることでグローバルからの参入障壁が生まれ、それらに則ってプロダクトを提供することでグローバルとの差別化が実現され、国内でのシェアを拡大することができるわけです。
成長著しいBill One(https://bill-one.com/)でも法改正の影響についての言及がありました。
「Bill One」は請求書関連業務のDX化に対するニーズや法改正の追い風などを背景に営業生産性が高まっていました。
一方、Global SaaSとはどういうものになるかというと、法律などのローカルに根付いたものではない概念などを扱う場合に該当するものになります。SlackやZoomなどのようなコミュニケーションだったり、Salesforceのような顧客管理だったり、Dropboxのようなクラウドストレージもこれに該当するでしょう。
つまりは、概念的には国や地理に影響なく受け入れられる普遍的な営みに対して価値を提供するものです。
セールステックが昨今注目されていると思いますが、セールステックを「営業という普遍的な営みをテクノロジーによって昇華するもの」であるとするならば、Global SaaS足り得る概念であると思われ、日本発Global SaaSというのが生まれることに期待が持てるかもしれません。
もちろんグローバルだからといってローカライズをしないわけではないので、その営みが根差しているのは何か？というのがこの軸を整理する上で重要な問いでしょう。
例えば、Stripeなどは決済という普遍的な営みをサービス化しているのでGlobal SaaSといえますが、各国の法規制や税制には対応する必要があるのでローカルな対応をしていないわけではありません。むしろ、グローバルであるために、あらゆるローカルな対応をサービス化していることやそれができる開発力こそが参入障壁となっている素晴らしい例です。Deelも同じようなアプローチにより参入障壁を作っている例でしょう。
逆にグローバルSaaSしかないと思われる領域でも何かしらの法規制によってローカルへの参入難易度が高くなっているものもある可能性はあり、ローカルでの事業発展余地があるビジネスモあるかもしれません。
ここまでホリゾンタルな例を挙げましたが、バーティカルでも同じように「Global / Local」かを整理することが可能ですが、特定業界が法規制に守られる可能性はあるため慎重に見極める必要があります。基本的に規制業種（金融、医療など）×SMBが多い産業は、TAMが一定あるため、ローカルになりやすい傾向が指摘されます。
そのSaaSが「根差しているのは何か？」を考えるということ
少し概念的な整理を進める上で、ソフトウェア業界にも影響を与えた建築の考え方をシェアします。
建築における古典的な考え方で、「シェアリング・レイヤーズ（Shearing Layers）」と呼ばれているものがあります。
この概念は、建築家のフランク・デュフィー（Frank Duffy）によって提唱され、のちにスチュワート・ブランド（Stewart Brand）によって彼の著書『How Buildings Learn』の中で広く知られるようになりました。
シェアリング・レイヤーズでは、建築物を以下の6つのレイヤーに分類しています：
サイト（Site）：建物が建っている土地そのもの
構造（Structure）：建物の基礎や骨組み
スキン（Skin）：建物の外装
サービス（Services）：配管、電気配線、空調設備など
スペースプラン（Space Plan）：内壁、天井、床などの内部レイアウト
スタッフ（Stuff）：家具、装飾品などの可動要素
これらのレイヤーは、変化のスピードが遅いものから速いものへと順番に並んでいます。サイトや構造は数百年という長いスパンで変化するのに対し、スペースプランやスタッフは数年から数ヶ月といった短いスパンで変化します。
この概念は、建築物の設計において、変化のスピードが異なる要素を適切に分離することの重要性を示唆しており、これは、ソフトウェア開発におけるレイヤードアーキテクチャの考え方とも共通しています。
解説はここまでにして、ここで言いたいのは、何に根差しているSaaSなのか(サイトが何なのか)が、自ずとそれ以上を規定するということです。この点について深く思考することで、この後の整理について理解が進むでしょう。
ちなみに、この考えは建築のみならず文明社会へと解釈を拡大され、ペースレイヤリングのモデルなどに発展していったのですが、ここでは触れません。より詳しく知りたい方はこちらをご参照ください。
また、近しい考え方として、SaaSは「普遍」を実装するものであるという考え方を示されている方もいらっしゃいました。この辺りもご参照ください。
2軸で業界を整理する
整理すると以下のような図になります。
そして各象限は以下のような特徴を持ちます。
Global Horizontal SaaS:
国や業界に関わらず、幅広い企業で利用可能なSaaS
例: Salesforce (CRM)、Slack (コミュニケーション)、Dropbox (クラウドストレージ)、Zoom (ビデオ会議)
Global Vertical SaaS:
特定の業界に特化しているが、国を問わず利用可能なSaaS
しかし、顧客がグローバルな大企業に限定される可能性あり
(※要検証)
例: Veeva Systems (製薬業界向けCRM)、Guidewire (保険業界向けソフトウェア)、Procore (建設業界向けプロジェクト管理)
Local Horizontal SaaS:
国ごとの法制度や市場の特性に合わせて設計されたSaaSで、国内の幅広い業界で利用可能
例: 国内の会計SaaS (freee、マネーフォワード)、国内の人事労務管理SaaS (SmartHR、KING OF TIME)
Local Vertical SaaS:
国ごとの法制度や市場の特性に合わせて設計され、特定の業界に特化したSaaS
例: 国内の医療機関向け電子カルテSaaS(ex.メディカルフォース)、国内の不動産業界向け物件管理システム
各軸(2軸)と各象限(4象限)で取れる成長戦略(=コンパス)
アップセルやクロスセルなど基本的な考え方はありつつも、それぞれで成長戦略は変わっていきますので、整理していきます。これにより、自分たちはどの象限にいて、今後どういう戦略を取り得るのかを理解することができます。
■Horizontal SaaS
・垂直統合戦略
特定の業界向けの機能を追加し、バーティカルSaaSにも近い動きを取ることを行うものです。これらはSalesforceが好例でしょう。
SalesforceのHealth Cloudは医療業界向けのソリューションで、患者の情報管理、ケアプランの作成、医療従事者間のコラボレーションを支援しています。また、Financial Services Cloudは金融サービス業界向けのソリューションで、顧客データの管理、金融商品の提案、規制対応などを支援しています。これらの業界特化型ソリューションは、Salesforceの基本的なCRM機能を土台に、各業界固有のニーズに応える機能を追加することで、市場での強固なポジションを獲得しています。
■Vertical SaaS
・アカウント深耕戦略
市場が限定されるが故に対象顧客数が増えにくい傾向があるため、ARRを伸ばしていくためには、アカウントごとの売上を最大化する必要があります。そこで、ソフトウェアだけでなく、プロフェッショナルサービスや専任のカスタマーサクセスチームを設置するなど人的リソースによるアカウントへのアップセルを通じて、売上を最大化するものです。
■Global Horizontal SaaS
・ローカライゼーション戦略
まずは言語的な意味合いでのローカライズが検討されるでしょう。言語の壁を越えることで色々なロケーションに進出することが可能になります。また、それ以外にもデータを当該国内に置いておくために、国内リージョンの設置なども行われます。
■Global Vertical SaaS
・共創プログラム
業界内で世界的にソートリーダシップを取っているような特定の顧客との共同での研究や開発プログラムを通じて、新しいソリューションやベストプラクティスを開発するものです。これにより、業界内の顧客のニーズにより的確に応えると同時に、他の顧客にも同様のソリューションを提供することができます。
・業界ルールの設立
自らを含めた業界団体を設置し、業界における標準を確立していくことで、根差しているルールごと掌握するような動きです。
■Local Horizontal SaaS
・ローカライゼーション戦略(※コピーを作っていくイメージでの)
他の国や地域に進出する際、現地の法制度や市場特性に合わせてサービスをローカライズしていくものです。ビジネス的にはグローバル化のように思えるかもしれませんが、あくまでLocal SaaSを別のロケーションで出すような動きになります。もし、真にグローバル化を目指すのあれば、似たような法制度や商習慣の国を選定した上で、どこまでを共通のものとして捉え、どこからがローカルなものかを整理しながら、進めていく必要があります。
■Local Vertical SaaS
・隣接市場参入戦略
現在の業界に隣接する業界へ進出して、市場を拡大します。
・データ活用戦略
自社のSaaSで収集した国内の特定業界におけるデータを活用し、新たな価値を創出するものです。予測モデルの提供、ベンチマーキングサービスなどが考えられるでしょう。不動産業界などはこの戦略を取ることが多いかもしれません。
各軸に依存しない成長戦略
・コンパウンド戦略
相互に連携した複数のSaaSを立ち上げ、より包括的なソリューションを提供するものです。単に複数SaaSを立ち上げてクロスセルを狙っていくというものではなく、複数であるからこそより高い価値を提供できるものです。
コンパウンド戦略を考える上でも、何に根差しているか(何が全てをバンドルするキーにあたるのか？)を定義するのが重要です。Ripplingでは、従業員データが全てのビジネスアプリを統合する概念であると考えて、そこに根差して複数SaaSを立ち上げているようです。
私たちは、ビジネスソフトウェアを全面的に「再考」する存在になろうとしています。なぜなら、全てのビジネスソフトウェアやアプリケーションは、従業員データに依存しているからです。あなたが誰で、ボスが誰なのかもわからないままに、GitHubを使ってソフトウェアを書くことなんてないですよね。そう、関係性を理解する必要がある。Ripplingにはその依存性を直接組み込んだのです。
日本の現状について補足
※ここはデータというよりも、お客様と面していて得たインサイトをもとにした私見になります。
日本においてはLocal SaaSが現状担っている領域に関して、特にSIerの活用をはじめとして、各企業の業務フローに合わせたソフトウェア開発というのが進められてきました。
ここでは各社の業務フローに根差していたわけですが、当然共通化ができ得るであろうということで、多くのパッケージソフトが開発され広く取り入れられてきたものと思います。しかし、日本においては、このパッケージソフトはあくまで共通部分の提供であり、個社部分をカスタマイズすることで、パッケージ+SIという収益構造を作ってきたと思われます。これは別のアプリを何個も立ち上げているということなので、運用負荷が高いモデルです。
とはいえ、カスタマイズしなかったとしても汎用性を求め続けて機能開発を拡張し続けると、ソフト自体が肥大化してしまい、手を入れるのが難しい巨大なモノリスアプリができるということもあったかと思います。
ここで根差しているものの違いからSaaS化の機運が到来するタイミングが分かれてきました。
Local Horizontal SaaSが担う会計や人事労務といった領域は、先般あった通り、法律などのルールに根差してることが多いため、提供者からすると外的な要因でソフトウェアの更新をせざるを得ません。そのためパッケージのバージョンを定期的に上げていく必要がありますが、契約の更新や減価償却なども含めた事務手続きまで含めると、頻繁な更新というのは割りに合いません。また頻度が高いと低単価なパッケージというのも作りにくく、結果高単価を払える顧客にセグメントが限定されてしまっていました。
そこの解消するものとして、サブスクリプションモデルやクラウドの活用を前提にして作られた会計系のSaaSなどが急速にシェアを伸ばしてきたのだと思われますし、パッケージソフトを提供していた企業群もSaaS版の開発に積極的になっています。
一方、Local Vertical SaaSの担う領域は、そういった外圧などが相対的に少ないこともあり、市場にレガシーになったパッケージソフトがまだまだ多く存在していると思われます。昨今は、これらを代替するLocal Vertical SaaSというのが、注目されていると感じています。また、外圧が弱いとはいえ、老朽化しているパッケージソフトの運用負荷やセキュリティ懸念、また、パッケージ+SIのビジネス的な安定性への懸念から、SaaS化(SaaSification)の機運は徐々に高まっているものと思われます。
なお、SIerについてのより深い考察はミックさんのnoteを参照されたい。
B2B SaaSの地図に新しい方向を加える（地図の拡張）
ここから更に一歩深くSaaS業界のトレンドを分析してみます。
SaaS for SaaSというDepth SaaSの領域
SaaSはカオスマップで表現されるように、数多く世の中に提供されていますし、まだまだソフトウェア化されていない領域は存在しているので、一個単位あたり規模の大小はあれど、まだまだ増えていくことでしょう。この事象によって開拓された領域がSaaS for SaaSです。HorizontalやVerticalにちなんで表現すると新しい方向である奥行きとしてのDepth SaaSとも言えるものでしょうか。
SaaSを管理するためのSaaS
DXなどを背景に、SaaS導入は促進されていますが、導入を進めれば進めるほど管理が煩雑になり、管理の現場は負担が増加しています。
「ユーザーは何のサービスを利用しているのか？「権限は適切か？」「コストは適正か？」「セキュリティリスクはどこにあるのか？」などなどが、SaaSの導入にあたって利用の現場に主体が寄ることで、管理側から見えないことにより、ときには、予期せぬITコスト増加、情報漏えいなどのセキュリティの問題など企業活動全体に影響する場合があります。
これを防ぐためにSaaSの管理業務自体をSaaS化しているのが「SaaS管理」などの言葉で表現される一つのSaaS for SaaSです。
具体的には「マネーフォワード Admina」や「ジョーシス」、「zooba」などが存在しています。
SaaSを活用するためのSaaS
■ワークフロー型
これは自社のワークフローに合わせたり、SaaSを横断的に使わないと実現できないワークフローをカバーするために活躍するSaaSです。
以前からあるもので言えば、Zapierや国内で言えばYoomなどが該当するかと思います。また、昨今話題のオープンソースのLLMアプリ開発プラットフォーム「Dify」もこのような流れの一つとして捉えることができるかもしれません。
また、Chatworkの提唱するBPaaS(Business Process as a Service)も実はこの領域であると言えるでしょう。インターフェースがチャット/人であって、中身はこの「SaaSを活用するためのSaaS」を構想していると思われます。BPaaSを単価を上げるアップセル手段として見ていると、(それはBPOでしかなく)BPaaSの本質を見誤ると思います。
業務の型にあわせてバックオフィス系のSaaSとビジネスチャットをAPIで連携させる「自動化エンジン」を構築することで、定型的な業務オペレーションを高度に自動化することができます。
なお、この領域に関しては、ブラウザのレベルではなくOSレベルで活用が進んでいく可能性があると考えられます。
先般発表されたPower Automateの新機能「AIレコーダー」などは、画面操作とその状況を会話することによって操作をAIが学習をし、業務を実行するような機能です。
https://www.publickey1.jp/blog/24/pcairpapower_automateai.html
■データ統合型
コンポーザブルなSaaSというのも「SaaSを活用するためのSaaS」として考えられるでしょう。複数のSaaSが各業務を担うと、データがサイロ化してしまい、統合的にデータを分析することができないことがあり、それを懸念されてエンタープライズにSaaSが導入されないという事象があるようです。
これを受けてパトスロゴスの提唱する「コンポーザブルERP」などは、コンパウンド戦略を自社で閉じるのではなく、HR SaaS業界全体で共創していこうという動きのように思えます。
(※詳しくは「前田ヒロ Startup Podcast」の牧野さん回をご視聴ください。)
もしくは Snowflakeなどデータを統合するSaaSや、primeNumberが提唱している「DATA ORCHESTRATION CLOUD」構想もこの辺りで活躍するかと思います。
また、前述の「SaaS管理」プレイヤーのビジネス拡張案としては、ワークフローをカバーするところまでいったり、SaaSのアプリストアのような購買を握りにいくような動き、データを統合するような動きなどが出てくるかもしれません。
いずれの型にしても、ここで問題になっていきそうなのは、日本国内のSaaSはAPIが公開されていないことが多い点です。あるけど有料+非公開だったり、確かに公開されているけど片手で数えられるだけしかAPIがなくて実質使えないとかだったりします。(※これは、以前公開されているAPIがどれほどあるのかを実際に調べてみての所感です。
結果記事：https://saasus.io/blog/saas-api-list)
何故公開されていないのかについては、調べる余地がありそうですが、何にせよAPIの公開に対する動機づけが弱かった、というのはあるのでしょう。
今後、こういったエコシステムが発展していくことによって、そこに参入できないリスクを解消するために、APIを公開していくという流れができていくと、業界全体の利便性が上がって良いなと思います。
SaaSを開発/運用するためのSaaS
※ここからはポジショントーク / PRも含みます
B2B SaaSには、それがたとえどの象限のSaaSであったとしても、共通で必要な機能群というものが存在しています。(ex.テナント管理 / 認証認可 / 請求利用料の計測など)
これらはSaaS Control Planeと言われています。
SaaS Control Planeに属する機能群は、明確にControl planeとして分割され管理されていないとしても、アプリケーションのどこかしらには実装されています。
これらはSaaSの成長には必要不可欠ではあるものの、顧客に直接的に価値を提供するような競争力の源泉(=売上に直結する)とは言い難いものです。
なお、このアーキテクチャの考え方などは2024年の4月に漸く書籍という形での公表がなされたものです。ご関心のある方は「Building Multi-Tenant SaaS Architectures」 by Tod Goldingをご購読されることをお勧めいたします。
https://www.oreilly.com/library/view/building-multi-tenant-saas/9781098140632/
もしくはAWS酒徳さんの講演動画を観るのもいいかと思います。
https://www.youtube.com/watch?v=ioFDS2q6zxA
さて、そんなSaaS Control PlaneをSaaSで提供しているのが、私が経営する株式会社アンチパターンの「SaaSus Platform」(https://saasus.io/)です。
SaaSus Platformを利用することで、SaaS Control Planeを自前でイチから作る必要がなくなります。これにより、コストの削減はもちろんリリース期間の短縮、何よりもコア機能の開発にフォーカスすることができるようになるので、より収益性の高いSaaSを市場に投入することができるようになります。(=売上に直結する機能のみを開発することで売上に対する開発生産性が高まる)
さらには、B2BにおいてもMicro SaaSが生まれやすくなるかもしれません。
以上のようにSaaSが発展していくことによって生まれた新たな方向性Depth SaaS (SaaS for SaaS)は、これから市場の拡大が大きく見込まれる新たな地平であると思います。
ビジネスとテックの融合こそがSaaS(地図とコンパスの指し示す場所に行くには)
SaaSはビジネスとテックが融合していることこそが面白味です。どちらかだけで考えられるようなものはなく、どちらも考えていかなくてはなりません。
アプリケーションのドメインモデルも何に根差したプロダクトなのかを話し合うことで整理され、実際の業務(ユースケース)が理解されていくことによって高度化が進んでいくものです。この重要性が理解されつつあり、最近ではそのドメインに最も詳しい人をドメインエキスパートとして、チームの中で役割定義をする動きなども見られるかと思います。
また、アプリケーションだけでなく、SaaSのデプロイメントモデルもビジネスとテックの両視点が必要なものです。
例えば、サイロモデルというテナントごとに専用リソースを提供するデプロイメントモデルは、コンプライアンス対応の都合で採択した方が良い場合や、Local Vertical SaaSなどで対象テナント数が極端に少なく、そもそも共有効果が得難い市場が対象であるなどの場合に有効な選択肢になり得ます。しかし、Horizontal SaaSのようにテナント数が多くなることが見込まれる場合には、このモデルの採択は慎重に検討が必要になるでしょう。
かえって対象テナント数が多くなる見込みがあるからといって、リソースを共有するデプロイメントモデルであるプールモデル一択というわけではありません。こちらはノイジーネイバー問題への対応やテナントの分離について、しっかりとした設計と実装が必要になってきます。
当然これらのデプロイメントモデルは画一的なものではなく、上位のティアのテナントはサイロで、下位のティアのテナントはプールなど、ビジネス戦略に合わせて複合的にアーキテクティング可能です。またブリッジモデルのようにコンピュート層はプールで、データ層はサイロなどの組み合わせ方も存在しています。
AWS Well-Architected フレームワークの SaaS レンズにも記載がありますが、「SaaS アーキテクチャに万能の解は存在しない」ので、ビジネスや周辺環境の変化ととも継続的に変化させ続けるものであるということを認識しておきましょう。
ビジネスとテックの融合によってSaaSは真価を発揮します。全てを一人で賄うことはできませんから自ずとチームでこれらに相対することになります。チームメンバーへのリスペクトを大切に、一丸となって事業運営をしていくことが重要です。
SaaSの旅をどこから始めるか？
まずはSaaSに関する知識を身につけるのが重要であると思います。最初にビジネス的な観点(一般的なSaaSの指標など)を中心に網羅的に学ぶのであれば、宮田さんの本を読んでみてはいかがでしょうか？
もしくはSaaSデータアナリストであるぽこしーさんの本も人気かと思います。
テクニカル寄りのを補足するコンテンツという意味では、アンチパターン社からもガイドブックを公開していますので、ご興味ある人はDLしてみてください。
以上で本稿は結びとなります。
今回整理した「B2B SaaSの地図とコンパス」の知見を用いてくださる方が出てくることにより、日本発のB2B SaaSがより発展していくことを祈念いたします。
査読への感謝
本稿は以下の方々にレビューをいただきました。御礼申し上げます。(※順不同)
前田ヒロ(@djtokyo)さん ALL STAR SAAS FUND
Masayuki Minato(https://note.com/minato1014)さん ALL STAR SAAS FUND
神前達哉(@tatsuyakozaki)さん ALL STAR SAAS FUND
早船明夫(@CraftData2)さん Next SaaS Media Primary 運営
AYA(@ayazook)さん from AWS SaaS Factory
信田健児(@kenjirp)さん
やぎぃ(@Yaggytter)さん
この記事が気に入ったらサポートをしてみませんか？