見出し画像

データ分析でビジネス価値を発揮するための10ステップ

こんにちは、DAIです。
機械学習・データサイエンスを中心としたコンサルティングを経験した後、現在は事業会社でデータ組織の責任者をしています。

本稿では、データ分析でビジネス価値を発揮するための10ステップと称して、「実際にビジネスバリューにつながる」分析を実現する方法論について簡単にご紹介したいと思います。

そもそもビジネス価値とは何か

なんとなくバリューと価値という言葉を使ってしまいがちですが、そもそもデータ分析でビジネス価値を発揮するとはどういうことなのでしょうか?
どういう状態であれば、データ分析によってビジネス的なバリューを発揮できていると言えるのでしょうか?

美しいダッシュボードを作ることでしょうか?
何か新しい発見をすることでしょうか?

私は、「データをもとに意思決定をしビジネス上の行動を変えることができたか」がバリューを発揮できているか否かの分かれ目だと思います。

極論ですが、意思決定をし行動を変えることができなかったのであれば、データ分析をした意味はありません。
美しくわかりやすいBIのダッシュボードができたところで、それを眺めるだけで何も行動を起こせないのであれば何の価値もありません。

会社規模が大きくなると、BIツールを推進する部門と実際に意思決定をする部門に壁があり、とりあえずツールだけ入れるといったことが起きることがあります。
結果として、使われないツールが誕生します。
これでは全く意味がありません。

このようなことにならないために、分析を行いビジネス価値につなげていくためのステップを整理したのが以下の10ステップです。

10のステップと最も重要な○○と●●

ここでは主に、人手で行うアドホックな分析を想定してフレームワーク化しています。
このようなデータ分析には、主に探索型と仮説検証型があります。
探索型は、データを見ながら課題や仮説を考えるというアプローチです。
一方で、仮説検証型は、解きたい問い(論点)に対する仮説を持ち、その仮説をデータで検証するというアプローチを取ります。

ビジネスの意思決定のための分析であれば、仮説検証型の方が成果につながりやすい、というのが私の経験則です。
(ちなみに実際にコンサルティングファームのプロジェクトでも、「論点設定」「仮説立案」「仮説検証」「打ち手策定」「打ち手実行」というステップを踏みます。)

データ分析に関する書籍でも似たようなことが言われています。
私の個人の経験論のみでなく、有識者の意見もあった方がよいと思うので紹介しておきます。

私は、先の流れとはまったく異なるステップで分析に臨みます。

1 .どんな表やチャートを作れば、自社のアクションが変わるのかを考える
2. データに触れる
3. 表やグラフにしてアウトプットする

何が違うのかというと、 前出のステップとは1 と2 の順番が逆なのです。 もっというと、ステップ 1の「 どんな表やチャートを作れば 、自社のアクシ ョ ン が 変わるのかを考える 」 ことに大部分の時間を投入しています。「こんな分析結果が出たら、こういう風に自社のアク ションが変わる」ということを 、データに触れる前にたくさんの脳内 シミュレーションをして考えてい るのです。これこそが、データ分析における最も付加価値の高いパートになります。

榊󠄀 淳(2024).「DATA is BOSS 収益が上がり続けるデータドリブン経営入門」. 翔泳社
※太字部分は本稿の筆者による強調

以下のフレームワークは、アドホックな分析の中でも仮説検証型の分析を想定して作成しています。

  1. 論点設定

  2. 仮説立案

  3. 分析設計

  4. データ収集・準備・分析

  5. 考察・示唆出し

  6. 報告・提案

  7. 意思決定

  8. 実験設計・施策実施

  9. 効果検証

  10. 改善

私がデータ分析の組織構築をする中でも、分析のプロジェクトは基本的にはこのようなステップを踏むようにしています。
(ただし、機械学習による自動化・効率化等を目指す場合は若干手順が異なりますのでご注意ください。)

実際にはこれらのステップが1から10まで綺麗に上から下に流れていくことは稀です。実務の現場では、これらのステップは行ったり来たりすることが多いものです。

そのようなものとして捉えておき、綺麗にこの手順が進まなくても、「そういうものだ」と割り切るようにしましょう。

例えば、立てた仮説を分析したが外れた、ということはよくあります。
また、論点を途中で見直すべき時もあります。
いずれにしても、このステップを常に綺麗に回せるという完璧主義は捨てましょう。

さて、見出しにつけた「○○」「●●」とは何でしょうか?
これは上記のステップを踏む上で特に意識したい重要な観点を表しています。
あるステップにおいて「○○」「●●」を自問自答する、というのがより正確な言い方です。

皆さんも、少し考えてみてください。


・・・

何が思いついたでしょうか?
私の答えは、
論点設定のステップにおいて「行動に変化が起きる論点を設定できているか?」
仮説立案のステップにおいて「その仮説が検証されたら行動が変わるのか?」
を自問自答せよ、
になります。

上記二つの自問自答すべき観点を含めて、各ステップについて解説していきます。

論点設定

何よりも先に、まずは解くべき問い(論点)を解いているか?が最も重要です。
この点についてはTipsを別なnoteの記事にも書いているので併せてご覧いただければ幸いです。

先ほど紹介した記事にも書きましたが、まずは分析者が向き合うべきビジネス的な問いは何か?を明確に言語化することが重要です。

データ分析で何かできないか?といったフワッとした依頼をきっかけに始まる分析プロジェクトは最も危険なものの一つです。

どのようなビジネス上の論点に対してデータ分析を適用すべきか?、を考えるべきなのです。

例えば、あるECサイトにおいて、月間売上が下落しているという傾向にあり、何か対策を講じる必要があるというケースであれば、「なぜ月間売上が下落しているのか?」という論点設定ができます。

繰り返しになりますが第一ステップとして、解くべき論点をきちんと言語化しておくことが非常に重要です。

しかし、第一ステップで言語化したような論点設定では、分析のアクションにつなげにくいことも多いでしょう。
先ほどのように「なぜ月間売上が下落しているのか?」という論点を言語化することは素晴らしいことです。
しかし、まだ問いが漠然としていて扱いにくいのではないかと思います。

もう一段深掘りしておくことで、具体的な分析アクションにつなげやすくなります。

例えば、さらに次のような問いを立てることで、分析観点をよりシャープにすることができます。

  • どのような顧客層の売上が低下しているのか?

  • 売上が低下しているのは自社特有の事象か、競合他者も同様なのか?

  • どのようなカテゴリーの商品で売上が低下しているか?

問いを深掘りする際に重要なのは、「この論点を解いたら行動は変わるのか?」という点です。
ここを自問自答し、「問いても意味がなさそうだ」と思うのであれば論点設定を再考しましょう。

さらに言うと、定量的なビジネス指標の何に効果を発揮させるための論点なのか?を考えておくことをお勧めします。
やはり最終的にはアクションを起こして何らかのビジネス成果に繋げることが期待されるので、自分が向き合っているビジネス指標との論点がつながっているか?はセルフチェックすることが重要です。

仮説立案

論点を設定できたら、仮説を立案します。
仮説とは、論点に対する「仮の答え」です。
ここで仮説をしっかりと言語化できていると、分析で検証することが具体化できます。すると、「分析してみたが何もわからなかった」という事態を避けることができます。

お気づきの方も多いと思いますが、論点と仮説はセットなので、独立して考えてはいけません。「問い ⇔ 答え」という関係性だからです。

例えば、先ほど挙げたような論点の例に対して、次のような仮説を立てることができます。

  • どのような顧客層の売上が低下しているのか?

    • (仮説):新規ユーザーの売上が継続的に低下しており、30%以上低下している

  • 売上が低下しているのは自社特有の事象か、競合他者も同様なのか?

    • (仮説):競合他社の成長は鈍化していない、自社のみ低下している

  • どのようなカテゴリーの商品で売上が低下しているか?

    • (仮説):ファッション小物のカテゴリーの売上が前年同月の80%程度の水準にまで低下している

このように仮説を具体化しておくことで、どのような分析をすればよいか?
その仮説を証明・反証するにはどうすればよいか?、
という思考が働き、分析結果をクリアにすることができます。

しつこいようですが、大事なのはこの仮説が証明されたら行動が変わるか、という点です。
「これがわかったところで何も意思決定につながらない、アクションが打たれない」という仮説を分析してもあまり良い結果は得られません。
これがわかったら行動が変わりそうだ、と思えるところまでしっかり時間を使って検討すべきです。

分析設計

分析設計では、論点・仮説に対してどのようなデータを用いてどのような分析手法を適用して分析していくか?を設計します。

より具体的には、以下のような論点に答えていくようにします。

  • どのようなデータを使うか

    • 例:注文履歴データ、主にxxxテーブルを使う、等

  • どこからデータを入手するか

    • 例:DWHからSQLで入手可能、等

  • どのような分析手法を使うか

    • 例:解釈性を重視して線形回帰の手法を用いる、等

  • どのようにアウトプットするか(アウトプットイメージ)

    • 例:分析結果のチャートのイメージやプレゼン等のイメージ

  • アウトプットをどう活用してどんな意思決定をするのか

    • 例:XX施策の継続可否を判断する、等

  • どのくらいのスケジュールでやるか?、重要なマイルストーンは?

  • どのくらいの工数が必要か?

Tech系の企業やWeb系の企業などであれば、分析者自らDWHからSQLを用いてデータを入手することが多いと思います。
会社によっては、データの入手にそれなり時間がかかったりするケースもあるので、個社の事情に応じてかかる工数は見立てておきましょう。

分析手法については、アウトプットイメージを具体化して取捨選択することが重要です。
そして、アウトプットしたものをどう活かしたいか?も含めて考える必要があります。
例えば、マーケティング関連の分析で、顧客行動を分析した結果を用いてマーケターと一緒に打ち手を議論するのであれば決定木や線形回帰系の手法を使うなど解釈性の高い方法が求められます。
よって、最終的な意思決定に至る状況をリアリティ高く描いておき、そこから逆算してアウトプットイメージや分析手法を考えることが重要です。

データ収集・準備・分析

ここは主にDWH等からSQLでデータを取得することが多いと思います。
実際の分析の現場では、分析設計やデータ収集・準備・分析のフェーズは行ったり来たりすることも多いため、分析者自身がデータ収集をできる方が良いでしょう。

考察・示唆出し

分析結果をもとに、考察・示唆出しを行います。
ここで重要なのは、考察や示唆出しは「答えたい論点」に対して行うことです。

なぜ、売上が下がっているのか?
という論点に対する考察であれば、当然「売上が下がっている要因」をデータドリブンに説明すべきです。
また、先ほども述べた通り、意思決定して行動を変えるために分析をしているので、ここでの示唆は行動を変えるものであるべきです。
その点を意識して考察をしていきましょう。

報告・提案

分析結果と考察結果をわかりやすくまとめます。

ここは一般的なプレゼンテーションのテクニックを基本的に踏襲すれば良いと思いますが、データ分析においては以下のような点は特に注意が必要でしょう。

  • 事実と解釈の区別

  • データやグラフは注目して欲しいポイントを明確に

  • 論点に対する「答え」を端的に書く

  • ビジネスサイドのリテラシーに合わせて専門用語を取捨選択する

意思決定

ここでは論点に沿った意思決定を行い、必要に応じて実際に施策を実行します。

例えば、あるECサイトにおいて初回購入ユーザー層の2回目購入率が下がっていることが売上成長の鈍化の要因であるとわかった、としましょう。

そこで、打ち手として、初回購入ユーザーに対する2回目購入クーポンを出す、という施策を行うこととなった・・・。

このような意思決定をこのフェーズでは行います。
(これは話の分かりやすさを重視しているので、単純な例を示しています。実際にはもっと深掘りした分析や打ち手の議論が必要でしょう。)

実験設計・施策実施

ここでは、実施する打ち手の効果を検証する方法を検討します。
最も典型的な例はRCTに基づいたABテストです。

重要なのは、測定したい効果をビジネスのコンテキストを理解したうえでしっかりと定義することです。

とりあえずABテストをしておけばいい、というのは思考停止でよくありません。
例えば、先ほどの例(2回目購入者へのクーポン配布)で言えば測りたい効果はX日以内2回目購入率のリフトだけとは限らないのです。
LTVベースで評価したい、というケースもあるでしょう。
また、短期効果だけでなく中長期効果も合わせて評価したいというケースもあると思います。例えば、単に需要の先食いがリフトのように見えているだけではないか
?という懸念を払拭したいケースです。
このあたりは、ビジネスサイドとしっかり議論して設定していくことが重要です。

また、この段階で効果検証に足るサンプルサイズを得られるよう実験を設計することも重要です。
例えば、ECサイトにて何らかのマーケティングキャンペーンによるCVR向上を狙うのであれば、CVRの向上の効果量や、実験期間に得られるセッション数等の情報を加味して実験期間や対象を決める必要があります。

それ以外にも、効果検証でバイアスが生じないようにすることも重要です。
なお、バイアスがあっても効果検証をすることは可能ですが、やはりRCTに基づくABテストがゴールデンスタンダードにはなります。
このあたりの詳細は、参考書籍に載せた効果検証入門やA/Bテスト実践ガイドなどをご参照ください。

効果検証

効果検証を「施策実施」のステップの後に置いていますが、効果検証を行うには、そもそも施策の実施段階で実験設計をしておくことが重要です。
そのため、前のステップで施策実施と実験設計をセットにしています。

ABテストであれば有意差の有無を検定するなどして、実際にどの程度の効果があったのか?を確認します。

この効果検証部分だけでもかなり深いテーマですので、本稿では簡単に言及するに留めます。
効果検証については以下の本が参考になるでしょう。

改善

効果検証で十分な効果が認められれば、状況に応じて施策実施の段階に立ち戻るか、論点設計や仮説に立ち戻るなどの対応を行います。

効果があったのであれば、施策の対象範囲をより大きく拡大したり、より良くするための改善計画を立てます。

本格的に拡大するにあたっては、この段階から施策を定常的に実行するためのデータパイプラインやCRMツール連携等のオペレーション設計も行なっていくことになります。

おわりに

簡単ですが、分析のステップ論について整理してみました。
皆さんの業務に少しでも役に立つヒントがあれば幸いです。

その他の参考図書

プロジェクトマネジメント関連

課題設定・論点・仮説思考関連

データ × ビジネス思考

A/Bテストなどの実験設計関連



お仕事のご相談等はこちらまで:

この記事が気に入ったらサポートをしてみませんか?