リーンスタートアップを実践するために理解すべき3つのこと『Running Lean ―実践リーンスタートアップ』アッシュ・マウリャ

  • このエントリーをはてなブックマークに追加

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

  スタートアップが成功しない。

もし現在よりも、多くのスタートアップが成功するようになれば、日本の未来はもっと明るくなるのではないだろうか。挑戦する土壌が整えば、タネをまく人は増える。

だからこそ、私たちには「成功の事例」と、そこから導きだされた「方法論」が必要なのだ。

  そして方法論は、『Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)』に書かれている。


リーンスタートアップとは

リーンスタートアップとは、簡単に言うと「仮説の構築と検証をくり返しながら顧客のニーズを探る」ことである。それが結果として、スタートアップを成功させる。

ただ、仮説の構築と検証は、PDCAサイクルでも行われてきたことだ。それがなぜ改めて必要とされているのだろうか。

それは、多くのスタートアップが、うまくPDCAサイクルをまわすことができていないからだ。そのために、リーンスタートアップという方法論が生まれた。

リーンスタートアップを実践する

リーンスタートアップを実践するには、以下の3点を意識する必要がある。

  1. くり返しテストする
  2. 継続的な「改善」と「学習」
  3. うまくいくプランを発見する (リソースを使い切るまでに)

1.くり返しテストする

リーンスタートアップでは、くり返しテストを行う。

  くり返しテストすることによって、つくり手本位の製品、企業本位の戦略、実現可能性の低いビジョンなどが明らかになる。

それは、一度だけ行うのではなく、くり返し行うことによって、より鮮明になる。

2.継続的な「改善」と「学習」

くり返しのテストを習慣化することによって、継続的な「改善」と「学習」が行える。

改善は、トラブルが発生したときや、売れ行きが芳しくないときだけに行えば良いというものではない。つねに市場を注視し、顧客の反応をみながら、随時改善することが大切だ。

また、学習も然りである。学んだことを復習しなければ、また、継続的に学びを得なければ、成長することはできない。人も企業も同じである。

3.うまくいくプランを発見する(リソースを使い切る前に)

最終的には、くり返しのテスト、そして継続的な改善と学習によって、うまくいくプランを発見するのが目的だ。それも、リソースを使い切ってしまう前に。

  いくら綿密に計画を立てても、当初のプランがそのまま成果を上げることは少ない。市場は生ものであるし、顧客はわがままである。いくら知恵を出し合っても、わがままな生ものを完璧に操ることはできない。詐欺でもしないかぎり。

もちろん、うまくいくプランの発見はリソースが尽きる前にしなければならない。“後の祭り”とならないためにも。

ヒトコトまとめ

スタートアップを成功させるには

くり返しのテストによる「改善」と「学習」を行い、リソースを使い切る前にうまくいくプランを発見する、こと。

お付き合いありがとうございました。多謝。

<目次>

第I部 ロードマップ

1章 メタ原則
    1.1 手順 1:プラン Aを文書化する
        ビジョンのなかに「私」がいる
        ビジネスモデルの仮説を捕まえる
        あなたの「製品」は製品では「ない」
    1.2 手順 2:プランで最もリスクの高い部分を見つける
        スタートアップの 3つのステージ
        製品/市場フィットの前にピボット、それから最適化
        資金調達について
    1.3 手順 3:プランを体系的にテストする
        実験とは何か
        イテレーションのメタパターン

2章  RunningLeanの実例
    2.1 ケーススタディ:いかにして私は本書を執筆反復したか
        課題を理解する
        ソリューションを決定する
        定性的に検証する
        定量的に検証する
        本書は完成するのか

第II部 プラン Aを文書化する
3章 リーンキャンバスの作成
    3.1 見込み客を考える
    3.2 リーンキャンバスをスケッチする
        課題と顧客セグメント
        UVP(独自の価値提案)
        ソリューション
        チャネル
        収益の流れとコスト構造
        主要指標
        圧倒的な優位性
    3.3 次はあなたの番です

第III部 プランで最もリスクの高い部分を見つける
4章 ビジネスモデルの優先順位
    4.1 リスクとは
    4.2 ビジネスモデルの比較
    4.3 外部の意見を求める

5章 実験の準備
    5.1 課題チームと解決チームを作る
        部門のことは忘れる
        小規模ではなく最小のチームで開始する
        絶対に必要な 3つの要素:開発・デザイン・マーケティング
        課題/解決チームの外部委託は慎重に
    5.2 効果的な実験
        速度・学習・集中を最大化する
        主要指標と目標を特定する
        学習に必要な最も小さいことをやる
        反証可能な仮説
        定性的検証と定量的検証
        結果を具体的な行動に結び付ける
        わかりやすいダッシュボードを作る
        学習を早めにしょっちゅう伝える
    5.3 イテレーションのメタパターンをリスクに適用する
        圧倒的な優位性

第IV部 プランを体系的にテストする

6章 顧客インタビューの準備
    6.1 アンケート調査もフォーカスグループも不要
        アンケート調査が適していること
    6.2 でも、人と話をするのは難しい
    6.3 見込み客を探す
    6.4 先制攻撃と反論(または私は如何にして顧客インタビューをしないか)

7章 課題インタビュー
    7.1 学習すべきこと
    7.2 課題のテスト
    7.3 反証可能な仮説
    7.4 課題インタビューの実施
        歓迎(場の設定)
        顧客情報の収集(顧客セグメントの検証)
        ストーリーの伝達(課題の文脈の設定)
        課題の優先順位(課題の検証)
        顧客の世界観の探求(課題の検証)
        まとめ(フックとお願い)
        結果の文書化
    7.5 課題を理解していますか?
        課題インタビューの終了条件

8章 ソリューションインタビュー
    8.1 学習すべきこと
    8.2 ソリューションのテスト
    8.3 価格のテスト
        価格のことは顧客に聞かず、ただ伝えるだけ
        登録の障壁を下げずに上げる
        ソリューションインタビューの AIDA
        ピッチとどこが違うのか
    8.4 テスト可能な仮説
    8.5 ソリューションインタビューの実施
        歓迎(場の設定)
        顧客情報の収集(顧客セグメントの検証)
        ストーリーの伝達(課題の文脈の設定)
        デモ(ソリューションの検証)
        価格の検証(収益の流れ)
        まとめ(質問)
        結果の文書化
    8.6 解決に値する課題はありましたか?
        ソリューションインタビューの終了条件

9章 バージョン 1.0をリリース
    9.1 製品開発は学習の邪魔
    9.2  MVPの縮小化
    9.3 継続的デプロイを始める
    9.4 アクティベーションの流れを定義する
        アクティベーションの流れの解剖
    9.5 マーケティング用のサイトを構築する
        マーケティング用のサイトの解剖
        ランディングページの分解

10章 計測の準備
    10.1 行動につながる指標が必要
        行動につながる指標
    10.2 指標は人が重要
    10.3 単純なファンネルレポートは十分ではない
    10.4 コホートによろしく
    10.5 コンバージョンダッシュボードの作り方

11章  MVPインタビュー
    11.1 学習すべきこと
    11.2 テスト可能な仮説
    11.3  MVPインタビューの実施
        歓迎(場の設定)
        ランディングページの提示( UVPの検証)
        価格ページの提示(価格の検証)
        登録とアクティベーション(ソリューションの検証)
        まとめ(フィードバックループの維持)
        結果の文書化

12章 顧客ライフサイクルの検証
    12.1 フィードバックを楽にする
    12.2 試用期間中に問題を解決する
        獲得とアクティベーション
        定着
        収益
        紹介
    12.3 ローンチの準備はできましたか?
        ローンチ条件
    3・2・1……ローンチ!

13章 機能の押し売りはやめよう
    13.1 機能は押しつけずに引っ張ってもらう
    13.2  80/20ルールを実施する
    13.3 機能の流れを抑制する
    13.4 機能要求を処理する
    13.5 機能ライフサイクル
        かんばんボードで機能を追跡する
        各手順の説明

14章 製品/市場フィットの計測
    14.1 製品/市場フィットとは
    14.2 ショーン・エリスのテスト
    14.3「適切な」マクロ指標に集中する
    14.4 収益について
    14.5 人が欲しがるものを作ったか
        初期のトラクションの終了条件
    14.6 製品/市場フィットにおける市場
        成長のエンジンの特定
    14.7 まとめ
        ネットワーク効果のある製品のデザインパターン
        マルチサイド(マーケットプレイス)製品のデザインパターン

15章 結論
    15.1 そして拡大へ
        製品/市場フィット後の時代
        私は約束を守れましたか?
        連絡先
    15.2 情報源書籍

付録 低燃費スタートアップの作り方
        A.1 なぜ早すぎる資金調達はムダなのか
        リーンスタートアップにおけるフローの達成方法
        時間の綱引き
        毎日のフローを作る
        週単位のフローを作る
        ソフトウェアのムダを排除する
    A.2  SaaS製品の価格設定
        フリーミアム
        フリーミアムの課題
        フリーミアムの使い方
    A.3 予告ページの作り方
        セールスレターの書き方
        予告用ランディングページの作り方
        A.4 継続的デプロイの始め方
        コミット
        テスト
        デプロイ
        監視
    A.5 コンバージョンダッシュボードの作り方
    A.6 データの収集方法
        コンバージョンダッシュボードの可視化方法
        定着の追跡方法

<著者>

USERcycleの創業者。7年前に最初の会社をブートストラッピングして以来、5つの製品と1つのピアツーウェブアプリケーションフレームワークをローンチしている。テキサス州オースティンに妻と2人の子どもと一緒に住んでいる 。

<類書>

『リーン・スタートアップ』

『起業家はどこで選択を誤るのか――スタートアップが必ず陥る9つのジレンマ』

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

  • このエントリーをはてなブックマークに追加

コメントをどうぞ

メールアドレスが公開されることはありません。 が付いている欄は必須項目です