エンタープライズSaaSを考える② ~ 新規事業開発編 ~

RightTouchの長崎です。
カスタマーサポート領域において、SaaSプロダクトを展開しています。

「Enterprise SaaSを考える」ということで、前回に続き書きたいと思います。（前回記事は以下です。）

前提

RightTouchはEnterprise SaaSという特徴とともに、複数プロダクトを展開する「コンパウンドスタートアップ」でもあります。Enterprise SaaSはコンパウンド化の重要度が相対的に高いと思っていて、その理由は3つです。

1. 対象とする業務の複雑性が高い

2. 一方で前回記事の通り、いきなり全体や基盤に近い部分のリプレイスは難しい

3. 対象とする裾野が狭い（顧客数が少ない）ので、複数プロダクトでARPAを上げないと高い成長率を作れない

本記事の50%くらいは社内の新規事業立ち上げに関わるメンバー向けの社内報的な要素を含んでいるのですが、「Enterprise SaaS及びコンパウンドスタートアップの事業開発」という観点で言語化してみました。SaaSの新規事業開発、EP向けにSaaSを展開されている方はぜひ読んでみてください。

事業開発の再現性について

「10回やって9回当てる新規事業づくり」

がエンタープライズ領域でのコンパウンド化を掲げている当社の命題の1つになっています。

どういうことでしょうか？

弊社は前述の通り、パラレルに新規事業/プロダクトを立ち上げていく必要があります。

新規事業は「10回やって1回あたるか」とよく言われるのですが、コンパウンドスタートアップにおいて、それは許されません（※ コンパウンド外の飛地の新規事業開発においてはこの限りではありません）。なぜなら、各プロダクトのPMFをもって、プラットフォーム全体の価値を最大化するのがコンパウンドのコンセプトだからです。

基本的に各プロダクトの従属性が高くなるため、1つ外してしまうと他プロダクトの成功確率も下がり、全体の事業価値が大きく毀損してしまうのです。ゆえに「9割の確率で成功する事業づくり」が必要になります。

「いや、高確率で事業を当てるなんてめっちゃむずくない？」

となるかもしれませんが、コンパウンドスタートアップにおける事業開発は通常のそれよりも成功確度は高められる構造にあると考えています。

事業開発の再現性を作る上でのポイントについて、以下3つの観点で説明していきます。

• 「良き隣接点」を見つける

• 共創型事業開発

• 需要の「発生条件」を考える

「良き隣接点」を見つける

コンパウンドスタートアップの概念を提唱したRippling社のPlaybookには、

Integration is the product.（連携そのものがプロダクト）

と述べられています。つまり、プロダクト間の連携やシナジーそのものが大きな価値を生み出すという考え方です。言い換えれば、既存事業とのシナジーを活用できる「良き隣接点」を見つけることができれば、新規事業の成功確度は格段に向上します。

ではどのようにして「良き隣接点」を見つけるのか？

ここでは、月並みですが市場や顧客課題の解像度が非常に重要になります。当社では、データとワークフローの整理・洗い出しを日々行い、その精度を高める取り組みを継続しています。
ここのプロセスはHowではあるのでどんな手段でもいいのですが、私自身は以下のようなステップを踏むことが多いです。

1.データとワークフローの洗い出し：既存事業が取得しているデータや、その周辺で活用されているデータ/ワークフローを網羅的に洗い出します

2. 顧客への深堀りインタビュー：既存事業のプロダクトフィードバックインタビューを進める過程で、顧客が日常的に行っている業務について深く掘り下げます。顧客の実務に隠れた課題やニーズを理解することで、新しい価値提供の可能性を探ります

3. コールセンター視察：ざっくりあたりがついてきたら、実際に顧客のコールセンターを訪れることも行います。より深い解像度でワークフローを理解する

これはいかなる事業開発にも言えることですが、課題の解像度は正義だと思います。解像度を高めるための取り組みであればなんでもやったほうが良い（馬田さんの「解像度を上げる」が良書なので、お時間ある方は読んでみてください！）

当社の具体事例で少し話すと、RightSupportという初期プロダクトからRightConnectに展開しましたが、これはまさに良き隣接点を見つけられたと言えると思います。問い合わせ前データを軸にしながら、それをオペレーターに還元。実際、スムーズなクロスセル促進が実現できています。

「スタートアップは市場選びが8割」

なんてことをよく聞くと思いますが、これはマクロな市場（e.g. 教育市場、物流市場など）選びの単位ではなく「”解くべきissueが何か”が8割」という話だと個人的に解釈しています。良き隣接点とそのissueを見極めることが、コンパウンドの事業開発のすべての始まりだと思います。

共創型事業開発

弊社は既存のお客様との関係性を特に重視しています。Enterprise SaaSは顧客層の裾野が狭い中、同一ターゲットでのバンドル化でARPAを上げていくことが基本戦略になることが多いゆえ、既存のお客様の声の重要性が相対的に高いです。

特に「リファレンスカスタマー」は会社にとって最大の資産と言っても良く、うまく事業づくりのプロセスに組み込むことができれば、大きな威力を発揮します。良い既存顧客が新規事業の方向性を評価してくれる上に、我々が気づいてない答えをくれる瞬間も多々あります。

そこでRightTouchは「共創型事業開発」を明確に掲げ、リファレンスカスタマーとの共創（Co-creation）を通じた事業開発を行っています。新規プロダクトの開発においても、この共創プロセスを通じて再現性を確保しながら事業づくりを進めています。

プロダクトマネジメントの名著「inspired 熱狂させる製品を生み出すプロダクトマネジメント」において、「PMFの4つのリスク」があります。

このうちSaaS事業を作っていて結局大事で争点になるのは「価値のリスク」「ユーザービリティのリスク」の2つだと痛感するのですが、これらのリスクは「共創型事業開発」で超えられるリスクだと考えています。

「価値のリスク」を超える

端的に言えば、「このプロダクトを作ってくれたら、ぜひお金を払ってでも買いたい！」と複数の顧客に言ってもらえる状態を作れれば、価値のリスクはクリアできていると言えます。
その検証をする上で以下を準備して、リファレンスカスタマーとディスカッションするのが良いと思います。

営業資料
細かい機能説明より、プロダクトコンセプトやプロダクトが解こうとしている課題に、顧客が深く共感するかを確認するのが良いです。

プロダクトデモ
実際のプロダクト上の動きを、Figmaなどをベースにしたデモを作ると良いです。これがあると圧倒的にお客様の理解が深まり、結果としてより良いFeedbackがもらえます。

※ 例えば弊社のRightConnectであれば、顧客体験のイメージとしてFigmaで作成した以下のようなデモを活用していました。

インタビュー
「PMFを達成する上で超えるべき論点」をちゃんとチーム内で言語化して、その論点を検証するために必要な質問をしましょう。

プロダクト開発の検証プロセスは、一度で終わらせるのではなく、複数回繰り返し行うことが重要です。

商談を通じてプロダクトの魅力を顧客に伝えながら、プロダクトのフィードバックを回収し、その内容を基にコンセプトや営業資料をブラッシュアップしする。そして、修正したものを別の顧客に試し、再びフィードバックを得る。この「1000本ノック」がプロダクト/事業の精度を格段に高めてくれます。

このプロセスを重ねることで、「価値のリスク」を確実性高く超えていき、最終的にプロダクトを作る段階に進むことが理想です。プロダクトを実際に「作る時間」よりも、その前の「作るまでの時間」にしっかりと注力し、慎重に準備を進めることが重要で、その鍵を握るのがリファレンスカスタマーだと言えます。

「ユーザービリティのリスク」を超える

ユーザビリティのリスクとはつまり、導入後にちゃんと顧客がプロダクトを使いこなして、カスタマーサクセスに至るか、という点についてです。

弊社のような活用が少し複雑化するプロダクトや、オペレーションに日常的に溶けるプロダクトはここで詰まるケースが非常に多いと感じます。営業力で導入数が幸いにも増えるものの、ユーザビリティのリスクが高いままでChurn Rateが高止まりして成長が停滞。採用を強化して人員を増やしてしまう。SaaS事業にとっては最も取っていけないリスクの1つだと言えます。

ユーザビリティのリスクも「リファレンスカスタマー」との共創型事業開発で超えることができます。

弊社ではほぼ毎度、新規プロダクトについてはローンチ前の検証期間を設けて、リファレンスカスタマーに触ってもらう時間を作っています。

「closedβ期間」という形でほぼプロダクトの完成品ができた状態で触ってもらうケースもあれば、もし検証したい論点が絞られる場合、MVPより小さいプロダクト単位で検証するのも1つの方法です。例えばとある分析系のプロダクトで「解析の精度が出るか？」が肝なのであれば、MVPすら作らずにデータをリファレンスカスタマーからもらって精度検証ができる、といった具合です。

リファレンスカスタマーとの共創型を意識した事業作りをしていけば、価値のリスク/ユーザビリティのリスクを超える可能性が高まるイメージができるかと思います。

需要の「発生条件」を考える

プロダクト開発の教科書ではよく「多くの人に60点よりも、少ない人に100点のプロダクトを作れ」と言われます。私もこの意見には賛成で、特にMVPを作るときには大事な考え方だと思います。当社の共創型事業開発とも相性の良い概念です。

しかし、上記のようにリファレンスカスタマーとの共創を通じてプロダクトを開発する場合、どうしてもn=1（特定の顧客）の声にどうしても引っ張られるという構造的な問題があります。この結果、よく起こるのが「対象顧客の裾野がとても狭い」、いわゆる「MVPの罠」に陥ることです。

MVPの罠からどのように抜け出すのか？

顧客の課題/需要の「発生条件」を深掘りすれば、糸口が見えてくると思います。

具体例を言うと、RightTouch創業時「コンタクトセンターの寄与による直接的な売上貢献を可視化したい」というニーズが一部の企業さまから上がりました。要は「電話問い合わせ後に、お客様は購入/契約に至ったのか？」を可視化して、コンタクトセンターのKPIをアップデートしたいというニーズです。コンタクトセンターを変革したい我々としてもテンションが上がる話題だったのですが、この課題/需要の発生条件を整理してみると、以下のようになりました。

Whyを深堀りして需要/課題の発生条件を見ていくと、解釈から「事実」に目を向けられるので、この需要の広さが見えてきます。「顧客LTVに対してサポートコストがかなり小さい業種ってXX業界とYY業界だよね。」「成約が簡易に計測可能な領域って少ないよね。」みたいな会話が可能になります。

今考えている構想の裾野の広さ/狭さの判断が可能になり、ざっくりとした天井が見えてくる。更に「こういう機能性があればTAMは広がるな」という目算が立ってくるので、オススメです。

とはいえ結局はマインドと気合い

Enterprise SaaSの新規事業開発という点で、ややテクニック論も含めて書いてしまったのですが、基本的に新規事業開発は最初の仮説が合ってることは少ないので、外れても思考し続けるマインドが一番重要だと思います。

自身も含めてスキル面は上記のような思考や議論を通じて磨いていける一方で、あくまで個人の解釈ですが「好奇心の強さ」や「失敗しても折れない心」は後天的に大きく変えづらいと感じています。

弊社は当記事の通り、新規事業を多く仕込んでいくフェーズに来ています（今も3つのプロダクトを抱えながら、3つの新規事業を仕込んでいます）。

今の経験やスキルに関係なく、「事業開発楽しそう」「壁や失敗を楽しめるタイプだ」という方、ざっくばらんな雑談やカジュアル面談からでも大歓迎で
す！

※ 次回は私と共に代表をしている野村から、EP SaaSにおけるセールスについてご説明します。私とは比較にならないくらいエンタープライズを熟知したプロなので、乞うご期待です。