【ふくだ学習録】実践リーンスタートアップ part2【50日目】

ふくだ学習録とは？

ふくだが学習したことの備忘録。
目に見える形で残すことによってやる気を出す個人的な作戦です。
他人に見せるように書いているわけではないので、すごく読みにくいです。

読了した本

データベースエンジニア養成読本 [DBを自由自在に活用するための知識とノウハウ満載!]
ゼロから作るDeepLearning
PHPフレームワーク CakePHP 3入門
SQLアンチパターン
Docker入門
PHPフレームワーク Laravel入門
サブスクリプション

今読んでいる本

Running Lean ―実践リーンスタートアップ

4章 ビジネスモデルの優先順位

リスクとは

不確実とリスクは違う。
不確実：確実性のないこと。複数の結果が存在すること。
リスク：損失や失敗などの好ましくない結果になり得る不確実な状態。

リーンキャンバスを使えば、リスクとなり得る不確実を見つけることができる。

スタートアップのリスクは３つのカテゴリに分けられる。
①製品リスク：正しい製品を作る
②顧客リスク：顧客への経路を作る
③市場リスク：実現可能なビジネスを作る

リスクをまとめた解決することは難しいため、体系的に優先順位をつけて解消していく。

ビジネスモデルの比較

リーンキャンバスを順番に並べて、どのモデルから手をつけるかを決める。
ここでの目的は、十分に大きな市場を持ち、製品の周りにビジネスを構築でき、その製品を必要とする顧客に近づけるようなビジネスモデルを見つけ出すこと。

以下は筆者が使用している評価基準（優先順位の高いもの順）
①顧客の不満レベル（課題）
→あなたの製品を必要とする顧客セグメントに優先順位をつけて、絶対に必要な上位3つの課題をあげる。

②近づきやすさ（チャネル）
→顧客への経路が作れるかどうかは非常に重要な部分。（MVPを作るための学習過程で必須）

③価格と粗利益（収益の流れとコスト構造）
→価格は顧客セグメントによって決まる。粗利益が最大になるような顧客セグメントを選ぶ。

④市場規模（顧客セグメント）
→あなたのビジネスにとって、十分に大きな市場となる顧客セグメントを選ぶ。

⑤技術的実現可能性（ソリューション）
→技術的な実現可能性を検討する。

外部の意見を求める

ビジネスモデルは最低でも自分以外の誰か1人と共有しなければいけない。
何故ならば、誰かに検証してもらうことで、リスクを効率よく評価できるから。

ビジネスモデルインタビューのガイドラインは下記。

• スライドを10枚のするのはやめる

スライドよりも学習。リーンキャンバスを少しずつ見せるようにして、話に合わせてビジネスモデルを伝えていく。

• 20%を準備に、80%を対話に使う

モデルを説明するのに3〜5分で終わらす。それからは黙って相手の話を聞く。

• 具体的な質問をする

「このプランでもっともリスクが高いと思われる部分はどこですか？」
「同様のリスクを克服したことがありますか？　それはどのように克服しましたか？」
「それらのリスクをどのようにテストしますか？」
「これから私が話を聞いた方がいい人はいますか？」
などの具体的な質問をする

• 「アドバイザーパラドックス」に気をつける

顧客インタビューは顧客に何が欲しいかを聞くためのものではない。
同様に、アドバイザーのインタビューもアドバイザーに何をすればいいかを聞くためのものではない。
あくまでリスクの特定や優先順位をつけるための手段だと考えるようにする（「決定」や「検証」とは捉えない）

• 先見性のあるアドバイザーを採用する

5章 実験の準備

モデルを書いてリスクの優先順位をつけたら、実験の準備が必要になる。

課題チームと解決チームを作る

初めての実験を開始する前に、適切なチームを作ることが大切。

部門のことは忘れる

リーンスタートアップでは「エンジニアリング」「QA」「マーケティング」のような部門は邪魔で、不要な摩擦をうむ原因とされている。
エリック・リースは課題チームと解決チームの２つのチームを作ることを進めている。

課題チーム：主に建物の外で活動する。顧客インタビューやユーザビリティテストなどを行う。
解決チーム：主に建物の内で活動する。開発・テスト・リリースのデプロイなどを行う。

注意することとして、２つのチームがあるがメンバーは重なっている点が挙げられる。
最初は１つのチームで両方のチームの役割を担うべき。

小規模ではなく最小のチームで開始する

課題チームと解決チームは、それぞれ2〜3名が最適。小さなチームでリリース1.0を作る理由は下記。
①コミュニケーションが簡単
②作れるものが小さいから
③コストが低く抑えられるから

絶対に必要な3つの要素：開発・デザイン・マーケティング

３つの分野にある程度の知識を持つ人がいればいい。（必ずしもチームは3人である必要はない）

開発：使用する技術選定ができたり、実際に開発経験があることが必須
デザイン：外見やユーザビリティに詳しい（良いアウトプットができる）ことが必須
マーケティング：顧客の立場になって考え、指標・価格設定・ポジショニングの理解だけでなく、優れたコピーライティングとコミュニケーションスキルが大切

解決チームの外部委託は慎重に

３つの分野を外部委託することによって、素早いイテレーションと学習の両方が犠牲になってしまうことがあるため注意が必要。特に、顧客について学習することは絶対に外部委託してはならない、

効果的な実験

効果的な実験の定義や実行のルールを設定する。

速度・学習・集中を最大化する

スタートアップの目標は、リソースを使い果たす前にうまくいくプランを見つけること。
そのためには速度だけではなく、学習と集中も最大化できるようにしなければならない。

主要指標と目標を特定する

複数の指標や目標に同時に取り組むことは難しい。一つに絞るべき。

学習に必要なもっとも小さなことをやる

仮説をテストするもっとも簡単なものを見つける。製品のもっともリスクの高い部分を理解していれば、製品以外の何かを構築して仮説をテストできるはず。

反証可能な仮説

仮説を具体的な数値と指標で、計測可能なものにする。

定性的検証と定量的検証

製品/市場フィットする前は不確実なことだらけ。学習に必要なデータが膨大にあるわけではない。
なので最初の目標は、強いシグナルを受け取ること。（肯定的なものでも、否定的なものでもいい）
少ない人数の顧客インタビューでも十分（例えば5人とか）

否定的な強いシグナルは、その仮説はうまくいかないので、すぐに改善か破棄すべきという意味。
一方で肯定的な強いシグナルは、その仮説が統計的優位性を確保できるという意味ではない。仮説を定量的データで検証してもいいということ。

定性的検証から定量的検証への移行は、いろんなステージで適用できる大切な原則。

結果は具体的な行動に結びつける

計測結果を具体的で反復可能な行動に結びつけて、製品を常に変更していく。
定性的検証（インタビューなど）では、パターンが見えるまで同じ方法を繰り返す。
定量的検証では、コホート分析やスプリットテストなどの技法を使う。

わかりやすいダッシュボードを作る

仮説の検証が正しいか間違っているかを、透明性と客観性のあるもので共有すべき。

学習を早めにしょっちゅう伝える

最後の実験から学習した教訓について、毎週定期的に（最低でも月一で）外部のアドバイザーや投資家に伝えるようにする。

まとめ方の例は下記。

イテレーションのメタパターンをリスクに適用する

リスクにはなんども実験して取り組む必要がある。その中で気をつけることは２つ。
①中途半端な学習や否定的な学習でやる気を失ってしまい、早々にピボットや実験の中止をしてしまうこと
②肯定的な学習から必要以上に楽観的になり、あとで行き詰まってしまうこと

スタートアップの最初の重要なマイルストーンは、製品/市場フィットを達成すること。これは正しい製品を作ることだけでなく、拡張性のあるビジネスモデルを作ることでもある。

最初はあなたがうまくいくだろうと思うことについて、リーンキャンバスを使ってプランを作る。それから、リーンキャンバスの各ボックスについて、段階的な実験を体系的に実施する。

各ステージで取り組むべきこと

リーンキャンバスの上位３つのリスクは、課題・チャネル・収益の流れ。
リーンキャンバスの優先順位をつけるときには、この３つのリスクが簡単な診断基準となる。
各ステージで体系的に取り組む方法は以下。

ステージ1：課題を理解する
→顧客インタビューや顧客観察を行なって、解決に値する課題かどうかを理解する。

ステージ2：ソリューションを決定する
→ステージ1で知識を身につけたら、ソリューションを決定する。デモを作って顧客にソリューションを見せてテストする。

ステージ3：定性的に検証する
→MVPを作ってアーリーアダプターに見てもらう。UVP（独自の価値提案）に気づいてもらえるかどうか。

ステージ4：定量的に検証する
→改良した製品をより多くの人たちに見てもらう。

リスクと基準にしたもの

製品リスク：正しい製品を作る
①解決に値する課題かどうかを確認する
②最小限のソリューション（MVP）を決定する
③MVPを構築して、小規模に検証する（UVPのデモ）
④大規模に検証する

顧客リスク：顧客への経路を作る
①不満を持っている人を特定する
②製品を今すぐに欲しいと思うアーリーアダプターに範囲を狭める
③アウトバウンドチャネルから開始しても構わない
④ただし、少しずつ拡大可能なインバウンドチャネルも構築/開始する。

市場リスク：実現可能なビジネスを作る
①既存の代替品から競合他社を特定して、ソリューションの価格を設定する
②顧客の声を聞いて、価格をテストする（口約束）
③顧客の行動を見て、価格をテストする
④ビジネスモデルがうまくいくように、コスト構造を最適化する

顧客インタビューの準備

アンケート調査もフォーカスグループも不要

理由は下記。

• アンケート調査は正しい質問があることを前提にしているから

顧客インタビューでは、あなたが何も理解できていないことを相手に説明してもらわなければならない。
何を質問すればいいのかすらわからない段階では無意味。

• アンケート調査は正しい答えがあることを前提にしている

アンケート形式では、答えの選択肢も顧客に提示しなければならない。
顧客インタビューでは「自由回答形式」の質問を使って学習する。

• アンケート調査は顧客の仕草が見えない。

ボディランゲージは、答えと同じぐらい重要

• フォーカスグループは間違っている

アンケート調査が適していること

顧客インタビューから学習したことを検証するには効果的。
いわゆる定性的検証から定量的検証へ移行する時の、定量的検証は適している。

人と話すことは難しい

• ピッチではなく学習を中心に考える

あなたが文脈を設定するが、話すのは顧客。

• 顧客が何を欲しいのか聞かない。行動を観察する。

• 台本に合わせて会話する

時間を無駄にしないようにするために、一貫したインタビューを行う必要がある。そのためには台本は必要。

• 網を広く投げる

最初の目的は、アーリーアダプターの特性を見極めることだが、全ての見込み顧客がアーリーアダプターになるわけではない。最初は局所化を避けて、徐々に絞っていく。

• 直接面会してインタビューする

ボディランゲージは重要。顧客関係を作る上でも、直接面会は効果的。

• 知り合いから始める

• 誰かと一緒にいく

客観的な視点を手に入れられる。

• 中立的な場所を選ぶ

カジュアルな場所（例えば喫茶店など）が好ましい。

• 十分な時間をもらう

20〜30分は確保しておく。

• 謝礼や贈り物はしないようにする

• インタビューを録音しないようにする

• インタビュー後すぐに文書化する

• 30〜60人にインタビューする

4〜6週間で30〜60人にインタビューする。1日2〜3人ペース。

見込み顧客を探す

将来的にはチャネル経由で探せることが理想だが、それが難しい場合は下記位の方法で探すのが良い。

• 近しい人から始める
• 紹介をお願いする。
• 地元で探す

7章 課題インタビュー

学習すべきこと

下記の３つのリスクに取り組み。
製品リスク：何を解決するのか？（課題）
市場リスク：競合は誰なのか？（既存の代替品）
顧客リスク：誰が困っているのか？（顧客セグメント）

インタビューの実施

下記のような構成で行うと良い。

①歓迎（場の設定） 2分
②顧客情報の収集（顧客セグメントの検証） 2分
③ストーリーの伝達（課題の文脈の設定） 2分
④課題の優先順位（課題の検証） 4分
⑤顧客の世界観の探求（課題の検証） 15分
⑥まとめ（フックとお願い） 2分
⑦結果の文書化 5分

課題の理解

インタビュー結果の分析・台本の改良・終了条件について

• 結果を週次でレビューする

週の途中で台本を変更しない。週の終わりにインタビューを振り返り、台本と顧客情報を修正する。

• アーリーアダプターから始める

• 課題を洗練する

「必要ない」といった強いシグナルを受け取ったら、その課題を台本から削除する。
また新しく重要な課題が出てきたら、それを台本やリーンキャンバスへ追加する。

- 既存の代替品を理解する

• 顧客が使う言葉に注目する

UVPの鍵となる可能性が高い。

8章 ソリューションインタビュー

以下のリスクをテストする。

顧客リスク：誰が困っているのか？（アーリーアダプター）
→どうやってアーリーアダプターを発見しますか？

製品リスク：課題をどのように解決するのか？（ソリューション）
→ローンチに必要な最低限の機能はなんですか？

市場リスク：どのような価格モデルにするのか？（収益の流れ）
→顧客はソリューションにお金を払ってくれますか？

価格のテスト

価格のことは顧客に聞かず、ただ伝えるだけ。
何故ならば顧客はあなたの製品に対しての適正な価格を知らないから。

顧客に「絶対に必要」な課題があると説得することはできないし、するべきではない。
ただし、あなたの製品に「適正な」価格があると説得することはできる。

9章 バージョン1.0をリリース

スコープを小さくして、要求とリリースのサイクルを短くすれば、学習を加速できる。

初めは必要最小限の機能の実装だけを行い、継続的デプロイを行なっていくようにする。（そうすることで学習の最大化を目指す）

10章 計測の準備

アクセス数やダウンロード数を指標にすべきではない。それらは計測対象ではなく、計測方法である。
人ベースで計測をすることが重要になり、ファンネルとコホートを組み合わせるべき。

今日の一言

読了したー！おもろい！
11章から15章（最後）までは結構メモするような感じではなかった！明日から実践していく！！！