created: 2018-10-28T09:14:17.000Z
起業の科学の読書メモ
会社でみんなで読もうみたいな機運だったのでちゃんと読みました
- 市場分析フレームワークの図鑑みたいな内容
- 前半部分、起業以前のところは一般常識として知っておくと非常識と言われず済みそう
- 後半部分は実際にプロダクトを作り始めたときに知ってればよさそうだった
一回通して読んで、付箋をつけたところを書き出したメモ
起業はタイミングが大事
- タイミングが悪いとどんな製品も売れない
- なぜ今なのか、という問いに答えらられるアイデアじゃないと厳しい
タイミングを図るためのフレームワークもあるのでそれを使う
PEST分析
PEST分析はご時世を認識するためのフレームワーク
テクノロジーが混乱してるところ分析
- テクノロジーの現状確認
- 求められているテクノロジーと、提供されてるもののギャップがあるところを探す
- 既存の市場が対応できてない&今のテクノロジーだと対応できるはずのところにチャンスがある
YCのDemoDay
海外の事例が簡単にまとめて見られるので歴史や事例の勉強に良さそう
スタートアップの10のフレームワーク
スライドだと9だけど本だと10個あった
本の煽りに「失敗の9割は潰せる」と書いてあったが、
こういうフレームワークに乗って先人の轍を踏まないで済むところのことを言ってるのかな
顧客課題
モノをつくるにあたって、どんな顧客課題を解決するかを考える
そしてどんな顧客がどんな課題を抱えているかを把握する
想定カスタマーをメンバーで共有しておくとコミュニケーションが楽
架空のカスタマーを想定するのに、必要なのか以下の三要素
- 場所
- 時間
- イベント
「いつ、どこで、なにをしようとしたときに困っているか(不便なのか)」を考える
そして考えたものは大事な仮説として管理する
ジャベリンボード
「課題があると思われる」となったことを仮説と呼ぶと、
ジャベリンボードは仮説を管理するために使われるフレームワーク
仮説の適切な管理は大事
インタビュー
顧客の課題を深掘りするためにインタビューを行うことがある
インタビューにも心得がある
- インタビュー相手のことをよく知る
- インタビュー相手の弟子になる (課題について根掘り葉掘り聞き込む)
- そもそもなんで今まで課題が放置されていたか
- 課題に対して定量的な評価が出来たりしないか
- 解決策でなく課題について聞き込む
- インタビュー直後に、相手の話を分析しておく
- 時間が経ってしまうとインタビュー時の印象は薄れる
そのほか
- ファウンダーが自分でインタビューしようね
- 相手の視線とか姿勢とか(非言語コミュニケーションも)みようね
インタビュー結果のまとめ方
フレームワークとしてKJ法が提案されていた
プロトタイプ
プロダクトを作った後もインタビューする (ユーザインタビュー)
プロトタイプを作って、顧客に触ってもらって、いろいろ聞く
アプリならすでに画面がある状態でUX的なところを詰めるために聞く
プロトタイプを操作してるところを録画しておくのがよい
質問リスト
画面を操作してる側から以下のようなことを聞いていく
- これは何をするものだと思いますか
- 今、何をしようとしていますか
- あなたは、xxxという文言をどう解釈しましたか
- xxxというボタンを何をするためのものだと思いましたか
- xxxというボタンは期待通りの動きをしましたか
- 期待とどうずれましたか
- 次は何をしますか
- これを使う際にあなたへのコストになるものはありますか
- 学習コスト
- 設備的なものが欲しいか
ユーザインタビューで確認するところ
- 便利だねという雰囲気だったか
- 操作中につまずいたポイントがあったか
- プロトタイプは最低限度の機能を持っていたか
- なんか機能が足りてなくて検証出来てないところがないか
- ユーザがUXでフォローして欲しいところを言語化出来たか
Minimum Viable Product
MVPはプロトタイプよりももうちょっと現実感があるところまで実装したもの
これを実際に市場に出して使ってもらって反応をみる
ここでもまだ「ユーザには受け入れられるか」が検証される(検証段階)
作るにも原則があって、以下のNGがある
- 顧客が欲しがる機能を全部搭載する
- 刺さったポイントが分からなくなって反応が見れない
- 検証項目を絞っていない
- まだ検証段階なので、なにを検証したいのか決めてからMVPを作る
- 無駄に自動化
- MVPを作るコストは低くあるべき
ユーザーストーリー
- 顧客がMVPを使って課題を解決するまでの一連の流れ
- ユーザーストーリーを定義して、MVPを使ってもらってそれが現実的か検証する
KPI
MVPの良し悪しを判断するためにKPIを設定する
- 次の課題が見つけられるようなKPIを設定する
- ユーザ数やCPAといった結果指標だけだと次の課題は見つけられrない
- 次に何をするべきかが判断できるKPIを設定する
- 検証内容がぼやけてると、KPIから具体的な解決手段が思い浮かばない
- 疑似相関的なKPIを追っている
- 対応策との因果関係が説明できるKPIが望ましい (難しそうだが)
最初からシステムの最適化/自動化はしなくてよい
- まずは製品が顧客に欲しがられるようにするのが第一
- 欲しがられるものが作れたら、その工程を自動化/最適化する順番が正しい
