patorashのブログ

方向性はまだない

仮説の検証の仕方が確認できた

GWにブックオフで買ってきた本の1冊。アウトプットの質を高めるとあったので、買った。がむしゃらにアウトプットしていてもなかなか質は上がらないよなぁ〜という気持ちだったので、ちょうどよかった。

アウトプットの質を高める 仮説検証力

アウトプットの質を高める 仮説検証力

仮説を立てる際に心がけたいこと

ついついテクニックに走りがちになるらしいのだけれど、とりあえずたくさんのデータがあればなんかわかるだろう…みたいな感じだとよくない。

目的を明確にする

なんのために仮説を立てるのかをはっきりしておかないと意味がない。無意味な計算を繰り返す羽目になる。

仮説の精度は準備で決まる

しっかりとしたデータの整理などをしておけば、おのずと精度は上がる。時間がかかりやすいところではあるけれど、不十分なデータで仮説を立て始めるほうが、時間を浪費する。

周囲と同じ仮説を出していては意味がない

ある程度の傾向が出てくると、みんな似たような仮説を立てるけれど、同じ仮説を立てて安心していてはいけない、と書いてあった。「自分ならではの仮説が立てられないようでは、新しい価値を生み出せない」というメッセージに、確かになぁ〜!と思わされた。誰でも立てられるような仮説は機械学習がやってくれるようになるだろうし、オリジナルの視点を持つことが人間の価値を高めることになりそう。

仮説の検証法は2種類

仮説の検証法は以下の2種類あるとのこと。

  1. 実験型検証
  2. 裏付け補強型検証

仮説は実験して検証するものという認識が強かったので1の実験型検証が普通かと思っていた。PDCAのDとCに当たるものだ。しかし、実験を行うのは時間的なコストや金銭的なコストがかかるので何度も行うのが難しいものが多い。

裏付け補強型検証は、PDCAのPに当たるもので、仮説の精度を高めようというものだ。仮説の精度が高くなければ、結果の要因があやふやになりやすい。

本の中では、例え話で、旅行の計画が順当なものかを検証するようなものと書かれていた。無謀なスケジュールを立ててしまったら旅行に支障が出るため、前もって情報を集め(移動時間は正しいか、美術館はその時間で回れるのか等)本当にそのプランで旅行できるかを検証しようということだ。

定量データと定性データ

仮説を立てるには、まず裏付けとなるデータが必要になる。そのデータは

  • 数値化できる定量データ
  • 数値化できない定性データ

である。

定量データは、来客数とか売上高、市場シェアなど。定性データは、アンケート結果など。基本的にどちらか一方だけではダメで、両方を使っていく模様。

定量データから仮説を立てるには?

まずは必要なデータだけに絞り込むことが大事という。とにかくデータを集めればいいというものではない。このあたり、機械学習の本でも同じことが書いてあった。まぁ機械学習もデータを元に傾向を見て仮説を立てて、インプットが仮説の通りかを検証してアウトプットするものだもんなーと思った。

仮説を立てる前にすること
  • 集約
    • MECE(漏れなくダブりなく、データを分類する)
    • 因数分解(足し算・引き算・掛け算・割り算)
  • 指標化(比較する際に必要)
比較する際に気をつけること

どう比較するか(HOW)、何と比較するか(WHAT)をちゃんと意識すること。

どう比較するか
時系列比較
時系列の比較は基本中の基本。昨年度との売上の比較など。
自分なりに設定した基準と比較
昨年度の売上の110%を基準として、それとの比較など。
外部の比較対象との比較
同業者の売上の伸び方との比較やシェアの比較など。ベンチマーク
何と比較するか
目的に沿ったデータと比較
分析の目的に合ってないデータだったら、比較する意味がない。どういう意図で作られたデータかが大事。
できるだけ同じものと比較
これは、外部の比較対象との比較のところの話。実力差や規模の差がありすぎるものと比較しても、意味のある仮説はなかなか立てられない。同規模で調子がいいもの、同期や1つ上と先輩などをベンチマークとするとよい
数値自体には意味がない

例えば、シェアが13%、みたいな数値があったとして、ここから何が読み解けるかというと、何もわからない。数値は他者や、時系列での過去との比較を行わないと意味がなく、また、比較して読み取れる傾向などが見えて、初めて意味が出てくる。データ比較で使われている縦軸・横軸に注目する。

定性データから仮説を立てるには?

定性データは準備が9割。記事やアンケートなどの定性データは分析にはそのまま使わない。ちゃんと下ごしらえを行うこと。定性データ同士で共通点や相違点を整理する。

定性データには特性がある

例えば、アンケートでいえば、回答者の年齢、性別、職業、身長、体重、趣味などがわかれば、それらで切り分けることができる。それらを特性という。本の中では、新作弁当のアンケートでは男女での違いがあった。男性は「ボリュームが少ない」、女性は「量がちょうどいい」など。これらを特性なしで判断すると、どっちが正しいかわからなくなる。お弁当のターゲットを男性にするか、女性にするかなどの判断材料となる。

アンケートなどのヒアリングを行った際の回答は、定性的データで、回答者の主観が入ってるので網羅的ではなかったりするのだけれど、アンケートも数があれば共通部分がでてきたり、回答者の属性で分類できたりする。

データの意味を浮かび上がらせるように整理する

データを整理して満足になってしまいがち。目的は整理したデータから意味を読み取ること。

定性的なデータの比較

意識するところは3つ。

比較対象としているデータは仮説を立てる目的に合っているものか?
漠然と比較しない
特性ベースで比較する
特性ごとの共通点・相違点を見つけていくことで方向性が生まれる。
意味を読み取る
  1. 全体の共通点から意味を読み取る
  2. 一部の共通点から意味を読み取る
  3. 意外な相違点を捉える

読み取ったら、一言でまとめてみるのがいいらしい。

定量データと定性データを組み合わせて仮説を立てる

どちらも使っていく。定量データで全体的な傾向をつかみ、掘り下げていくときに定性データを使っていく。定量データで見られた傾向に、定性データで肉付けを行っていき、仮説をより強固なものにしていく。

事例では、X社の代理店の売上の推移(定量データ)と、代理店の担当者とX社の営業へのヒアリング(定性データ)が使われていた。定性データの特性は、代理店の規模感と、代理店におけるX社製品の売上成長率・シェアなどなど。この事例での定量データ、定性データのまとめ方は非常に参考になるなと感じた。

裏付け補強型検証

裏付け補強型検証は上のほうでも説明したのだけれど、実験しにくい仮説の精度をまず上げるために行う。 裏付けのない仮説は仮説ではない。単なる思いつき。

仮説の精度を確認する
  • そもそも言いたいことがあるか
  • 目的・問題意識に沿ったものか
  • 漠然とした内容になっていないか(精度の高い仮説は具体性が命)
  • 裏付けの精度はどうか(量・偏り・信頼性)
補強するべきポイントを明らかにする
なにが不足しているか、偏りがあるか、など。具体的に。
入手するべきデータを明確化する
定量データ、定性データの構造化を行い、欲しいデータを定義する。
データを入手する
  • 入手したいデータを考える
  • 具体的な入手方法を考える
  • 代替案を考えておく
入手したデータで補強して仮説の精度を高める
仮説の修正を行う。

どこまで検証を進めるか

際限のないことなので、時間を区切って進めるか、インパクトのある仮説ならば満足する精度だと思うまでやる。

実験型検証

試行錯誤の検証はこちら。実験型検証は日々、みんながやっていることと同じ。しかし、「これで失敗したから同じ失敗はしないようにしよう」みたいなレベルに止まることが多いので、もう一段階高い視点を持っておく。

実際に行う場合に気をつけること

自分なりのこだわりを持つ

仮説の中でも、ここに注意してみよう、これを意識した行動をしてみようなど、具体的な違いを作っておくと後で検証しやすい。

結果だけでなくプロセスを考慮する

結果だけにフォーカスすると、ただ運が良かっただけなのに勘違いしてしまうことが多い。重要なのは再現性があることなので、プロセスが大事。なので、その仮説が成立するプロセスを具体的にイメージしておくことが大切。上の「自分なりのこだわりをもつ」ところは、このプロセスの中で意識することになるのだろう。

プロセスの中にこそ、改善点が埋もれている。

結果の検証

問題点が解消したかどうか
前より改善したのか、そうでもなかったのか。
実験による副作用はどうか
何かをするということは、他のことが起きる。Aが売れた結果、Bが売れなくなった等。
目的の達成度はどうか
問題点が解決しても目的が達成されない場合もある。(Aが売れなかったという問題は解消されたが、Bが売れなくなって目的の売上アップはできなかった等)

実験を繰り返す

  • 実際に効果があるのかを確認
  • なんども行うことで傾向を見る

異なる実験を行う

  • 目的は変えないこと!
  • 意図を明確に変える
    • どの観点に効果がある、ないかを掴むことができる
  • 現状や以前の実験との違い・差分を意識する
    • 同時に複数のものを変えないこと
      • 何が原因かわからなくなるから

うまくいった(いかなかった)要因を把握する

プロセスを具体的にイメージして実験したとしても、うまくいく場合とうまくいかない場合がある。期待したプロセス通りに物事が運ばなかった場合もある。そのあたりの要因を把握する。

  • 他の要因を探る
    • たまたまうまくいった場合
      • 当日イベントが近所であってお客さんが多かった等
      • 景気がよくなってきていた等
    • 逆もしかり。たまたまうまくいかなかった場合
  • 改善ポイントを掴む
    • 次に似たようなことをするときに活かせる

要因の捉え方

  • 自分の立てた仮説は正しかったか
  • 想定通りに仮説を実行できたか
  • 裏付けに見落としはなかったか
    • 責任を自分のせいにして変にいじけないこと
      • 想定外のことは起きる時は起きる
      • 誰だって見落とすことはある
  • 他の要因はなかったか
    • コントロールできる要因
      • 情報の共有など(連絡していれば防げたこと等)
    • コントロールできない要因
      • 天候・集客など

実験結果を活用する

実験結果がうまくいった場合は、似たような場面があれば精度を向上させることができる。他の仮説にも応用できるところを探していく。仮説自体の応用や、プロセスや考え方を応用するなど。

うまくいかなかった場合は、改善ポイントを探して、他の仮説に活かすことができる。

感想

検証といえばPDCAのC(Check)だろうと思っていたのだが、裏付け補強型検証でPの段階でもやるもんだとわかったのがよかった。たぶん、普段から知らず知らずのままやっていたとは思うけれど、とりあえずDoしちゃおうぜ!みたいなことは結構あったと思う。回転速度の早いPDCAならそれでも振り返りできるのでいいのだろうけれど、AIや機械学習の技術が一般化してくると、Pの裏付けが今後は大事になっていくと思う。

また、成功体験が運が良かっただけなのに勘違いしてしまうというのは本で読んだことがあるが、それもちゃんと考慮してプロセスが期待通りだったか、他の要因はなかったかを検証するという視点が書かれているのはよかったと思う。逆もしかりで、たまたま運が悪かっただけというのもあるけれど、運だったのか、計画が杜撰だったのか、その辺りはちゃんと裏付けしていかないといけない。

本のまとめみたいな記事になってしまったが、自分の中でフワッとやっていたことなので要点を整理しようとしただけで長くなってしまった。仮説はアップデートできるし、ブログ記事もアップデートできるので発見があったら更新しとこうと思う。