データサイエンティストの業務
データサイエンティストの業務ってなんだろ
おそらく、データサイエンティストのブログにでもいけば、必ずこのテーマで記事があるんじゃないかというぐらい、ありふれた話題だ。自分も含めて、データサイエンティストがよく自問自答している。データサイエンス業務とは･･･、データサイエンティストとは･･･とかいまさら感が強いテーマだと思うけど、私も自問自答する機会が多くなった。
ひとつの大きな理由は、これってデータサイエンティストの普通にやる仕事なの？って仕事をすることが多分にあるからだ。私が、データサイエンティスト自体を再定義するつもりはないが、データ分析プロジェクトの普通というものが、あまり調べても出てこなかったので、私の経験からまとめたい。
データサイエンティストとは
データサイエンティスト協会が、策定したスキルセットによる定義がもっとも有名だと思う。「ビジネス」、「データサイエンス」、「データエンジニア」の３つの能力を持っている人という定義である。
図１：データサイエンティストに求められるスキルセット
https://www.datascientist.or.jp/common/docs/skillcheck.pdf
データ分析業務で必要となるスキルであることは確かである。求められるスキルであるなら、ベン図の中心だけでよいので、ベン図にする必要もないと思うがなんなんだろこれ。当初の背景を考えると、これでよかったのかも知れないが、この定義だけでデータサイエンティストが定義されることに納得する人は少ない。
TJOさんの記事の最後の部分
tjo.hatenablog.com
榊さんは、自社内でちゃんと定義を持とうよという提言
www.hottolink.co.jp
個人的な感想を延べさせてもらうと、バズワードとなったデータサイエンティストを名乗る人が増えてきて、肩書きだけデータサイエンティストになったコンサルタント、インフラエンジニアやWebアナリストなどが多くいたが、彼らが誰も外れることなくデータサイエンティストと名乗れるように包容力の広い定義になったようなものだ。
データサイエンス業務とは
さて、データサイエンティストにもそれぞれ得意分野と不得意分野があるため、だんだんと役割分担が進み、コンサルや機械学習エンジニアと分化していく（いった）のは必然である。その分化を前提に、データサイエンティストやその周辺職種を再定義してほしいのだけど、当初のデータサインティスト協会ほど勢いがなくなってきたので、少しでも文章に残して、議論が盛り上がることを願うばかりである*1
そこで、データサイエンティスト業務を振り返ってみることにしたい。私が企業に転職したときも、データサイエンティストがどういう流れで業務をこなしているかを探してもあまり見つからなかった。すこし私の経験の下でまとめてみたい。
図：データサイエンティスト業務に関わる主要な区分
まず、大きな括りで重要だと思ったのは、事業会社で内製化された分析に従事する場合、分析ファームで社外の分析案件に従事する場合でそもそも業務は大きく異なる。
- 事業会社所属
社内に存在する顧客データや品質管理データをもとに、自社事業の改善や自動化を試みる。特定データの理解の深さや接する時間が長いため、データサイエンティストとしては、特定ドメインに注力することになり、業務の幅は狭まるが、じっくり分析できる。一方で、データサイエンティストへの理解は会社によってさまざまである。
- 分析ファーム所属
顧客企業へ分析しますよという営業をかけて、分析をする。3か月～6カ月の期間を設けて、提供されたデータを分析する。手元にデータがないので、技術力を社内で醸成していくことが難しく、分析サービスの差別化のためには、ほぼ御用聞きのコンサルと化すか、高い技術力獲得のために投資するかのどちらかしないとまずい印象である。
後者の分析ファーム所属のデータサイエンス業務は、営業、データ精査、分析、報告、成果物、テスト、最終報告である。データ分析が絡むことならデータサイエンティストは何でもできるはずだという幻想*2にとらわれる小さい企業なら、一人が全部やることになるかもしれない*3。データサイエンス業務についても、協会がタスク策定を行っている。が、だれがどういうタスクを行うのかについては、かなりの違いがある。私の周辺だと、営業とデータ精査についてはコンサルやアナリストが行って、分析と報告はデータサイエンティストや機械学習エンジニア、テストと実装に、データエンジニアがようやく出てくる感じか。営業、データ精査までは無償で引き受ける企業もある。分析業務やりますと決まってから、データ分析できるようなデータではないことが分かったとき、データサイエンティストが拘束されることになってしまうからだ。
データ分析を伴う目的としては、人が動くルールを作るか、機械が動くルールを作るかで求められる分析アプローチは大きく異なる。特に、前者は「業務評価」と「業務改善」、後者は「業務自動化」と「研究開発」のいずれかになると思う。
- 業務評価
ある業務を評価してほしいという依頼の元、KPI（評価軸）を作ってあげる仕事である。お客さん自身が経験で行ってきた業務の現状を、金額や時間などコストを見える化・数値化してエクセル作ったり、ダッシュボード作ったりする。 - 業務改善
ある評価軸をもとに業務の改善を依頼されて行う分析業務である。件数獲得や経費削減をして、最適化を行うことである。ドメイン知識が非常に求められるこの仕事のやり方は、人によってかなり異なる。 - 業務自動化
定常的な業務を人の手から機械にゆだねるために、いかに緻密に数値化するかという意味で、機械学習やAI技術の深さが要求される。自動化をする仕事では、いつもと同じことができるかが求められるだけで、中身の構成については説明要求されることが少ない。 - 研究開発
分析技術自体や分析プラットフォームを開発する業務である。
データ分析自体は、過去（データ）にあったことを、数値で表すだけなので、経験が数値化される以上に新しいものが出てくることはほぼない。人が動くルールを作る「業務改善」は、新しいものを出すためには、機械が発見できない対象を先に特定して、仮説をたてて、分析する必要がある。この点、データ分析とは全く関係ない能力が求められる。
この手の分析方法は、マーケティングアナリストやコンサルが得意としているように思う。経済学や経営学のような仮説と検証をデータ分析として、意外性のある切り口や気付きを分析の価値としていくデータ分析である。そのため、仮説と検証で終わってしまうことが多く、データマイニング技術をもとにした、自動化のモデルにつなげるには難しい。
一方で、機械が動くルールについては、機械学習やAI技術の知識の深さが要求される。成果は人の目からすると当たり前のことだが、当たり前のことを量的関係でうまく結びつけていくことを積み重ねて、少しずつ定常業務の自動化モデルを図っていくという流れにあると思う。エンジニア出身のデータサイエンティストが得意とする領域だと考える。
得意分野とレベル感
データサイエンス業務と一言で言っても、顧客とヒアリングするコンサル的役割、データ分析に耐えられるレベルのデータベースかどうかの診断と初期集計行うアナリスト的役割、分析方針を決め、既存の論文を応用するだけでなく必要に応じてアルゴリズム開発するかどうかまでを見通し、分析プロジェクトをハンドルするデータサイエンティスト的役割、成果物をシステムに組み込むエンジニア的役割と大いにその業務によって登場人物が変わってくる。プロジェクトの方向性に応じて、AIエンジニアや機械学習エンジニアやDBエンジニアまで必要になることもある。
データサイエンティストも分析対象や業種が広がってきて、特定のドメインに強みを持つ人、業務改善を得意とする人など分化されてきている。今一度、データサイエンティストを業務で分別し、分類することをしなければ、スキルを学ぶ傍ら、統計の勉強だけした機械学習エンジニアだらけになるし、口のうまいコンサルしか残らなくなってくるのではないかと危惧する。
少し前のTJOさんの記事で言うと、
超弩級のデータサイエンスのスキルを持つレベル4～5ぐらいの人々のアウトプットを手元で一手にまとめた上で、それより上の（例えば）役員や統括レベルの人々に向かって「我々データ分析チームの分析結果によれば、ユーザー導線AをこのスライドにあるようなA1 / A2 / A3に細分化した上でデモグラ情報に基づいて云々」とサックリ分かりやすく伝えられる、言わば取りまとめ役兼科学コミュニケーターのようなマネージャーが必要なのでは？
tjo.hatenablog.com
この一言に尽きる。科学論文書いて、著書も持ってるような超弩級のデータサイエンス人材のことを、データが絡めば何でもできると勘違いして、営業から何から引っ張りまわすようなことをしないで、適材適所に配置できるPMが必要である。
※この記事は少しずつ更新していくと思う。そういう意味では、wikiのような形式が適切だったのかもしれない…。
