データと語るのではなく、自分と語り合え
本日は「データ分析」という言葉について考えてみたいと思います。尚、本稿は”経営戦略”の視点での解説ですので、具体的なデータ分析の手法やノウハウについてご興味のある方はコチラをご覧ください。
分析は「仮説思考」のためにある（断言！）
言い切ってしまいますが、分析は「仮説思考」を円滑に回すために存在します。
もちろん、世の中には「仮説は最初に立てるな」というような表現をする方もいらっしゃるのは存じ上げていますが、これは、見解の相違ではなく表現の相違だと僕は思っています。（関連記事：ギックスの本棚／1億人のための統計解析） 分析をするということは、何か検証したい（言い方を変えれば、明らかにしたい）ことが先に存在するのです。それが明確に「AなのかBなのか」というレベルで具体化されていることもあれば、「なぜXという事象が起こっているのだろうか」というようなモヤモヤしたオープンクエスチョンのこともあるでしょう。ただ、それがどういうものであろうとも、最初に”問い”が無ければ、データ分析は総当たりで全部見て何か発見があったらラッキーというゲームになってしまいます。そんなものは体系化された手法とは呼べません。
分析が活きる場面は２つ
では、分析が活きるのは、どういう場面なのでしょうか。僕は、仮説検証サイクルにおいては、２つの場面だと思っています。
仮説検証のサイクルは、
- 何らかの”気づき”を得る ：データから、何らかの異変・特異点に気づく。あれ？っと思う。
- その”気づき”を基に”仮説”を構築する ：なぜ、その異変が起こっているのか。特異点の理由は何か。を考える
- ”仮説”を検証する ：考えた”理由”＝仮説が正しいかどうかをデータを見て確認する
- 検証結果から”新たな疑問”を得る ：仮説の正誤に関わらず、見落としが無いか、あるいは、違う切り口はないのかを考える
- その疑問について深く考える ：疑問点（あるいは着眼点）をデータに現れる変化に落とし込む。つまり、理論的に”どういう変化が起こるはずなのか”を想像する。
- →（最初に戻る）
という流れで行われます。そのうち、データを用いて何かを考えるのは太字で記載した２つの場面です。
ここで重要なのは、データに接しているときに、自分が「気づきを得るためにデータを見ている」のか「仮説を検証するためにデータを見ている」のかを、自分自身で理解しておくことです。
慣れてくると、仮説を検証しながら新たな気付きを得ることもあるでしょうし、反対に、気づきを得ていたはずがそのまま仮説検証に入ることもあるでしょう。しかし、最初のうちは「データを何のために見ているのか」を意識しておくことが重要です。データは嘘をつきません。しかし、データはそのものズバリの正解を教えてくれるわけでもないのです。問いを持ち、答えを探すのは、あなた自身です。
仮説構築はデータ＋経験・知識
データを見て”気づき”を得たら、それを元に”仮説”を構築していくことになります。ここで重要なのは「データだけ見てても仮説は作れない」ということです。
何が必要なのか。それは「経験・知識」です。
関連記事でも述べましたが、分析において重要なのは、ツールを操るスキルや数字を扱うテクニックではありません。データ分析は、その結果として得られる「ビジネス上の成果」が重要です。この「ビジネス上の成果」を定義するには、ビジネスに携わることによって得られる業務経験・業務知識が不可欠です。ただし、それは「勘・経験・嗅覚」という表現をされ、およそ論理的でないものとして、昨今の欧米式経営トレンドにおいて蛇蝎のように嫌われているものだったりします。
しかし、「●●店の売上が急に減少した」や「新商品のCMを投下した途端に、関連商品の▲▲が爆発的に売れるようになった」といった”気づき”に対して、「なぜか？」と考え、その理由を考えること＝仮説を立てることには、それらの”業務経験・業務知識”が必要なのは疑いようのない事実なのです。
検証するから”論理的”になれる
とはいえ、いくら仮説構築が「勘・経験・嗅覚」の賜物だからといって、それだけでは論理的思考とはほど遠いわけです。そこで、データを用いた仮説検証が必要になるわけです。
データによって、自らが立てた”仮説”が、正しいのかどうかを検証するわけです。ここまでやって初めて「仮説思考」はひと段落します。
ありがちな失敗として、この仮説構築→仮説検証のプロセスを、そのまま報告するというものがあります。残念ながら、このプロセスそれ自体は、他の人にとっては聞いてもあまり意味がないものです。その仮説が、１回目に思いついたまま正しかったものなのか、20回の検証による”誤り”判定を受けて21回目に正しいと証明されたものなのかは、聞き手にとってはどうでもよいのです。聞き手が知りたいことは「その仮説が正しかったという事実＋正しいと証明できる裏付け（データ）」です。そして、さらに言えば「その仮説が正しいと分かった今、次にビジネス上の判断として何をすべきなのか」なのです。（関連記事：考えた順序と説明する順序は違う）
尚、多くの会社で起こっている【現場】と【経営】の乖離は、上記よりも手前の問題だったりします。この検証プロセスを経ないで、”仮説”だけを報告してしまうんですよね。そして、その検証されていない仮説を前提としてビジネス上の判断について議論が進んでしまう、と。こうなると【経営】は、「【現場】はまったく考えていない」と思ってしまいますし、一方【現場】は「【経営】は我々のことを全く理解していない」という結論に至ってしまいます。
いずれにしても、仮説は検証して初めて意味があり、その仮説を元に、どのようなビジネス判断をしていくかを報告することが大切です。
※尚、中間報告・進捗報告として「現段階では、こういう”気づき”から、こういう”仮説”に至ったので、これからこういうデータを使って”検証”していこうと思っている」というステータス報告をするのはアリです。というか、むしろ、どんどんやりましょう。そこで、報告した相手から「他に、こういう”仮説”もあるんじゃないか？」であるとか「検証に使えるデータは、ほかにこんなのもあるんじゃないか？」であるとかいうインプットを貰えれば、仮説構築・検証サイクルは高度化・効率化されます。
深く考える＝自分と対話する時間をつくる
データと向き合うことは言うまでもなく大切なのですが、分析作業をビジネス判断につなぐためには、「自分自信と対話する時間」が必要です。サイクルの中では「仮説構築」と「疑問の深掘り」がそれに当たります。
分析というのは「データとの対話」であると思われがちです。しかし、分析は目的ではなく手段である、と定義するならば、分析において対話すべき相手は、データではなく自分自身である、ということがお分かりいただけるでしょう。
数字を触って終わり、グラフを作って終わり、とならないために、自分自身の経験や知識をフル稼働して「このデータ（数字・グラフ）は、何を意味しているのか」「それは、なぜなのか」を問い続けるシンカホリックな姿勢を持つことが、ビジネスシーンにおける分析の正しい在り方だと僕は思います。
関連記事： データ分析を経営に活かす”CAO（Chief Analytics Officer ＝ 最高分析責任者）”という役割
