【MLエンジニア体験談：なるまで編】MLエンジニアになるまでに効いたこと

はじめに

こんにちは、kittchyです。

研究室でMLをやっていて、そろそろ就職を考えている人に向けて書きます。自分は2024年4月からMLエンジニアとして働いていて、いま2年半です。

この連載では、MLエンジニアになるまでと、なってからの2年半でやって良かったことを書いていきます。とはいえまだ2年半なので、業界がどうとか、MLエンジニアはこうあるべきとか、大きい話はできません。書けるのは、そのとき何に困って何を選んだか、というくらいの話です。手法そのものの解説はZennのほうに書いているので、こちらには出てきません。

今回はその1本目で、目指していた頃にやったことのうち、今も効いているものの話をします。次からは、働き始めてからの話に進んでいきます。

不安だったのは、研究のほうではありませんでした

学生のころは研究が面白くて、音声認識のドメイン適応をテーマに、国内の学会と国際会議で発表しました。論文もいっぱい読みましたし、ハッカソンでものづくりを体験したり、インターンに3〜4社行って研究テーマではない音声合成やMLOpsを触ったりもしました。

それでも一番不安だったのは、機械学習ではなくバックエンド・サーバサイド・インフラのほうです。ちょうどAIエンジニアという肩書きが増え始めた時期で、研究分野を深く学ぶのは当然として、そのうえでエンジニアとしても戦えないと厳しいだろうと思っていました。研究室にいるあいだは、学習を回してスコアが出れば終わりですが、会社ではそのモデルがどこかで動き続けないと価値になりません。その「どこかで動き続ける」部分を、自分は一度も作ったことがありませんでした。

そこで、研究の合間にMLの外側を触ることにしました。インターンやアルバイトで研究室の外にコードを書く場所を持って、モデルより手前と後ろを見に行った、という感じです。今からその選択がどうなったかを書きます。

今も効いていること

1. MLの外側へ、横に広げた

会社に入って分かったのは、MLエンジニアの仕事はエンジニアリングが8割を占めるということでした（会社によると思います）。モデルを学習させている時間より、それを載せる場所を作っている時間のほうがずっと長いです。データを取ってくるところ、推論を呼べる形にするところ、動かし続けるところ、壊れたときに気づくところが全部ついてきます。

効いたのは知識より経験のほうで、自分でデプロイまでやったこと、CI/CDを組んだこと、Kubernetesを触ったことが、そのまま業務の入り口になりました。クラウドもGCPとAWSを両方いじっておいたので、どちらの話が来ても地図がある状態で聞けます。ここが白紙だと、機械学習の議論に入る前の段取りで毎回止まっていたと思います。

一番心配していたのは、入った会社のサーバサイドがRuby on Railsで、自分はRubyを書いたことがなかったことです。ただ、言語が違ってもリクエストが来てからDBに触るまでの構造は同じなので、思ったより苦労しませんでした。書き方は調べれば出てきますし、分からないのは文法のほうだけで、何をしているコードなのかは読めます。早い時期からコードレビューに入れたのは、Rubyが書けたからではなく、その周りを知っていたからだと思っています。

2. 資格ではなく、論文に時間を寄せた

学生のときに取った資格はほとんどありません。G検定のような選択肢もありましたが、自分が見られるのは論文を出したかどうかだと思ったので、そちらに時間を寄せました。

読むほうも同じで、研究に必要な範囲を超えて読んだ分が、いま新しい手法を追うときの速さになっています。論文を読むこと自体に体力が要らなくなるので、業務で知らない技術が出てきても、一次情報から入るのが億劫になりません。

効かなかったもの

強いていえば、基本情報技術者です。取ったこと自体を後悔してはいませんが、2年半のあいだに「あれを取っておいてよかった」と思った場面はまだありません。試験のために覚えた範囲は、実務だと必要になったときに調べれば足りる形でしか出てきませんでした。

最後に

学生のときに一番不安だったことが、今のところ一番効いています。研究を薄くしろという話ではなくて、研究をやり切ったうえで、その外側を触る時間を少しだけ確保しておくと入社後が楽になる、という話です。

当時の自分に一言かけるなら、「もっとチャレンジして、起業なり事業を起こす経験もしてみたら、もっと新しい世界が見えてたかもね」ですかね。そこだけはやらずに来ました。

次回は、研究室でやっていたことが会社のどこで効いたかを書きます。それでは。