この記事では、分析において重要な課題のヒアリング方法、顧客との認識ズレを起こさないための事前の調整方法、バリューのあるデータアナリストとしてどう分析プロジェクトをリードしていくべきか、分析官に必要なコンサルティングの基礎を12年の現場経験を元にまとめています。
分析を開始する前の顧客との初打ち合わせからどんなことに注意していけばよいか？そんなシチュエーションを想像しながらお読み頂ければと思います。
本記事は「データ分析の仕方」シリーズの第2回目となります。
シリーズの全体感、概要は「データ分析の仕方①分析レポートの書き方までの実務上のポイント」もご覧ください。
目次
課題を知る前に把握したい分析依頼主の背景3パターン
分析プロジェクトが発生した際、まず抑えておくべきポイントは何でしょうか？
分析官としては具体的な分析課題や必要な分析手法に目が行きがちですが、プロジェクトの枠組みやステークホルダーの確認、それから顧客である分析依頼主の所属部署やポジション、課せられている（であろう）ミッションへの思慮が重要です。
依頼主は分析プロジェクトに何を求めているのか？どんな課題があって実現したいことは何なのか？まずはそこから理解する必要があります。今回は以下3つのケースについて考えてみましょう。
①明確に改善したいKPIが決まってるケース
②売上や利益などのKGIに課題感があるだけのケース
③社内にデータ分析の価値を認知・啓蒙したいケース
①明確に改善したいKPIが決まってるケースの例
例えば、「既存の社内分析によりF2転換率（「初回購入をした」層が、「2回目の購入をした」層に変化した割合を示す指標）をKPIとすることが決定している。その上で、どのようにF2転換率を改善できるかを分析委託したい」…といったケース等。
このようなケースでは、分析ターゲットが絞れるので、分析方針の認識合わせもしやすく、アウトプットもイメージしやすいです。
また、結果の解釈からネクストアクションもあらかじめ想定しやすく、分析初期からスムーズにPDCAを回していきやすい＝「失敗しにくい」ケースと言えるでしょう。
一方で、木を見て森を見ずにならないよう、点の分析をしながらも常に全体俯瞰の意識でデータ理解に努めたり、場面によって点の分析から視点を拡張した調査に舵を切る柔軟さも必要です。
比較的データ活用力の高い企業や部署からの分析依頼に見られるケースです。具体的な課題が明確な分、未経験者や経験の浅いアナリストでも対応しやすい案件と言えます。
②売上や利益などのKGIに課題感があるだけのケース
分析依頼をしている担当者が「とりあえず売上を上げたいので分析をお任せしよう」…といったケース。
このようなケースでは、データ分析は魔法の杖だと思われていたり、短期間の分析でROIが出て当然と思われている可能性もあります。
「何だ、分析しても大したことないな…やっぱり直感が大事だ。」といったお互いに不幸な結果にならないよう、「どのフェーズでどこまでやるか？」「どういうステップでビジネス貢献の道筋をつけていくか？」丁寧に分析計画を練って期待値調整をしていくことが重要です。
まずは俯瞰的な基礎集計、探索的データ分析(EDA)からはじめて、ビジネスインパクトが大きくかつ改善施策の難易度が低そうな課題にフォーカスして分析していくような設計が望ましいです。
③社内にデータ分析の価値を認知・啓蒙したいケース
「社内でのデータ活用文化があまりなく、これから分析をうまく活用してサービス改善していく土壌を作っていきたい」…といったケース。
顧客の分析期待値は高くはなく、「まずは小さな成功を収めて社内に分析の価値を認めてもらい、分析プロジェクトを継続的に進行していける環境の土台作りをしたい」そのお手伝いとして分析で伴走していくということはよくあることです。
この場合、理想的な分析活用として夢を描きすぎても、現状のデータ環境とのギャップが大き過ぎたり、そもそも「なるべく短期間で小さな成功からはじめたい」という顧客の要望に合致していない可能性があるで注意が必要です。
このケースでは分析に使えるデータもバラバラで中身も汚い状態であることが高い確率で考えられるので、使えるデータの範囲で低コストかつ課題改善の打ち手に結びつきやすそうなテーマを見つけることが重要です。
分析テーマの選定がプロジェクトの成否に直結するため、それなりに経験やビジネス力も求められるケースとなります。
分析を依頼する目的を意識しよう
上記のように、分析を依頼する相手がどういう環境・立場で分析リテラシーがどの程度で、何を期待しているのか？を理解することが重要です。
この時点で認識のズレが起きるとその後の分析工程全てが的外れで終いには「こんな結果を報告して欲しかったんじゃないんだけどな…」なんて結果になりません。そして、この工程の重要さに気づいていなかったり疎かにしてしまうアナリストが多いため、現場でくどいくらいに注意喚起をしています。
課題は分かった？それでもヒアリングをしよう
分析を依頼する背景は理解できたとしましょう。それでもまだヒアリングは不十分です。
通常、顧客も分析の依頼に慣れていることは稀です。キックオフミーティングの場があっても分析官として知っておきたい情報が揃えられているとは限らないので、コミュニケーションを取りながら本音を引き出したり、時には顧客の頭にある分析像を壊す必要があるかもしれません。
大事な話は引き出さないと出てこないことも…
例えば、上記②で挙げた「売上や利益などのKGIに課題感があるだけのケース」と思っていたけど、よくよく話を聞いてみると、より具体的な改善したいKPIがぽろぽろ出てくることもあります。
こういったプラスアルファの情報収集の有無で、「分かってるアナリスト」「センスがないアナリスト」といった評価の分かれ道になる可能性もあると考えると、顧客の立場に立って業務やサービスについて思いを張り巡らせたり、「こんな課題を持ってるんじゃないかな？」といった想定をした上でヒアリングに臨むことが重要です。
また、顧客は思い描いてる制約の中で話を進めている可能性も往々にしてあります。
意味のない制約を見破ろう
例えば、「こんなデータは分析には使えないだろう」「これは別部署のデータだから必要ないだろう」「データから行動結果は分かるがユーザー心理を定量化することはできないだろう」といった思い込み・決めつけによってスコープが狭くなってしまっていることも多々あります。
そこは分析のプロの立場としては、そのような前提を取っ払って、可能性を広げた上で最適化を考える必要があります。
分析方法のイメージが全く沸かない状態ならちょっと待った！
ヒアリング時に意識すべきことをもう少し。
ものすごく当たり前なことですが、相手の意図していること・やってほしいことが理解できていない状態でヒアリング（キックオフなどのミーティング）を終わらせないことです。当たり前なことなんですが、いろいろなものが邪魔をして「ちょっと待った」ができない人が多いです。
分析ってかなり高度な知的作業なのでいろんなレベルで分からないことがあって当然だと思うんですよね。素直に分からない部分を聞き直したり、発言の理由を確認したりすることは最終的に分析プロジェクトを成功させてみんなでハッピーになるための真摯な行動だと思います。
基準としては「自分自身が分析設計を作れる状態になっているか？」。
詳細設計まで思いつかなくても、「どんな方針でどういう比較検証することで白黒つけられそうな分析ができそうかな？」という自信がある程度持てれば分析前のヒアリングとしては合格かと思います。
逆にここが想像できない状態でヒアリングを終えるのは問題があります。最悪その場で疑問が残ったとしても、そのまま自分で「たぶんこういうことだよな」と無理に納得せずに後からでも質問をしましょう。
認識のズレを減らす工夫
また、打合せの際に自分自身理解できた、腹落ちしたと思っても、認識合わせの念を押すことをおすすめします。
「ネクストアクション（分析概要など）について相手の言ったことを自分の言葉に置き換えて確認する」ということです。
「それって～～こういうことですよね？」とか「では、～～という方向性で分析を進めていきます」のような。これは単純なんですが効果絶大です。
自分自身、認識合ってることが確認できて不安なく分析を進められることもそうですし、確認を取った上でプロジェクトを進めている形、つまり後々まで「顧客と一緒に考えてきたプロジェクト」という形になるので余計な意識違いのクレームにつながることを未然に防ぐことにもつながります。
自分の首を絞めないための作業工数見積もり
さて、やるべきことが握れたなら工数を見積もる必要があります。
ベストは打合せの最中に課題や分析案の話をしながら工数もイメージしてスケジュールも含めて議論することですが、明確な納期が迫っているわけではない＆分析経験が浅ければスケジュールは持ち帰りでもよいでしょう。
分析手法とそれにかかる時間が読めずに分析着手してしまうことだけは避けたいところです。アナリストが納期に間に合わずクオリティを犠牲にしたり深夜残業で擦り切れるようなPDCAを回し続ける姿を見てきていますが、課題に対して適した分析手段をイメージする力とそれにかかる時間をイメージする力が足りないのが大きな原因と感じます。
言われるがままにタスクを背負い込んで、やってみたら終わらないので根性でがんばる…というのでは分析を持続的に続けていくのは難しいし結果的に迷惑をかけることになりがちです。
現実的なラインで適切に工数を見積もり、どういうスケジュール・ステップで分析を進めていくのかを顧客と共通認識にした上で、健全に分析を進めていきたいところです。
工数に落とし込む技術の磨き方
さて、「適切に工数を見積もる」といってもこればかりはほぼ経験が全てです。
新米アナリストであればこの経験がないのは仕方のないことですが、日々分析手段の知識のストックと、作業工数を見積もる習慣をつけていくことを意識的にやっていくのをおすすめします。
具体的には1つ1つのタスクの各工程を何分で終わらせるのか、予測した上で時間を計ってみる。予測とのギャップがどれくらいあったのかを確認する。ということをしていると、自分の工数の見積もりが弱い部分に気づいたりと、見積もり感覚を鍛えていくことができます。
別に分析に限ったことではないですがこれも立派なスキルですね。このような時間の意識をしているか否かでアナリストとしての信頼・評価にもつながっていきます。
さて、分析依頼の背景理解、課題のヒアリング、分析工数の見積もりからスケジュール感を握るところまで話を進めてきました。その後実際に分析サイクルを回していくと、アナリストとしていろいろな気づきが出てくるかと思います。次のステップに進みましょう。
課題は聞き取るだけではない。バリューのあるアナリストとは？
綿密なヒアリングで顧客が思っている課題が聞き取れれば、当面分析の計画を立てて進めていくことはできるでしょう。
ですが分析を進めていくと、生データをいろいろと覗いた分析官としての疑問や数値の違和感が出てくるのが普通だと思います。
それはビジネス理解が足りないがゆえの疑問である場合もあれば、それまで気づかれていなかった想定外の事実が露見する場合もあります（分析の本筋ではない部分でも）。
顧客の課題感と自分自身が感じ取った課題感が直接結びつかなくとも、課題の根本でつながっているケースもよくあります。情報を整理して分析に深みを増していきたいところです。
たとえば「○○の数値が気になる。ここにフォーカスして検証してみることで△△な結果になったら、□□が問題と言えるので、深堀り分析してみる価値があります」というように単なる疑問で終わらせずに次のアクションにつながるような課題の検証へと提案していけると良いです。
このように「自分自身がデータから感じとった気持ちを、分析課題に落として顧客に提案できる」ということもバリューのあるアナリストの条件だと思います。
次何を分析する？分析プロジェクトをリードしよう
課題がいくつもあって、1つ1つこなしているうちは気になりませんが、継続的な分析プロジェクトで、目先の分析テーマに一区切りついたとき、顧客に「次何を分析しましょうか？」とお題が来るのを待っているスタンスだとプロジェクトがマンネリ化してしまいます。
最悪なのは顧客担当者が「当面の課題感があまりない状態なのに無理やり課題を作り出して依頼をする」というパターン（そうさせてしまうパターン）です。
こじつけに近かったり行きあたりばったりの分析進行はお互いに不幸な結果を生みます。そのような分析テーマは分析で検証するのが難しいようなテーマだったり、そもそも解決してもビジネスインパクトがあまりない本質からズレたテーマだったりすることが多いです。
分析プロジェクトを形骸化させないためにも、分析テーマが途切れそうなときこそ「分析テーマの提案書」を用意すべきです。
「考えられる課題と対応する分析テーマと改善できること」をセットに数パターンの提案を用意することで、顧客の方で依頼したい分析テーマがとりわけない場合に、「どのテーマから優先的に分析していきましょうか？」という方向に話を進めることができます。
このように、アナリスト自身が構築した分析テーマはそもそも自分が興味関心があったり、キーポイントと思っている対象の分析となるため、分析結果がどうあれ分析後の解釈やストーリーの構築・レポーティングが非常にやりやすいし、納得性の高いものになる可能性が高いです。
アナリストが自ら分析テーマを考えて提案していく習慣をつけることで、分析プロジェクト自体がお互いにハッピーな方向にコントロールしやすくなると私は思っています。
まとめ
今回はビジネスとしての分析の導入部分、ざっくばらんに顧客とコミュニケーションを取って、分析が必要となった背景や課題感について把握していく分析キックオフミーティングのようなシチュエーションを想定して意識したほうが良いことをまとめてみました。
データアナリスト・データサイエンティストとしてビジネス現場で活躍していくには、統計知識や分析スキルも必要ですが、今回ご紹介したようなソフトスキル（ビジネススキル・コンサルティングスキル）も求められる重要な要素となります。
今後ますますその要望は強くなり分析官の差別化ポイントとなってくることでしょう。一長一短で身につくものでもありませんが、データ分析関連職で働いていくにはぜひ意識して経験を積んでいきたいところです。
