データアナリストには最低限データの処理スキルが必要になります。
企業の分析環境にもよりますが、大体はSQLやSAS／SPSSといったツールなどで自由自在にデータの抽出・集計・加工などができることが求められます。
しかし、それだけで十分かというとそうでもありません。
クライアントからどういったデータが必要なのか伝えられる際、そのアウトプットイメージはあまり具体的でなく抽象的なものが多いです。
要件があいまいだとデータ処理に落とし込めないので、まず要件定義をきちんと行えるスキルも必要になります。
例えば「先週のサービスAの顧客数を出してくれ」としか言われなかった場合、1週間の総計を出すのか、1週間分の日別のデータを出すのか、またサービスAの顧客数というのも全体の総計だけでよいのか店舗別や性年代別などのように何らかの内訳も必要なのかなどデータの粒度が不明です。仮に総計のみを出すと、追加で××別にも見てみたいと再依頼されて手戻りが発生してしまう可能性も高いです。
また顧客数そのものについても、のべ客数が必要なのか、ユニーク顧客数が必要なのか（DAUなのか、WAUなのか、現時点でのMAUなのか）、あるいはその両方が必要なのかも確認しておきたいところです。
さらに顧客の定義についても誤解が生じる可能性があります。新規獲得した顧客のことを指しているのか、サービス利用のあったアクティブな顧客を指しているのか、また仮登録などの見込み顧客は含めるのかなど、定義があいまいだとクライアントの求めるデータとは異なる値を集計してしまうことになりかねません。
データを出す場合は、メジャー（指標）とディメンション（切り口）が何かをきちんと定義・確認するのが基本でかつ重要なところです。
| 【指標】顧客数とは？ | 【指標】顧客とは？ | 【切り口】期間の粒度は？ | 【切り口】顧客の粒度は？ |
|---|---|---|---|
| のべ客数？ ユニーク顧客数？(集約単位は？) その両方？ |
新規顧客？ アクティブ顧客？ 見込み顧客は？ |
期間総計のみ？ 日別？ |
全体のみ？ 性年代別？ 店舗別？ |
最終的にはデータの検索条件にまで落とし込みたいところですが、クライアントはデータアナリストと違ってデータの仕様にまで必ずしも詳しいわけではないので、お互いの認識が合わせられるレベルまで何らかの共通ドキュメントを用意したり、あるいはアナリストが適切に翻訳したりすることも必要になってきます。
そして、できればさらに依頼されたデータがそもそも本当にクライアントの必要としているものかを見極められるスキルも欲しいところです。
言われたデータを出せばクライアントの要求を満たしたことになるのでそこで対応完了としても通常は問題ありませんが、それでクライアントの課題が解決しないということは非常によくあります。
先ほどの「先週のサービスAの顧客数を出してくれ」の例でいうと、実は本当にクライアントが知りたいのは「先週サービスAのプロモーションを実施したのでその効果が知りたい」とか、「先週トラブルがあって解約する顧客が増えたかもしれない。実際どうだったか知りたい」だったとすると、単純に先週の顧客数を出すだけではおそらく足りない可能性が高いです。
通常クライアントはデータアナリストを「課題解決してくれるコンサルタント」とは認識していません。多くは「データ分析してくれる人（単なる抽出・集計含む）」あるいは「データを出してくれる人」と見ています。
よってクライアントは自らの目的や課題解決のためにはおそらくこういうデータがあれば良いだろうと「自分で見積もって」、それをアナリストに抽出するよう依頼してくるというのがよくあるパターンです。
そのため彼らが毎度依頼の背景や目的、それに「なぜそのデータが必要と思ったのか」など詳細まで語ってくれるとは限りません。
彼らの課題解決につながるデータや分析結果を提供したいと思うなら、その部分を省略するわけにはいきません。クライアントが相談してくれないならこちらから聞き出すなどしていく必要があります。
ただ、いきなり「その依頼の目的は何でしょうか？なんのために必要なのか背景を説明して下さい（そうしないと対応しませんよ）」などと言うとクライアントも身構えてしまうので、クライアントの背景や課題をある程度推察してこちらから提案してみたり、依頼内容を確認する中でさりげなく背景や目的を聞き出したりするようなヒアリングスキルもあると良いですね。
こうしたスキルは場数を踏んで失敗しながら学んでいくのが結局は近道なのでなかなか簡単に身につくものでもないかもしれませんが、とりあえずお手軽なやり方として一つ紹介しておくと、私はクライアントには「どんなデータが見たいのか」ではなく「何が知りたいのか」という質問をよくします。すると背景などについても向こうから話してくれることが多いのでおすすめです。
またクライアントが本当に知りたいことは「良いのか悪いのか知りたい」「次にどうすれば良いのか知りたい」「原因が知りたい」などのように大体のところシンプルなものに帰着します。しかしシンプルゆえに詳細まで細かく具体化されていなくて抽象的でもあります。
その回答も関連しそうなデータをたくさん提示してレポート数十枚などになるのは大体NGです。簡潔にまとめないとそもそも読んでもらえませんし、理解もしてもらえません。シンプルな結論にまとめるには、それをデータでどう正しくかつ簡潔に表現できるかといったデザインスキルも必要になります。
先ほどの「先週サービスAのプロモーションを実施したのでその効果が知りたい」だと、平常時の週（先々週など）の顧客数と比較した伸び率を出すなどしたほうが良さそうです。プロモーション未実施の顧客群のデータがとれるならその顧客群の変動率と比較するとより良いです。また今後の実施についても検討したいならば、プラスで別プロモーション時期や別サービスとの比較も判断に必要でしょう。
ちなみにサービスの商品設計において特に性年代別などの分類が考慮されていないならば、性年代別に分けてみる必要はありません。must have のデータ（必要なデータ）とnice to haveのデータ（なくても良いデータ）をきちんと見極めることも簡潔にまとめるためには必要になります。
また「先週トラブルがあって解約する顧客が増えたかもしれない。実際どうだったか知りたい」だと、解約顧客数を解約理由別に集計してトラブルによる数とそうでない数をきちんと区別できるように集計した方が良いですね。ついでに過去と比べてそれらが顕著に増えたかどうかも明らかにするとトラブル影響が明確に把握できそうです。またこうしたトラブルが今後も起こりうるものであれば、事前に対策やフォローがとれるように影響を受けやすい顧客セグメントを分析しておくのも良いかと思います。
| 正しいデザイン | シンプルなデザイン |
|---|---|
| 適切な比較対象の選定・設定 ロジカルな展開の組み立て |
must have/nice to haveの見極め 表現力、構成力、伝達力 |
他にもクライアント等との関係構築力や交渉力、チームワークのスキル、プロジェクト管理のスキルなど色々とありますが、きりがないのでひとまずここら辺までで終了します。
データアナリストがコンサル系のスキルも身に着けて実績を積むと、クライアントから単なる「データを出してくれる人」ではなく「課題を解決してくれるパートナー」と見なしてもらえるようになってきます。データや分析結果をクライアントの意思決定にきちんと活用してもらいたい、ビジネスに貢献できるデータ分析をやりたいという人にはこうしたスキルも必要になってくるのではないでしょうか。
