新規事業開発の常識:無償のPoCはダメ、絶対

新規事業開発の常識:無償のPoCはダメ、絶対

新規事業開発の常識:無償のPoCはダメ、絶対

2022.02.27

事業開発の新常識:「正式な」サービスローンチは必要なし?

あなたの開発中のそのサービス、「正式なサービスローンチ」をする必要は、実はないのです。Yコンビネーターが教育した、ソフトウェアのスタートアップたちは、完成品をいつかサービスローンチするなんてことは、つゆ考えなくて良い、としつけられます。それよりは拙速で、小銭でいいから稼げる「何か」(= MVP Minimum Viable Product)を一刻も早く出せ、と。極端な話、プロダクトは一生完成しなくてよいのです。

ハードウェアのスタートアップですら、

製品ができあがる前に売れ(アッシュ・マウリヤ)
[出所] Ash Maurya, “Running Lean, 3rd Edition”, O’Reilly Media刊

と、教わります。新規事業の鉄則は、

無償のPoCはするな、サービスローンチはいろいろなタイプのマーケットに対して繰り返しおこなえ

だからです。

事業開発の新常識:明日から課金してください

Yコンビネーターの前CEOマイケル・サイベル氏は、スタートアップの創業者からの FAQ の一つである「いつから(=プロダクトがどの成熟段階に達したら)ユーザに課金していいですか?」という質問に対し、「α版とかβ版とか、私はよく知らないけど、とにかくASAPで課金せよ」と答えています。

「自分のサービスは無料で使ってもらわないといけない、これが唯一のユーザをゲットする道だからだ」という考え方は根本的に間違っている。自分のプロダクトがいいものかどうかを知りたければ、ユーザがプロダクトを使うさいのハードルを少しだけ上げ、ユーザが使い続けるかどうか見ることだ。
出典:Michael Seibel – Building Product

サイベル氏は別の機会に「MVPはせいぜい2週間~ひと月でつくれ、それ以上かかったらそれは Minimum VPとはいえない」とも発言していますので、この二つのステートメントを掛け合わせると、

新規事業開発開始から、ひと月後には課金し始めろ

という、一見、めちゃくちゃなアドバイスになります。

そんなことが可能でしょうか?ーーはい、可能というか、それを忠実に実行して、創立からひと月で10社のお客さんをゲットした、現在成長中のB2Bセキュリティソフトウェアの企業があります。

その名は
Plusidentity [https://www.plusidentity.com/]/プラスアイデンティティ
です。2021年のYコンビネーター夏期バッチの卒業生です。

以下出典:
https://techcrunch.com/2021/08/31/here-are-all-the-companies-from-y-combinators-summer-2021-demo-day-part-1/

新規事業開発のカギ:PlusidentityのMVP戦略

MVP Minimum Viable Product = ギリギリ問題解決のために使えなくはないプロダクト

とは、それを利用することで、企業は顧客からのフィードバックを早期に受け取り、事業企画の変更や、製品の改善に役立てることができる「何か」です。MVPの定義からその活かし方については、「MVPの重要性:新規事業 成功の秘訣を徹底解説」で詳細に語っていますので、そちらに譲ります。

Plusidentityとはどんなスタートアップか?

Plusidentityがユーザであるスタートアップの従業員に提供する利便性は、SaaS間の「SSO/シングルサインオン」です。顧客のスタートアップの社員が、開発などに用いている複数のウェブシステムへのサインオンを、ユーザが一度で行うものです。

この業界には、B2BとしてはOkta、OneLogin、B2Cとしては、LastPassなどが、大手既存プレイヤーとして存在します。このPlusidentityの直接の競合というと、Okta、OneLoginでしょうが、これはスタートアップがおいそれと使える代物ではありません。ライセンス料が非常に高いからです。

そこへこの Plusidentity は、ローエンド破壊型のイノベーション(イノベーションのタイプについてはこの記事「事業開発の要諦:イノベーションのタイプ」をご覧ください)をしかけました。

SSO機能を提供する=がっちりしたセキュリティの城壁が必要

というのが、セキュリティ製品の業界では常識です。実際 LastPass など、パスワード漏洩のインシデントを起こして、大変なことになったことがあります。しかし、Plusidentity は、たった1か月で最初のプロダクトをランチしました。むろん、そのMVPのユーザにも、最初から課金しています。

私も以前、セキュリティ製品の開発にかかわったことがあるので誰よりもよくわかるのですが、セキュリティ・バイ・デザインの考え方を用いたとしても、たった1か月で、完璧なセキュリティを担保する製品を作るのは、逆立ちしたって無理です。常識的に言ったら、1か月でローンチするのは、万が一インシデントがあったときのレピュテーション(評判/信用)コストを考えると、ローンチしないほうがましでしょう。

しかし、Plusidentity のターゲティングは非常に巧みで、ジョブ理論(市場を性別や年齢層といったデモグラフィでセグメンテーションするのではなく、顧客のなすべき用事でセグメンテーションする考え方、詳しくは「ジョブ理論で、他社を寄せ付けない オンリーワンのプロダクトを開発する」参照)ベースといっていいもので、この落とし穴を免れました。

彼らが賢かったのは、自身がスタートアップであるがゆえに、

スタートアップが、自分たちが製品開発に使用する SaaS への SSO に、そこまでしっかりしたセキュリティなど求めるわけがない

ということを、わきまえていたことです。大企業は、万が一、自分の知財情報やお客様の情報が外部に漏れたら、そのレピュテーションコストたるや甚大なものがあるから、CISOなど責任者をおいてセキュリティをガチガチにかため、インシデント・レスポンス・チームを置いて、デジタルフォレンジクスができる業者と契約し、万が一に備えます。ソニーも昔、パスワード漏洩スキャンダルで、パスワードをハッシュしていなかったなどという、「そんなばかな」レベルのあらぬ嫌疑をかけられて炎上し、大変な目にあったことがあります。

しかし、立ち上がったばかりのスタートアップは全然知られていないわけですから、レピュテーションも何もあったものではありません。売れないスタートアップのサービスのソースコードを、GitHub のパスワードをわざわざ取得してまで盗もうとする人間がいるわけがありませんし、使用している IaaS のパスワードが漏れて、万が一サービスが停止したとしても、数十人しかユーザがいなければ、「最初からやり直そう(溜息)」で、すむわけです。とどめは、明らかに貧乏と判っているシード段階/シリーズAのスタートアップを、ランサムウェアでゆする馬鹿がいるわけない……。

成熟していないスタートアップが最も気にするのは、それよりも、それこそ、

MVP を一刻も早く世に出さなければならない この状況で、セキュリティを気にして、パスワードとかいちいちタイプしている暇なんかない!

ではないでしょうか?

そこそこの品質で良いから、価格勝負でローエンド破壊型のイノベーションをしかけることができるのです。

Plusidentity の「MVP」と製品ランチ

ウェブ上のサイトの昔の姿を残しているサービスを用いて遡るとわかるのですが、この会社の誕生時のサイト、素晴らしい恥も外聞もなさを誇る代物でした。(現時点でも簡素なサイトです。上掲のサイトを覗いて確認してみてください。)

最初にこの製品がランチされ、たちまち10社のユーザを獲得したときのサービスは

Slack からのSSO/シングルサインオンのみを提供しています

というものでした。その当時のサイトには、下記のように堂々と謳われていました。

  • Chromeの拡張機能を使ったSSO?→鋭意開発中です。
  • iPhoneアプリでのSSO?→鋭意開発中です。
  • AndroidアプリでのSSO?→鋭意開発中です。

「どうもすいません」という創業者の声が聞こえてきそうですが、しかし、これでいいというか、MVPとはこうあるべきです。

最小にリリースしたプロダクトを恥ずかしいと思わないのなら、それは遅すぎたということだ
(LinkedIn創業者 リード・ホフマン氏)

大企業ならもしかしたら、せめて、Slack + Chrome 拡張機能を開発して、まずは無償でPoCしてから、晴れてサービスをランチしたい、と思うかもしれません。でもその「晴れて」は、以下の大きなデメリットをもたらす、「晴れて」です。

  1. 製品のランチが遅くなる
  2. 自分たちのサービスの価値がわからなくなる
  3. 自分たちがいまいかなる仮説を検証しているのか、わからなくなる

デメリット1:製品のランチが遅くなる

これは一目瞭然でしょう。スタートアップのマジョリティを占める Slack ユーザにのみ、的を絞ってASAPで開発したからこそ、1か月かからずに最初のMVPが世に出せたのです。これは逆に、失敗したときのデメリットも最小化できることを意味します。

この記事でとりあげたファーストリテイリングの野菜通販事業「SKIP」のように、全てのサービスを整えてから広いエリアにランチしたら、失敗したときにダメージが大きいのは火を見るよりも明らかです。

デメリット2:自分たちのサービスの価値がわからなくなる

Plusidentity が最初から有償でランチしたのは、

ローエンド破壊型の製品の価格弾力性を算出するため

です。当然ですが、無償でランチしたら最後、最も肝要な問いの一つである、「わが社のサービスにはいったい いくらの価値があるのか?」が全く不明になります。

無償でPoCしておいて、無償期間が終わった瞬間に、全ユーザが使わなくなるのと、有償でMVPをランチしておいて、全く売れないという二つの現象を比べたとき、どちらが有益なフィードバックをもたらすでしょうか?

後者だとは思われませんか?

前者だと、「無償だから付き合ってやっている」という本気度が甚だ低いユーザからは、有効なフィードバックがほとんど得られないのに比べ、金を支払って使用いただいている顧客からなら、この上なく真剣なフィードバックが得られます。売れないなら売れないで、売れない理由を突き止め、様々な変数を変更して仮説を検証していくことで、収益を拡大していくヒントが得られます。その結果どうしても売れないと結論されれば、MVPの段階で、その事業企画をあきらめればいいだけの話です。

デメリット3:自分たちがいまいかなる仮説を検証しているのか、わからなくなる

大企業がよくやるように、最初から機能をそろえた、フル装備の

Minimum??? VP

をランチした場合、どうなるでしょうか?そこそこユーザがついたとしても、恐ろしいことに、MVPの一体どの部分がきちんとユーザに訴求しているのか、不明になるのです。

Plusidentityの場合、最初のMVPで証明したかった仮説はきわめて明確です。

Slackを使うことの多いスタートアップの開発者(イノベーター)たちは、低セキュリティでもその分 安価なSSOに価値を見出すか?

わざと Slack のみに絞ったところが絶妙なのです。なぜなら、Slack 自身が、まずはスタートアップ業界を制覇し、巨大既存企業は、末端社員レベルからのボトムアップで攻略したサービスで、スタートアップ内のコミュニケーションツールのデファクトスタンダードだからです。

Plusidentityは、最初のMVPがバカ売れしてほしいとは、恐らく毛頭考えていなかったでしょう。この段階では、まずは、スタートアップが使うのか?という上の価値仮説が検証できれば良いのです。同社の場合、10社のユーザがつくことによってたちまち上の価値仮説が正しいことが証明されたのですが、万が一これが完全否定されても、事業企画の変更を考え始めればよいだけで、その際、たった数週間で開発したMVPを葬り去るのは、すこぶるダメージが小さいわけです。

そして、この最初の価値仮説が正しいと、顧客の反応から証明されたら、

長く存続している中小企業(スタートアップよりマーケットが大きい)の従業員たちは、低セキュリティ(どこまで妥協できるか?)でも、その分 低価格(いくらぐらい?)なSSOに価値を見出すか?

という、マーケットのすそ野を広げる次の仮説を、段階的に検証していけばよいということです。

Plusidentity のセキュリティ基準もおそらく「MVP」ならでは

Okta も OneLogin も、自社のセキュリティの方針を、当然中身が正確には外部にわからない形で、しかし、顧客企業のCISOなどプロにはちゃんと信用される粒度できちんと説明しているのに、Plusidentity はちょっと笑ってしまうほど簡素な説明で済ませています。サービス開始初期は、ISMSはおろか、SOC2(SaaSのセキュリティの資格)の取得すら、宣言していませんでした。セキュリティの商売をするのに、SOC2の取得は最低限満たすべき条件ですが、それすらあえていまは無視していたということは、

SSOが商材ですが、我々は、少なくても現時点では、がちがちのセキュリティをウリはしていないです
(大企業の皆さんは、既存の他社サービスを使ってください)

という確信犯的なやり方です。

SOC2は取得に金も手間も時間もかかり、しかも一度取得したら終わりというものでもないので、生まれたてのスタートアップには負担が大きすぎ、このブログ記事の初稿を書いた時点ではMVP水準のセキュリティ方針で我慢してください、ということなのだと思います。

新規事業開発のカギ:マーケットを変えながら、ランチを繰り返していく

(あらかじめ申し上げておくと、恥ずかしいことに、以下の記事は、私自身がかつてやってしまった失敗談から得た教訓です。)

最初から一気に成熟度 fidelity の高い **Minimum** VP(それはもはや Minimum からは程遠い)を開発

無償でPoC

価格を付けて販売開始(「正式」なサービスローンチ)

というのは、ほとんどの場合で、膨大な資源の無駄をともなうわりに、実を結びにくい開発手法です。なぜなら、たまたまうまくいけばいいのですが、誰も買わなかった場合、

このサービスに需要はなかった、だけど、なぜうまくいかなかったのか、はっきりとはわからない

という教訓しか、膨大なカネと手間をかけて、得られないからです。さらにまずいことに、最初から一気に成熟度 fidelity の高い、Minimum ならぬ Maximum? VPを、

数か月かけて一生懸命に開発

1年間、無償でPoC

価格を付けて販売開始(「正式」なサービスローンチ、PR Times とかに告知、話題にはなる)

しかし、誰も買わない、かつ、売れない理由は皆目不明

「結果としてうまくいかなかったけどよく頑張ったね」と(株主の金と、優秀なエンジニアたちの数を無駄に使ったにもかかわらず)そこそこの人事評価を、担当者は得られる

という、外部から見ると、何がしたかったのか よくわからない顛末になることすら、ままあるからです。

読者のあなたがこのようなことを実際におやりになったことがあり、私の描き方を不愉快に思って気分を害されていたら、謝ります。実際は、この記事「PoC(Proof of Concept)とは?ほとんどのPoCが失敗する理由を解説」に書いた通り、私自身、似たような手痛い失敗をしてしまったことがあり、その反省から得た洞察がこれなのです。

だから(自分自身に言い聞かせているのですが)、

無償のPoCはダメ、絶対

なのです。

Plusidentity をはじめとしたYコンビネーターの教えを受けたスタートアップたちは、これを絶対にやりません。

  1. まず、Slackのみ対応で、一番尖ったユーザ(イノベーター)のいるはずの、スタートアップに絞って市場試験
  2. 次に、Slackより使用者数の多いはずの、Chromeの拡張機能対応で、SMBの市場試験
  3.  …………

というように、様々なタイプのマーケットに、そのマーケットに一番響く有償のMVPを投入していくことで、
Product/Market Fit(プロダクト/マーケット・フィット)への道を段階的にたどっていくのです。

次の記事では、

MVP≠プロトタイプ

をあらためて議論し、それと上記のターゲット市場の話を結び付けて語ります。

※ここで語った無償のPoCに関する議論を、よりコンパクトに自著で語っております。

新規事業を崩壊させる5つの常識

コメントを書く

送信いただいたコメントは承認後、表示されます。

CAPTCHA