データ分析を始める時に必要なのはデータサイエンティストのような専門家ではなく「アナリティクスディレクター」である

データ分析が盛り上がっている今だからこそ考えなければならない

以前データ分析組織に必要なのはデータサイエンティストではなくデータ分析プロセスをマネジメントする人というのを書いたが、その後の学びや「アナリティクスディレクター」を名付けたこともあり、さらにバージョンアップ版を今回書いてみる。

さて、「データ分析」の仕事や求人はビックデータ、データサイエンティスト、人工知能に機械学習と2010年代になって急激に増えた。ところが、うまくデータ分析を競争力にできている企業というのは少ない。

データ分析人材の採用がどれだけうまくいっていないかについては日本のデータ分析における最大のボトルネックは「採用する企業側の致命的なデータ分析リテラシーの低さ」であるにまとめたが、もともとほとんどいない上に採用もできなければデータ分析はうまく回らないし、ましてや組織がうまくいくはずがない。

データ分析組織の立ち上げに失敗している話は結構見聞きする。立ち上げに失敗するとその遅れを取り戻すのにまた時間がかかるし、やり方が悪いのに「データ分析は使えない」と組織を解散してしまう話もまれではない。

そこで今回のテーマは「データ分析を始める時に必要なのはどんな人か」という問題への答えの1つとして、「データ分析を始める時に必要なのはアナリティクスディレクター」である、というのが主張なのだが、そこに至るまでの考察を順を追って書いていくことにしよう。

分析の実務ができる人がいないと話が進まない

まず最初に、どんなに優秀なマネジメントがいても実際に手を動かす人がいないのでは意味がない。なので当然ながらデータ分析の実務ができることは必要だ。データ分析は内製化しなければならないので、実務を外注するのは外注をコントロールできる場合に限るべきだ。

ここでデータ分析をするのだからデータ分析の経験者を連れてくればいい、と考えるのは自然であるが、とはいえ高度なことを知っています、プログラミングが得意ですという人を連れてくると失敗するし、そしてこの手の話が非常に多い。

これは「データ分析」と聞くと「プログラミングを」「マニアックな人が」「閉じこもって何をしているかわからない」と考える人が多いからとりあえずそういう人を連れてくれば良いと発想するからだろうが、まずその勘違いを改めないことにはデータ分析はうまくいかない。

さて、その勘違いが無くなったとして肝心のデータ分析の実務であるが、技術的にはExcelやSQLでデータを集計することができれば結構いろいろなことに対応できるし、そこにPythonなどでデータハンドリングができれば効率が良くなるのでできればなおよしである。

あとパワポで資料を作り、場合によっては施策も行ったりと一通りのことはできる。後はその企業の環境に応じて足りない部分を埋めていけば最初はなんとかなるだろう。

今度は専門家からすると実に退屈でレベルの低い話をしていると思うだろうし、技術という面においてそれは正しい。ここに出てきた技術の話だけなら新卒でも1年あればかなりカバーできる。

それでもかまわないのは、特に最初は他にやることがたくさんあるから「分析」だけに集中できないのがデータ分析だからだ。専門的なことに時間を費やす余裕はないのである。

後々のことを考えてそこにちょっとだけ高度なことを加えておくことで仕事の幅を広げたいし、できるに越したことはないのはそうなのだがそれはもうちょっと人が増えてからでも良い気はする。

データ分析プロセスを動かすことができる人

「データ分析」といってもデータを渡せばあとはうまいように誰かがやってくれるとわけもない。データ分析は目的の決定から始まる一連のプロセスであり、関係者は全員データ分析プロセスの概要を理解していなければプロセスはうまく回らない。

このデータ分析プロセスは、目的を決めてから情報・データを収集して分析・洞察し、結果を伝達した後に意思決定と施策の実行を行う一連のプロセスであり、このプロセスをきちんと回せるかどうかが実務上の鍵となる。

データがあってそれを「分析」する人は結構いる。専門家はもちろんのこと大学や独学で学んでいる人はこの部分だけを集中的に身に着けている場合が多いのだが、大学や独学でデータ分析の勉強をしただけだと実務で使えない理由に書いたように「データ分析」にはそれ以外にもやることがたくさんあるので「分析」だけではプロセスを動かせない。

その中でも筆頭に挙げられるのがコミュニケーションだ。経営者から営業まで社内の様々な人々からの依頼を聞き、情報・データ分析の言葉に変換し、できることと納期の調整や不可能な依頼を断ることまでが範囲の要求フェーズと、分析・洞察の後に相手の性格や好みを考えた上で結果を伝える伝達フェーズである。

さらに状況によってはデータ分析者としての役割を飛び出して「目的の決定」に関与したり、「意思決定」や施策の「実行」についても自ら行うこともある。そしてこれらは「分析」とはまったく違うスキルであり、「分析すること」とは別に考えなければならない。

しかも、これらの話はデータや環境が一通りそろって実際に依頼を受ける段階になってから求められるのであり、そこまでたどり着くまでにはまだまだ色々なハードルが存在する。

現状の確認とニーズのくみ取り

データ分析プロセスについて考える前に、まず社内の各人が現状何をしていて、これから何が求められているのかをくみ取ることが挙げられる。これは具体的な依頼によりデータ分析プロセスが動く以前の話だ。

もちろん会社の方針としてはこんなことをして欲しいと求められることが事前に提示されていなければいけないが、ここでくみ取るのは個別の部署や人のニ-ズのこと。どこで誰がどんなことを求めているかを聞き、求めていないないのは必要ないからかリテラシー不足なのかを確かめ、求められている以上のことが提案できるのであれば行う。

個別の担当者が分析を行っている場合は、データ分析担当者としてそれらをまず引き受けることも検討すべきだろう。

専門家は自分がやれること、やりたいことを優先しすぎてここをすっ飛ばしてしまい孤立したりするのだが、何度も書いているように事前にきちんと説明している場合を除き、専門家には専門家が力を発揮できる場を会社が用意するべきであり、専門家に責任を問うのは筋違いだ。

データの整理

データ分析の話では前処理が話題に上るが、その前処理を行うためにはデータがないと話にならない。なので次に、どこにどんなデータがあるのかを把握するのが始まりとして、それで全てのデータがすぐに使えるようになっていることもないので、次にそのデータを使えるようにしなければならない。

データは入手できる状態にあるか?

たいした量でもないのに毎回ベンダーに依頼しては1週間の納期とそれなりの金額を持っていかれるのでは分析業務に支障をきたす。そのデータは使わないとできればよいが、一番肝心なログやIDPOSデータがその状態だったら大変だ。仕組みを変えるにしても時間がかかるため長期的にだけでなく当面の対応策を考えないといけない

データはきちんと取れているか?

データは取れているはずだけど、ちゃんと調べたことが無くふたを開けてみたらちゃんと取れていなかったなら取れるようにしないといけないし、一応取れていても形がおかしければ直さなければならない。値にカンマが入っているcsvとか…。

データは使えるか?

入手はできる、データもきちんととれている、でもそれが数千個csvファイルに分かれ、しかも期間によって微妙に形式が違う状態だったとしたらそのままで使おうというのは無理がある。なので使えるかどうかを確かめ、使えないならばつかえるようにしないとならない。

足りないデータを収集する

さしあたりやろうと思っていることに必要なデータ、あればこんなこともできるのにというデータなど無ければ収集のプランを考え、その後どう管理して保管するかまでエンジニアと協力しながら仕組みを作っていく。新しい要望は常にあるのでこれは最初に限らない。

いわゆるデータマネジメントで、職種としてはデータエンジニアなどと呼ばれることもあるが、分析側が分析用にエンジニアと協力しながら整理していく。これもエンジニアリングなので親和性はあるかもしれないがあくまでも「分析」とは別。

よりデータを使いやすくする仕組みづくり

また、データをより使いやすくするためにマートを設計したり、KPIモニタリングのためにダッシュボードを設計したり作ったりすることもある。やらなくても仕事はできるが、できることは仕組み化することで生産性を上げて考えることに集中するためには必要なことだ。

ツールの選定や環境の整備

どんなツールを使うのかも考えるべきことだ。本人の使い勝手はもちろん、コストや組織が拡大した時のことも想像し、かつ予算確保のために経営陣の説得という仕事が待っている。これは最初から注力する話ではないかもしれないが、かといってまったく忘れるということもできない。

また、インフラ環境整備はエンジニアの領域であるが、プログラミングができる=エンジアリングが出来ると思っている人も少なくないため、機械学習エンジニアなどはこの役割を兼任させられることもある。

分析を中心に活動している人からすると全くの畑違いということもあるので、その場合は自分でやらずにエンジニアに協力を要請するのが望ましい。

フローの整備

どこからどんな依頼が入っていつまでにやればいいとか、依頼の受け方をどうするかなどは分析担当者が1人なら気にしなくてもなんとかなるが、将来の組織の拡大を見越して、また、あまり自由に依頼を受けていると後になってルールを決めたら窮屈だと思われたりするのでだったら最初からある程度の流れを作っておくと良いだろう。忙しいと忘れがちになるが、ボディーブローのごとく後で効いてくる。

提案や実行

「どんな分析をしたらいいのか」の提案、さらに分析に基づいて「次にどうしたら良いか」の施策を考え、さらに実行にも関わることを求められることは多い。中小企業であればなおさらだ。もはや分析ですらなくマーケターやコンサルタントの仕事であるが、それでも会社は要求してくる。

ビジネスにおいて企画と情報を明確に切り分けること、分けないとしたらどう関わるかといった問題は議論していかなければならないが、特にこれからデータ分析を始めようとしている企業では「分析によって情報・データを提供する」ことだけしかやらないと、「分析しかしない口だけな奴」となる危険が非常に高い。

もちろん最初の段階できちんと分担を確認しておくことは重要だが、この分担について理解がある企業ならとっくにデータ分析を行っているはずなので、あまり期待はしない方がよさそうだ。

1人では全部できないので最初から分担が理想

ざっと分析とそれ以外にやらなければいけないことを見てきたが、1人で全部やるにはスキルも違えば仕事量も多すぎる。なので分析を始める時には理想としては「分析ができる」「データ分析とビジネスの間を翻訳する」「分析とエンジニアリングができる」「コンサル出身でKPI設計ができる」「分析ができるマーケター」など複数の人がいて分担するのが理想である、ということに反対する人はいないと思う。

とはいえ得体のしれない「データ分析」にいきなり大量のリソースを投入することが難しいのであれば、優先順位を付けて選ばないといけない。では、最初の1人にはどんな人がいればいいだろうか。

データサイエンティストや機械学習エンジニアのような高度な技術を持つ専門家だけでは機能するとは限らない

データサイエンティストや機械学習エンジニアのような高度な技術を持つ専門家を環境も何も整っていないところに連れてきても機能しないのは、これからレストランを始めようとするのにシェフだけ連れてきて、さぁ経営方針を考えなさい、内装どうするか決めなさい、オペレーションを考えて人の採用をしなさいなど料理以外のことも任せようとするのと同じである。なお、現在多くの企業で起きているのはシェフどころか料理未経験者に全面的に丸投げという状況だがそれは論外だ。

もちろん、シェフでも経営や運営をやりたい人はいるだろう。しかしそれは専門家のうちの全員ではなくむしろ少数派だろうし、だったら最初から経営をやりたい人を連れてくるべきだ。なので専門スキルは考慮外として良い。ただし、あくまでも最初の段階においてということは絶対に忘れないように。

ある特殊な場合ならエンジニアでも良いが、その状況は少ない。

次にエンジニアだが、WebサービスであればレコメンデーションやSEOのようにエンジニアリングの内部で解決できることもあるのでその場合はエンジニアでも良いかもしれない。独立して考え、自分で作って実行することまでできてしまう人であれば放置してもよいぐらいだ(が、そういう人は独立出来てしまうのであまりあてにするのもどうかとは思う)。

しかし、言い換えればWebで完結しないような場合、つまりほとんどの企業やサービスではデータ分析は営業、コンサルタント、マーケターのようなフロント側と一緒に進めていくことになるが、エンジニアはマーケティングなどの分析の素養は少ない上にご存知のように大抵は仲が良くない。

仲が良くないのに情報の提供をしても無視されるし、特に都合の悪いことなどうまく伝えられるはずもない。受け取る側が悪いのはそうなのだが、それで話が終わってしまうのでは意味がない。なので、フロント側ともバックエンド側ともコミュニケーションが取れる人が欲しくなる。

データアナリストの場合を考える前に、役割の名称についての再考

そう考えると、データ分析の経験者といっても専門的なことよりも広く浅く課題設定、コミュニケーション、分析、プレゼン、施策の実行を広く経験しており、その流れの中で営業やコンサルといったフロント側からエンジニアのようなバックエンド側両方とのコミュニケーションを行っている人の方が機能するだろう。肩書としてはデータアナリスト(+コンサルタント)あたりが多そうだ。

では「データアナリスト」を連れてくればいいのかというとまた違う。「営業 兼 コンサルタント 兼 マーケティング 兼 カスタマーサポート」という肩書を付けたところで全て行えるわけもないが、それぞれ別の役割だというのは名前がついているからか認識されやすい。しかしデータ分析においては「データ分析をする人」以外にうまい言葉がなく、「営業」も「コンサルタント」も「マーケティング」も「カスタマーサポート」も全部まとめて「営業」と表記されているような状態だ。

だから「データアナリスト」という言葉に飛びつくのは「営業」を雇えば「マーケティング」や「カスタマーサポート」もできる、と言うのと同じになってしまう。実態を把握するために何をしているかで分けないといけないのだが、名前すらないと分けられない。

そこで、役割には名前を付けなければならない。一方であまり細かく職種を分けすぎても混乱するので、まずは「分析する」こととそれ以外を区別することから始めるのが良いだろうと考え、後者に「アナリティクスディレクター」という名前を付けた。つまりアナリティクスディレクターの役割とは大まかに言えば

  • データ分析プロセスの各フェーズにおける問題に対処する
  • 様々な部署や人との「つなぎ役」になる
  • リソース配分を決める
  • 適切な納期に適切な内容を届ける

といった役割だ。詳細は「アナリティクスディレクター」とは「データ分析プロセスのマネジメントを行い、様々な部署や人とのつなぎ役となる役割」であるに書いた。

こうして名前を付けると、データサイエンティスト・データアナリストの仕事はあくまでも「分析すること」であり、それ以外は「アナリティクスディレクター」の役割であるといったことが言えるようになる。

これでようやく結論が言える。それは「組織としてデータ分析を始める時に必要なのはアナリティクスディレクターである」だ。

アナリティクスディレクターに全部押し付けてはいけない

アナリティクスディレクターを置くのは今までうまく行かなかった要因をなくすことであり、始まりに過ぎない。アナリティクスディレクターの力量が足りなければうまく行かないのはもちろん、アナリティクスディレクターを雇えばすべてうまく行くというわけもなく、結局のところは社内にデータ分析の文化を作るのに一番良いのは「社長が自らの意思決定にデータ分析を活用すること」なのでこれがついてこないと相当に遠回りになる。

逆に経営陣の後押しがあれば心強い。『分析力を武器とする企業』ではこれを「ファストパス」と呼んでいるが、早い遅いで表現できるレベルではないのではというのが個人的な思いだ。

できるだけ早く組織を強化するのが望ましいが、そのためにはアナリティクスディレクターが結果を出さねばならず、だとしたら人を増やさないと・・・と堂々巡りになってしまうのでここで止めておくが、現実的にはアナリティクスディレクターが結果を残すことを先にしないと話が動かない。だからといって会社側がアナリティクスディレクターに責任を押し付けることはしてはならない。

アナリティクスディレクターは始まりに過ぎない

「アナリティクスディレクターがいればあとは全部やってくれるんでしょ」では「データサイエンティストがいれば(略」と同じであって論外だし、たとえアナリティクスディレクターが出来る人を連れてきても1人で出来ることはたかが知れている。繰り返しになるが、アナリティクスディレクターを置くことは始まりに過ぎない。

また、いくらアナリティクスディレクターを置くべきだといったところでどうやって探すのかという問題が残っている。もちろんアナリティクスディレクターをやるにはデータ分析の実務経験なしにうまくできるとは思えないので、データアナリストやマーケターの中から素養のあるをどうやって見極めるか、これから育成するならどうするかかという話になってくる。

そこから先は未知数であるが、こうしたらいいのではないかという案はいくつかあるのでこれは次に話をしよう。