見出し画像

進出して分かった日本とアメリカのSaaSプロダクトニーズの違い

高田優哉/Commune

はじめに

  • これは何？

    • 数カ月間マーケット調査、商談をして見えてきた日本とグローバルでSaaSプロダクトに求められることの違いを紹介する

  • 誰向けの記事？

    • グローバルで利用されるプロダクト開発に興味のあるPdM, エンジニアの方

  • まとめると？

    • 競合がエグい。日本はプロ野球で、グローバルはメジャーリーグみたいなイメージ。プロダクトは広く浅く→狭く深くに要件が変わる。

    • エコシステム、SaaS市場の成熟度の違いから、インテグレーションファーストになる

    • 時差や人件費の違いがプロダクトに影響を与え、セルフサービス前提の設計になる

  • 伝えたいこと

    • グローバルで使われるSaaSプロダクトづくり（＝メジャーで野球する）、そしてそこで勝つためのプロダクト・開発組織づくりに経営者として本気で取り組みます。

    • メジャーで勝利するために、優秀なメンバーが集まり、切磋琢磨し、成長できる環境。勝ち筋も見えています。他ではできない挑戦だと思います。メジャーへの挑戦を牽引する優秀なエンジニアの方にコミューンの仲間になってほしいです。

    • エンジニアの方、わたしと直接のカジュアル面談でぜひお話させてください。DM歓迎です！（もちろんメンバーとのカジュアル面談も大歓迎です！笑）


自己紹介

こんにちは、コミューン株式会社CEOの高田です！
昨年末に米国進出に関するブログを書きましたが、今年度からようやくグローバル事業における市場調査や初期商談が開始でき、直近やっとご契約もいただきました。
いいタイミングだと思い、グローバルプロダクト開発に求められることについて現時点での学びをご共有させてください。

私は基本的に「成功していないのに積極的に発信すべきではない」というスタンスなのですが、グローバルで勝つためのプロダクトづくり、開発組織づくりに熱量のあるエンジニアの方に少しでもコミューンに興味を持ってほしくて、この記事を書いています。もしこの記事が少しでもみなさんのお役に立ったなら、ぜひSNSでシェアしていただきたいです！

前提：コミューンにおけるグローバルプロダクト開発体制

ワンプロダクト思想

  • BtoCサービスだと日本向けプロダクトと海外向けプロダクトを別ものとして作り直すことがよくあります（例：メルカリ）

  • BtoBサービスだと多国籍企業に使われることもあるので、コードベースは共通していることがほとんどです。（例：Salesforce）

  • コミューンもBtoBサービスを提供しているので、グローバル向けにあたらしくゼロからものづくりをするのではなく、日本ですでに使われているプロダクトの拡張により英語版を開発しています。

既存機能の英語化のみ独立チーム

  • すでに日本語で提供されている機能については、翻訳のインプリや細やかな文化面での調整に、意外と莫大な工数がかかります。（初期から英語版を見据えて作っていれば…というのはタラレバで、当時はそんな余裕もグローバル展開の確証もなかった）
    ここについては専門チームを立ち上げて、PdM1名、エンジニア4名でかなり頑張ってもらっています。

  • 一方で、グローバライズを決めてからの新しい開発については、日本語環境／英語環境両方での価値提供を前提に仕様決定→開発→QAまで日英分離せず全開発者が行っています。

英語力はまちまち

  • 日本で立ち上げて、日本で拡張してきたチームなので、初期から英語力を必須にはしていません。一定の技術力と、強いカルチャーフィットを要件にしています。

  • ほぼネイティブのメンバーもいますが、それはたまたまかつ例外です。

  • ただし、現在開発組織のグローバライズは進めています。


違い①：マーケットサイズと競合環境が全然違うので、狭さと深さが大事

そもそもSaaSのマーケットサイズは米国だけで日本の10倍、世界でいうと20倍以上ある

  • グローバルSaaSマーケットサイズは$166B (2021)

  • アメリカのSaaSマーケットサイズは$73B (2021)

  • ボクシルさんによると、日本のSaaSマーケットサイズは8,000~8,500億円。（= 120円/1$で換算すると$7B）

市場のサイズが10倍だと、競合も10倍。レベルもあがる。

  • 例えば「コミュニティ」という切り口で捉えると、グローバルには30社以上存在(実態がある事業者のみでも)。日本には数社しかいない

  • かつ、プロダクトクオリティの面でも平均値が高い。

  • メジャーリーグは30球団あり(日本は12球団)、かつ、大谷とかトラウトとかに目が行くけど、メジャーリーグでスタメンなだけでそもそもの平均値が日本のプロ野球より高いのと一緒

  • 毎月新しい競合が出てくるし、知名度がないけどARR100億のSaaSとか普通にあるなかで、それらに勝たないといけない。それがすごい面白い。


影響1：とにかく狭くしないといけない

  • コミューンは日本でNo.1コミュニティ／カスタマーサクセスプロダクトだと自負しています。しかし、それくらいふわっとしていると市場の掴みどころがなく、むしろスコープとして広すぎます。

  • USで勝つには、なぜそのプロダクトを選ぶか？の明確なフックが必要です。

  • ポイントはそのフックが日本市場に慣れている身だと’狭すぎる’と感じること。

  • なぜ狭すぎると感じるのか、というと、一つ一つの池の大きさが日本だと1/10なので、日本だと十分にスケールしないからです。日本でグロースしているorできる起業家ほど、ここの感覚のフィットが大変だと思います。

  • また、競合の数、も影響として大きいです。日本だとそもそも市場にあるプロダクト数が少ないので、顧客企業側は全社を比較検討しても問題ないですが、グローバルだとスコープを広げすぎるときりがありません。ので、顧客企業側も、ダブルクリックした自社ニーズを理解した上でサービス調査をすることが多いです。

    • 例：「コミュニティサービスが使いたい」だと選択肢が多すぎるので、「NPO運営に特化した安価なプラットフォームで寄付機能があるサービスが使いたい」まで顧客側で要件を絞ってサービスを探す。ツール側の視点に立つと、この粒度のレーダーに引っかからないと声がかからない。

  • ゆえに、プロダクト開発において、選択と集中／戦略的動きがこれだけ大事な環境はないと感じます。日本のマーケット環境は総花的なプロダクトになることにインセンティブがある構造になっているのですが、グローバルだと如何に絞るか、です。なんというか、プロダクトづくりこそ経営、という感じがあります。

マーケットの大きさ/市場選択の狭さの一例として、営業メンバーのインセンティブ給を計算/管理するSaaSがあります。
これだけ市場規模が狭く見えるドメインでも今年1月のファイナンスでユニコーンになっています。日本で同じビジネスをやっても(商習慣の違いはありますが)ここまでスケールしないでしょう。

影響2：深くまで掘って掘って掘る

  • マーケットサイズが大きいので、上述のように狭くマーケットを捉えることも大事ですが、そのうえで脇目をふらずにマーケットを掘ることが重要です。つまり、プロダクトを狭く深くしていくイメージ。

    • このマーケットはおいしそう、となると、競合（他の選択肢）がどんどん出てきます。LPだけいい感じに作るのは秒でできます。その中で突き抜けるためには、掘りまくることによる競合優位性の構築／維持が大事です。

  • 日本だとそもそもひとつひとつの鉱脈が小さいので、単一プロダクトでなるべく多くのニーズをカバーするためにプロダクトを磨いていくことが多いです。ざっくりいうとプロダクトは広く浅くなっていくイメージです。

    • そもそも日本はマクロで市場が成長していないので、「プロダクトで解決するニーズ」を広げるしかありません。

    • 日本で伸びるプロダクトは売上成長のためにだいたい広いニーズをカバーすることになるので、グローバルで見るとどの市場でも60点になり、激しい競争に勝てない、となりがちです。

  • じゃあ日本で単一市場ニッチ戦略を取ればいいじゃんと思うかもしれませんが、市場が小さすぎて売上が上がらないから資金調達もできず、それはそれで苦しい。という解けないパズルがあるから、日本でそこそこグロースしてからのグローバル展開はしんどいのです。

補足
バックオフィス系だと、グローバルチャレンジの際にマーケットサイズや競合環境以上に法律や商習慣の違いが大きな障壁になると思います。
コミューンの場合、バックオフィスSaaSのように法律や商習慣に強く依存しないので、ピュアに顧客ニーズに向き合い自由度高く開発できる、というのがグローバル展開の大きなアドバンテージです。

違い②：SaaSはとにかくインテグレーション

  • コミューンではコミュニティプロダクトを提供しているので、商談の際にコミュニティに求める要件を聞きます。すると、最初に「すでに使っているシステムとのインテグレーション」が上がります。コミュニティ活性でもデータ分析でもありません。ぶっちゃけ手段の目的化なんじゃないか？と思うこともありますが、とりあえず事実ですし、これが足切り要件になることがほとんどです。

理由1：すでに日本の9倍の数のSaaSが使われていて、そのエコシステムありきだから

  • 2020年のデータでいうと、日本企業の1社あたり平均SaaS導入数は8.7個、一方でアメリカでは約80個。その差は約9倍。活用しているSaaSの数が文字通り桁違いなので、新しいSaaS導入を検討する際にも、すでに活用しているSaaS群の中でどのように位置づけられ、どのように連携するのか？が非常に気にされます。

  • 業務がSaaSオリエンテッドになっていることも大きな違いです。業務に合わせシステムを入れるのではなく、システムに合わせて業務を変化させる動きが一般的がゆえに、SaaSエコシステムとのフィット感をすごく気にするのかもしれません。

理由2：インテグレーション負担(コスト)が日本よりリーズナブルだから

  • 日本だとユーザー企業にエンジニア工数が少なく、インテグレーションを行うためには外部SIerに委託することも珍しくありません。そこで結構なお金と時間がかかってしまいます。

  • また日本だとSaaSとの連携ではなく自社独自のDBとの連携が必要なケースがあり、やろうとするとSaaSとの連携に比べて費用や工数が重くなり、更に割に合わなくなります。

  • 一方でアメリカだと非ソフトウェア企業でもユーザー企業サイドにエンジニアがいることが多く、インテグレーションがスピーディかつ安く済みます。またSaaS同士の連携が主であり、コストも抑えられます。以上からインテグレーションを行う費用対効果が高く、インテグレーションありきになるのだと考えます。

  • 参考）エンジニアのベンダー／ユーザー所属比率。正確にはITか非ITか、という仕分けだが

    • 日本：IT企業(ベンダー側)72％、非IT企業(ユーザー側)28％

    • アメリカ：IT企業(ベンダー側)35％、非IT企業(ユーザー側)65％

開発においてもエコシステムを正しく捉え、その中での自社サービスの位置づけを理解する必要がある。

  • 例えばコミューンでも「コミューンAPI」として汎用的なAPIは提供していますが、それでは不十分です。

  • 「Salesforceの提供するSalescloudというSaaSの指定カラムに、メールアドレスをKEYにしてコミュニティのログイン回数データを反映するSalesforce連携用のAPI」とかのレベルで個別具体なものが求められます。

  • 自分たちのサービスを使うユーザーは他にこういうSaaSを使っていて、ゆえに自分たちはこういうエコシステムの中で、こういう役割が期待されていて、そのなかでユーザーがこう使うからこの個別ニーズに対応するAPIを…の繰り返しが必要です。
    (こう書くと当たり前のことみたいですが…。)

違い③：セルフサービス前提のプロダクト設計

  • 昨今プロダクトレッドグロース(PLG)という考え方が流行っています。セールスレッドグロース(SLG)というビジネス組織(更にいうと営業)が売上成長を牽引するモデルに対比するもので、プロダクトが売上成長を牽引する、という考え方です。

  • セルフサービスによるプロダクト活用と人によるプロダクト活用支援はPLG⇔SLGの構造とセットで語られることも多いですが、それ以上に市場構造の違いが一般にセルフサービスの必要性を高めています。

時差

  • そもそもアメリカ国内でも最大3時間の時差があります。この時差が意外ときつくて、西海岸の人と東海岸の人だと一日5時間しか勤務時間がかぶりません。顧客の視点に立つと、営業時間のなかなのに最大37％担当者と接触できない時間があるということになります。結構でかいです。

  • また、英語でプロダクト提供をすると北米以外の顧客を獲得するケースもあります。日本にいるみなさんも、日本語対応していないSaaSを導入していたりしないでしょうか？それ以外にも、イギリスやオーストラリア、インドなど英語圏の国で活用されるケースも有るため、セルフサービス度合いを高めないと価値提供が困難になります。

サポート・カスタマーサクセスクオリティ

  • これはいろいろな理由が混在していると思うのですが、特に超ハイクラスの給与ではない場合におけるカスタマーサポートやカスタマーサクセスのクオリティが日本は高すぎるくらい高いです。

  • 一方でアメリカは…なので、人による顧客支援を前提としたプロダクトよりもシステムに任せたほうが企業にメリットがある構造になっています。

人件費と雇用流動性

  • アメリカの人件費はすごく高いです。コミューンでも、USの給与テーブルは日本の約1.7倍としていますが、それでも日本での採用環境に比べて不利な状況にあります。(本当に同クオリティの人が採用したければ2.0倍~の給与なイメージ)。なので、アメリカではプロダクトの価格を2倍にする、とかしない限りはセルフサービス度合いを高めないと整合が取れません。

  • 更に、At will basisという雇用原則がありいつでも解雇できる/いつでも辞められるのもあり、人の稼働に依存するビジネスモデルのリスクは大きいです。

いかに人が介入しないで価値提供が提供できるか？がスケールのポイントであり、プロダクト開発の観点では、一層ユーザージャーニーに想像力を持ちプロダクトのみで解決するためには？を考え開発する必要があります。


まとめ

  • マーケットサイズは日本の10−20倍。かつ競合環境がエグい。日本はプロ野球で、グローバルはメジャーリーグみたいなイメージ。

  • 日本で勝つ野球の仕方とメジャーで勝つ野球の仕方が違うのと同様に、日本で売上を上げていくプロダクトの作り方とグローバルで売上を上げていくプロダクトの作り方は違う。

  • プロダクトは、狭すぎるくらい狭いニーズを掘って掘って掘りまくることが大事。浅く広くの日本とは真逆のアプローチ。

  • また、すでにSaaSがたくさん使われていてエコシステムがしっかりあり、ユーザー企業側にエンジニアがいるので、インテグレーション能力が重要。

  • 時差や人件費などの市場構造の違いから、如何にセルフサービスさせるか？(自社のビジネスチーム工数をかけないか？)を重視したプロダクト開発が大事


最後に

そもそもコミューンのグローバルでの挑戦は始まったばかりで、成功といえる成果からはまだまだ遠い状況です。

しかし、ようやく勝ち筋、一筋の光が見えてきました。

ここからは、プロダクトをどれだけ早く、どれだけよいものにできるかの勝負になります。

対戦相手はアメリカで著名VCから大型調達をしているようなグローバル企業です。

グローバルで評価されるSaaSプロダクトづくり、そしてそこで勝つための開発組織づくりに経営者として本気で取り組みます。

メジャーリーグで勝利するために、日本のプロ野球のエースが集まり、切磋琢磨し、成長できる環境。他ではできない挑戦だと思います。

グローバル市場で評価されるプロダクトづくりを牽引する優秀なエンジニアの方にコミューンの仲間になってほしいです。
一緒に、日本発のソフトウェアがグローバル市場で勝てることを証明したいです。

もし少しでもご興味があれば、わたしと直接カジュアル面談させていただきたいです。

もちろんコミューンの開発組織メンバーに直接お話聞いていただくのも大歓迎です！

本気です。
ぜひよろしくお願いいたします。


サポートもうれしいですが、シェアやお友達に紹介いただくともっとうれしいです！🙇🏻‍♂️