機械学習の仕事ができないかなーとぼんやり思うも、今の知識ではまったく無理、どころか下っ端として使い物になるのにすら 3-4 年かかりそうな感触。ただ情報産業の関心がコードからデータにシフトしていく流れ自体は変わらなそうなので、いますぐに機械学習は無理にしろもうちょっとデータに近い仕事をしたい。しかしデータに近い仕事というのがよくわからない。データエンジニアとかがそうなの？世間の求人などをみながらつらつら考える。

Analytics Stack

データの仕事の一番下にはインフラを作る仕事がある。ログのストレージだったり OLAP のデータベースだったり。OSS なり商用なりのソフトウェアをもってきて運用する仕事かもしれないし、組織の規模によってはそういうインフラ的ソフトウェア自体を開発する仕事もある。世間では「インフラエンジニア」と言われる職種の一部に見える。インフラエンジニアは、データよりはコードの仕事に近い気がする。ふつうはデータの中身を解釈しないだろうから。

次に、そういうインフラにデータを ingest する仕事がある。それは serving のレイヤからログのストレージにデータをつなぎこむ仕事かもしれないし、生のログ(アクセスログとか)をもうちょっとプロダクトドメイン寄りのログに整形、集計しなおす仕事かもしれない。これは世間では「Data engineer」と呼ばれている仕事な気がする。Hadoop とか Spark とか Kafka とかでコードを書く世界。Data engineer は、インフラエンジニアよりはデータの中身を知っている。Schema とかわからないと整形できないから。ただ主要な関心は automation とか scalability とかにありそう。

Data Engineer の用意したデータから UI を作る人がいる。可視化したり, drill down の手段を用意したり、あとは alert の画面を作ったり。世間では Visualization Engineer とか、単により広いくくりで Fronend Engineer などと呼ばれている。Data Engineer よりはニッチで、サードパーティのツールで済まされてしまうことも多そうだけれど、一定規模以上の企業には専業でやってる人もいるし求人もある。このひとたちは Data Engineer 以上にデータの中身を気にしている。一方で何か insight を導いたり意思決定をしたりはあまりしなそう。

Data Engineer と Visualization Engineer は Analytics とかなんとか言われるチームで一緒にはたらいていることが多いように見える。Analytics のチームには、こうした人たちがお膳立てした platform で実際にデータをつついて reporting をする人がいる。いわゆる Data Scientist とか Analyst と呼ばれる人たち。この人達はデータの中身を気にしている。というかそれが主な仕事。色々な調査から insights を導き出して report したり、偉い人や顧客の質問に答えたりする。

Analytics の platform は PM とかエンジニアも必要に応じて使い product decision の材料にしている。Product team だけでなく Sales とか Partnership とかの人も、たぶん使っている。こういう人たち...つまり自分とか...は数字の中身を気にしているが、一方でたいして難しいことはしない。多くは集計して比べるだけ。

この Infrastructure - Ingestion - Visualization - Analytics というスタックはいわゆる Data Warehouse というやつで、基本的には中の人が意思決定をする道具である。意思決定の部分を機械学習とかで自動化しちゃうのがモダン Analytics なのかもしれないが、中の人のための道具であることに代わりはない。

Discovery Stack

Analytics とは別に、 Production でデータを使う人たちがいる。Search, ads, feed, recommendation などの ranking アルゴリズムを書いている人たち。あとは anomaly/fraud/spam detection とかをしている人たち。など。ひとまとめにする良い言葉がないけれど、仮に Discovery Stack とでも読んでおこう。

この人達は Data Warehouse のログだけでなくサービスがもっているデータ(商品情報、 UGC など)も使う。まあ Analytics でもサービスのデータを使うことはあるだろうけれども、重点の置き方が違う。より大きな違いとして discovery stack は製品やサービスの一部として結果をユーザに serve する。なので性能とか自動化とかが不可欠。エンドユーザは SQL を書かないし、結果がでるまで何分も待ちはしないから。あとはサービスの出来に直結するので既存の製品/SaaS とかををそのまま使うより自社開発することが多い、気がする。いろいろ求人がある。

Discovery Stack にも Analytics Stack 同様インフラがある。Analytics stack と共有している部分もある。あとはふつうにデータベースとか。ここでいうインフラエンジニアはざっくり言うとデータベースとかを開発したり運用したりする人、ということになる。ただユーザに serve する必要があるので serving 側のインフラも面倒をみている場合がある。データの中身は、たぶんさほど気にしていない。

純粋なインフラの上は, Analytics ほど分業化されていない印象。どちらかというと偉いプログラマが discovery のコアとなる システムやアルゴリズムを作って、下々がそれをチューニングしたり拡張したりするかんじ。 ingestion も機能毎のチーム単位でなんとかしているように見える。なのでインフラより上の Discovery Stack のプログラマは割とみんなデータの中身を気にしていると言える。なぜ product 側のほうが end-to-end な性質が強いんだろうね。Analytics Stack の Data warehouse よりも製品毎のアーキテクチャのばらつきが大きいからだろうか。

Discovery Stack のコアには ML があることが多いだろうけれども、下々のプログラマはそのモデルを触るのか。よくわからない。どちらかというとシグナルを探し出して新しいパラメタとして既存のモデルににつっこむのがメインなのではないかなあ。そうでないとでかいシステムを安定して動かせなさそうじゃん? ただモデルの中身は理解しているのだろうな。

Prevalence of ML

機械学習の普及に伴い ML Engineer みたいな求人をよく見かけるようになった。上に書いたような文脈でこの職種を解釈すると、 ML Engineer には新しい discovery のジャンルを開拓することが期待されている、ように見える。新しい問題に ML を適用し production で動かす仕事。要するに discovery stack の偉いプログラマ相当。

新しい discovery システムが使う ML モデルの構築は Researcher という専門家がやってくれる場合がある。あるいは逆に researcher のアイデアを production にもっていくために ML Engineer が求められる。そして新しい discovery systems は成熟しておらず platform になっていないため下々の出番はあまりない。人海戦術に値するスケールがあるかもわからないし。

従来の Discovery Stack でも色々なものが ML というか DNN に置き換えられていくにつれ Researcher の存在感が大きくなる。これが一過性のもので DNN が成熟するにつれ ML Engineer だけで足りるようになるのか researcher の強い立場が続くのかはわからない。

伝統的な discovery とは違う局面で nice-to-have 的に ML を使う場合もある。そういうときは product team のエンジニアが researcher からモデルをもらって回しておわり、みたいになりがち。このとき エンジニアは Analytics Stack の Data Engineer に相当する役割を勤めている。つまり、データやモデルの中身はそんなに気にしてない。Researcher の片腕となる ML Engineer とは違う。

でも自分の近所でこの仕事をやっている人をみると、データは気にしている雰囲気があるな。モデルをどのくらい理解しているのかは知らないけれど・・・。

ML As A Product

こうした「とりあえず ML してみようぜ」的な世界の反対に、ガチ AI みたいなジャンルもある。翻訳、音声認識など。こういう機械学習をそのまま製品にしたようなプロジェクトは、意外と求人のスコープがわかりにくい。コアのアルゴリズムやモデルを作る人もいれば、それをチューニングする人もいる。そしてアルゴリズムにデータを流しこんだり UI をつけたりする人もいる。Discovery Stack の求人以上に End-to−End な性質が強いせいで、仕事がどれだけデータに近いのかすぐにはわからない。逆に flexibility があるということかもしれない。そしてこういうアカデミアが state of the art を競い合っているようなジャンルでデータに近い仕事をするのは大変そう。ジャンルの成熟度ゆえ超大規模システムで下々にもやることがある、という可能性もないではないけど、どうなのだろうなあ。

外野たる自分の理解を書き出してみた。どのくらいあってるのかね・・・。それなりに正しいと仮定して話を進めるしかないので話を進めると、ではほぼクライアントサイドの経験しかない、かつ特に活躍もしていないおっさんが紛れ込む余地があるのはどこだろう。そして自分がやりたいと思える仕事はどのへんだろう。

データよりコードに近い方が generalist 枠で紛れ込みやすい。つまり Data engineering とか Infrastructure の方が入り込みやすい、気がする。一方で、できるだけ実際にデータの中身を解釈する仕事をしたい。この二つは相反しているので、データに近づける範囲で近づくしかない。

Analytics, Discovery, Emerging Areas, ML Product という軸はどれがよいか。Analytics はプログラマ自身がデータを扱う余地は少なそうなので、なんとなく違う気がする。Discovery はよさそう。ただ敷居も高そう。Emerging Areas の ML Engineer は更に敷居が高く、即戦力以外はお呼びでない感。ガチ ML Product は、わからん。データからは遠い仕事に回されてしまうようにも思えるが、job description をみて position を選べばそういう心配はないかもしれない。しかしそれは end-to-end な性質が近いという自分の予想と矛盾する話でもある。

未経験おっさんの入り込む余地は・・・基本的にはなさそうなので妥協したり運を頼ったりで無理やり下っ端として入り込むしかなさげ。無茶に失敗し、データに近づききれず残念な仕事をする羽目にあうかもしれない。が、それは自分がとるべきリスクなのだろうなあ。最低限サーバ側でデータのパイプラインの一部に入り込めればよし、くらいが現実的か。謎のプロプリエタリインフラとかあんましさわりたくないがやむなし・・・。

あまりうれしい結論ではない。おとなしく Android  仕事を続けろということだろうか。それで良いといえばいいのだけれど。

まあ目先の仕事はあるので気長に考えます。