データ分析の仕方・分析レポートの書き方までの実務上のポイント

個別のテクニカルな分析手法については世に情報が溢れていますが、データ分析という仕事の進め方については、抽象的でケースバイケースなこともありあまり情報がないように感じます。

今回は「インサイト発見からサービス改善を目的にしたアドホックな分析レポーティング」に焦点をあて、抽象的なフレームワークの紹介ではなく、データ分析という仕事の進め方・ビジネス上重要な分析レポーティングのポイントについて、12年程の現場での経験をまとめてみます。

さて、データ分析ってどんなアウトプットをもってデータ分析したと言えるのでしょうか？
何となく、データを可視化して今まで気づかなかった新たなインサイトが得られるようなレポートを作ること、のように捉えているかもしれません。何を目的に、分析後どんな状態になっていることをゴールとして行うべきでしょうか？

ここからは何回かに分けて、データ分析の仕方、特に分析レポーティングの考え方、手順、についてまとめていきます。今回は「分析レポーティングの全体像」について見ていきます。

分析レポーティングの基本的な流れ

まず最初に対象データの確認とデータの理解が必須です。「どんなデータがどういった形式で保持されているか」「分析に使える項目はどんなものがあるか」などの把握をした上で、顧客の課題を解決するための分析レポーティングの進め方に焦点をあてます。

まず、よくある失敗例として計画を練らずに手を動かしてしまうことがあげられます。

仕事として分析するからには納期があるので、計画的に分析をしないと「分析してみたら良い結果が何も出なかった」「何もアウトプットが得られず納期が来てしまった」なんていうことにもなりかねません。

そもそも「どんな結果が出るかわからない分析によって突然窮地に立たされる」なんて状況は心臓に悪すぎです。これは計画的に分析を設計することでかなりの部分緩和できます。

課題の明確化

依頼された内容を自分自身吟味して腹落ちしてるわけでもなく愚直に実行してしまうと、顧客の本質的に解決したい課題とズレが生じて、「こんな分析をして欲しかったんじゃないんだけどな…」が発生します。

顧客から本質的な課題を引き出すのも分析官としての重要な仕事です。顧客は分析のプロではないので分析で解決できる範囲も明確ではないし、そもそも人間なので言い間違い・聞き間違いもあって当然なので、きちんと分析官自身が「その課題を解決する意味は何なのか？分析で解決できそうなことか？」を認識してから具体的な分析に入っていくべきです。

そこが腹落ちしてないのであればもっとヒアリングをする必要があります。「何でこんな集計をしてほしいんだろう？これやる意味ある？」というような疑問があって確認してみると、たいてい前提の勘違いなどを認識合わせすることができて「なるほどね、そういう意味なら確かにやる価値あるね」もしくは「それなら、こっちの検証をした方が目的に合致してますね」といった形で前に進むことができます。

ここが疎かになると違うベクトルに進んでしまうので事故を未然に防ぐために丁寧に進めたいところです。このように「顧客からのヒアリングにより分析官自身が分析の設計を作れる状態になるまで課題を明確化」する必要があります。

分析設計への落とし込み

ノープランで分析をはじめると、「あれもやろうこれもやろう、結果が微妙…これも出してみようか」と時間も無駄にかかるし、分析目的から軸がブレてきます。気がついたら時間切れで「結局何をやりたかったんだっけ？」なんてことになりかねません。

分析を進めながら迷いが出てきたときには、指針となるような分析の設計書を作成することが効果的です。要件定義の分析版ですね。自分のための指針でもあり、後から見直したときに「どういう背景で何のためにどんな分析をしてたんだっけ？」というのがわかるようにする意味でも役に立ちます。

抑えておくべき項目としては、「分析テーマ・背景・課題・目的・仮説・分析手法・集計条件」あたりで良いでしょう。この時点で集計条件まで考えておけると実際に集計するときのスピードが段違いです。

具体的な分析設計時のコツについては別途まとめたいと思います。

集計・分析

分析設計で書き出した集計を実施します。定義した集計条件でたんたんとSQLを書いていきます。

初級者と中級者の差が出てくるポイントとして、「自分で集計の間違いに気づけるか？」という点があげられます。集計ミスは経験を積んでいるアナリストでも発生はしますが、数値の違和感に気づいたり、普段からミスをあぶり出すようなチェックの工夫が大切です。

また集計をしてみて新たな仮説が生まれたり、より重要と考えられる軸に気づくことも日常茶飯事で、都度分析設計を更新していきます。ただしスケジュール感と相談しながらタスクを管理していかないと追加タスクで潰れることにもなるのでそのあたりの落とし込みも重要なスキルなので別途まとめようと思います。

集計だけで終わるテーマもあれば、要因分析として多変量を取り扱う分析テーマもあります。ここでは個別の手法については割愛しますが、多変量は工数もかかるので事前に丁寧に設計と、想定されうる分析結果を数パターン考えておき、「このような結果になったら結論をまとめられそう」「こっちの結果だったら、次手としてこういう軸で掘っていこう」というような分析後の対応についても考慮しておきたいところです。

分析ストーリーの構築

プロジェクトマネージャーの立場からアナリストの力量判断の材料として、この「分析ストーリーの構築」能力はかなり重視しています。

テクニカルなスキルは後からでも伸ばしやすいし、みなさん興味関心が高いので黙ってても勉強してくれます。一方で、顧客が理解できるようにわかりやすく分析報告を簡潔なストーリーに仕立てる能力というのは経験の積み重ねも必要だし、なかなか人によって伸ばしにくいスキルでもあります。

さらには重要性をあまり認識されていないのか学ぶ機会が少ないのか、そもそも伸ばそうという気持ちはテクニカルなスキルに比べ低いように思います。

こちらについても実作業で具体的に考えていることをまとめていこうと思います。

レポート作成

分析ストーリーまで組み立てができていれば、レポート作成は半分以上終わったようなものです。分析ストーリーが紙芝居なら、そこにブラッシュアップとしてセリフを付け加えていくようなイメージです。

ポイントとしては、「読み手・報告相手を意識して、伝わる構成、伝わる表現になっているか」をこれでもかと追求すべきだと思います。どんなにすばらしい分析をしていても、伝わらなければ価値がゼロだからです。

もう一つ、分析の目的としては、「～が分かった。」ではなく「～が分かったので、こうしよう。」と、次のアクションに繋げるところまでを意識することが重要です。報告相手に伝わりかつ、具体的に動ける状態に持っていけて成功と言えます。分析ストーリーの構築からレポート作成ブラッシュアップで、報告相手が何をすればよいのかのメッセージを打ち出せているか確認しましょう。

このブラッシュアップの時間が確保できるかで最終的なレポートの質が大きく左右されます。
時間とクオリティのコストパフォーマンスは高い作業なので、事前にタスクスケジュールとして確保しておきたいところです。

まとめ

改めて今回は以下の内容に着目して概要を書いてみました。

今後、下記内容の詳細について、実作業で重要だと思うポイントについて個別にまとめていこうと思います。