🎲

データサイエンス人材、外から採るか？中で育てるか？

2021/12/19に公開

MLOps

humanresources

idea

「データサイエンスがわかるような人材を確保したいものの、採用するのも現状なかなか難しいし、中で育てていくのにも時間かかるし、どうするのがいいですかね？」という質問を受けた際に話した内容を明文化します。

データサイエンスがわかるような人材のスキルセット
重要な周辺領域 3 つ
プロダクトを作る場合、必然的にチーム戦

なお、対象読者としてはデータサイエンスのニュース記事は読めるものの実際に手を動かしたことはなく、主な仕事はプロジェクトマネジメント、でも採用を考えなければいけない人とします。

データサイエンスがわかるような人材のスキルセット

まずはデータサイエンスがわかるような人材とは何かを確認しましょう。
さまざまな観点があり得ると思いますが、ここではスキルの面から見ていきましょう。
よく使われるのは次のような領域への分解かと思います。

データサイエンスそのもの
エンジニアリング
ビジネス知識

それぞれについて内容を確認しましょう。
ただし、ここでは採用すべき人材レベルを定義するのではなく、それぞれについてどのような内容なのか共通認識を作ることを目的とします。

データサイエンスそのもの

わかりやすく確率統計や機械学習の知識です。

確率統計は、大学の学部で習得するような内容を指します。
基本的な確率分布とそれらの間の関係、検定といった項目が具体例としてあげられます。
統計検定の 2 級程度の内容を見ると想像がつきやすいかもしれません。

機械学習は、さまざまなオンラインのコースで取り組まれるような内容を指します。
アルゴリズムについての知識と、与えられたデータセットに対しての適用方法と、その評価方法といった項目が具体例としてあげられます。
ド定番ですが Machine Learning by Stanford University を見ると想像がつきやすいかもしれません。

機械学習についてはさまざまな領域があり、細分化がすすんできました。
表形式データ、画像、自然言語処理、音声といった領域が代表的です。
実際に適用したい領域がこれらのどれに当たるかは調べておくと良いでしょう。

エンジニアリング

次にエンジニアリングです。
これは 2 つの分野にさらに細分化できます。
データを使うための技術と、プロダクトに組み込むための知識です。

最初の分野はデータを使うための技術です。
機械学習やデータ分析を行いたい場合、必要になるデータを取得し整形する必要があるため、それを実行できる必要があります。
具体的には SQL や Python が相当します。

ここで言う "SQL" はアプリケーションで用いる SQL とは別の技術です。
アプリケーションで用いる RDBMS ではデータは正規化され、ER 図を書くとスター型になっているような場合が多いでしょう。
一方、機械学習においては各所からデータをひっぱってきて JOIN し、列数が 100 程度のテーブルを作成して使うことが珍しくありません。
このため、正規化されたテーブルの設計ができることとは別に、正規化されたテーブルをかき集めて非正規化するスキルが必要になります。

次の分野はプロダクトに組み込むための技術です。
これはプロジェクトマネジメントやシステムの基本的な開発工程といった、業務の進め方に関する知識を指します。

データサイエンティストがこの分野について熟知し、大規模プロジェクトを運営できる必要があると考えているわけではありません。
しかし、この知識がないと現場は悲惨なことになります。
この知識がないデータサイエンティストは周りが何をやっているのか、何について話しているのかわからなくなります。
また、周囲もデータサイエンティストは何ができるのかまったくわからなくなってしまい、コミュニケーションが成立しなくなります。
現場にはどんな工程があり、どうつながっていて、個々の工程では何が重要なのか、共通認識を形成することが必要です。

ビジネス知識

最後に、ビジネス知識です。
これはとくにデータサイエンス界隈ではドメイン知識と呼ばれるので覚えておくと良いかもしれません。

ビジネス知識はデータサイエンスの活用においては必須です。
データサイエンスを用いてどんな結果を出せばいいのか知るためには、対象としている領域についての知識が必要です。
また、目の前のデータがどんな意味なのか知るためにも、やはり対象としている領域についての知識が必須です。

どんなデータからどんな成果を生み出せば価値があるのか、見定めるのためには対象となる業務や業界についての知識が必要になります。
報告時に行うプレゼンテーションの技法もここに含めます。

重要な周辺領域 3 つ

これまでに述べてきた領域は互いに独立ではなく、重なり合うものです。
ここからはデータを活用しようとすると必要になる、3 つの周辺領域について述べます。

実験デザイン
データマネジメント
プロダクトマネジメント

実験デザイン

実験デザインは、どんな問題に取り組むため、どんなデータを取得し、どのように処理し、どのような結果を出し、どのように意思決定を行うかを事前に検討する取り組みを指します。
これはデータサイエンスとビジネス知識の周辺領域だと考えます。

データサイエンスの技法を用いれば、データさえあれば事前の検討がなくてもそこから意思決定に資する情報が得られると思われるかもしれません。
実際にはこれは誤りです。
事前にプロセスの検討を行わずにひたすら試行錯誤を行った場合、成果が得られなかった場合には何が悪かったのか振り返ることができず、学習がまったく進みません。
事前にプロセスを検討しておくことは、データ分析を行い、うまくいかなかった場合にはなぜうまく行かなかったのか特定し、改善していくためには必須です。

また、機械学習を用いて何らかの予測モデルを作った場合、本番環境での利用前に何らかの実証実験が必要になります。
その場合に、どのような成果があればよいのか、そのためにはどのようなデータが必要になるのか、事前に設計できていないと場合によっては悲惨な結果に繋がります。
たとえば、一連の実験を追え、レポーティングのために資料作成を行っていたところ、取得すべきデータを取得していないことに気がつくかもしれません。
この場合、今からそのデータを取得できればマシですが、たとえば「利用者の作業時間」「ユーザーから見た第一印象」のような再取得不能なデータの場合、実験を再度やり直す必要があります。

この実験デザインですが、確率統計や機械学習のアルゴリズムについて詳しい人でも、必ずしもできるとは限りません。
実験デザインは取り組む問題、データの取得方法から考え直す分野です。
たとえ大学で機械学習アルゴリズムの研究を行っていたとしても、Kaggle のように提示されたデータセットを用いたアルゴリズムの分析しか行っていなければ、この分野に触れる機会すらないでしょう。

実験デザインは精緻に体系化されているというわけではなく、さまざまなケースについて触れつつ学ぶしかない分野でもあります。
このため、実際に手を動かすことが必要になります。

データマネジメント

データ活用の目的を決め、データを利用しようとしたときの最初の壁は、そのデータがどこにあるのかわからないことです。

たとえば、アプリケーションで用いている RDB の、どのテーブルのどのカラムを利用すれば欲しいデータが取得できるのか知ることは大変困難です。
僕自身の体験として、基幹システムのテーブルとカラム一覧を渡されそこから需要予測モデルを作成するということがありました。
そこには 100 を超えるテーブル一覧が記された Excel ファイルと、それぞれのカラムの名前、意味が記されていましたが、解読に莫大な時間がかかりました。
結局、自分だけで考えることは諦め、そのシステムの専門家に質問することでようやく所望のデータを手に入れることができました。

データサイエンティストは一般的なデータ分析手法についての専門家ではありますが、あなたのシステムのデータの専門家ではないのです。
このため、データを活用するためにはどのデータがどこにあるのか探しやすく、実際にアクセスしやすいように権限管理がなされ、そのデータの意味や背景がわかるようなドキュメントと紐付いていることが必要です。

データマネジメントはこれらの課題に対する取り組み全般を指す用語です。
データマネジメントが行われていない状態であったとしても、データサイエンティストなら成果を出せるのではないかというのは過剰な期待です。
データが一元管理され、それが維持されている状態が必要です。

また、データマネジメントはどうしても組織全体を巻き込む取り組みになります。
これは、すべての組織が利用しているデータを一元管理しようとするためです。
このため、経営層の理解や、経営層とのコミュニケーションが重要となります。

僕はデータマネジメントを、データサイエンスとエンジニアリングの周辺領域だと考えています。

プロダクトマネジメント

データを使うのは手段であり、その目的は別にあるはずです。
組織の目的や中長期的な目標を細分化し、その業務で取り組む目的や成功/失敗のしきい値、用いる指標やその測定方法をすべてつなげて設計する必要があります。
プロダクトマネジメントは広大な分野で、すべてを書き下すことは難しいですが、さきほど述べた一連の流れを設計するのはその仕事の 1 つです。

ユーザーに価値を提供するまでの全体を把握し、データをもとに計測し、ボトルネックを発見して改善するのは専門性の高い仕事です。
また、ビジネスへの影響を考えつつ仕事をすすめるために、対象となるビジネスについての深い知識も必要です。

僕はデータ活用の文脈において、プロダクトマネジメントをデータサイエンスとビジネス知識の周辺領域だと考えています。

必然的にチーム戦

これまで 3 つの大きなスキルの分類と 3 つの周辺領域を見てきました。
僕の知る限り、これらすべてを単独でこなせる個人は存在しません。
そのため、必然的にチーム戦となります。

たとえば、機械学習を用いたプロダクトを作成したい場合、次の役割をこなせるメンバーが揃っていることが最低要件でしょう。

プロダクトマネージャー (戦略立案・推進担当)
機械学習エンジニア (アルゴリズムの設計・構築)
バックエンドエンジニア
フロントエンドエンジニア
デザイナー

上記はプロダクト作成を意図している人員構成ですが、マーケティング戦略立案などの場合はまた別になります。
このため、目的に合わせて人員構成を考え、そこで必要になる役割を特定し、チーム構成を考える必要があります。
チーム構成の立案には外部の事例が多分に参考となるでしょう。

冒頭の採用か教育のどちらが望ましいかですが、チームの人員のスキルセットを検討し、不足しているスキルについて基づいて検討するのが望ましいと考えます。
たとえば、データサイエンスに関する知識だけが不足している場合、外部からの専門家の登用や新卒採用も手段に入ってくると思います。
一方、特殊な業務領域であったり、その業務領域に関わる専門家がそもそも不足している場合は、内部での教育が手段として望ましいでしょう。

さいごに

最後に MLOps との関連について述べて終えます。

必然的にチーム戦と述べましたが、そこでは専門性のまったく違う人が必要になります。
たとえば、デザイナーにバックエンドや機械学習のアルゴリズムについて熟知してもらうのは酷でしょう。
そのため、専門性の違う人が一緒にチームとして機械学習プロダクトを運用、改善し、価値を届ける必要があります。

このために必要となる取り組み全体のことを、僕は MLOps と呼んでいます。
機械学習を取り入れることで、さまざまな混乱や複雑さがもたらされます。
それらを解消し、チームとしてプロダクトを運営していくこと全体が MLOps です。

MLOps はさまざまな人がさまざまに定義している状態です。
たとえば、僕が登壇したイベントでは 3 人が MLOps の定義について述べましたが、3 人ともに別々の定義でした。
このため、上記の定義は僕個人のものでしかありませんが、少しでも役立てば幸いです。

ということで MLOps やっていきましょう。