SaaS企業はコンパウンドスタートアップを目指すべきか？（後編）
自己紹介
澤悠詩（@kujira_poe）と申します。8年間freeeに在籍しています。
顧客インタビューとSaaSとプライシングが好きです。
前編の要約
前回見たように、コンパウンド企業が生まれた背景は3つありました
・オンプレからクラウドの移行期にはシングルSaaSに取り組む合理性があったが、今後コンパウンド企業がソフトウェア業界において復権する
・シングルSaaSの飽和によって、必要な機能は収斂してきている
・コンパウンド企業を支える大きな資金調達ができる外部環境になってきた
また、コンパウンド企業には開発・ビジネスの両方でメリットが大きいことを確認しました。
・ミドルウェアは複数製品で再利用されるので、シングルSaaSができないレベルで開発投資が可能になる
・ミドルウェアを使って新製品を素早く構築できる
・バンドルによる価格優位性がある
・効率的なクロスセルができるので、ARPUを最大化できる
・その結果、少ないS&Mで高いARPUを実現できるのでSMB市場でもビジネスが成立する
開発・ビジネスにおけるメリットが多大にあるコンパウンド企業ですが、顧客への提供価値はどのように変わるのでしょうか。
顧客への提供価値
統合による幅広いユースケース
コンパウンド企業では、個々の製品がミドルウェアと深く統合され、ミドルウェアを通じて他製品とも統合されているため、製品を横断的、かつカスタマイズして使うことができて幅広いユースケースに対応できるようになります。
一般的なSaaSにおけるマスタが非常にフラットで静的、かつ一次元的であるのに対して、コンパウンドスタートアップでは個々の製品に共通するグラフ（Ripplingでは従業員グラフ）に、全ての情報が紐付けられます
マスタの例：従業員名簿。ユーザー名やパスワード、グループメンバー
グラフの例：従業員グラフ。基本的な人事部の社員データ、報酬に関する情報、仕事、役割、機能、特定の部署だけでなく、部署全体の階層、チーム、勤務地、雇用形態、使用するコンピュータの種類やオペレーティング・システムの種類、未解決のプルリクエストはいくつあるか？そして、彼らが持っている最も古いオープンなプルリクエストは何か？そして、彼らに割り当てられている Jira チケットは何枚あるか？Cartaには各自がどれだけの株をもっているのか？
横断的にレポートや分析できるのはもちろん、本来他製品に格納されているデータが、グラフを通して異なる製品でも扱うことができるようになります。統合することで、ベンダー側が当初想定していなかったユースケースも実現できるようになっています。
分かりやすい例として、RipplingのAutomationというミドルウェアを挙げてみます。異なる製品で収集した情報も従業員グラフに紐付けられているので、製品をまたがった自動化を設定できるようになっています。例えば、Ripplingの従業員アンケート機能で、遠隔地からTGIF（会社の華金イベント）に参加する、と回答したユーザーに、Ripplingの支出管理機能から、自動でプリペイドカードを発行する、といった具合です。
このように製品を横断的、かつカスタマイズして使うことができると、結果的に効率的に業務を行うことができるようになります。
Ripplingの場合、企業規模を問わずRipplingを使っている会社の人事、IT、財務の人数は、使っていない会社のほぼ1/2になっています
低い学習・管理コスト
ミドルウェアやコンポーネントが共通化され、異なる製品でもUXパターンが同じになるので、ユーザーが新しい製品を使うときの学習コストを低く抑えることができます。
また多くの異なるSaaSを使っている場合、最終的には管理すること自体が課題になりますが、コンパウンド企業はこれらのシステムの多くを1つに統合することで管理の複雑さを軽減します。
注釈 通常のマルチプロダクト企業も最終的に、異なる製品でも共通の顧客体験を提供しているケースは多いと思います。ただし、シングルSaaSからマルチプロダクト企業になる過程においては、素早く立ち上げるために既存プロダクトからミドルウェアを切り出すことはせず独自に立ち上げて、あとから共通化を図ることもあります。最初から同じミドルウェア・コンポーネントを使うことを意識しているコンパウンドスタートアップは、アクセスしやすい提供価値だと思います。
コンパウンド企業に必要なこと
統合が重要な分野を選ぶこと
コンパウンド企業にとって最も重要なことは、構築しようとしている製品群と分野において、統合が本当に重要であるという確信をもつことです。
複数製品をもつということは、基本的にバイヤーが分かれることになります（もちろん同じ場合もあります）。これは販売上のデメリットになりえます。複数製品を統合することによってシングルSaaSにはない提供価値を引き出すことができない場合、単に構築と販売に余計なコストがかかるだけのビジネスになります。
これはコンパウンド企業が新製品の立ち上げる際にも同じことが言えます。新しい製品を立ち上げる際には、具体的には次の4つの利点が活かせる分野へ進出していくことが重要です。
新製品と既存製品で同じグラフを使うことができる
既存のミドルウェアと統合可能である
既存製品とUXを実現できる
競合他社を価格設定で圧倒できる
開発チームを分けて集中させる
コンパウンド企業において重要なことは、いかにして複数のことを同時にうまくやるか、です。そのため、特に新製品を構築する際には、小規模な部門横断的チームを作り、フォーカスできるようにする必要があります。デザイナー、プロダクトマネージャーやカスタマーサポート、エンジニアを一つの製品に取り組むチームとしてまとめることで、新製品に対してコンテクストを共有することができるようになります。
理想的には、新製品チームに限らず、あらゆるチームをモジュール単位で可能な限り互いに切り離すことです。互いに調整する必要がなく、必要なやり取りはSLAやインターフェースで行う方法を考えましょう。そうすれば、他のチームとの調整に阻まれることなく、独立して活動することができるようになります。後述しますが、採用した元起業家をリテンションするためにも、他チームとの膨大な調整をせずとも済む構造にしておく必要があります。
エンジニアと元起業家の大量採用
ミドルウェア、ハイペースな新製品リリースなど、コンパウンド企業では同時並列に開発を行うため、エンジニアを大量に採用する必要があります。
Ripplingの場合、会社の約半数がエンジニアで構成されています。研究開発費の観点で見ると、平均的なARR100〜200億円のB2B SaaS企業の研究開発費が売上高の約20%相当である一方で、Ripplingの研究開発費は、売上高の60%以上に相当します。
会社の半分以上がバンガロール（インド）のオフィスにあり、その多くがエンジニアリングを担当しています。リモートチームを抱えることの課題はもちろんあります。でも、ベイエリアですべてを構築するのは不可能なので、そうした課題を克服する方法を見つける必要があります
また、製品ごとにチームが分かれており、チームリーダーがエンジニアだけでなくビジネス部門（カスタマーサポート、プロダクトマネジメント、デザインなど）を束ねる必要があるため、元起業家のような人材を大量に必要とします。Ripplingの場合、35〜40人の創業経験者がいて、従業員数の10％以上を占めると言われています。
またRipplingでは新製品を作る際、最初の4〜5人のエンジニアをプロジェクトリーダー（元起業家）のネットワークを通じて集めさせています。会社本体の採用リソースを一切使わせません。自分の言葉で説得、採用ができなければプロジェクトの本当のリーダーにはなれません（注釈 大量に優秀なエンジニアを採用するための一つの工夫でもありそうです）。
クロスセル組織の機能分解
複数製品をもっていると、すべての製品がクロスセルを担当する組織のリソースを奪い合うというボトルネックに直面することになります。
そこでクロスセル組織をマーケティングとセールスに分解して、既存顧客へのマーケティングは各製品チームが行い商談を創出して、クロスセルセールス組織が商談をクローズする、と役割分担を行っています。
SaaS企業はコンパウンドスタートアップを目指すべきか？
コンパウンド企業とは、マルチプロダクト企業の展開方法の一つ
急成長するSaaS企業は、タイミングは違えど複数のプロダクトを作る傾向にあります。
顧客体験の観点から言えば、コアなプロダクトから派生して出てくる要望に応えるために、ホールプロダクトの概念でいう「拡張プロダクト」を揃えることがセオリーとされています。
ビジネス成長の観点から言えば、プロダクトの成長は逓減していきます（プロダクトライフサイクル）。これはシングルプロダクトの限界、という文脈で、最近になって各所で議論されています。だからこそ「まだ早いのでは」と思われるうちから、2つ目のプロダクトについて取り組み始めます。
例えばSaaStrでは、マルチプロダクト企業になるべき時期を明確に取り上げています。
大雑把に言えば、顧客数が1万社に達するまでにマルチプロダクト企業になっておきたい
・エンタープライズの場合、ARR300-500億のタイミング
・ミッドマーケットの場合、ARR100億のタイミング
・SMBの場合、ARR20-30億のタイミングがそれに当たる。
- Jason Lemkin
プロダクトの立ち上がりまでにかかる年数を考えると、マルチプロダクト展開を始めるのは、この半分以下や四分の一のタイミング、というのが個人的な印象です。
では、マルチプロダクトを展開する前提ならば、最初からコンパウンド企業を目指すべきなのでしょうか。Parker Conradは2つほど判断基準を挙げています。
自社ドメインにおいて統合の重要性
そもそも、自社が向き合う顧客課題にとって、統合がどの程度重要なのか考えてみる必要があります。複数製品でグラフが共通であることが、具体的にどう顧客の役に立つでしょうか。従来、顧客が製品を跨いで分析したり、製品を跨いだワークフローがある業務分野なのであれば、十分に重要そうです。
人事労務分野であれば、おそらく毎回異なる切り口での集計や、個社ごとにまったくことなるワークフローが考えられます（例えば従業員の入社にともなうオンボーディング準備のワークフローは、会社によって異なるはずです）。定型化しにくく、従来はユースケースとして明確に挙げられにくかった課題が、統合によって解決できるようになるかもしれません。
また一口に統合と言っても、どの情報を軸に統合するかも考えてみる必要があると思います。Ripplingは従業員を、Salesforceは取引先を、Rampは取引を共通グラフにしていますが、自社の場合は何がグラフになりえるのでしょうか。共通の軸が見えにくいドメイン、Parkerの言葉で言えば「過当競争によって製品仕様が収斂している分野」以外では、コンパウンドスタートアップの実現は難しいかもしれません（一方でERPのようにカテゴリーの歴史が長いために、妥当とされる仕様が収斂していることもあると思います）。
自社ドメインにおいて、統合が重要なのか・何を軸に統合するのか。このあたりが最初の判断軸のように思います。
プロダクトを増やす余地のある市場
コンパウンド企業はプロダクトを作れば作るほど、多額の投資をして作ったミドルウェアを償却することになります。逆に言えば、沢山のプロダクトを作る予定がない、余地がない市場であれば、コンパウンドな製品構築をする意味はないと言えます。
コンパウンドスタートアップはミドルウェアのおかげで、新しいプロダクトを競合に比べて低い開発投資で生産できます（Ripplingの場合は、競合の20％がベンチマーク）。言い換えれば競合の5倍の速さでプロダクトを出荷できるわけです。Ripplingは28個、Datadogは20個、CrowdStrikeは10個のプロダクトをもっており、Rampは1年に2.5個のペースで新しいプロダクトを出荷しています。
将来に渡って、いくつプロダクトを生産する余地があるのかは考慮する必要があります。
おわりに
「SaaS企業はコンパウンドスタートアップを目指すべきか？」に対しては、「（かなり展開する分野を選ぶものの）目指すべき」と思います。
統合されたプロダクト群は、頻度が少ないためにユースケースとして挙げられにくい使い方もカバーできます。個人的には、実はそういったアドホックな業務がユーザーの時間をかなり取っているのでは、と思います。例えば年一回しかやらない業務であれば開発の優先順位には上がりにくい一方で、ユーザーはまずどうやって行うのか思い出す、から始まります。手順を思い出しながら、手弁当で行う業務ほどストレスがかかる仕事はありません。
Ripplingが実現しているような、複数製品間での自動化や分析は、頻度は少ないイレギュラーな業務にも柔軟に対応できそうに思いますし、実際にParker Conrad自身がそういった機会に遭遇して自社プロダクトの価値を再認識したそうです。コンパウンドスタートアップの製品は、GASやiPaaSを使ってなんとか自動化できてしまう人ではない、ほとんどのユーザーが遭遇する課題をすくい上げることができるのではないでしょうか。
事業としては、Parker Conradが何度も強調するように難易度が高いものの、製品の生産スピードを押し上げ、幅をもって意図的な価格戦略ができるバンドル戦略はとても魅力的だと思います。特にユーザーが最初に使うことが多い業務ソフトウェアに参入する際に、未来のクロスセルを念頭に、他社がUnitEconomics上できない低価格に設定できることは、戦略の幅を広げてくれそうです（Ripplingは給与計算ソフトウェアで同様のことを行っています）。
記事を書くにあたってまとめたPodcastは2020年から2022年年初にかけて収録されたものです。したがって当時と今では外部環境の違いがありますが、コンパウンドスタートアップのメリットやデメリットといった議論は根本的なところで以前も今もそう変わらないように思います。
どなたかにとって本doc記載の内容が一助になれば幸いです。
Appendix
本論には関係ないものの、調べている途中で見つけたParker Conradの面白い意見がいくつかあったので、備忘録的に記載しておく。
Ripplintg のビジョン
Ripplingは、従業員データのSalesforceになると思います。Salesforceのように、ビジネスプロセスやワークフローを管理するシステムになると思いますが、顧客データではなく、従業員や組織のデータという異なる基盤の上に構築されます。企業内には、Salesforceと同じようなツールを必要とするビジネスプロセスやワークフローが存在すると思いますが、それは異なる基本的な要素に基づいて構築される必要があるのです。私たちはそれを構築しようとしているのです
グラフについて
Facebookにはソーシャルグラフがあり、Salesforceにはカスタマーグラフがあり、そして従業員グラフがあるように思えます。従業員グラフについては、従業員名簿と区別するために、よく話しています。
マイクロソフトのビジネスの根幹はActive Directoryですが、これは従業員のリストとユーザー名、パスワードが記載されたテーブルという、非常に静的なビューです。
特異なサポート
私のキャリアの中で最も怖いローンチは、数週間前に行ったのですが、カスタマーサポートの日々の統計情報を公開するようにしたことです。基本的に、私がサポートチームのために社内で見ているすべてのデータを、私たちの一般向けサイトで公開するようにしたのです。rippling.comのサポート状況を見ることができます。
私たちのような製品はビジネスの中核をなすものです。誰かの給与計算を行う場合、それがうまくいかず、誰かに連絡を取ることができなかったらどうしようかと、とても不安になるものなのです。私たちがこれをやろうと決めた理由は、それが正しいことであることに加えて、「素晴らしいサポートがあります」と言っても、誰も信じてくれないだろうと思ったからです。本当に評価されるには、思い切って自分を売り込み、実際に基礎データを公開するしかないのです。
リードタイムの長期化
コンパウンドスタートアップは目に見える狭い課題ではなく、異なる課題を結びつける、より抽象度の高い課題について顧客を説得する必要があるため、商談のリードタイムが伸びる傾向があります。対策として、個々の製品を別々に購買できるようにしておくことが挙げられますが、理想的には、ある特定の製品を求めてきた顧客でも、社内の他の関係者を巻き込んでもらい、デモに参加させ、評価をしてもらうことが望ましいと言われています。例え複数製品の契約に至らなかったとしても、あとからクロスセルできる可能性が残ります。
この記事が気に入ったらサポートをしてみませんか？