バックエンドに進出したMLエンジニアが苦労した話

こんにちは、MLエンジニアのふるです。
今回は、エンジニアリングに進出した機械学習エンジニアが組織で動く中で苦労した話と、良かった話をまとめていこうと思います。

私は機械学習エンジニアとして生成AI導入などのミッションを持ちつつ、個人開発でもエンジニアリングをやっていた経歴があります。そのため、バックエンドや今ではスタンダードとなったIaC周りの知見をある程度持っています。もちろん Kaggle Master としての機械学習スキルもありますが、「ものづくりが好き」という点と、スタートアップ環境では分断型よりも幅広く担える方が活躍しやすいという理由から、エンジニアチームのやっていることがある程度わかるMLエンジニアとしての動きをできないか？を探っていました。

実際に働いてみての所感を述べていきます。

データサイエンスの軸：意思決定のための分析

機械学習エンジニア（あるいはデータサイエンティスト（略してDSと以下記述））の軸は、やはり分析を通した意思決定です。目的は意思決定の質と速度を上げること。プロダクトやフェーズによって先をどれくらい見据えるかは変わりますが、少なくともスタートアップでは「目先のABテストに勝てるか」「施策の有効性をフェルミ推定や思考実験で示せるか」がほとんどを占めます。そのため、「目的さえ達成できれば手段は問わない」という姿勢が一般的です。プログラムコードそのものの美しさや長期運用性は、相対的に優先度が下がりがちです。ただし、プロダクトのフェーズによって「迅速な」意思決定をすべきか「正しい」意思決定をすべきかの議論はあるのですが、この議論についてはプロの方に議論を委ねましょう。

エンジニアリングの軸：数年先でも耐えうる設計とコスト最小化

一方、エンジニアリングの本質的な価値は「数年先でも耐えうる技術選定や、それに相当する価値を作れること」にあります。近いようで、実はDSの発想と真逆です。エンジニアリングの設計では、協調性（チームや他システムとの整合）、再利用性、可用性、保守性、安全性など、複数のKPIを同時に満たしながら、限られたコストで実現することが求められます。つまり、DSが「事業KPI（売上など）」に直結した意思決定を最適化するのに対して、エンジニアは事業成長のための"ペインを除く"——すなわち運用コストを抑え、変更容易性を上げ、障害を起こさない仕組みをつくる——ことにも強く向き合う必要があります。

ここで伝えなければならない点としては、「エンジニアだからといって目先の利益を追求する必要がない」と述べているわけではなく、目先の利益を追求することも時には求められるが、本質的な価値は目先の価値の最適化よりもプロダクトグロースする際の長期的な最適化が世の中における価値となるという点です。

マインドセットの切り替えに苦労した話

この「意思決定に向けた分析の思考」と「エンジニアリング思考」を行き来するマインドの切り替えは、最初は正直かなり苦労しました。ここでこの2つの思考を切り替える軸で私が重要だと感じているのは以下の3点です。

• データを使うことでどの程度事業貢献できるのか
• 作ったシステムが３年以上使われている確率がどれくらいか
• 今が勝負時かどうか

こちらをそれぞれ述べていきます。

データを使うことでどの程度事業貢献できるのか

MLエンジニアおよびDSは簡単に言ってしまえば、「データという専門知識を武器にして何らかのチームの意思決定を推し進める」職種です。そのため、DSには「今あるデータを使ってどの程度強い意思決定ができるのか（=データドリブンな運用がどれくらいできるか）」を見極める必要があり、「データをどう貯めればデータドリブンな意思決定へ向かえるか？」という設計ができる必要があります。

こうやっていうとDSっすごいじゃん！！という気持ちになりますが、実際のところ「どうデータを貯めればデータドリブンな意思決定ができるか？」はチームで議論するとほとんどのケースにおいて「売上が上がればデータが貯まるからデータドリブンな意思決定ができる」に辿り着きます。つまり、商品が売れるような施策をたくさん出す人（=プロダクトオーナー）への道を辿ることになり、そのようなレバーを取ることは容易ではありません。なぜなら、データサイエンティストという特殊な武器を持ちながら、データ以外の観点（=ドメイン知識など）でプロダクトオーナーよりも優れた施策を出し遂行するというのは、常人にこなすのは難しいからです。

そのため、私はプロダクト軸の部分ではなく、より汎用的な軸としてバックエンドやインフラへ参入してレバーを取りに行くという道を選びました。

作ったシステムが３年以上使われている確率がどれくらいか

作ったシステムがどれくらいの利益を売り上げ、どれくらい長く使われるのかの観点は抜け落ちがちかなと思ってます。クリーンアーキテクチャとかリファクタリングが大好きなエンジニアは世の中にたくさんいるかと思いますが、極端な話100ユーザー3日しか使わないシステムのリファクタリングをしたところで、リファクタリングし切る頃にはユーザーが離れてしまいます。

どれくらい利益があってどれくらい長く使われるかは、最初に冷静に考える必要があります。例によって上のような施策の例「100ユーザー3日」ではもしかすると、何かSaaSを使って代用する設計の方が良いかもしれません。ここの温度感を合わせられるかどうかは、当たり前でしょって思う一方で非常に重要です。

今が勝負時かどうか

今が勝負時かどうかは個人的にはスタートアップフェーズにおいてかなり重要だと感じています。基本的にはMLエンジニアやDSのタスクはほとんどのケースにおいて、お金を浪費する施策をすることになります。データ基盤だったり、データ分析は基本的に高価なので、お金を使ってでもデータという事実に基づいてプロダクトに白黒をつけたいというシチュエーションです。

そのため、今が勝負時かどうかは非常に重要な観点になります。例えば、有力な施策が見つからないときに弱いABテストをやり続けても有意差が出ずに終わります。こういう時の場合はエンジニアリングに回った方がバリューが出せると自分では感じています。先ほどの事項は正確に述べるとサンプルサイズと効果のバランスにおいて、スタートアップフェーズでは勝負時（キャンペーン実施など）以外ではサンプルサイズと期待する効果が足りずほとんどのケースで有意差なしで終わるということです。

2つの思考を切り替える判断基準

上記内容を考えることで、どれくらいエンジニアリングの思考を入れるべきのか、データサイエンス的な動きが重要なのかを切り分けています。個人的には、大規模プロダクトでは、これらのことをあんまり考えずにクリティカルパスだけで動けるケースが多いので少し気が楽だなと思うこともあります。

まとめ

機械学習エンジニアとしてバックエンドエンジニアリングに進出することは、単なるスキルセットの拡張ではなく、思考法の切り替えを伴う挑戦でした。データドリブンな意思決定とエンジニアリング設計のバランスを取るには、事業貢献度、システムの寿命、そして今が勝負時かどうかという3つの軸を意識することが重要だと意見を述べました。次回は「バックエンドとMLエンジニアができる人間がどうキャリアを選ぶべきか」について記述していこうと思います。