$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

事前にアイデアを検証する方法を学ぶ - 「NO FLOP!」を読んだ

施策のヒット率を高める方法について学んでいる。今回は「NO FLOP!」を読んだ。

定性調査・定量調査の両方で参考になりそうな前提知識を学べたと感じた。印象に残ったのは

  • 「身銭」を切ってない人の意見を聞くな
    • 結果に対して、何かしら失うものや得るものを持っている人の意見だけを聞く
    • 気づき: 確かにこれが欲しいと言った意見を聞いて実装しても、それにお金を払う段階では使われないということはよく起こる
  • 「あいまいな思考」を「検証可能な仮説」に変えるためには、できる限り数字で表現することが大切
    • あいまいな意見例: この申し込みボタンの横幅をもう少し広げたら、クリック率もちょっとは上がるんじゃないかな
    • 検証可能な仮説: この申し込みボタンの横幅を20%広げた場合、申込者は10%増加する
    • 気づき: 数字で表現することで、周りの人との認識合わせもしやすそう。今後仮説を表現するときはなんでもいいので数字で表現したい

意見を言っている人は身銭を切っているか?自分が唱えている仮説は数字で表現できているか?を意識しながら行動したいと思う。

読書ノート

- 「身銭」を切ってない人の意見を聞くな 59
    - 結果に対して、何かしら失うものや得るものを持っている人の意見だけを聞く
    - メールアドレス・電話番号を提供した、お金を払ったなど
- 意思決定する時に使って良いデータの基準 71
    - (1) 新鮮でなければならない
        - 新しさはそのデータが何を対象にするかによる。データの種類によって消費期限は変わる
    - (2) 製品と強く関連していなければならない
        - マクドナルドの注文傾向と、今検討しているハンバーガー店の注文傾向は違う可能性が高いので、マクドナルドの注文傾向はデータとして参考にならないかもしれない
    - (3) 出どころを把握しておかなければならない
        - 出どころによっては、データの正確性の問題や、そもそも利害関係によって有利に改変されているかもしれない
    - (4) 統計的に正確でなければならない
- 他人のデータを信用せず、自分のデータを収集せよ 75
    - 他人のデータ(OPD) = 他人によって/他プロジェクトのために/他のときに/他の場所で/他の手法で/他の目的で収集された市場データ。この条件の一つでも該当していればOPD
        - OPDは自分の現在の状況とは異なるはずなので、似たようなアイデアについて他人が何をしたかだけで判断してはいけない
    - あなた自身のデータ(YOD)を収集することに力を注ぐ
- 「あいまいな思考」を「検証可能な仮説」に変えるためには、できる限り数字で表現することが大切 90
    - あいまいな意見例: この申し込みボタンの横幅をもう少し広げたら、クリック率もちょっとは上がるんじゃないかな
    - 検証可能な仮説: この申し込みボタンの横幅を20%広げた場合、申込者は10%増加する
    - XYZ仮説のフォーマットを使うと、検証可能な仮説にしやすい 94
        - 少なくともXパーセントのYはZする
        - 大気汚染指数(AQI)が一〇〇以上の都市に住む人の少なくとも一〇パーセントは、定価一二〇ドルのポータブル大気汚染モニターを購入するはずだ。
- 検証可能な仮説を、超ズームインした小規模でシンプルな仮説(xyz仮説)に変えることで、今すぐ検証できるようにする 100
    - 大気汚染指数(AQI)が一〇〇以上の都市に住む人の少なくとも一〇パーセントは、定価一二〇ドルのポータブル大気汚染モニターを購入するはずだ。
    - =>
    - 「北京子どもアカデミー」に子供を通わせる親の少なくとも10%は、定価800元のポータブル大気汚染モニターを購入するはずだ
- 大きな投資をする前には、それに関するxyz仮説を短期間で検証する = プレトタイプ検証 172
    - プレトタイプの3条件 = 「身銭を伴ったYODの収集につながる」「素早く行える」「低コストで行える」
- 身銭測定器を使ってどの程度人に刺さっているかを見る 194
    - 意見、使い捨てメールアドレス、SNSのいいね、調査やインタビューは0
    - 有効なメールアドレスは1、電話番号は10、相手の時間は1ポイント/分、現金1ポイント/100円など
- 成功と失敗のパターン 229
    - 意見や他人のデータを検討し、事業計画を立てるのに何ヶ月もかけたチームは失敗する傾向にある
    - 最低限のプランニングと検証しかせず、大急ぎで製品を市場に送り込んだチームは失敗する傾向にある
    - 大急ぎで市場テストを行ったチームは成功する傾向がある