「Lean Startup Bootcamp」に参加してきました！～後編～

こんにちは！おおはしりきたけです！今回は実践編となる後編になります。

■Lean Startupの必要性

○ビジネスのペア

事業は、何を持って成立するのか製品・サービス⇒顧客、ユーザーがあって事業が成立

• 製品・サービスはある⇒フランチャイズ、新規顧客開拓
• ユーザー、顧客がいる⇒受託開発、コンサルティング

スタートアップは、上記の両方が必要。スタートアップは両方を作っていくから難しい。再生可能なカタチにする。両方をバランス良く育てなくてはいけない。しかし、スタートアップと呼ばれている人たちは製品を先に作りたがってしまう。このやり方は上手くいかない。製品ありきだと以下のようなことが起こる。

• アイデアの製品化に失敗
• 製品・サービスが技術的に完成しない
• 広告・PR・マーケティングに失敗
• 時代背景とマッチしない

上記が起こると、チーム内で犯人捜しが起こる。すでにモノ余り時代なので、これ以上アイデアを出してもダメ。ユーザーが求めているのは製品ではなくExperience。ユーザの目的達成を重視した、製品・サービス及びインターフェース設計。UCD/UX。ユーザー目線だが、ウォーターフォールでは意味はない。ユーザビリティテストなどもそのフィードバックを活用できたとは言えない。そこで、AgileUCDなどでユーザー体験を反復的にやればよい。だがそれでも問題は残る。

上記は、機能の正当性、事業の成功性については立ち入らない。製品ができたから事業成立ではない。製品そのものをインクリメンタルに作っても、市場がなければダメ。インクリメンタルで市場をつくっていくのは難しい。また、イテレーティブなやりかたでは、てんこ盛りにしがち。そこで顧客開発モデルができた。顧客開発は両方を一緒に作る。マーケットが必要とする製品・サービス仕様は1つではないといういうことに着目

スタートアップの9割は失敗する。ここから学ぶべき。新規事業でコケる理由。そもそもマーケットは存在しない。新しいものを使う人はごく一部。その人達に向けてつくらないといけない。この人達が熱狂する製品が必要。

つまり、メインストリームではなく、アーリーアダプターに向けた製品づくり

■LeanStartupでは何を仮説検証するのか？

何をやろうとしているのかを明確にする。何に対して？どうしていくべき？

• 挑戦の要
• 価値仮説
• 成長仮説

○検証したい課題　※これが一番重要！

自分が考えているアイデアは事業として成立するのか？

例） 「タッチデバイスを活用して私鉄沿線の商店街を活性化する事業モデル」 ⇒このままでは検証できない

なぜか？イシュー(課題、問題、論点）が大きすぎる！原因分析ができない。

例えばこれくらいの仮説

• 「商店主の5割がタブレット端末を抵抗なく操作可能なはずである」
• 「操作はブラウザによる検索を基準とする」

このくらいであれば検証できる。検証結果が定量的に分析できる。課題は定量的に検証できるサイズにまで落としこんでいく。

「小さな作業に分割できさえすれば、特に困難なことなどない」ヘンリー・フォード ⇒逆に言えば、小さな作業に切り出すことこそが、すべての検証を可能にするキモだということ！

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

• アイデアを事業化できるか
• 誰も必要としていないものを作っていないか

という最も大きなリスクを仮説として切り出す。

• ターゲットユーザーの絞り込み
• ビジョンのモデル化
• 検証ポイントの特定
• 仮説と検証手段の設定

○ターゲットユーザーの絞り込み

マスのユーザーはイノベーションを積極的には求めないマスのユーザのニーズは多様化している。だから、アーリーに絞り込む必要がある。しかし、最初に訪れるジレンマは、より大きなビジネスへと育てたいにもかかわらず、最初に最も小さなユーザーを目指さなければならいない。しかし、これは「小さな事業にする」ということではない。

ビジョンでターゲットにするのはマスマーケット ⇒検証可能なのはイノベーター～アーリーアダプタ

「製品」軸で考えるとベルカーブの曲線になる。「ニーズ」軸で探さなければならない。

実態はこう

イノベーター

• とにかく新しいものは試したい

アーリーアダプタ(悩みが明確にわかっている人)

• サイト訪問者数を増やしたい
• 実来店者を増やしたい
• 購入者/来店者率を上げたい
• リピート率を上げたい
• プッシュ型のセールスをかけたい
• アーリーマジョリティ
• 集客に関してまとめて頼める業者が欲しいけど、自分からは積極的には探さない。アーリーアダプタの意見が便り

レイトマジョリティ

• 集客の問題よりもコストの削減をなんとかしたい、などの理由で、周囲が全員採用した後に検討をはじめる。

ラガード

• 興味なし

つまりあるテーマに対するニーズ別のユーザ数の分布図だということ。

アーリーアダプタのどれか1つを突き刺さないとメインスリームには乗ることができない。メインストリームに乗るための挑戦権を勝ち取るための作業

メインストリームのユーザは次のどちらかを基準にしている

1. 現在利用している製品の後継製品
2. アーリーアダプタがおすすめしている製品

つまりアーリーアダプタを動かさない限り、メインストリームのユーザは永遠に現在利用しているサービスしか使わない

○ビジョンのモデル化

ビジョン⇒戦略⇒製品

• ビジョン：将来のあるべき姿を描いたもの
• 戦略：ビジョンを実現させるためのプラン。
• 製品：戦略を具体化した戦術案。

このアプローチだと「製品仕様の詳細化」へ向かいそう。でも、検証する対象を洗い出すには別のアプローチが必要。ビジョンをモデル化するには2つのアプローチを行う

• ビジネスモデルを図式化
• 検証ポイントの特定

○ビジネスモデルの図式化

企画書などは、潜在顧客や投資家への説明ならいいけどリーンはだめ。チームにはもう一歩進んだビジネスモデル図が必要となる。今のところピクト図解はリーンスタートアップと相性が良い。ピクト図解は、仮説検証すべきポイントがすべて交換式で書き出せているから

例のEtsyの事例では検証ポイントが５つあるので、別の観点で検証が必要だということが一目瞭然

最終的に交換条件がすべて成立して継続可能な事業が検証されたたことになる。交換式では「バリュー」と「コスト」の交換式が成り立つ。

バリュー＞コストが成立しないとユーザは交換してくれない。バリューとコストの交換条件は検証ポイントによって異なる。

• バリューとはニーズを満たすものすべて
• 「コスト」は定量的に判断しやすい
• 時間のほうがはるかに高いコストの場合もある

ユーザーが考えるコストは以下

• 金額(Money)
• 時間(Time)
• 手間(Passion)
• 知識(Skill)

エリック・リースはこの4つをCustomerCurrency（顧客通貨）と呼んでいる

得られるバリュー　＞　顧客通貨のコスト合計※4つのコストの合計であることに注意！

これが上回らないとユーザーは実践しない。バリューの判断はできないので、バリューを創造させ信用させること

 ○仮説検証の実行

分析・調査の基本を理解する。

• 仮説を立てる
• 仮説を検証する

似ているけど、違う。仮説を立てることに失敗すると検証できない。学びを得る。最適化する。どういう目的で仮説検証をしようとしているのか分類する。

仮説の設定手段と検証方法

	BeforeMVP(学び)	AfterMVP(最適化)
仮説 設定	◆定性分析 ・行動観察 ・インタビュー	◆定量分析 ・KPIの設定
	◆発想法 ・ブレインストーミング ・etc	◆定性分析 ・ユーザビリティテストシナリオ作成 ・アンケート作成
仮説 検証	◆定性分析 ・インタビュー ・プロトタイプ観察	◆定性分析 ・フィードバック ・ユーザビリティテスト解析 ・アンケート解析
		◆定量調査 ・アクセス解析 ・アンケート解析

仮説の設定と検証/beforeMVP

手段	目的
行動観察	【学び】 課題の存在 課題の強度 代替手段 顧客の属性 ソリューション案
インタビュー
ブレインストーミング
プロトタイプ観察
プレゼンテーション (推奨しません)

※上：自然　下：バイアスがかかっている

プレゼンテーションは、強いバイアスがかかっているため推奨しない。ブレーンストーミングは仮説の候補を洗い出すには適してるが検証の手段にはあっていない。

インタビューは上手にできれば適しているが、スキルが問われる ⇒インタビュィーが自然な状態で話をしてくれるか

仮説の設定と検証/AfterMVP

	BeforeMVP(学び)	AfterMVP(最適化)
設定	◆定量分析 ・KPIの設定	【最適化】 ファネル コネクトポイント 【観点】 ユーザビリティ デザイン ポジショニング
	◆定性分析 ・ユーザビリティテストシナリオ作成 ・アンケート作成
検証	◆定性分析 ・フィードバック ・ユーザビリティテスト解析 アンケート解析
	◆定量調査 ・アクセス解析 ・アンケート解析

Experiment　→　Metric　→　Hypothesis　のループ。

（Build　→　Measure　→　Learnのループは間違い）

例）最悪パターン

とりあえずアクセス解析でもしてみるか… ⇒何も得られない。多分、迷うだけ。

○明日からどうする？

「製品・サービスを絶対にただしい方向に修正するんだ！」というのを捨てる。間違い。

正解は

• 仕事を大きくしない
• 結果を先送りにしない
• 間違いを歓迎する

これが最初の第一歩。

• 隣の人、上司、投資家に話をする。
• ティッピング・ポイントを超えるまでは学びから離れてはいけない。
• 上手くいかないのはチームの文化の問題。製品やサービスが悪いからではない。

会社というものは既存事業をどうやって上手く回すか、が前提に構築されている。新規事業に携わっている人を正しく人事評価するシステムがない。だからウソの報告をしてしまう。

これを当たり前だと思える「チーム作り」から始めましょう！

■まとめ

今回は実践編について書かせていただきました、「仕事を大きくしない」、「結果を先送りにしない」、「間違いを歓迎する」というのは当たり前のようで難しい事です。これを当たり前にできる組織がスタートアップで成功する企業になるといえるのでしょう。また、スタートアップと書かれているためもちろん起業に関する本なのですが、会社や組織に置き換えても十分いかせる内容だと思います。