名称未設定

データサイエンティスト・マルチリンガル論

Hikaru Kashidaです。
僕が誰かというと、2018年時点ではざっくりこういう者です。
Twitter / 取材1 / 取材2 / 取材3 / 登壇1登壇2 

↓ 本書きました。他の共著さんも結構面白いのでよかったらどうぞ ↓

とても昔に、データサイエンティストの定義について語る文章を書いたことがあるのですが、その内容を少しリメイク&加筆してnoteに載せてみたものがこちらです。

定義についてはとかく色々と言われがちな職種のようなのですが、ココでは僕の自分なりに思うことを書いていきます。

半ば独り言と思ってもらって大丈夫です。

お断り

上記の通り、"データサイエンティスト" は其の定義や存在についてとかく色々と言われがちな職種だと思います。

それは結構なことなのですが、ひとつ僕がこの文章を書くにあたって避けたいと思っているのが『定義警察』的な人の議論に巻き込まれることです。

『定義警察』、つまりは、何かの言葉の定義について自分の考え(ときには社会の公式見解)と異なる言説について、厳しく取り締まる人が巷にはたくさんいると、世間ではまことしやかに囁かれている。

(下記はブロックチェーンの定義警察を警戒する人の例)

ってことで、この記事について意見をいただくのは大歓迎です、が。
定義取締り警察的な態度の人には、余り巻き込まれたくないなあ。

定義警察さま、どうか広い心で見逃してください。もしくは、自分の唱える定義と異なった言説に我慢がならないという方はそっとブラウザを閉じていただけると...

ってことで、本文に入ります。

既存でよく言われる定義について

データサイエンティストの定義について。
僕が好きな定義はこちらのものだ。(だいぶ古いジョークだが)

カリフォルニアに住むデータアナリストをデータサイエンティストと呼ぶ

それはさておき、世間的にもっともよく言われているのは『3つのスキルセットを併せ持ったやつだよ論』だろうか。なんとなしにこちらから図をお借りしてみた。

画像1

このベン図はデータサイエンティスト的な人たちの界隈では非常に有名で、事あるごとに持ち出される人気の図になっている。

もっと構造化して捉えたい

さて、なんに関しても持論というのは既存のなにかにケチを付けるところから始まるものだ。

上記の既存の定義は言いたいことはわかるが、どれも十分なものではない気がしている。その理由は次の2つだ。

① 構造的でない
ビジネスにおける分析業務のバリューチェーンが示されておらず、それぞれのスキルがどの局面でどのように必要なのかがわかりづらい

昨今で注目されているデータサイエンスというのは、主にビジネスの中で活用されていることを期待されている用語だろう
であれば、ビジネスのどういったシーンで役に立つスキルなのかということがもう少し構造的になっていたほうが良い気がする
② スキルが『ある』or『ない』かの二元論的
正直、上記のベン図で示される3つのスキルを包括的に完璧なレベルで取得するのは非常に難しい

というか、そもそも『どのレベルで取得』すればよいのかがわからない

この記事では、この2つの問題を解決する形で、データサイエンティストのスキルセットを構造的に定義して見たいと思う。
特に②に関しては、スキルのレベルとして『読み』『書き』の2レベルが存在するという概念を導入することで、必要なスキルセットの議論をしたいと考えている。

マルチリンガルとしてのデータサイエンティスト

ここで一つ提唱してみたいのが『データサイエンティスト=マルチリンガルであることの価値』理論だ。

ここで述べている言語というのは、いわゆる人間が日常的に話している自然言語体系のことではなく、データサイエンティストが(特にビジネスの環境で)活きる世界で必要となってくる共通言語、すなわち

・ビジネス
・数字 or KPI
・統計学、数式
・プログラミング言語

下記のような状況を想定してみよう。

これらのプレーヤは、全てビジネスシーンの中でデータに関係がある仕事をしている人たち(一部人間ではない)だが、お互いに扱っている言語が違うために会話が成立していない例である。

*  わかりやすさのためにあくまで誇張して書いています

シーン 1 
経営者
:  業績をV字回復させてくれ
分析者:『業績』とはこの場合どのKPIのことをおっしゃってます?
経営者 :  いいからなんとかしろ!株主が騒いでるんだよ
分析者: V字回復とはどの水準まで、またいつまでを指しています?
経営者 :  こいつ...
シーン 2
事業家
 : この施策が上手く行ったのか知りたい
統計家 : ユーザの行動がポアソン分布に従うとすれば、p値0.02で有意です 
事業家 : えと、良かったの?悪かったの?
統計家 : ですから、p値0.02で有意です。ただ、ポアソン分布を仮定....
事業家 : だ・か・ら、売上に換算するとどれくらいなの??
シーン 3 
企画者
: ユーザの離脱確率を教えて、と
Python :  SyntaxError: invalid character in identifier
企画者 : ユーザ 離脱確率!
Python : SyntaxError: invalid syntax....

もし仮に全てのプレイヤー(計算機は除くが)がデータ分析やデータドリブンの重要性を理解していたとしても、上記のようなシチュエーションはよく起こるものだ。『同じ日本語で話してるんだから通じるやろ!』と思ってしまうのは非常に危険だ。それぞれ立場が違うのだから、使う言語体系とその背後にある意味は全く異なる。

この状態を打開するために『データサイエンティスト』は存在する

というのがこの記事で論じたいデータサイエンティスト像の姿だ。それぞれの異なる言語の間を自由に行き来し、必要な場合は翻訳家となり、データ分析に関する一連のバリューチェーンを飛び回る便利屋となる必要がある。

データに係るバリューチェーンの『読み』と『書き』

ビジネスのシーンにおいて、データを使って何かをする際のプロセスのバリューチェーンはおおまかに下記のような構造になっている。

画像2

そしてこのバリューチェーンは『書き』と『読み』の往復プロセスによってV字型にフローを構成することになる。

画像3

ひとつづつ説明しよう。
まずはこのプロセスを下に進めていく『書き』のスキルセットから。

この場合(=下方向に進む)には、各所ごとに非常に強力なスキルが必要になる。一般的に 『書き』のプロセスのほうが『読み』よりも難易度が高い。

書き(↓方向)のスキル >  読み(↑方向)のスキル

画像4

ここで『書き』として表されている、データにまつわる何か(敢えてココでは"データサイエンス"だけに絞らない)を↓方向に進めるには、おおよそで言うと次のようなスキルセットが必要とされるだろう。

Planning - 企画レイヤー
ビジネスの知識とロジックを総動員して、意味があり納得感があり、かつ計算の可能なKPIを設計しなければならない。ビジネスマネージャの期待に答えた内容になっていることも重要だ。
Analysis 分析レイヤー
見たいKPIをどのように分析・定量化するかの具体的な方策を考える必要がある。使えるデータを精査し、(悪さをするデータを除くなど)実際に使うデータの範囲を決め、みる粒度について考え、必要であれば統計的なモデルを設計する必要がある。結果をどのような図表で見せるかも考えておかなければならない。
Engineering - エンジニアリングレイヤー
分析家の考えた計算ロジックを実装する。データの範囲や粒度が変わった時のことを考えて汎用的な設計をし、処理速度に留意する必要がある。場合によっては、統計モデルのパッケージの知識も必要になる。また、出力形式を熟慮し、必要であればビジュアライゼーションなどの手法に通じていることも望まれる。
Infra. - 計算インフラレイヤー
データ量によるが、計算リソースや並列化などのチューニングのために、インフラエンジニア的な知識を持った人材が必要になることもあるだろう

これら全てのスキルを1人の人間に求めるのは酷である。
というかほぼ不可能に近い。

これが意味することは、なんだろうか。

それはつまり、『書き』のスキルをフルスタックで持った人間を "データサイエンティスト" と定義してしまうと、この職種はあっという間に詰んでしまうだろう、ということだ。

『書けない』けど『読める』場合も考えてみる

英語や中国語を習得するケースを考えてみよう。基本的に、読み書きよりも易しい。英語は話せないけど、読み取りや聞き取りならなんとか、という人は少なくないだろう。

日本の英語学習課程だと、Readingは強くなるがWritingやSpeakingは発達しない、という点が問題視されるが、個人的には読めるようになるだけで大いに意味はあると思う(読みというか、Listeningもできるようになるといいとは思うけど)

また、世の中には猫語を話せるわけではないが、猫が話していることを理解することはできる人がいるとかなんとか。にゃーん。

それはさておき、何が言いたいかというと、次の2点だ。

・ビジネスの分析に係るプロセスにも『書き』と『読み』の概念が存在する
・『読み』には『読み』の価値が存在する

先ほどと同じように書くと下記のような感じだろうか。

画像5

この↑に進めるプロセスでは、『書き』に必要とされるほどの強力な能力が備わっていなくても『読み』の力があれば十分に会話に加われるし、意見を言って貢献をすることも可能だ。

Planning - 企画レイヤー
KPIを自分でいちから設計するスキルは半人前でも、各KPIの数値を読み解き、ビジネス的な解釈と仮説の立案ができれば良い。
Analysis 分析レイヤー
統計モデルを自分で組めなくても、入力したデータの構造とモデルの結果の読み方がわかっていればよい。そして、そこから自分の知見を活かしてなんらかの提案ができれば十分かもしれない。
Engineering - エンジニアリングレイヤー
自分でコードをスクラッチで書けなくても、必要な場合は既存のコードを多少改変して自分のほしい結果を得られるくらいのコーディング力があれば役に立つことがある。

この程度であれば『書き』よりも習得のハードルは大幅に低いと思われるが、実際のところこの程度のリテラシーでもビジネスにおいては十分に役立つシーンが少なくない。(という筆者の実感)

言いたいこと

ここまで論じてきたことを表にまとめてみるとこんな感じかと思う。

画像6

大体この表で『書き』で2個くらいに強みがあり、それ以外は『読み』がある程度できるのであれば、データ分析・データサイエンスのプロセスに関わる人間としては十分強力なのではないかと思う。

そしてその要件を満たしている場合、本人が名乗りたければ、『データサイエンティスト』的な職種を名乗っても良いんじゃね?と僕は思う。(定義警察サンが許してくれるかは知らん。)

まあそれはどうでもよくて、強調したいことは

1. 全部の分野を『書ける』必要はない
できるのであればそれに越したことはないが、実際には難しい
また『書き』のカバレッジを頑張って増やすよりも、既に書ける分野をさらに特化して深めるほうが有益な場合もある

そして、一人の人間に全ての『書き』能力が宿っていたとしても、現実的にはその全てのチカラを発揮することは時間的な制約から難しいだろう

室伏選手は野球やラグビー、やり投げをやらせても一流だろうが、ハンマー投げ以外のことに時間を使っている余裕はさほどなかっただろう。
2.『書け』ない言語も『読め』ればよい
英語と同様、データサイエンスに関わる言語も、読みは書きよりも易しい
そして自分の仕事の内容によってはそれで十分なこともある

無理にWriting/Speakingまで行かず、まずは着実にReading/Listeningできるようになることが大事

ということだ。
個人的に一番重要なのは、どの言語で交わされる会話にも参加できるようになることだと思っている。

それは、中途半端と言われるかも知れないが、いわゆるマルチリンガルとしての価値なのだ。どの言語で交わされる会話にも参加できるようにしつつ、自分が『書ける言語』の会話であれば自分で実際に『書き』部分を担うなりして、より強いイニシアティブを持ってプロセスの推進を主導していけば良い。

マルチリンガルとしての価値

事業会社で仕事をしていて感じることは、この図の各レイヤー間においての断絶が起こっているケースが少なくないということだ。

画像7

データ分析やデータサイエンスが、企業内でうまくワークしていないとすればその原因はなんだろうか?

統計のことを完璧に理解している人がいないから?
機械学習のアルゴリズムに精通したエンジニアがいないから?

もちろんそれもあると思うが、それ以上にデータ分析やデータサイエンスの世界では、異なるドメインのブリッジ(つなぎ役)が足りていないのではないかと感じる。

実感としても周囲の話を聞いている限りでも、そこが一番必要とされているように思えるし、かつそれがビジネスの中でデータの価値を発揮するために最も必要な役割だと思う。

全てのレイヤーで『書き』ができるスーパーマンでなくとも、全てのレイヤーの会話に加わっていけるマルチリンガルな存在がこの状況を救う。これこそが、いま実務の世界で最も必要とされている『データサイエンティスト』の姿なのかも知れない。

僕はデータサイエンティストなのか

ちなみに、僕はどうかと言うと、僕自身では自分を"データサイエンティスト"だと思ったことはありません。

たまに名乗ったり、気づいたら名刺にそう書いてあることはありますが。
ではデータアナリストかと言われると、今はそう名乗っていますが、実際のところそれも怪しいです。

何故か?
敢えて言語化すると『データにまつわるなにかが自分のコアスキルだと思っているわけではないから。』だと思います。

じゃあなんなんだろう。あまり自分でもよくわかっていません。
とりあえず、データサイエンティストより猫になりたい。

気をつけたいこと

さて、この職種の定義についての解釈がややこしくなる理由のひとつに、『自分が注意を向けているもの重要と錯覚する認知バイアス』の存在があるのではないかと思う。

すでに述べたとおり、この職種の呼称が扱う範囲が非常にいろんなレイヤーのスキルのハイブリッドであるため、各レイヤーでのプロフェッショナルの人たちが、自分の得意領域で上記のバイアスを全力で振りかざす場合がある。

* 例によって、わかりやすさのためにあくまで誇張して書いています
---

エンジニアリングに強いタイプのひと

『〇〇もスクラッチで実装できないやつはダメだ』

理論に強いタイプのひと
『〇〇の本をちゃんと読んで内容理解してないやつはダメだ』
『論文読め。サイエンスに敬意を払えよ(怒)』

ビジネスに強いタイプのひと

『ビジネスに浸かった経験がないやつは、ドメイン知識なくて碌な仮説が出せないからなー(笑)』

これは残念なことだ。
お互いのレイヤーに敬意を払い合い、理解しようとし、両者の架け橋となるマルチ言語力を持つことにこそ価値があると僕は信じている。

終わりに

つらつらと書いたが、いちばん言いたいことは

『Ph.D持ちで、Spark / Hadoop / SQLあたりは当然に使えて、Pythonが分析のみならずプロダクトに組み込むアルゴリズムの構築レベルでかけて、統計モデルと機械学習の知識が豊富で、ビジネス経験が十分で、チームマネジメントに長け、コミュニケーション能力の高い人』  募集 / 年収 : 450万~

みたいなデータサイエンティスト求人がこの世からなくなりますように。

ってことです。

最後まで読んでくださいましてありがとうございました。
次の記事でお会いしましょう。

↓ 本書きました。他の共著さんも結構面白いのでよかったらどうぞ ↓



この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
note.user.nickname || note.user.urlname

いつも読んでくださってありがとうございます。 サポートいただいたお代は、執筆時に使っている近所のお気に入りのカフェへのお布施にさせていただきます。

A/Bテストのやりすぎには注意
139
メルカリのデータアナリストチームのヘッドが、分析を中心に徒然書いていきます。長文・図表多め。 お仕事や相談などはTwitterのDMへどうぞ => https://twitter.com/hik0107 / 出版した本 : https://amzn.to/2GmsHnD

こちらでもピックアップされています

「データ分析・KPI・グロース」などなどのマガジン
「データ分析・KPI・グロース」などなどのマガジン
  • 13本

メルカリのデータアナリストチームのヘッドHikaru Kashida https://twitter.com/hik0107 が、分析を中心に思ったこと徒然について書いていきます。長文・図表多め。

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。