B-log

コンサル→ベンチャー。ビジネス系のネタ。

分析は、行ったり来たり

コンサルの入社直後に教わって今も覚えていることの一つに「分析は発散と収束を繰り返す」というものがあります。

先に図示するとこんな感じの話です。

曰く

  • 先にイシュー・仮説があって、その可能性を検証して潰していくのが理想。その場合、図の左側の感じで分析が進むとどんどん可能性が狭まって答えに近づいていくイメージになると思う。
  • でも実際は、分析している途中で「あ、こっちの方が切り口鋭いな」って気づいたり、最初に立てた問いが間違っていることに気づいて手戻りしたりすることも多い。その場合、図の右側のイメージで答えに近づいたり離れたりを繰り返す振り子みたいなイメージになる。
  • もちろん、事前にキレイにイシュー分析ができていてその通り進むのが理想だし実際それができる人はいるけど、(特に新人のお前らは)そうは行かないのが現実。
  • そうなったときに、最初の仮説や構造に固執して事実やデータを曲解するのが最悪。情報を素直な目で見て、必要に応じて可能性を広げ直すことが大切。で、多分俺も間違えるから分析実務でデータと睨めっこする君らが違和感に気づいたら遠慮なく言ってほしい。

こんな感じの話だったと思います。

なんとなく「分析は『狭める』一方の行為」だと思っていた自分にとって、目から鱗の教えでした。

 

いくつか大事なポイントがある気がするので、詳述していきます。

 

そもそも分析はイシュードリブン

前提として、分析は何かと何かを比較してイシュー(その場で白黒つけるべき課題)を解決するために行われるべきものです。

仮に上司から「●●の市場規模調べといて」とイシューがなさそうなタスクが投げられてきた時でも、 本当は「●●の市場は1,000億円以上の規模があるのか」「●●の市場は拡大しているのか縮小しているのか」「●●の市場は、実は▲▲の市場より小さいんじゃないか」など、何かしらその場で白黒つけたい課題があるはずです。

もっと日常業務的なところでも同じ話です。

例えば、「明日のテレアポはどこにアタックすべきか」みたいなレベルでも「アポ数とアポ率どっちが課題なのか?」「その課題を解決できそうなのはAリストかBリストか」みたいに、白黒つけるべき課題はあるはずです。

イシューがない(あるいはイシュー度の低い)分析は、悪です。

でも、イシューや仮説を外すこともある

でも、実際はイシューや仮説は外れることがあります。

そもそもイシューを的確に当てる能力というのは、かなりのトレーニングが必要です。「イシューからはじめよ」で有名な安宅さんも以下の通り書いています。

これは「イシューアナリシス」と呼ばれるコンサルティング現場では秘宝のように鍵とされている方法論で、体系的にトレーニングをしても、実際には日々の実践で身につける以外の方法はない。基礎レベルであっても身に付くのはそれなりの時間がかかるし、その課題についてのセンスがあるほど、そして経験を積むほど、レベルが上がる。  
圧倒的に生産性の高い人(サイエンティスト)の研究スタイル より)

逆にいうと、日々の実践でイシューアナリシスが身についていない段階や、課題についてセンスや経験がない領域では、イシューや仮説を外すことはたくさんあります。

 

仮説が外れたときに一度視野を広げる

そんなわけで、実際にはイシューは外れるし仮説も外れます。

仮説を否定する分析結果が出たときに、一番ダメなのがデータを曲解してどうにか最初の仮説をサポートするかのように見せてしまうことです。

次にダメなのが、最初の仮説の構造に固執して周辺で言えそうなことを言ってお茶を濁そうとするパターン。

 

本当は、仮説が外れたらただそれを素直に受け入れて、仮説やイシューツリーを組み立て直さなくてはいけない。

例えば、売上低迷の理由を<地域別>で分析しても仮説通りの結果が出なかった時に、

  • じゃあ、地域 x 商品別で見たらどうだろう?
  • 地域 x 商品別で見たら切れ味よかった。特に影響強かった商品群XXは▲▲業界でよく売れているはずだから、実は商品というより顧客の業界別の方が切れ味鋭いのでは?そうすると、地域って切り口はもはや不要なのでは?
  • そうだとすると、イシューツリー全体の組み替えが必要で….

と、次の仮説にどんどん移っていくことが大切だという話です。

このタイミングがまさに、分析が「広がる」瞬間です。(広がるは広がるのですが、前の仮説が否定されているので多くの場合は振れ幅は前回より狭くなる。)

 

分析は発散と収束を繰り返す

そんなわけで「分析は発散と収束を繰り返す」というコンサル入社数週間で教わった教えは、今も自分の中にしっかり残っています。

 

 

実務上のTips

以下は若干の蛇足・おまけ的内容です。

「分析は発散と収束を繰り返す」というのは、「仮説が外れたらすぐ次の可能性に行こうぜ」というある種当たり前の話なのですが、その後の長い実務経験の中で、なるほど確かにこれができていないケースが意外とあるということを実感してきました。

そして失敗するケースをみていると、そこから導かれるTipsみたいなものがある気がしてきました。具体的には以下の3つです(MECEなまとめではなく「あるある」な話として)。

  • データを少し広めに準備しておく(広げやすい形でデータを作っておく)
  • 余裕をもったスケジューリング(Quick & Dirty)
  • 単純に分析の速度を上げる

以下順に解説していきます。

 

データを少し広めに準備しておく(広げやすい形でデータを作っておく)

実務上、外れた最初の仮説にこだわってしまうパターンの一つとして「次の仮説を分析するのに必要なデータがない(集めるのが面倒)」というケースがあります。

先ほどの例でいうと、<地域別>で売上低迷を説明する仮説が外れた時に、<商品別><顧客業界別>のデータが用意されていないと「本当は商品別で見た方がいい気がするけど、データセット作り直すのが面倒臭い(データ集め直すと納期に間に合わない)」となってしまいがちです。

最初にデータを集めるときに、仮説が外れた時を想定して広めにデータを集めておくor後からデータを足しやすい形でデータセットを準備しておく、というのは実は大切なポイントな気がします。

余裕をもったスケジューリング(Quick & Dirty)

もう一つ最初の仮説にこだわってしまう(あるいはその周辺で何かを言ってお茶を濁そうとする)パターンとして、「本当はイシューツリーを大きく組み直さなきゃ行けないけど、納期まであと3日しかない」みたいなのがあります。

(これは本当は「イシュードリブン」の一部なのですが)「ここの仮説外れたら全部やり直しだな」というポイントがあるのであれば、雑にでも早めに結論を出してみた方がいいです。そのために、影響が大きい論点の見極めと早く雑に結論を出す検証方法を考えることが大切。

逆説的ですが、イシュードリブンでの分析の経験がない人ほど、最初の仮説検証をギリギリのスケジュールで組む気がします。

余裕持ったスケジュール大切。

単純に分析の速度を上げる

以上の前提として、単純な分析の速度、という変数も重要な気がします。

例えば「地域別に売上を分析する」と言ったときに、「比較ってどうやるのか、平均値?合計?その差分が有為かの検定方法は?」的な数学っぽい話から、単純にExcelで関数知ってるか/操作早いか、みたいなのも仮説検証の回数を増やす上で地味に重要です。雑に言えば、Excelでピボットテーブルをスムーズに使えない人がQuick&Dirtyなんてできないことが多いんです。

で、これは正直ある程度座学したら、あとは場数な部分もあるので、早くなるまでは多少睡眠時間削っても頑張るしかないのかなあ、と思います。

(「イシューからはじめよ 」で言う犬の道っぽいですがこれは許されていい気がする。筋トレみたいなもんです。コンサル会社のアソシエイトがショートカットキー使いまくるのも近い話。)

 

 

本当は、イシュー・アナリシスをちゃんとできるのが一番大切です。

イシュー・アナリシスを本当の意味でできていれば、tipsで触れたような内容はまさに瑣末でしかない。

しかし、上でも述べた通りイシュー・アナリシスはそう簡単にできるようにならない。そうである以上、多くの人にとってtipsのような内容もそれなりに重要になるのではないかと思ってます。