ハンマーを手にすると全て釘に見えてくる

色々と分析手法を学ぶとそれを使ってみたくなると思います。

顧客の分類をするときに、とりあえずありもののデータを突っ込んでクラスター分析にかけるということをしていた時期が私にもありました。

またデータがあると聞けば、とりあえずそのデータを分析（確認）したくなる人もいるでしょう。

顧客データの属性が掲載されたレポートが共有されると、同じように自分の業務レポートにも顧客属性を掲載しようとする人もたくさんいました。（今もいそうですが。。。）

半ば条件反射のように思考パターンが固定化されていると、当然ながら他の考え方を受け入れることや視野を広げて考えることもやりにくくなります。

データ分析職はデータという客観的なものを扱うので比較的バイアスがかかりにくいかもしれませんが、それでも「データがないと分析できない」「目的がはっきりしないとデータ分析する意味がない」などといって、it's none of my business な対応をする人もたまにみかけます。

データがない状況でできそうなことは何かないかと取り組んでみた、目的がはっきりしてない状況でクライアントとどう合意形成したか、といった経験がないとなかなか先に進めないものではないかと思います。

データ分析をする人には論理的思考にみられる客観的な視点も必要ですが、その客観性が非常に狭い範囲で限定されてしまっていると、単に視野が狭いとか思考停止していると言われるだけです。

視野の広さも身に着けるために、色々チャレンジしてみるのも大切なことでしょう。

「それはデータアナリストの仕事ではない」、「自分の仕事は機械学習モデルの作成とチューニングだけだ」などのようはセリフはなるべく使いたくないものです。

もちろん最初は学んで身に着けた自分の武器でやってみるのもよいと思います。しかしそれでうまくいかない場合は、諦めるのではなくて次に他の視点でできることがないか考えられるかどうかです。

ちなみにタイトルの意味は、なんでも自分の得意な視点や考え方で進めようとする（状況等に合わせて柔軟に考え方を変えるべし）ということです。

元はアメリカの有名な心理学者（マズローさん）の言葉らしいです。

MAUの見積もり方

MAUとは何か

MAUとは、Monthly Active Users（月間アクティブユーザ数）の略です。

WebサービスやアプリなどのKPIとしてよく使用される指標です。

ダウンロード数や登録数を増やしても、コンテンツなどに問題があってユーザがどんどん離脱しているようではMAUはなかなか増えていきません。

ユーザに継続的に来店（利用）してもらうための仕組みが必要になります。

そのためサービス提供者側はこうしたMAUのような指標をモニタリングし、アクティブなユーザ数をチェックしようとします。

ソーシャルゲームのようにほぼ毎日アクセスがあるようなサービスでは、DAU（Daily Active Users）を確認したりしますが、そこまで頻度の高いサービスでなければ通常はMAUをモニタリングすれば良いかと思います。

実店舗の顧客に対してもポイントカードを導入するなどしてIDを管理できるようにすれば、全ての顧客は無理にしてもおおよその継続顧客の傾向は把握できるようになります。

MAUが増加傾向にあればサービスとして成長しており、逆に減少傾向にあればサービスとして縮小が見られ、あまり増減がないようであればサービスとして成熟してしまったあるいは停滞していると判断できます。

MAUの見積もり方

さて、こうしたMAUをKPIとしてモニタリングしていると「今後どのように推移するのだろうか？」「このまま行けば目標値に達するのだろうか？」が気になってくると思います。

さらに、月初に今月は先月よりもMAUが増えるだろうか？などを気にする人も出てくるでしょう。

精緻に見積もりたいのであれば、MAUに影響する変数データを調査して、それを使って時系列予測ないしは重回帰分析を行うとそれっぽい数字が出てくると思われます。

ただし、その影響変数も例えば天候のように今後が未知数のものであれば見積もりが難しくなります。

ちなみに未知数の値を予測してその値を使って別のデータを予測するのは誤差が重なってズレが大きくなる可能性が高いので、あまり予測に予測を重ねるのは精度が悪くなるかもしれないので注意です。（欠損値を埋める場合などは除く）

なお、現在の新型コロナや過去ではリーマンショック等といったものの影響を予測するのはほぼ不可能なので、今後何が影響して予測を外してくるかは本当にわかりません。

成長、停滞、縮小の傾向をシンプルにとらえるだけであれば、回帰分析で過去のトレンドを分析すればわかるでしょう。

もちろんそのトレンドが今後も継続するとは限りませんが、重要なのは「このまま」いくとどうなるかではなく、「このまま」が何に起因しているのか？を分析することです。

・各宣伝やプロモーションによってどれくらいユーザが獲得できるのか

・何もしないと（ブランド力？）どれくらいユーザが増えるのか、減るのか

・既存ユーザの離脱率は大体変わらないのか（自然減なのか）

・どういうときに既存ユーザの離脱率は上がるのか、などなど

MAUの予測精度を気にするよりも、MAUに影響する変数を洗い出してそれをモニタリングし、異常が見られそうであればその対策をいち早くとれるようにすることの方が重要です。

一方でメーカーや小売など仕入れや在庫が発生するビジネスでは、コスト削減や機会損失を防ぐために精緻の高い需要予測が求められますが、こちらも精度を高めるには影響のある変数を見つけることがポイントとなるので根本的な分析方針としては共通ではないかと思います。

データアナリスト向けドメイン知識習得方法を考えてみる

ドメイン知識とは

データ分析に携わる方であれば、ドメイン知識の重要性はあちこちで語られるのを聞いたこともあるでしょう。

ドメイン知識とはある専門分野に特化した知識であり、一般的な知識と対比されるもの、とのことです。（wikipediaより）

担当する業界、業種のビジネス知識がないと、ピントのずれた仮説立案／分析結果の解釈／報告や提言をしてしまう恐れが出てきます。

そのためデータ分析職にはデータ分析のスキルだけでなく、ドメイン知識も身に着けるべきとしてあちこちで推奨されています。

では、そうしたドメイン知識はどのようにして身に着ければ良いのでしょうか。

業務経験を通じて身に着ける

どのような職業でもそうであるように、最も一般的な方法は業務経験を通じて身に着けるということでしょう。（いわゆるOJT）

関連書籍を読むなど基本的な知識を学ぶことも必要ですが、おそらくそれだけでは十分ではありません。

同時になるべく業務担当者と近いところでデータアナリストとして仕事を行い、書籍では得られない実務の詳細や現場感などに触れる機会を多く持って学ぶこともたくさんあるでしょう。

まずは現場担当として配属

中途ならあまりないと思われますが、新卒ではまず最初に現場経験を積ませるために、研修後に半年～1年ないしは2年ほどは全員工場配属や営業配属とする企業をときどき見かけます。

データアナリストのように専門職扱いであっても例外はなく全員です。

特に現場からの叩き上げや過去に同様の現場配属を経験したことのある人が偉い立場にいると、なおさらそうした新人教育を課そうとする傾向にあるのではないかと思います。

しかし、これは当の新卒の方たちからすると大変不評です。

早く一人前になりたいのに、希望と異なる仕事をしろと言われるのは納得がいかないと思うのも無理がありません。

特にアナリスト志望だと、営業や支店配属などは自分には向いていないとして嫌がる人はたくさんいますが、最初にそうした仕事をしばらくやれと言われたらかなりショックでしょう。

私が所属していた企業でも同様のことがあり、中には事業部長に転属させて欲しいと直談判しに行った新人までいました。

おそらく上層部からも、現場経験を積むことが将来役に立つとか、これも研修の一環であるとか何らかの説明はあると思いますが、おそらく皆が納得できるとも限らないものなのでしょう。

せめて入社前からそのような配属情報やキャリアプランなどを明らかにしていたならば、それに納得した人だけが入社してくるでしょうが、もし後出しで伝えているならひどいですね。

ドメイン知識を習得するのに一定期間の現場配属はひとつの手段ではあります。

しかし、なぜ現場配属を行うのか、その目的を明確にすればほかのやり方も選択肢として考えられるのではないか？という気もします。

・どんな経験を積み、どのようなスキルを身につけさせたいのか

・期間が半年や1年というのはなぜなのか？
（頑張って早く結果を出せば短縮可能なのか？）

・受け入れ側の負担は問題ないのか？
（短期間でいなくなる新人に手間をかけて育成させる意味はあるのか？）

・とりあえず現場に放り込んでおけば勝手に育つだろうと思考停止していないか？

・ジェネラリストや幹部候補の育成のやり方と勘違いしていないか？

どのようなドメイン知識を身に着ければ良いのか

そもそもドメイン知識と言っても多種多様でそれだけでも膨大なものですが、それを全て身につけなければならないのならば半年や1年程度の現場経験だけでは無理でしょう。

長年その業務に従事している方々でさえ、常に学び続けておられると思います。

最低限必要な用語や業務フローなどは整理してドキュメントから学べるようにし、実際に業務上体験しないと学べないようなことはOJTで行うなど切り分けた方がよいのではと思います。

前者について、現場は人手不足で業務に必要な情報やマニュアルがまとめられていなかったり、情報があっても古いままであったり、最新版がどこにあるかわからないなど整備されていないことはよくあります。

通常は人の出入りが激しいなどの事情がなければそうした情報は工数をかけてまとめられておらず、現担当者から新担当者へ引き継ぎ時に口頭や簡単なメモ等で伝承されていくくらいかもしれません。

現場に新人を配属するならば、そのような知見の整理と共有を担ってもらうなどもありだと思います。

以前新人にOJTをやってもらう中で、業務で扱う用語集の作成、業界状況、TIPSや注意点をレビューの上Wikiにまとめることも担当業務としてやってもらったことがあります。（基本的な業務マニュアル等はあらかじめ私のほうで整備済）

それらのコンテンツは新たな新人が配属されたときや中途入社の方の早期キャッチアップに役立っています。

さらに他のチームメンバーからのナレッジや実プロジェクトのアウトプットなどもそこに加えるなどして日々充実を図っています。

また机上だけで学ぶのが厳しい業務については、いくつかのテーマごとに業務を一通り回すことを経験してもらうために、疑似プロジェクトを複数回実施し、報告・レビューを経て一定の基準をクリアすれば次からは実担当としてアサインするということも行っていました。

なお、疑似プロジェクトは営業等の担当としてではなくデータアナリストとして参画してもらったので、現場配属はせずに実施しています（個人的には現場配属しなくても現場の方と一緒に仕事できる環境があればドメイン知識は身に着けられると思ってます）

疑似プロジェクトを通じて、報連相、ヒアリング、プレゼン、ドキュメンテーション、スケジューリング等一通りの業務を回すために必要な基礎スキルを磨き、かつ現場の方々との関係性構築やフィードバックを通じて彼らの考え方や現場の背景や事情なども学んでもらえたと思っています。今後また彼らと一緒に仕事をする上では必要な準備となったのではないでしょうか。また報告の場ではアナリストの先輩たちからもフィードバックしてもらっていたので、分析面での甘さや不十分さなども指摘され学べるものがあったと思います。

現場配属を行い一定期間現場担当者について回ってもらうというだけでは、現場担当者によって学べる内容も統一されませんし、その期間に発生する仕事内容も各新人で異なってくる可能性もあります。そもそもそこで何が学べるのかも実際に担当者がついてみないとわからないというのでは新人も先行きが見えずに不安でしょう。

疑似プロジェクトのようなものもベストな手法とは限らないでしょうが、実業務に近いカリキュラムのひとつとしては有力な選択肢ではないかと思って紹介してみました。

ドメイン知識の習得とひとことでいっても、正解が決まっているわけではないので基本的には試行錯誤の連続になるのでしょうけれど、こうしたこともチームで色々と考えながら取り組めると成果も大きくなるのではないかと思っています。

仮説の立て方３ 原因を探る

以前に仮説の立て方について記事を書きました。

custle.hatenablog.com

custle.hatenablog.com

今回は何らかの問題解決のためにその原因を調べる場面での仮説立案ということで、しばらくぶりですが第三弾の記事になります。

事象の原因を調べる

・売上が急に下がった原因は何か？

・顧客の離脱が増えたがどうしてなのか？

・新規施策の効果が見られないのは何故だろう？

といった場面にて、原因と思われる仮説を色々考えて調査するといった経験のあるデータアナリストも多いのではないでしょうか。

事象を切り分けて問題点を絞り込む

原因を調べる場合は、正解となる仮説にたどり着くのが目的なので、無作為に仮説を考えて検証するよりも、まずは事象の切り分けや問題点の絞り込みにつながる仮説から検証するのが効率的です。

例えばテレビが映らないときに、故障かもしれないと思って修理業者を呼んだけれど、実はコンセントが抜けていただけで無駄足だったなんてことはよく聞く笑い話です。

まずはコンセントやアンテナ線が抜けていないか、リモコンの電池が切れてないかといった単純な見落としがないかなどを調べて、原因がそれ以外なのかを切り分ける方が一般的でしょう。

売上の減少などに関しても、例えば全ての商品で減少が見られるのかそうでないか等を確認しておくと、実は無関係である（減少傾向にない）商品の減少理由を考えてしまうといった無駄なことを避けられます。

事象の切り分け方

過去と同じ問題が再燃したというケースも結構多いので、まずは過去の問題の原因と同じかどうかを調べることから試してみても良いかもしれません。

しかし、もし過去の問題の原因とは別の原因であることが判明したら新たな仮説が必要になります。

その場合は、以前紹介したようにフレームワークを使うなどして漏れや重複のないようざっくりと切り分けていくことになります。

余談ですがITシステムのトラブルにおいても、原因を調べる場合はITシステムを構成するサーバ、ネットワーク、アプリケーション等のどこに問題があるのか切り分けながら範囲を絞り込んでいきます。

売上減少でいえば、マーケティングの4P（Product、Promotion、Price、Place）や3C（Company、Customer、Competitor）などを元に絞り込んでみるのも良いかもしれません。

4Pを元にした場合は以下のような感じでしょうか。

・商品による差
・プロモーションの有無あるいは種別による差
・商品の価格帯による差（競合と比べて相対的価格差が生じていないかも注意）
・エリアやチャネルによる差

例えば上記の差などを調べて、差があるところが見つかればそこを深堀りしていくと原因にたどり着けます。逆に差がないようであればそこは除外して別の個所を調べます。

3Cを使う場合は、自社側に原因があるのか、顧客側に原因があるのか、競合が原因を作り出していないかなどを切り分けるイメージです。

ただ自社側の場合は調査範囲が広くなりがちなので、まずは競合の動きや顧客の反応から調べてみるのが良いかもしれません。

ざっくり範囲を絞れてそこからさらに深堀りしていく際にも、フレームワークや構成要素などを元になるべく抜け漏れがないように調べていくのが基本的な流れとなります。

仮説検証時の注意点

問題点を切り分けようとしたが、実はそれは問題ではなかったということもたまにあります。

売上減少でいえば、例えば比較対象とした時期がキャンペーンなどをやっていて売上が好調な時期だったので、そこと比べて大幅に減少しているのを問題と見なしてしまうなどです。

また細かく切り分け過ぎて原因を勘違いしてしまうこともありえない話ではありません。

またまた売上減少でいえば、平均よりも大きく売上の下がっている商品を見つけたが、その減少額は全体の減少額から見るとほんの一部で、売上全体の減少にはあまり影響していなかったなどです。

あとケースによっては原因特定に至らないことも十分考えられます。これ以上仮説が思いつかない、検証できるデータがないなどで行き詰まるパターンです。

そのような場合はなかなか悩ましいかと思いますが、徒に時間や人のリソースをかけるよりもどこかの段階で諦めるのも選択肢のひとつです。

ただそのときの対応や知見を蓄積・共有したり、新たなデータの取得に取り組むなどなるべくなら次に活かせることにも目を向けたいですね。

アンケート設計のやり方

データを収集するやり方のひとつにアンケートがあります。

調査会社を通じたモニターや自社の会員等に質問をすることで、行動履歴ではわからない顧客のインサイトなどのデータを集めることが可能です。

ただし、裏付けのあるものではないため、嘘や適当に答えた回答データも混ざってしまうので信頼度はやや下がります。

客観的な設計

アンケートで難しいのは、客観的な設計です。

質問の仕方や選択肢のチョイスによっては、回答をある程度誘導してしまう恐れがあります。

アンケートにはある程度恣意的なデータを集めるために実施されるものもありますが、その類のものでは正に意図的にそうした設計が行われます。

しかし調査目的で行う場合でも、客観的な質問や選択肢を作ることができずに、意図せず偏りを生んでしまうこともよくあります。

例えば以下は回答者が答えに窮する可能性があり、結局「その他」や無難な選択肢に流れてしまいやすくなります。

・ひとつの質問に複数の論点がある
・選択肢に漏れがある

また以下のように回答者に負荷を強いると、適当な回答をされやすくなったり途中離脱されやすくなります。

・質問文が長くてわかりにくい
・選択肢が多い
・選択肢に似たものが複数あり迷う

意図せず回答を誘導してしまう情報を載せてしまうこともあります。

・補足情報などに情報の一側面のみしか入っていない
・補足情報などに意見や見解などが入っている
・選択肢のバランスが悪い（出題者の好ましい選択肢が多いなど）

尺度を問う質問でも選択肢の表現によっては偏ってしまう場合もあります。

例えば「満足したかどうか？」は総合的な印象を問うものですが、「役に立ったか？」とか「ためになったか？」だと何かひとつでもそう感じるものがあれば肯定の回答が得られやすくなります。（テーマ等にもよるので全てのケースで当てはまるわけでもないですが）

他にも選択肢が「満足・やや満足・普通」とした場合と「大変満足・満足・どちらともいえない」とした場合はおそらく同じ偏りにはならないでしょう。

少なくとも別のアンケート結果と比較するのであれば表現は統一する必要がありますし、本来聞きたいことは満足度なのか何なのかは予めきちんと検討した上で選択肢を作りたいものです。

深堀りの設計

アンケートでは普段のデータではわからないデータを集める折角の機会ということで、「なぜそう思うのか」や「なぜそう行動するのか」の理由を調査することをよくやります。

しかし、回答者に聞けば答えが出るだろうと気楽に思われているのか、あまりきちんと仮説を立てて選択肢を用意したり、直接的な質問しかしていないような設計のアンケートも多く、おそらく集計してもその結果を活かすことなく終わるというパターンも多いようです。

例：商品Xを購入しない理由を次からお教え下さい

１．価格が高いから　
２．品質が低いから　
３．好きなブランドでないから　
４．その他（　　）

上記の質問にて仮に1の回答が最も多く「商品Xの弱みは価格の高さである」ということがわかったとして何に活かせるでしょうか？

まず価格が問題だとしてもアンケート結果から単純に値段を下げられるのか？という問題があります。

さらに、価格を下げることで同時に品質も下げても良いのか、品質を維持して価格を下げるならいくらならば良いのか、など結局悩みは解決されずに次の行動に起こすこともできないのであれば、「元々聞く必要のない質問」なのかもしれません。

そもそも価格はアンケートで聞くまでもなく競合商品と比較すればわかります。もし顧客が商品Xの価格が高いと感じているならば、同価格の競合商品よりも機能や量などの面でコストパフォーマンスが低いと感じているのか、付加価値（低価格の競合商品にない機能等）があまり評価されていないかどちらかでしょう。

質問も単純に「価格が高いかどうか」を問うのではなく例えば各機能の要不要などを聞けば、不要な機能を外してその分価格を下げるとか機能別に商品を分けることで競争力を上げることも可能かもしれません。

他の選択肢の「品質」や「ブランド」もただそれだけを購入しない理由として回答されても如何ともしがたいのは最初から自明なので、そのような質問をしても無駄に終わる可能性が高いでしょう。

ひとつの質問で大雑把な理由を聞くのではなく、知りたいこと／知って意味のあることをあらかじめきちんと整理してひとつひとつ問うのが良いかと思います。

また回答者の「購入しない理由」もひとつとは限りませんし、複数の選択肢を選べるようにしてもそれぞれ重要度が異なる可能性もあります。

さらに選択肢が多くなると上記でも述べたように回答者の読解の負荷が高くなり、回答の質が下がるかもしれません。（個人的には尺度以外の選択肢は「はい／いいえ／（どちらでもない）」の二択ないしは三択がベストかと思ってます）

そういった意味でも「理由」を問う質問のように選択肢が多くなりそうな質問は、分解や分岐によって複数の質問に分けて少ない選択肢になるように設計したほうがよい場合もあります。

例えば先ほどの商品Xの非購入理由の調査であれば、

・購入したことがあるか／ないか

・機能Aは必要と思うか／そうでないか（その他機能も同様の質問を行う）

・機能Aの品質は同価格帯の競合商品と比べて高いと思うか／低いと思うか

・商品Xのネーミングは購入に影響するか／しないか／わからないか

・商品Xのデザインは購入に影響するか／しないか／わからないか

・商品XのCMは購入に影響するか／しないか／わからない（見てない）か

・購入に影響すると回答したものの中でも最も影響の高いものは何か

・今後購入したいと思うか／思わないか／わからないか

などなど、とりあえずいくつか思いついたものをざっと挙げてみました。

他にも商品Xの認知状況の確認や購入経験者ならではの不満なども聞けると、販促手法や商品のユーザビリティにおける課題が見つかるかもしれませんね。

ちなみにインタビューなどでもいきなり核心の質問やオープンクエスチョン（どう思うか？のようにYes/Noで簡単に答えられない質問）をするということはあまりなく、最初にアイスブレイクを入れたり、簡単な質問から始めて段階的に深堀りした質問を重ねていくほうが主流かと思います。

アンケートの回答者もそもそも質問内容（考えや行動の理由）を常日頃から考えていて、いきなり聞かれてもパッと答えられる状態ということはあまりないので、ある程度考えを整理するためのステップ等があった方が回答の質も上がるのではないでしょうか。

データアナリストに必要なコンサル系スキル

データアナリストには最低限データの処理スキルが必要になります。

企業の分析環境にもよりますが、大体はSQLやSAS／SPSSといったツールなどで自由自在にデータの抽出・集計・加工などができることが求められます。

しかし、それだけで十分かというとそうでもありません。

クライアントからどういったデータが必要なのか伝えられる際、そのアウトプットイメージはあまり具体的でなく抽象的なものが多いです。

要件があいまいだとデータ処理に落とし込めないので、まず要件定義をきちんと行えるスキルも必要になります。

例えば「先週のサービスAの顧客数を出してくれ」としか言われなかった場合、1週間の総計を出すのか、1週間分の日別のデータを出すのか、またサービスAの顧客数というのも全体の総計だけでよいのか店舗別や性年代別などのように何らかの内訳も必要なのかなどデータの粒度が不明です。仮に総計のみを出すと、追加で××別にも見てみたいと再依頼されて手戻りが発生してしまう可能性も高いです。

また顧客数そのものについても、のべ客数が必要なのか、ユニーク顧客数が必要なのか（DAUなのか、WAUなのか、現時点でのMAUなのか）、あるいはその両方が必要なのかも確認しておきたいところです。

さらに顧客の定義についても誤解が生じる可能性があります。新規獲得した顧客のことを指しているのか、サービス利用のあったアクティブな顧客を指しているのか、また仮登録などの見込み顧客は含めるのかなど、定義があいまいだとクライアントの求めるデータとは異なる値を集計してしまうことになりかねません。

データを出す場合は、メジャー（指標）とディメンション（切り口）が何かをきちんと定義・確認するのが基本でかつ重要なところです。

【指標】顧客数とは？	【指標】顧客とは？	【切り口】期間の粒度は？	【切り口】顧客の粒度は？
のべ客数？ ユニーク顧客数？(集約単位は？) その両方？	新規顧客？ アクティブ顧客？ 見込み顧客は？	期間総計のみ？ 日別？	全体のみ？ 性年代別？ 店舗別？

最終的にはデータの検索条件にまで落とし込みたいところですが、クライアントはデータアナリストと違ってデータの仕様にまで必ずしも詳しいわけではないので、お互いの認識が合わせられるレベルまで何らかの共通ドキュメントを用意したり、あるいはアナリストが適切に翻訳したりすることも必要になってきます。

そして、できればさらに依頼されたデータがそもそも本当にクライアントの必要としているものかを見極められるスキルも欲しいところです。

言われたデータを出せばクライアントの要求を満たしたことになるのでそこで対応完了としても通常は問題ありませんが、それでクライアントの課題が解決しないということは非常によくあります。

先ほどの「先週のサービスAの顧客数を出してくれ」の例でいうと、実は本当にクライアントが知りたいのは「先週サービスAのプロモーションを実施したのでその効果が知りたい」とか、「先週トラブルがあって解約する顧客が増えたかもしれない。実際どうだったか知りたい」だったとすると、単純に先週の顧客数を出すだけではおそらく足りない可能性が高いです。

通常クライアントはデータアナリストを「課題解決してくれるコンサルタント」とは認識していません。多くは「データ分析してくれる人（単なる抽出・集計含む）」あるいは「データを出してくれる人」と見ています。

よってクライアントは自らの目的や課題解決のためにはおそらくこういうデータがあれば良いだろうと「自分で見積もって」、それをアナリストに抽出するよう依頼してくるというのがよくあるパターンです。

そのため彼らが毎度依頼の背景や目的、それに「なぜそのデータが必要と思ったのか」など詳細まで語ってくれるとは限りません。

彼らの課題解決につながるデータや分析結果を提供したいと思うなら、その部分を省略するわけにはいきません。クライアントが相談してくれないならこちらから聞き出すなどしていく必要があります。

ただ、いきなり「その依頼の目的は何でしょうか？なんのために必要なのか背景を説明して下さい（そうしないと対応しませんよ）」などと言うとクライアントも身構えてしまうので、クライアントの背景や課題をある程度推察してこちらから提案してみたり、依頼内容を確認する中でさりげなく背景や目的を聞き出したりするようなヒアリングスキルもあると良いですね。

こうしたスキルは場数を踏んで失敗しながら学んでいくのが結局は近道なのでなかなか簡単に身につくものでもないかもしれませんが、とりあえずお手軽なやり方として一つ紹介しておくと、私はクライアントには「どんなデータが見たいのか」ではなく「何が知りたいのか」という質問をよくします。すると背景などについても向こうから話してくれることが多いのでおすすめです。

またクライアントが本当に知りたいことは「良いのか悪いのか知りたい」「次にどうすれば良いのか知りたい」「原因が知りたい」などのように大体のところシンプルなものに帰着します。しかしシンプルゆえに詳細まで細かく具体化されていなくて抽象的でもあります。

その回答も関連しそうなデータをたくさん提示してレポート数十枚などになるのは大体NGです。簡潔にまとめないとそもそも読んでもらえませんし、理解もしてもらえません。シンプルな結論にまとめるには、それをデータでどう正しくかつ簡潔に表現できるかといったデザインスキルも必要になります。

先ほどの「先週サービスAのプロモーションを実施したのでその効果が知りたい」だと、平常時の週（先々週など）の顧客数と比較した伸び率を出すなどしたほうが良さそうです。プロモーション未実施の顧客群のデータがとれるならその顧客群の変動率と比較するとより良いです。また今後の実施についても検討したいならば、プラスで別プロモーション時期や別サービスとの比較も判断に必要でしょう。

ちなみにサービスの商品設計において特に性年代別などの分類が考慮されていないならば、性年代別に分けてみる必要はありません。must have のデータ（必要なデータ）とnice to haveのデータ（なくても良いデータ）をきちんと見極めることも簡潔にまとめるためには必要になります。

また「先週トラブルがあって解約する顧客が増えたかもしれない。実際どうだったか知りたい」だと、解約顧客数を解約理由別に集計してトラブルによる数とそうでない数をきちんと区別できるように集計した方が良いですね。ついでに過去と比べてそれらが顕著に増えたかどうかも明らかにするとトラブル影響が明確に把握できそうです。またこうしたトラブルが今後も起こりうるものであれば、事前に対策やフォローがとれるように影響を受けやすい顧客セグメントを分析しておくのも良いかと思います。

正しいデザイン	シンプルなデザイン
適切な比較対象の選定・設定 ロジカルな展開の組み立て	must have/nice to haveの見極め 表現力、構成力、伝達力

他にもクライアント等との関係構築力や交渉力、チームワークのスキル、プロジェクト管理のスキルなど色々とありますが、きりがないのでひとまずここら辺までで終了します。

データアナリストがコンサル系のスキルも身に着けて実績を積むと、クライアントから単なる「データを出してくれる人」ではなく「課題を解決してくれるパートナー」と見なしてもらえるようになってきます。データや分析結果をクライアントの意思決定にきちんと活用してもらいたい、ビジネスに貢献できるデータ分析をやりたいという人にはこうしたスキルも必要になってくるのではないでしょうか。

データ集計者のキャリア

データ活用があまり進んでいない企業や組織では、「とりあえずデータを見るだけ」業務が多量に発生してしまいがちです。

そうした企業ではデータ活用のための適切なKPI設計を行える人も、そのために必要なデータの収集や管理を行う人もほとんどおらず、逆に「とりあえずデータを見たがる人」と「そのためのデータ集計を行う作業者」だけになっているというケースが多いようです。

もし前者の業務ができる人が入社したとしても、それらに取り組む以前にデータを見るだけ業務の対応で忙殺されるなどして嫌気をさして再び転職、結果として定着されずじまいなのではないでしょうか。

別途こうした課題を解決するというニーズはあるのでそうしたビジネスのマーケットはあるのですがそれはさておき、そうした企業にいるとデータアナリストの肩書があってもただ言われたデータを抽出するだけのデータ集計者として終ってしまう可能性が高くなります。

特にデータアナリストと名乗っている人であれば、自分たちの仕事はデータを分析することで、依頼者の代わりにデータを集計するだけの作業者ではないという思いから、そうした仕事を嫌がって避けるか、嫌々ながら取り組んでいるという人が散見されます。

今はまだデータを見るだけ業務もたくさんありますが、それに付加価値が伴わないと今後は縮小されていくかそれにかける費用が削減されていくのも想像に難くないでしょう。そしてそれはデータ集計者の収入にも跳ね返ってくることでしょう。

またそれなりの企業であればデータの仕様やツールなど環境面ではある程度整備されているので、数か月ほどかけてそれらに習熟すれば若手でも早期にデータ集計・抽出の業務において活躍することは可能です。（ある程度センスも必要ですが）

つまり多少経験あるアナリストであっても、データ集計・抽出だけの業務しかしていないと評価も上がりづらくなりますし、同じことができる人が増えてくると他との差別化も難しくなります。いずれ物足りなさやキャリアの先行きに不安を感じてきてもおかしくはありません。

必ずしも皆が皆ステップアップしていけるキャリアが用意されているわけではないのはどんな職業でも同じだと思いますが、データアナリストにおいては特にこうしたデータ集計業務に慣れてきたころがその先のキャリアにおいて結構大きな分水嶺になっている気がします。

そのころにはこの先行き詰まってしまいそうだからと転職やジョブチェンジを考える人も増えてきます。

ただ、安易な転職はあまりおすすめしません。ビッグデータがあってもデータ活用が進んでいない企業は意外とたくさんあるからです。環境を理由に転職しても、転職先がまた同じような環境であれば再び同じようなことで悩みを抱えることになるでしょう。

また現状のデータ集計・抽出業務に物足りなさを感じるようになったアナリストには、次に若手アナリストやエンジニアとの差別化につながるのではないかと「高度な分析」を身に着けることや「分析力の向上」を目指す人も時々います。

ちなみに「高度な分析」とか「分析力」って何？と思われるでしょうが、私もそういう言葉をよく使う人に聞いてみてもどうも要領を得ないことが多いのですが、どうやらメインは機械学習のことを指していたようでした。

「高度な分析」や「分析力の向上」とやらはさておき、何らかの差別化スキルを身に着けること自体は良いことでしょう。機械学習も昨今のAIブームや応用性の高さからニーズは高いですね。ただ、多くはチュートリアルを動かすか、セミナーや書籍・Web等で基本的な内容を学習したりすること止まりで、実業務に活かせるレベルにまで到達できる人はなかなか多くはいないようです。（当然ながら専門家と呼ばれるレベルにまで到達できる人も少数です）

実業務に活かすには業務やサービスの企画・設計・調整方面のスキルも必要になってくるので、アナリスト皆が向いているとは言い難いのでしょう。そうした分野が苦手な人は、既に実業務に機械学習を活用している企業に転職するか、（機械学習）エンジニアにジョブチェンジすることを目指す人もいます。

またスキル面で差別化するといっても、当然ニッチなスキルであれば何でも良いわけではなく、ビジネス的な付加価値につながらないとなかなか周りからは評価されません。（そういう意味でも「高度な分析」とか「分析力の向上」とか定義や理由があいまいなものが必要と思いこんだりするのは危険です）

特にそうした面を強く意識する人は、依頼者の意思決定により役立つデータを提供できるよう、彼らの業務や戦略を理解し、マクロなものからミクロのものまでKPIの設計をこなせるようになることにより注力します。さらに彼らの本来の課題を明らかにし解決方針を提示するなどコンサルのようなことまでする人もいます。しかしこれらも元々のデータハンドリングのスキルとは異なる類のものなので、データハンドリング経験を積めばできるようになるものでもなく、ハードルはやはり低くはないかと思います。

また技術者寄りの志向の方には、データ活用を支えるエンジニア方面にシフトする人もいます。どんな人でも気軽に求めるデータにアクセスできるようにレポート環境を整備したり、各種業務におけるログやデータを効率的に収集・管理できるように業務（あるいはその一部）をアプリケーション化したり、多量のデータを取り扱えるようにハイパフォーマンスなDWH環境を構築したり、複雑なデータ処理をしなくても良いように汎用性のあるデータマートを開発したりしています。

今は多くの企業でデータ活用に取り組んでいるので、こうしたニーズはたくさんありますし、そのためのツールやソフトウェアなども多くのベンダーから新たに開発されるなど技術的な革新も進んでおり、技術志向の人にとっても刺激を受ける機会も多くあることでしょう。

いずれにせよ、データハンドリングの経験をある程度積んだ後にもキャリアアップの道は開けていると思います。

ただハードルはその分高くなっていきますし、新たなスキルや経験を積むことも必要になってくるので簡単ではないでしょう。もちろん割り切ってデータ集計者としてやっていく人もいますし、その道も否定されるべきものではありません。ただ、嫌々ながら消極的にデータ集計業務をこなし続けていくくらいならあまりやりがいも得られないと思うので、少しでもクライアントの満足度を上げるにはどうしたら良いか、集計業務自体をより正確により効率的にするにはどうしたら良いかかなどを考えながら取り組むと道が開けてくる可能性もあるかもしれません。私も道半ばですし、行き詰まり感を感じることが全くないわけではないので引き続き色々模索していこうと思ってます。