先週の『Zero to One』に続いてスタートアップ3大レジェンド本の一角を改めて読んだ

以下、個人的まとめ

事業立ち上げの攻略本

現実にはスタートアップのほとんどが失敗するのだ。新製品のほとんどが成功しない。ベンチャーのほとんどが実力を発揮できずに終わる。

細かなこと、おもしろくないこと、ちょっとした判断はどれも些末であり、「スゴいプロダクトをしかるべきタイミングで作れば」成功できると考えれば、失敗しても言い訳ができる。しかるべきものを用意できなかったからだ、先見の明が足りなかった、時と場所を間違えていた、と。

私は自身の経験と多くの起業家の成功と失敗から、こういう風に考えるのは間違いだと分かった。面白くないことこそが重要なのだと分かったのだ。

スタートアップは運が良ければ、遺伝的に優秀であれば成功するものでも、タイミング次第で成功するものでもない。

正しいやり方で進めるからこそ成功するのだ。

それはつまり、やり方を学べるということであり、やり方を教えられるということである。

立ち上げ期

スタートアップの進捗は「検証による学び(validated learning)」で測る

• スタートアップの事業の進捗を測ることは難しい

エンジニアやマネージャー職の場合は、仕事が計画どおりに進行しているか、質は確保できているか、コストは想定内に収まっているかといった観点で進捗を測る。

しかし、アントレプレナーは、このような形で進捗を測って本当にいいのだろうかと不安を感じる。自分たちが作っているのは誰も欲しがらないモノなんじゃないだろうか。もしそうなら、スケジュールや予算を守ることにどんな意味があるのだろうか。そう思ってしまうのだ。

• 「何をどれだけ作っているのか」を基準にするのではなく、「投入した労力から検証による学びをどれほど多く得ているのか」を基準にするのがスタートアップにおける生産性の正しい評価方法である

リーンな考え方における価値とは顧客にとってのメリットを提供するものを指し、それ以外はすべて無駄だと考える。

製造業に関して言えば、製品がどのように組みたてられているのかは顧客にとって意味がない。顧客が気にするのは製品がきちんと動いてくれるかどうかだけだからだ。

ところがスタートアップの場合、顧客が誰なのかもわからなければその顧客が何に価値を見いだすのかもわからない。スタートアップというのは、その定義から、このような不確実性を必ず持つものなのだ。だからスタートアップの場合、価値の定義自体から見直す必要がある。

つまり、「何が顧客にとっての価値を生みだすのかについての学び」こそがスタートアップにおける前進の実体だったのだ。

きらめくようなアイデア、仮説とホワイトボードに描かれた駆け引きや戦略、高機能で壮大なプロダクトではなく、顧客が”本当に”望んでいることを見つけだし、その望みに製品を合わせていくという地道な作業こそがスタートアップの最も重要な仕事だったのだ。

立てる仮説と検証方法

立てるべき2つの最重要仮説

1. 価値仮説 (value hypothesis)
   • 「もし顧客が製品を使ってくれたら価値を提供できるか」の仮説
2. 成長仮説 (growth hypothesis)
   • 「製品に価値があり、使われた場合にどうやって広がるか」の仮説

検証の方法

• 仮説に対して「類例」や「反例」が存在する場合は
  • 類例: 他の人が行った同じような製品や実験で既に 正しいと検証された事例
  • 反例: 他の人が行った同じような製品や実験で既に 正しくないと検証された事例
• どちらの仮説もヒアリングをして出てきた「意見」程度では検証の精度が低すぎるため、実際に見込み顧客に対して実験を行って「行動」を見て検証する

顧客に望みを質問するのではない点に注意してほしい。顧客というのは、製品を提示される前にどういうものが欲しいかわからないことが多い。

製品をちょっと使ってみるチャンスを顧客に提供し、その反応を観測するという実験をしてみることもできたのではないだろうか。

顧客はこう望んでいるはずという自分の考えを正当化するのは簡単だ。的外れのことを学ぶのも簡単だ。

だから、検証による学びを得るためには、現実の顧客から集めた実測データを基礎とする必要がある。

「構築 - 計測 - 学習」のFBループを速く回す

• 「構築 - 計測 - 学習のFBループ」の一周にかかるトータルの時間を最小にする
• 学びのプロセスには始まりはあるが、終わりはない
• このフィードバックループの速度こそが競争力

• 「構築 - 計測 - 学習」のFBループの計画は、実行順の逆順で考える
  1. 学習 - 検証する必要がある仮説を立てる
  2. 計測 - 検証による学びを得るために計測しなければならないものを革新会計から確認する
  3. 構築 - 実験を行うにはどのようなMVPを作らなければならないのかを考える

以下で「構築 - 計測 - 学習」3つの要素について深ぼっていく

構築 - MVP (Minimum Viable Product)

• MVPは事業仮説を検証するための製品

  • 上記のFBループの「製品」に当たり、仮説を検証して学びを得るための計測を行うためのもの
  • プロトタイプやコンセプト検証と違い、MVPは製品デザインや技術的な問題を解決するためのものではない

• MVPはアーリーアダプター層からFBを得ることを目的にする

  • アーリーアダプターは新しいもののコアなバリューに魅力があれば残りの完成度は気にせずに使ってくれるため、重要な事業仮説を検証する相手としてはピッタリ
  • アーリーアダプターが求める以上に機能を増やしたり完成度を高めたりするのは、時間の無駄

• MVP = Minimum Viable Product = 実用最小限の製品 は、文字通り重要な事業仮説を検証するために必要な最小限の機能と体験を実装する

  • アーリーアダプター層に対して、重要な事業仮説の検証が可能ならMVPは何でも良い
  • 紙芝居、動画、簡易デモ、モック、コンシェルジュ型MVP (人力)
  • サービスの裏側を人力で対処するMVPから、徐々にスケールするために技術で自動化を進めていく立ち上げ方は多い

• 作り手の見栄やエゴを出さない、恥ずかしがらない、恐れない

  誰が顧客なのかが分からなければ、何が品質なのかも分からない

  • MVPはその特性上、顧客から「低品質」と見られることは往々にしてあるが、それは顧客が気にするポイントを学ぶチャンスだと捉えるべき

    MVPの発表はその性質上、必ずチームに悪いニュースをもたらすものである

• Facebook社のHacker wayはまさにこの精神を体現している

The Hacker Way is an approach to building that involves continuous improvement and iteration.

ハッカーウェイとは継続的な改良と反復による製作のアプローチだ。

Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once.

ハッカーは素晴らしいサービスを一気に製作するのではなく、素早くリリースして、小さな改善から学ぶことによって長い時間かけて製作しようとする。

“Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.

我々は “Done is better than perfect” 「完璧を目指すより、まず終わらせろ」というポスターを壁に貼り、常にサービスを顧客に届け続けることを意識している。

計測 - 革新会計 (Innovation Accounting)

• 革新会計という手法は以下の3ステップを繰り返す
  1. MVPから得られる現状のデータ (ベースライン) を計測する
  2. 事業計画上の理想状態とベースラインの差分を計測し、差分を埋める改善(エンジンのチューニング)をする
  3. ピボットするかを判断する

1. ベースラインの設定

• MVPに含められる仮説が限られているなどの状況で、仮説を抜粋しなくてはならない場合は、なるべくリスクの大きい仮説から優先的に検証する
• ベースラインの計測方法
  • 基本はMVPをマーケティング・チャネルを通して実際の顧客に販売し、その反応を計測し、仮説に対してのベースラインを設定する
    • 検証したい全ての仮説が含まれたMVPを使う場合も、仮説1つに対して1つのMVPを使う場合もある
  • MVPの製作が不可能な場合はスモークテストも有効
    • 紙芝居などの資料を使ってまだ作っていない商品を契約、予約してもらう手法
    • 製品を使ってみたいと顧客が思っていることが検証できるだけで、どう成長するかは検証できないのが注意点
      • つまり、スモークテストでは価値仮説は検証できるが成長仮説は検証できない

2. エンジンのチューニング

• 新規顧客のアクティベーション率などの「成長の原動力となるKPI」を定める
• 事業計画から導かれるそのKPIの理想状態とベースラインの差分を計測する
• その差分を改善する仮説を立て、仮説を検証する実験のための改善を製品に入れる
• これを繰り返す

ここにスタートアップが2社あったとしよう。片方はベースラインとなる数値を明確に定め、こうすればその数値がよくなるという仮説があり、その仮説を検証する実験をいろいろな形で行う。もう片方はどうすれば製品がよくなるかを皆で相談し、いろいろなアイデアを採用して製品に変更を加えては何かの数値がよくなったと喜ぶ。効率的な仕事で長持ちする成果を上げられる可能性が高いのは、どちらのスタートアップだろうか。

3. ピボットするかの判断

• エンジンのチューニングにおいて想像しうる全ての手を尽くしてもビジネスモデルの原動力が改善されない場合は、ピボットを検討する
• ピボットした場合は再度仮説→MVPの構築から始める
• 詳しくは後述

※ 計測するデータの注意点

• 上記2つのグラフを見ると一目瞭然だが、累計有料会員数のみを計測して判断の根拠にしていたら、チューニングによって製品が改善しているように錯覚してしまう
• このような虚栄の評価基準を避けることは非常に重要である
• また、因果関係がはっきりしないデータは意味がない
  • 数字の変化がなぜ起こったのかが分からなければ、次に何をするべきかの仮説が立たず、チューニングができないため
• Actionableな評価基準を計測することを徹底すべき

学習 - PivotかStayか

• 製品の価値仮説 と ビジネスモデルの成長仮説を新たに策定し、それを検証できるような構造の変化をピボットと呼ぶ
  • ピボットする場合は、それまでに学んだ顧客へのInsightを軸にして、戦略を根本的に見直し、検証による学びを今まで以上に得られるようにしなくてはならない

ピボットするかどうかの判断基準

• 完全に科学的・定量的な判断軸はないが、考えられる改善(チューニング)をしきったが、事前に想定していた価値仮説と成長仮説を満たす結果が出なかった時にピボットを検討する
• つまり、ピボットの意思決定をするためには
  1. 明確な価値仮説と成長仮説
  2. 革新会計による徹底した計測
• が必要である

アントレプレナーの多くが同じ経験をする。シリコンバレーで「ゾンビの世界にとらわれる」と言われる状況だ。若干の成功──なんとか事業を継続できる程度の成功──は収めたが、創業者や投資家が期待したほどの成功は収められていない。こうなると、関係者のエネルギーがどんどん浪費されていく。愛社精神から社員も創業者もあきらめない。もうちょっとがまんすれば成功するのではないか……そう思うのだ。

仮説があいまいだと明確な失敗がなくなり、ピボットに必要な根本的見直しをする気にならない。「とりあえず製品を出してどうなるかを見る」というアプローチでは、**”様子見に必ず成功するという失敗”**が起きる。

体系的にピボットの決断を行う

• ピボットの決断は感情的になりがちなので、Monthly ~ Quarterlyで意思決定に関わるメンバー全員で行う「ピボット検討会議」をスケジュールしておく

成長期

成長に必要な3要素

1. 小さいバッチサイズ

• バッチサイズは小さい方が良い
  • もし無駄なものを作っていたと分かった時に無駄になるコストが最小限で済むため
• 小さいバッチサイズで細かく欠陥を検知して改善する
  • 例: トヨタの「アンドン」
    • 製造工程で全体に影響する致命的な欠陥に気づいたら誰でもアラートを上げて全体のラインを止めて良いという仕組み
    • 短期で見れば全体のスピードと生産性が下がってしまいそうだが、長期での継続的な改善速度に効いてくる
  • ソフトウェアの場合もアンドンのようにCICDなどを整備し、CommitやPRの度に欠陥を検知できるようにして、長期的な生産性を下げる要素が入り込まないようにする仕組みを構築する

2. 成長のエンジン

• 成長のエンジン = スタートアップが持続的に成長するためのメカニズム
  • 単発の広告やメディア露出などの長期的な成長を支えられないものは成長のエンジンではない
• スタートアップが自社の成長のエンジンが何かを理解しておくことは優先順位を決める際に不可欠である

選択肢を狭め、どの部分にエネルギーを集中すべきなのかをわかりやすくするのが成長のエンジンだ。

製品を改善するアイデアなら数えきれないほど浮かぶが、このようなアイデアの大半はごくわずかな違いしかもたらさない。それが現実だ。ほとんどが単なる最適化にすぎないからだ。

スタートアップは検証による学びが得られる大きな実験に注力しなければならない。成長のエンジンを枠組みに据えれば、意味のある尺度に集中しやすくなるはずだ。

• 大抵の事業では以下の3つの成長エンジンのうち複数に当てはまるが、注力する成長エンジンを1つに絞るべき
• 成長のエンジンは一度成立させたら終わりという類のものではない
  • いつかは対象の顧客を使い切ってしまい、ガス欠を起こすものである
  • そのため、エンジンをチューニングし続ける必要がある

粘着型成長エンジン

• 一度利用され始めれば、乗り換えられにくいタイプのサービスに当てはまる
• 重要な指標は チャーンレート(離反率・解約率) のみ
• 新規顧客の獲得速度が解約速度を上回れば成長する

ウイルス型成長エンジン

• そのサービスを顧客が普通に使うだけで人から人へと認知が広まってユーザーが増えるタイプのサービスに当てはまる
• 重要な指標は ウイルス係数 (新規顧客1人が何人のユーザーを連れてきてくれるか)
• 少しのウイルス係数の改善で指数関数的に成長曲線が変化する

支出型成長エンジン

• コストを払って新規顧客を獲得するタイプのサービスに当てはまる
• CPA と LTVで考えられる成長エンジン
  • CPAとLTVの差が重要指標
  • 顧客当たりの売上を増やす か、新規顧客の獲得コストを減らすかで改善できる
• CPAとLTVの差を長期的に享受するためには、一部の顧客から他社よりも多くの利益を引き出せなければならない

競争の結果、顧客獲得単価は基本的に上昇していく。

販売あたりの収益が業界内で変わらないなら、全社が限界利益の殆どを顧客獲得費として吐き出すようになるだろう。

つまり、支出型エンジンで長期に渡って成長するには、一部の顧客から他社よりも多くの利益を引き出せなければならない。

3. 順応性の高い組織

• 順応性の高い組織を作っていくためには、プロセスをリアルタイムで改善していくことが重要
• 「構築 - 計測 - 学習」のFBループを速く回すことは重要だが、スピードのために長期的な品質が犠牲になるほどスピードを速くする必要はなく、バランスが重要
• 1人の天才より、組織された凡人

1911年にテイラーは以下のように述べている。

「正しく訓練された人のみがリーダーになるべきだ。偉大な人間1人では、効率的に協力できるように組織化された凡人にかなわないと考えられるようになるだろう。今までは人間が優先されていたが、これからは仕組みを優先する時代だ。」

檄文

やってはいけないことを素晴らしい効率で行うほど無駄なことはない。

イノベーションにおける無駄の大半は、その原因さえ掴めれば防げる。

仕事の進め方について関係者全員の考え方を変えることさえできればいい。

もっと頑張れと従業員に言うだけではダメだ。

そもそも間違ったことを頑張りすぎることが問題なのだから。

新たな事業の始まりは事実よりも直感に基づいて出される事が多い。イノベーションは必ずビジョンから始まるからだ。大事なのは、その次にどうするか、だ。

ビジョンの構成要素を1つずつ実験にかけるのではなく、自分たちのビジョンに都合のよいデータを選んで成功劇場に酔うイノベーションチームが多すぎる。

いや、それどころか、ステルスモードにとどまってデータのないゾーンを作り、顧客のフィードバックや外部に対する責任などを一切なくした果てしない”実験”を進めることもある。

全体的な尺度のグラフで因果関係を説明しようとするのはフェイクだ。提出された因果関係が正しいとわかるわけがないからだ。

失敗はしたが学びもあったと言い訳をするのもフェイクだ。 どこかのサイクルで何か学びがあったのなら、それは次のサイクルで検証による学びへと一歩進めるべきだ。

顧客の行動モデルを作り、その行動を製品やサービスで少しずつ変えられると示してはじめて、ビジョンの妥当性を本当に示せたことになる。

小ネタ・事例

リーンスタートアップの起源

• トヨタで大野耐一と新郷重夫が開発したリーン生産方式をスタートアップに応用したものがリーンスタートアップ

コダックギャラリーの新規事業に対する4つの仮説

• 新規事業立ち上げ時には以下の4つの仮説を立てさせ、検証させる
  1. 我々が解決しようとしている問題に消費者は気づいているか？
  2. 解決策があれば消費者はそれを買うか？
  3. 我々から買ってくれるか？
  4. その問題の解決策を我々は用意できるか？

Facebookの初期仮説

投資家が着目したのは2つの事実である。1つはフェイスブックのアクティブユーザーがサイトで過ごす時間。ユーザーの半数以上が毎日アクセスしていたのだ。これは、顧客が製品に価値を認めていることを確認する価値仮説検証のいい例である。立ち上げ期のフェイスブックに魅力を感じるもうひとつの事実は、大学キャンパスへの普及速度である。成長速度が半端ではないのだ。フェイスブックのサービスが始まったのは2004年2月4日だが、2月中にはハーバードの学生の4分の3近くが使うほどになっていた。マーケティングや広告には一銭もかけていないのに、だ。言い換えると、フェイスブックは成長仮説も検証済みだったのだ。

AppleやGoogleのMVP

初代iPhoneが発売されたとき、コピーペーストなどの基本機能もなければ高速の3Gインターネットも使えない、企業の電子メールもサポートしていない製品であるにもかかわらずアップルストアに行列したのがアーリーアダプターたちだ。のちにグーグルとなる検索エンジンは、登場時、スタンフォード大学やリナックスオペレーティングシステムなどのトピックしか検索できず、「世界の情報を整理」できるようになるまで何年もかかった。

それでもアーリーアダプターには人気となり、高い評価を得た。

DropboxのMVP

• 創業当時はクラウドストレージにデータを保管すると複数端末でデータにアクセスできるというバリューは顕在化していなかったどころか、その概念がそもそも理解されていなかった
• そのため、MVPを触ってもらっても普通の人はそもそも何がしたいのか良く分からないため良いFBが得られなかった
• そこでターゲットをアーリーアダプター (コンピュータ好きのオタク層)に定め、彼らが好きなジョークを織り交ぜた3分のデモ動画を作った結果、バズった

製品開発に「検証」を含める

• Sprint運営のユーザーストーリーのStatusに「検証中」を含め、その機能で検証したい仮説が検証されて初めて完了にするという手法
• エンジニアがなぜその機能を作るのかを理解し、無駄なものを作らない意識が生まれる

所感

• まさにスタートアップの事業立ち上げの攻略本の代表格と言える名著
  • 本書の概念を知らずに事業を立ち上げるのは、運転の仕方を知らずに公道に飛び出すようなものと言っても過言ではないと感じた
• Zero to Oneとリーンスタートアップは相反しない。リーンスタートアップは「成功するためのやり方がある」と主張する点でZero to Oneと同じ"明確な楽観主義“の思想だと感じた。Zero to Oneの思想で壮大なビジョンを描き、それを実現するための手段としてリーンスタートアップを用いることができる。
• リーンスタートアップは時代遅れという主張があるようだが、全く時代遅れではないと感じた。現在においてもリーンスタートアップの手法を凡事徹底することの重要性は非常に大きく、この基礎ができて初めて応用的な手段を用いることができるのではないかと思った。