2012年12月23日日曜日
『実践リーンスタートアップセッション at クックパッド』ノート
2012/12/18に開催された『実践リーンスタートアップセッション at クックパッド』のノートです。開始時刻に間に合わなかったため、前半15分ありません。ただ、ノートを見る文には本編自体は問題なく参加できたみたいです。
～10 Steps to Product/Market Fit -製品/市場フィットを達成する10のステップ～
■Problem/Solution Fit
◆1. Document your Plan A
◇第一ステップ = Plan Aを文章化すること
・一番最初にあるアイデアをドキュメントにする
・特に重要なポイント
→企業家はもともとの素性としてものごとを整理だって考えるのが得意な人が多い
→そういう意味でもアイデアをきちんと文書化するのは有効
◇こういったものの文書化はスタートアップ以外の企業でもやっている
・そういう企業はビジネスプランや事業計画を書く
→形こそ違えどスタートアップと同じようなものを文書化している
・「今日の会場でビジネスプランや事業計画を書いたことがある人は？」
→「それが本当に楽しくてしょうがなかった人は？」
→→（ほとんどいない）
・ビジネスプランや事業計画というのは、作りこむのがPainfulだということ
→しかも作れと命令した人に限って最後まで読まない
◇ビジネスプランや事業計画のよくないところ
・分からないことを想定して作りこんでいかないといけない
→空想の産物になりがち
→→リアリティを反映しているというよりは、そうなる傾向がある
◇Lean Canvas
・「事業計画はなくて… でも事業計画で求められているコアの部分だけを1ページに抽出してまとめ込んでいこう」
→「それをビジネスモデルの形にしよう」
→→そのビジネスモデリングのやり方がLean Canvas
・Lean Canvasが要素としているもの
→ビジネスを実際にやっている人が見ればすぐ分かるようなもの
・強み
→コアになるような前提条件などを非常にスピーディにまとめることができる
→1ページに収まるものなのですぐにできる
・Lean Canvasは自分が作ったもの
→だが、全くオリジナルなものではない
・ビジネスモデルキャンバスを基にした
→それを調整してリーンキャンバスにした
◇なぜBusinss Model Canvasを作り変えたのか
・「どうして変えた変えた？」「根拠を教えてくれ」
→よく質問を受ける内容の1つとして聞かれる
・アクショナブル（アクションをとり易いよう）に変えている
→これが要点
・もっと知りたい人は…
→私のブログを見れば1000ページくらいかけて説明している
◇ここまでが第1ステージ
・ビジョンを捉えるイメージで
◆2. ?
◇Product-Vision-Strategy
・アントレプレナーはアイデアが浮かぶとどうなるか
→すごくクリアなシグナルとして何かを感じる
→3つのレイヤに分けてそのアイデアを扱う
→→これは知らずにをやっていると思う
・3つのレイヤ
→Product
→Vision
→Strategy
→→これがピラミッドのような構造になっている
/\ ← Product
/__\ ← Vision
/____\ ← Strategy
◇アントレプレナーの人にありがちな失敗
・このピラミッドを出来るだけ早く上にたどり着きたい
→プロダクトを急いでしまう傾向がある
→→ビジョンやストラテジーを考えることに、充分に時間を取っていないということ
・ビジョンやストラテジーは重要
→この2つはピラミッドの基礎をなす部分
・ビジョンはだいたい誰でも考えていると思う
→でも、ビジョンだけでは充分ではない
◇facebookの例
・結果的にソーシャルネットワークで最大のプレイヤーになった
→facebookと同じようなビジョンを持った人達は他にもいた
・ではfacebookは何が違ったのか
→Howの部分が違う
→→「どういう風にビジョンを実現していったのか」が違う
■Product/Market Fit
◆3. Hone in process on early adopters first
◇facebookでさえも最初はアーリーアダプター中心にやっていた
・「いつかはfacebookのようなメインストリームの会社やプロダクトを作りたい」
→スタートアップをやっている人はそう思う
→だがfacebookも最初からそうだったわけではない
・facebookはまずハーバードの大学生をアーリーアダプターとした
→ここでビジネスモデルを定義していった
→→そういう過程をふんだ
・アーリーアダプターが誰かによって、ビジネスモデルは大きく展開する
→これはリーンキャンバスを見てもわかる
・チャネルもプロダクトもソリューションもレベニューストリームも大きく変わる
→アーリーアダプターがどういう人達なのか見極めることが大事
◇Geoffrey Moore "Crossing Chasm"
・アーリーアダプターまでと、そこからの拡大
→この間には大きなギャップがある
◇一番初めはアーリーアダプターにきちんとフォーカスする
・「メインストリームに出ていきたい」「大きくて皆に使ってもらえるようなプロダクトを作りたい」
→最初にに始めたときはそう思いがち
→→これはよくありがちな大きなミステイク
→→→そうでない
・「誰にも受けるようなものをメインストリームにもっていく」
→そう思って作りこんでしまう
→→結局は誰も使ってくれないような楽しめないものになってしまう
→→こういう傾向も大きくありがち
◇キャズムを渡ることは1つの大きなポイント
・最初はきちんとアーリーアダプターから腰を据えてやっていくこと
→キャズムを渡る近道はない
・アーリーアダプターからモメンタム（加速度）をつける
→それからメインストリームに行く
→→そういうステップをきちんと踏まないといけない
◇MVP(Most Viable Product)
・「アーリーアダプターがどういう人達なのか」をきちんと分かったらどうするか？
→そのアーリーアダプターがどういう課題を抱えているのか見極めていく
→→ここで出てくるのがMVP
・MVPの定義はいろいろある
→「カスタマに対してバリューを提供できる最小単位のソリューション」
→→これが自分の定義
・MVPの例 = かなりストリップダウンされた何もついてないver. 1.0のリリース
→ただし、カスタマーの直面している課題にきちんと何かできているもの
・MVPの例 = 中の人がオペレーションして、カスタマーに体験してもらう（コンシェルジュMVP）
→作りこむ代わりに、こうやってバリューを確認するというやり方もある
◇「MVPが何か」ということをきちんと見極めてから作りこんでいく
・「カスタマーが本当に求めているもの・バリューとして感じられるものがその中にきちんと盛り込めているか」
→MVPが何か分かったら作りこみをやる
◇一番初めにMVP・プロダクトをローンチした段階ではいろいろな問題が起こる
・それを使ってできるだけデータを集めたい
→よくあるひとつの傾向
・でもやろうと思えば情報はいくらでも集められる
→現代ではそのくらいの情報が存在する
・その情報の海に溺れてしまうこともある
→マトリックスを作ってきちんと指標を追いかけていかないといけない
・始めは少ないツールで見るところから始まる
→でも、そうこうしているうちに情報まみれになってしまう
◆4 Establish a standard measure of progress
◇進捗を図っていくスタンダードなものをきちんと作っていく
・情報まみれになってしまうことへの1つのソリューション
・既存の会社は財務指標できちんと測って業績を評価している
→では、スタートアップのきちんとした指標は何か？
◇Dave Mcclure's "Pirate Metrics"
・ざっくりいうとカスタマーライフサイクルがどうなっているかを表す指標
1. Acquitision : 新規の顧客を獲得
2. Activation : どう一番最初のエクスペリエンスをしてもらうか
3. Retension : 最初のエクスペリエンスすごくよかったら使い続けてくれる。カムバックしてくれる
4. Revenue : 使ってもらうことで売り上げが立っている
5. Referral : 使うことで満足しているカスタマーが他の人に宣伝してくれる
◇基本はこの5つ
・業績の指標として見るものはいろいろある
→自分の会社ではこれに絞っている
→→それぞれの後ろに詳細なのはある
・この5つが基本でメインのルール
◇まずカスタマーバリューにきちんとフォーカスすること
・最初にプロダクトをローンチしたときはこれをやる
→このタイミングではこれが重要
・成長がどうだとか売り上げやレベニューにフォーカスしてはいけない
◆5. Deliver value before growth
◇Pirate Metricsでバリューはどこに位置づけられているのか
・Acuisition
→ここではない
・Activation
→まずはよい良いカスタマーエクスペリエンスを提供できているか
→そうじゃないと戻ってまた使ってもらうことはありえない
・Retension
→2つめに重要なのがバリューの観点
→使い続けてくれているか、カムバックしてくれているかも指標としてみる
・Revenue
→課金モデル使っている場合は、ActivarionできていてRetntionしていれば売り上げや収益はついてくる
→そういう意味では相対的に重要ではないかもしれない
・Referral
→ここではない
◆6. The terrain before Product/Market fit is riddled with qualitative learning
◇ローンチしたばかり = 使ってくれるユーザは限定的
・ユーザの数が少ない
→定量的な評価よりも定性的な評価の方がよっぽど重要
・ポイント = "「成長を求めてバリューを無視」はしない"
→あえて限定的な数のカスタマーにフォーカスして情報を得たほうがよい
→大規模な集団を使ってそこからインタビューしたり情報を得るよりもよい
◇まだまだ最初の段階なので分析ツールは使わない
・シンプルなもので学ぶようにしていく
・Pirate Metricsの5つのステージを書いたカンバンボード
→Acquitision □□□□□□□
→Activation □□□□□□□□□□□□□
→Retension □□□□
→Revenue □□
→Referral □□□□□
→→それぞれのカードがカスタマーに関する情報が書いてある
・指標を管理するにあたってするべきこと
→Referralへカスタマーを持っていくためにはどうすればいいか
→→できるだけカスタマーに満足してもらったうえで、Referralにいくように
◇実際に使っているユーザが限定的で少ないことはありがたいこと
・かなりパーソナルなところまで確認・ラーニングができる
→10人～20人くらいしか使っていない
→→学習のスピードも加速する
・一番最初なのでバグもあるかもしれない
→人数が少ないのは非常によい
◇Product/Market fit拡大のステージ
・Pirate Metricsの5つのステージを書いたカンバンボードで、7～8割がReferralにできたら移行する
■Scale
◆7. Identify your engine of growth
◇ここまで来たら「どう成長させるか」「どこが成長のエンジンか」を模索する
・ここまで来ているということは、プランがマーク？し始めている段階
◇成長のエンジンとは？
・Acquisition - Paid
→最初の成長エンジンは支払い
→→できるだけユーザーベースを広げていくイメージ
→維持できるようにするためには獲得コストがRevenueを下回っていないといけない
→→そうじゃないと長期的には持続できない
・Retension - Sticky
→できるだけ長い間使ってもらう
→→例. 携帯電話の契約や雑誌の定期購入
・Referral - Viral
→facebookやtwitterがこれをすごく活用している
→→既存ユーザがReferralすることで、新しいカスタマーににうまく入り込んでもらっている
◇最初はどれか1つの成長エンジンにフォーカスをあてる
→そうやって進めることが重要
→→プロダクトによっては1つ以上の成長エンジンが関係していることも
・1つの判断の仕方 = 「プロダクトがどれだけ効果を出せるか？」
→例えばfacebook
→→3つのエンジンへの可能性があった
→→→でもバイラルにフォーカスを当てた
→→→→それは、そこが一番効果が大きいという判断をしたから（なのではないか）
◆8. Measure everything as a cohort
◇ユーザが増えた状態になるとパフォーマンスを計測するのが楽になるか？
・逆に難しくなってくる
→ここまでいくとプロダクトのユーザベースもかなり増えている
◇何故ユーザベースが増えると難しいか？
・1つはプロダクトは常に変化しているものだから
→新しい機能が加わってくる
→マーケティングキャンペーンによって何か変わることもある
→→川の流れのような（同じところに足を突っ込むことがないような）状況
・2つ目の理由はそれぞれサイクルの長さが違うから
→例えばレベニューのサイクルは他より長い
→→レベニューは後半にならないと入ってこない
・サイクルの長さが違うと原因と結果の関連付けが難しい
→「何かが起こっても結果が出てくるのは数ヵ月後」というのが普通にありえる
→→「うまくいってる」と思ったとき時点ではものすごく間違った方向に入っていたりすることもある
◇そういう風に悩んでいる人には？
・コホートの考え方が有効な手段
→ある一定の特性ごとにユーザをまとめる(Align)
→→こうすることで、さっき言ったような"ずれ"をなくす
→→→これが基本的な考え方
・コホートはマトリックスによる管理方法の上級版
→原因と結果をより関連付ける手法
◇ここまでくれば何が間違っていたか問題だったかというのは指標で分かる
・ただそれで解決したかというと…
→そうではない
→原因(Why)には、これだけでは充分ではない
◆9. Build a continuous feedback loop with customers for rapid hypothesis generation
◇ここで重要なこと
・いかにカスタマーからフィードバックをもらい続けてフィードバックループを実践できるか
◇"指標"ということで数値で表してしまいがち
・でも指標を作っているのは個々の人なのでこういうことが重要になる
◇「マトリックスと指標の裏に誰がいるのかははっきり分かるようにする」
・自分達の場合は仮説を立ててやり始めた
→そうやって運用していった
→→次に進んでくれるハッピーなユーザとそうでないユーザの両方を見た
◇どんな人達か限定できた段階で問い合わせをする
・何が問題なのかをメールで聞く
→これはけっこう辛いこと
→→1日100ユーザにメールを送るとかけっこう大変
・で、メールを自動送信するシステムを作った
→問い合わせのためのメールを自動で作ってくれる
→→1日に30, 40通くらいのメールが返ってくる
◇メールの回答はかなり活用している
・これのおかげでかなり理解が深まる
・次はどんなExperimentで回してみようかという判断もできる
・自動でメールを送るというのは全プロダクトでやっている
◆10. Breakthrough insights are usually hidden within failed experiments
◇失敗した場合に、いかにExperimentのプロセスを使えるか
・Experiment = 実験
→新しい機能を追加するときは実験（評価・テスト）する
◇ピボットは（いろいろな意味で）間違った意味でも使い込まれている
・何かが1回でも失敗すると、それを理由になんでもいいからピボットしてしまう
→よくアントレプレナーがやりがち
・本当の意味でのピボットとは単になんでも変えることではない
→学習に基づいているのかが一番重要
・適当にピボットする = いろいろ試してみて何がうまくいくかを適当にやっているだけ
◇失敗それ自体はいいことだし想定するべきもの
・ホッケースティック曲線
→幾つもの成功している会社がこういう曲線を描いて成長していた
→→成功にたどり着くまでにはかなりの期間を要するということ
・伸びていない期間が長いのは？
→ある程度やらなければいけないことが、前段階では必要だということ
→→創立者が仕事をしていなかったとか、そのときたまたま間抜けだったとか、そういうわけではない
◇トヨタ生産方式でも同じ事を言っている
・課題・問題は何かというのを製造工程ですごく追いかけている
・「課題・問題がない = それがわかっていないということ」
→この状態なら、そのこと自体が問題だと言っているくらいに追いかけている
◇実験に失敗はない
・単に想定外の結果が起きただけ
→そのとおりだと思う
◇「失敗したからピボットする = 失敗から逃げる」ではいけない
・失敗があったのであればピボットする前にまずきちんと理解する
→何故だったのかという原因を探ってからでないと、ピボットしてはいけない
・そうなると作業量が手間だということにはなりがち
→でもExperimentをやるなら最終的には学習がなければいけない
→→時にはカスタマーに戻ってもっと質問を投げないといけないかもしれない
・いずれにしても根本原因について見極めないといけない
◇失敗の中に通常は磨けば輝く宝石が眠っているということ
・それを見つけて磨くのが皆さんの仕事だと思う
■質疑応答
Q.
Pirate Metricsの5つのステージを書いたカンバンボードはどういう使い方になっているのか？
A.
カード = カスタマー。
カードの端には担当者の写真がついている。
一番注目して欲しいのはカスタマーがどれくらい各ステージにいるか。
ユーザが次のステップに進んだときカードを手で動かす。
10人とか20人程度なので、これでできる。
ただし、これでビジネスモデルを作れるかというと… 20人程度のユーザでは到底想定できない。
一方で「20人を満足させられないなら、到底満足できるビジネスモデルは作れない」という考え方も持っている。
Q.
アクティベーションやリテンションまで行ってからユーザ獲得やバイラルという話があったと思う。
ただ、新サービスはリリース直後がニュースとか掲載されやすいし、そういうときにツイートやPRもすると思う。
それに、ツール自体にバイラルも組み込んであることも多いと思う。
今の話を踏まえれば、最初の方はそういうことや機能の搭載はしない方がいいということか？
A.
そういうことで間違いない。
PRをあまりにも早い時期にやってしまうのはいけない。
印象付けるのに一番初めが重要というのもある（早い時期にPRするとProduct/Market fitしている途中のものが印象付けられてしまうということ）。
よく言っているのはできるだけ規模を小さくしてバリューを試すことをした方がいい。
何千人とか言う規模にする必要はないと思う
最初は10人とか20人くらいの小規模なもので始めて、そこにバリューがあるかどうかを確認する。
本当にPRをするのは、山を登ってもっと上のほうに行ってからでいい。それからで充分。
その時点でPRしてAcquisitionすればいいと思う。
Q.
10～20人くらいで始めて、その後PRする場合を考える。
ADを出すということではお金をかければいい。
リリースを打つとしたら「30万ユーザが使っている」とかあれば出しやすい。
逆に、そうじゃないとなかなか出しづらい。
この時、アプリの中から静かにバイラルを待つのか、それともお金を使って広告を打ったほうがいいのか？
A.
10人20人の規模のときにはメディアやプレスとは全くトークしない。
トークするのはカスタマーだけ。
facebookがローンチしたときも、一番初めから拡大を狙っていたわけではなかった
大学の寮の中でユーザを広げて、そこで全体に広がってから他の大学に広げた。
ただ、それもハーバード全体に広がったからといってすぐに広げたわけではない。
マーク・ザッカーバーグも、さっき言ったプロセスと全く同じことをやった。
あまりにも早い段階で成長にばかり意識を使うのはやめるべき。
Q.
日本の企業やアントレプレナーは製品を作ったら「価値がある」「みんな使ってもらえる」と思う
でも多くの製品は、誰も欲しくない使いたくないようなもの。
そういうものを既に作ってしまっている。
リーンスタートアップでは本当に価値があるものだけを市場に出そうとする考え方。
でも日本は作ってしまっている。そこにずれがあるように思う。
A.
それは日本だけではなくて、伝統的ないわゆるリリースとかローンチをやっているところはそうなのだと思う。
確認しないで作りこんでしまい、販売された後でないとチェックをしない。
これだと、販売するまでは学びが全くできていないということなので、失敗の率がすごく高くなるという問題がある。
Q.
リーンキャンバスを書くときに、どの時点の収益なコストを想定して書くのか？
A.
リーンキャンバスはコンスタントに変わっていくオーガニックなドキュメント。
一番初めにキャンバスを作るときのコストとレベニューは、どの段階というより「どこまで目指せるか」「ビジネスがどれだけ大きくなるか」というビジョンという意味で書くもの。
実現可能(Make sense)なものを書きこむこと。
作ったら各ステージごとにアップデートしていく。
例えばProblem/Solution fitのときには、それを実現するためにはどれくらいのコストが必要かということ。
「それを達成するには」というところで「どれだけの資金が必要か」などの観点から変えていく。
で、第一ステージをクリアできたら第二ステージ。
今度はEarly Tractionで、どれだけのコストが必要になるのか。
Lean Canvasは本当に日々明確に変えていくべきもの。
事業計画の場合、5ヵ年計画といって最初に作りこみ、それに後から現実をあわせていくと思う。
Lean Canvasはそうではなくて、それ自体を進化させていくもの。
Ash Maurya様、O'Reilly Japan様、クックパッド様、ありがとうございました。
2012年12月22日土曜日
『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』ノート - 質疑応答 (4 / 4)
2012/12/17に開催された『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』のノートの質疑応答部分です。
◆質疑応答
Q.
日本でワークショップをやる予定は？
翻訳者である角征典氏のワークショップは素晴らしかったが、マウリャ氏のワークショップはそれと全く同じものか？
そうでない（同じものではない）としたら、日本で誰かにやってもらう予定などはあるか？
A.
角征典氏からは翻訳の過程で的を射た質問をたくさんもらった。
その中で自分として内容を詰めていったり、リファインしたものもあった。
彼はエッセンスを捉えていて、だから（彼のワークショップは）同じものだと認識している。
Q.
「書籍のMVPがワークショップ」というのは、ぱっと見た感じわかりにくいと感じた。MVPを見つけるコツというのは？
A.
MVPでは「課題が何か」をきちんと把握することと、「それに対して正しいプロダクトやソリューションを出せるか」を確認しなければいけない思う。
ここは人によって違うと思うが… （これを踏まえて）自分の場合は「デモをできるかどうか」。
（MVPの定義に対して）少し厳密に考えるようにしている。
ここでいうデモとは、「デモをやることによって需要の有無を確認ができる」という意味でのデモ。
また、「デモをやることによってバリューを確認できるので、これを元に考えるといい」と提言もしている。
「バリューを提供できているかに注意すればいい」ということは、「どういう形で提供するか」ということをそんなに気にしなくていということ。
コードでなく全てを人がやっても、充分バリューは確認できる。
Q.
Running LeanのメソッドとLean Canvasは既存の企業においても有効？
有効ならどういった点に注意すれば？
A.
いろいろなビジネスの形態があると思うが、Lean Canvasの考え方は全てに有効だと思う。
事業の立ち上げだけではなく、プロダクトを新たに出すところなど。
「カスタマがいるか」「市場はどこにあるか」というのは一番リスクが多いところだと思うので、そこを注意すればいいと思う。
これらはそれを確認するための1つの有効なやり方だと思うし、そこさえ確認できれば後は容易に埋めていくことができる。
あとは、プランを完璧にしようとしすぎないこと。
チーム内で一緒に作るとしても半日。時間をかけるとしても、1日以上はかけないようにする。
以降はとにかく外にでて実際のデータの回収。
そういうことをできるだけすぐやったほうがいい。
Q.
日本という市場と、日本のスタートアップに対して考えていることは？
A.
日本に長くいたわけではないので、日本の市場やスタートアップについて特に意見があるわけではないが… 何人もの日本人のスタートアップの人とは話しをしているので、その辺りの意見や認識は持っている。
この2年、世界中を飛び回って世界中の国の人と話をした。
どこであっても、アントレプレナーとしてのスピリットや気持ちは同じだった。
一方で文化的な違いはある。
失敗に対してどこまで受け入れられる文化的な環境なのか。特にこれは大きいと思う。
周りの人から「そんなことやめとけ」と言われる文化か、そこまではでない文化か、というのはある。
できるだけ早期の段階で「リスクがどこにあるのか」というのを見極め、そのリスクを緩和させていくことが今日の話の1つのポイント。
必然的にリスクが減ってくるので、どの文化でもやりやすい手法であると思う。
Q.
プランをピボットするのかそれともそこで中止するのかの見極めがすごく難しい。
何かそこで大切にしているポイントは？
A.
これはすごく難しい問題だと思う。判断を迷うところだと思う。
自分個人でやるようにしているのは「成功というのはどういうものなのか」きちんと定義すること。
「5年後にどういう成功を収めるべきである」とか「どういう形を持って成功とする」であるとか、そういうものもあっていいけど、それだけではなくもっと短期的に。
「3ヶ月とか6ヶ月先に目指すところ」をきちんと定義できているかということと、それに対して定期的に確認するということ。
月に1回でも2回でもいいので、目指すところに対してどこまでいけているか、というのをきちんと測定する。
そういうことをやっていると「きちんと正しい方向に進んでいる」であるとか「これはどこにも向かっていない」であるとか、確認することができる。
もちろん上手くいっていないからといって経験や学びができないわけではない。
そういうことを繰り返しやっていると「これは方向的に向かっていない」とか、そういうサインが見えてくる。
こういう形で短期的に確認し続けるというのが1つのやり方。
もう1つやってしまいがちな傾向として、1回Experimentしてみて失敗したから「じゃあ変えよう」として失敗するたびに変えるというというのがある。
これではいけない。ランダムに適当にピボットというのはよくない。
失敗したのであれば、失敗の根本原因(Root cause)というのをきちんと見極めたうえで判断しないといけない。
失敗の原因さえ分かっていれば… 分かった上でのピボットであればいい。
ピボットはきちんとした根拠のあるものでなければいけない。
Q.
Experiment(Learn-Build-Measure)という流れの中を一通り回してみて、Learnの箇所は難しいと思った。
「正しい学びなのか間違った学びなのか」という判別が自分ではなかなかできない。
迷ったときに何が正しい学びなのかということを見抜く方法があれば教えて欲しい。
A.
私はLearn-Build-MeasureのサイクルをExperimentと言っている。これは科学的な言葉を"あえて"使用している。
なぜ科学の言葉を使っているかというと、「どんな仮定であっても、間違ったことを証明できる可能性がある仮定でなければいけない」と思うからだ。
「この何かを1ヵ月100ドルで提供する」と言った場合は「それに加入するかどうか」。具体的な数値でないといけない。
「この何かを良いと思ってくれるかどうか」だけだと、その仮定が間違ったという証明すらできない。
そうではなく、Experimentが成功か失敗かはっきりするような形の仮定を組むことが重要。
「100$じゃなくて80$-90$だ」となるかもしれないし、もしくは「5$-10$だ」とか。
後者の場合はビジネスとして成立しないということが分かる。
きちんとした仮定を持ち、それで判断すること。
Q.
今回の事例ではまずブログがあったということで、ある程度リーンスタートアップに興味がある人（カスタマー）がついていたと思う。
そうでない場合に、アーリーアダプターがいなかったのか仮説検証の方法が間違っていたのかを判断する方法は？
A.
「アーリーアダプターがどこにいるかわからないとき、どういう風に見つけていくか」という質問だとしたら… 最初のところではそこが一番リスクが高い。見つけるのも見極めるのも大変。
たしかに今回の事例ではブログというベースがあったが、それ以外のプロダクトの立ち上げでも使ってみたことがある。
そのときの例でいうと、想定するカスタマーセグメントを幾つかの切り口で作り、その人達に使ってもらうことで見極めようとした。
まずは限定した形で始めて、その中で本当に限定した人数からインタビューなどをした。
「まず規模を小さくして、そこからスケールアップして規模の拡大をできるかを考える」という形で始めた。
Ash Maurya様、O'Reilly Japan様、Yahoo! JAPAN様、ありがとうございました。
『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』ノート - ケーススタディ (2 / 4)
2012/12/17に開催された『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』のノートのケーススタディの部分です。
◆ケーススタディ - アッシュ・マウリャ氏が本を書いたときの話
◇自分が本を書くにあたってどういうプロセスを辿ったか
・本を書きながらメソドロジの評価・テストをした
→これについて細かく書いたのが『Running Lean』の第2章
◇この話は本を書くもっと前の段階から始まる
・そもそもはブログに書いていた
→Running Leanの原則の部分についてはずっと書いていた
→→ただし、原則について知っていたからではなく、自分も分からないから書いているという状態
・「ブログの内容を本にまとめるつもりはないのか」
→そういった記事を幾つも書いていたら、このようなコメントがきた
◇本を書くような時間はなかった
・当時（今も）事業をやっている
→正直に言うと興味はなかった
・作家 = 山小屋とか人里離れたところにこもって本を書く人
→自分はそんな人間になりたくない
◇そうこうしているうちに、11 ～ 12人くらいからリクエストがきた
・この辺りから「これはどういうことができるか」というのを考えるようになった
◇自分に問いかけた質問
・「これは取り組むに値するものなのか？」
・「ソリューションを提供する価値があるだけの課題が存在するのか？」
◇何をしたか
・出版のリクエストした人に直接インタビュー
・ティーザー（触りとなる）ページを作った
→プロダクトでいうデモのようなもの
・ブックカバーもないしタイトルも今とは違う
→それは最適化の作業
→→そういうものが必要になるのは最終的な段階
→それらは「最初からしっかりしていなくてもいいだろう」という考え方
→「タイトルやカバーにリスクはそんなにないだろう」
◇「一番リスクが高いところにフォーカスしよう」
・まずは目次を書き出した
→本のリクエストをした人達と目次の案を共有した
→→対話(Conversation)を行った
→→→彼らからいろいろな意見をもらえた
◇「この目次のとおり、こんな形の内容で書いてくれるなら… お金を出して買ってもいい」
→対象（リクエストをくれた10人くらい）全員が言ってくれた
→→ある程度繰り返してここまでもっていけた
◇ここまでが定性的な確認作業(Validation)
・これができても証明できないことがある
→「スケーラビリティがあるか？」
→「本を書くだけの労力を使う価値があるのか？」
◇目次ができた段階でティーザーページに変更を加えた
・タイトルを変更
→ヒアリングしたときにいろいろな人からフィードバックをもらえた
→→もともとよりいい案がたくさん
→→→そのうちの1つがタイトルに
・この夏(2009年の夏）に出すということを宣伝
→この時点では後4～5ヶ月先
→かなりアグレッシブなスケジュール
・メールアドレスを送ってもらうシステムを組み込んだ
→送ってもらうことで、どれだけの人が関心を持っているかを図れる
◇実際には夏には出版されなかった
・「ブログにいろいろ書いてあるからできるだろう」と思っていた
→見積もりが甘かった
→→結局遅れてしまった
◇変更した後にやったこと
・ブログやtwitterに書いて告知
・Eric riesなどにもコメントをもらった
◇その後… 何もしなかった
・他の仕事をやっていて、この本からはいっさい離れた
・エビデンスは作っていた
→「関心を持っている人の規模が充分にあるか？」
→これが確認できるまでは動かなかった
◇夏には1000を超えるメールアドレスが送られてきた
・プロジェクトとして価値がある
→これだけのメールがくるのは、実際に課題として認識されているから
→プロジェクト化
◇まずはMVPに手をつけることに
・ブログで情報はかなり書いていた
→でも本を書くにはもっと膨大な作業が必要だった
→→とてもすぐ終わるものではない
・MVPの（1つ）の定義
→「最終製品の一番小さなバージョンをカスタマーに示し、そこから学ぶこと」
◇MVP = ワークショップ
・ワークショップを開催することに
→目次をベースにスライドを起こした
→→テキストしかないようなもの
→→→時間をかけずに作ることができる
・オースティンで無料のワークショップをやると告知
→30人が関心を示した
◇無料で始めた目的は
・バリューを確かめるため
→「無料にも関わらずバリューが無いなら、絶対お金を出してくれない」
・リスク緩和
・無料だから気に入らなかった人は「ワークショップは駄目だった」で終わり
→お金を返せと言われることがない
・30人の申し込みはあったが、10人だけ
→最初は10人だけが参加するという形で組んだ
→→あとで違うバリエーションのワークショップをやるための余裕を持っておきたかった
◇最初の1回目からうまく評価された
・「これならお金を払ってもいい」
→いくらくらいかを確認
・残りの二回はPaidなワークショップに
→最初の1回以降は全て有料
◇有料のワークショップ開催は目的でもゴールでもない
・「コンテンツにバリューがあると感じてもらえるか」を確認するのが目的
→無料だとバリューがあると感じてもらえているかを確認しにくい
・夏の間はずっとワークショップを開催
→中身や流れをリファインしていった
・でも本やチャプターは全く書いてない
→この段階ではまだスライドを作っているだけ
◇夏に出すと言ったのに、夏の間ずっとワークショップをやっていた
・いろいろな人から「まだでないのか」「どうなっているのか」というメールが届くように
→対応しないといけない
・「もともと想定したより見込みが甘くて… 時間がかかってしまっている」
→「これからきちんとプロジェクトに対応する」
→「あと1つ、約束しましょう」
◇普通の本のそれではないやり方でローンチした
・「この本は、ソフトウェアのようにイテレーションをベースにして出します」
・「無料のチャプターを提供します」
・「プレビューも提供します」
→プレオーダーしてもらえれば、2週間毎にチャプター2つを送ると約束
・これらを受けてランディングページを変更
→プレオーダーのページを追加
→"coming this summer" -> "comming soon"
→→どれだけ時間がかかるか分からない
◇2週間毎にリリースするというやり方は、想定外なくらい上手くいった
・2週間の間にいろいろなフィードバックをもらえる
→それを元に改善をかけていくことができた
・読者自身もアントレプレナー
→構成の変更内容の提案
→図を作って送ってくれることも
→もちろんスペルミス・誤字脱字・文法の指摘も
◇全員がフィードバックをくれたわけではない
・注文してくれた人の半分くらい
→彼らはアーリーアダプターだと思う
・アーリーアダプターなので出たらすぐに欲しい
→出た後にきちんと改善・ヘルプすることをいとわない
→→アーリーアダプターにはそういう人が多いと思う
◇だいたい本の3/4を書いた
・ここで想定外のことがおきた
→大手出版社から連絡をもらった
・この本はリークしているようなもの
→何度も出している
→PDFかつDRMも入ってない
・何度も確認した
→そのくらい驚いた
◇出版社の人が気にしていること
・この本がマーケットを作ることが出来たこと
→魅力(Traction)があるということ
→気になっているのはそれだけ
→PDFやnoDRMのことは特に心配していない
・まさしく投資家の考え方と同じ
→始まったばかりのプロジェクトに投資するというのはリスクが大きい
→→彼らの方でかなりのリスク削減策をとらないといけない
→本でも同じ考えが言えるということ
◇勢いもあってそのまま第一項を書き終えた
・この時点では複数の出版社と話を進めるようになっていた
→最終的には2010/2に販売
・ランディングページ・ブックカバーをこの段階で綺麗に
→この段階になって始めて綺麗にすることが重要になった
→それまでは全く気にしていなかった
◇アーリーアダプターの人達がいて助かること
・「これには本当に価値がある」と思うときちんと評価のコメントを出してくれる
→実際にコメントをもらい掲載した
◇この本は大規模なソフトウェアと全く同じ
・終わりはなくてリリースがあるだけ
→第一版は対話(Conversation)の始まり
→今でも改定を加えている
→ブログ、ニュースレターでの活動も継続している
◇徐々にカスタマー層が広がっていった
・最初はアーリーアダプターだけだった
→ウェブデザイナーやデベロッパー
→今ではいろいろな人が読んでくれるように
・ワークショップは継続してやった
→ワークショップはこの本のMVPになっているため
→→内容を変えたり、客層を変えたり
→→→そうやってきちんと学習しながら、第二版を作っていった
◇ワークショップで知ることができたこと
・本についての学び
・アントレプレナーが問題・課題がとして感じていること
→これらの課題のために、この本以外にもプロダクトも作った
→→オンラインで使うリーンキャンバスというツール
→→他のプロダクト（metricsSystemなど）への派生も
◇最後に
・メタ原則の要素を感じ取ってもらえれば幸い
・ケーススタディはこれ以外にもいっぱいある
→ハードウェア
→ソフトウェア
→政府
→→実際にこのプロセスを使ってプロジェクトの成功率を上げている事例も
・もっとケーススタディを知りたい人は？
→Lean Start Up Conferenceを検索してみるといいと思う
→→政府系・教育系などいろいろな事例が見つかる
Ash Maurya様、O'Reilly Japan様、Yahoo! JAPAN様、ありがとうございました。
2012年12月18日火曜日
『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』ノート - 導入・理論 (1 / 4)
2012/12/17に開催された『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』のノートの前半です。
◆カスタマーとお金を出す人とスタートアップの中の人の話
◇まずは悪いニュースから…
・ほとんどのスタートアップは失敗に終わる
→これが現実
・でも失敗するのはスタートアップだけじゃない
→大企業が新製品を市場に投入するときも同じ
→→大企業の中の人もアントレプレナー精神が必要
・そして、成功した例の2/3は途中でプランを大きく変えている
◇Not a better plan A but a path to a plan that works
・成功するためには何が大事か
→必ずしも完璧なビジョンは必要ない
→→計画がワークするように調整できるか
→→それをリソースが無くなる前にできるか
◇今日話すこと
・"plan A"から"ワークするプラン"へ、システマチックに調整できるということ
・それをリソースがなくなる前にやるにはどうすればいいかということ
→スタートアップはリソースがなくなってダメになる、ということが多い
◇どうしてスタートアップを成功させることは難しいのか？
・普通のスタートアップはどういう流れで進むのか
→まず良いアイデアが浮かぶ
→→そのアイデア（ソリューション）に恋してしまう
→→→そしてそれをビルドする
・これが一番典型的な形
→ソリューションへの情熱があるから動く、ということが多い
→→それはマーク・ザッカーバーグも同じだった
・我々はプロダクトをそういう風に見てしまいがち
→「どういう風にペイするか、どういう風に開発していくか」というのが一番難しい
・お金を確保するためにどうするのか？
→投資家を探したり、社内なら予算をくれる人を説得するのが普通
◇ではお金を出してくれる人はどう見ているか？
・彼らは、我々の考えたソリューションに恋なんてしていない
→ソリューションなんて何でもいいと思っている人が多い
・彼らの関心毎は1つ
→いかに提案をスケールアウトさせ、ビジネスモデルとしてペイさせるか
◇お金を出す人が注目するものは何か？
・魅力(traction)があるか？
→作っている人以外にユーザがいるか？
→ユーザがバリューを感じているか？
・コストストラクチャとレベニューストリームに関する計画があるか？
・どれくらいのカスタマー数・市場規模があるか？
→カスタマーが誰かなのかは気にしない
・ディフェンス力があるか？
→成功した後、どれだけ他社から市場を守れるか
・まとめると
→魅力(traction)があるか？
→カスタマーや市場に展開できるか？
◇そこまでの魅力があることが証明できていないなら？
・それはなんとかしないといけない
→まずはカスタマーから始める必要がある
◇カスタマーはどう見ているか？
・自分の課題やproblemを解決してくれるものが欲しい
→始めはあなたのソリューションへ恋してない
・関心は「あなたはどういうソリューションを提供してくれるのか?」
→課題とソリューションの間にあるのがプロミス
→→プロミスに注目するのがカスタマー
・この時点で注意すること
→どんな課題を対象にするのか、というのは具体的にイメージできているべき
→→そうすれば、どういうカスタマーに確認すればいいか分かる
・facebookも最初はカスタマーを絞っていた
→ハーバード大学の学生のためのサービス
→今は誰でも使っているけど、最初は違った
・誰にでも受けるよう広いスコープにしてしまうと、結局は誰にも受けないものができあがる
◇次にカスタマーが気にすることは？
・どれだけ負担がかかるかということ
→負担などいろいろなものが条件を満たしていて、プロミスが魅力的なら参加してくれる
→→参加してもらえれば、いろいろ試してもらえる
◇True productとは何か
・ビジネスモデル全体のこと
→ソリューションではない
◇アントレプレナーの本当の仕事は、ビジネスモデルが持っているリスクを削っていくこと
・対話をとおしてリスクを削っていく
→顧客と
→社内の人と
→投資家と
→アドバイザーと
→ときには競合他社と
・どう対話するか？
→それはRunning Leanに書いてある
◆Running Leanの3つのメタ原則
・Document your plan A
・Identify the riskest parts of your plan
・Systematically test your plan
◇メタ原則の基になる考え方
・本当のプロダクト(True product)はビジネスモデルだということ
・ビジネスモデルを考えるときもテクニカルな観点から説明が付くということは重要
→そこは注意してやった
◇メタ原則1 : plan Aの文書化
・これはなんでもそう
→家なら設計図
→旅行なら旅程表
・きちんと文書化しようというもの
◇通常ならビジネスプラン（事業計画）やビジネスケースとして文書化する
・ビジネスプランを書くことが楽しかった人はどれだけいるか？
→ビジネスプランはとてもｐａｉｎｆｕｌ
→→しかも書けと指示した人は最後まで読まない
・でもこういうことをしっかりやるのはアントレプレナーには非常に重要
→その前にどれだけ対話ができているのかという問題があることに注意
◇エグゼクティブサマリとかエレベータピッチを書けといわれることもある
・どうせそういわれるなら…
→最初から1ページに綿密でシンプルなものを書くのはどうだろうか？
・それがLean Canvas
→こういう形でも充分作ることができる
◇事業計画やビジネスプランを作ったことがある人は、見出しを見るだけでLean Canvasに何が書いてあるかわかる
・ビジネスで重要となる、コアになるものを書き出したもの
→特にリスクに着目している
・ビジネスモデルキャンバスに調整を加えてある
→よりアクションがとりやすいように
・分割統治
→複雑な問題は要素ごとに分解するという方法
→Lean Canvasも1つ1つが独立した観点からまとめてある
・だからといってバラバラで良いわけではない
→最終的にはジグソーパズルみたいに1つにまとまらないといけない
◇メタ原則2 : どこが一番リスクを高いか見つけるには？
・ソフトウェア開発はリスクが高いところから手をつける
→それはビジネスも同じ
・どこにリスクがあるか、どうやってそれを低減するか
→これが成功へのひとつの道
・EasiestではなくRiskestなところから始めるということ
→これはポイント
・プロダクトを作るのはEasiest
→特にプロダクトを自分で作っている人にとってはそう
・プロダクト自体が失敗するのは作りこみの問題ではない
→カスタマーが見つからない、市場がないというのが一番の理由
◇どこがリスクなのか見極めるためには？
・Problem/Solution fit
→課題と解決がどれだけフィットしているか
→解決・対策に値する課題が存在しているのか
・もともとはトヨタ式、リーンの考え方
→外・現場に出て行かないといけない
→自分がいいと思っていることだけをやっていてもダメ
◇カスタマーに存在する問題、その中で何が重要なのか知る方法
・これはいろいろあると思う
◇カスタマーの重要な問題を理解した上で出来ることは
・何を最小単位で提供できるか
・MVP(Most Viable Products)
→本当に小さな規模のソリューション
→小さいけどカスタマーにバリューは提供できているもの
◇今までの伝統的なやり方
・時間をかけた作りこみ、テスト、調整
→それからくカスタマーに使ってもらっていた
→→そうやってできたものを使ってもカスタマーは迷子になってしまう
・途中のものでも、それがカスタマーの望むものか確認しながら進める
→全体が出来上がってからカスタマーに出すのではなく
・小さい規模でも「これはカスタマーがバリューを感じている」という確認をとる
→それからスケールするというステージに進むべき
◇通常のやり方とProblem/Solution fitの違い
・どのサイクルでもカスタマーを巻き込んで進めている
・プランをまとめて、そのプランにどういうリスクがあるかを確認する
→そのリスクに対して体系的にテストもやるべき
◇メタ原則3 : システマチックにテストする
・Experiment - Eric RiesのBuild-Measure-Learnのサイクル
→アイデア（仮説）からスタート
→それを元にプロダクトを作る
→→本当に小さなもの、全部ではないもの
→実際に使ってもらう
→そして定量的定性的に計測する
→データとして確認する
→データを活かして学習する
◇学習することによって調整を行う
・学習することで、想定していたリスクの正しさが分かる
→違えば修正して進めばいい
◇Experimentを回していく上で重要なもの
1. スピード
→時間は、スタートアップにとって一番大切で一番足りないリソース
2. 全てのExperimentはLearningで閉じる
→成功のいかんに関わらず学ぶことはできる
3. 適切なフォーカスができているか
→回そうとしているExperimentのフォーカス自体が正しいか
・フォーカスをきちんとやる
→これがないと、Experimentのサイクルを回してもアクションが伴わなくなってしまう
→→カスタマーすらついていないのにサーバを増設したりコードを書いてしまったりとか
◇次の3つを、フィードバックループを回す形でやっていく
1. Document your plan A
2. Identify the riskest parts of your plan
3. Systematically test your plan
・左から右、右から左へと
◆リーンスタートアップとは何か
◇リーンという言葉自体が昔は誤解を生んでいた
→チープとか良くないプロダクトであるとか
◇リーンはトヨタの製造システムから取ってきた考え
・リーンの考え方の重要なポイント
→いかにムダを省くか
→いかにリソースを有効活用するか
・お金は重要なリソース
→ただ、お金が一番価値があるリソースというわけではない
→一番価値があるのは時間
・お金や人的資源は増減できる
→時間は一定方向にしか進まない
◇自分のリーンスタートアップの定義
・ある一定の時間の単位で、何が一番リスクなのか最も効果的に学べるやり方
Ash Maurya様、O'Reilly Japan様、Yahoo! JAPAN様、ありがとうございました。
登録:
投稿 (Atom)