BizDeep

個人の見解です

大企業機械学習エンジニアに立ちはだかる3つの壁おじさん

昨今大企業やめました記事が盛り上がってますね。

anond.hatelabo.jp

kumagi.hatenablog.com

僕もかくいう大企業ソフトウェアエンジニアで、機械学習を担当していて、クソみたいなことがいっぱい起こって辞めようかと思うことが非常に多い。 怒りの原因を分析したところ、僕のケースでは以下の3人の壁となるおじさんがいることがわかった。

[ここで注意]
本記事は著者含め大企業で働く機械学習エンジニアの友達とslackやtwitterで盛り上がった内容を、全て”僕”一人の体験としてまとめ上げたものです。つまり 実話に基づいたフィクションです
分散する様々な大企業の悪いところをまとめて3人のタイプのおじさんを作っているので、とある大企業の批判をしていたり、著者個人がこの様な体験をしている訳ではないことにご留意ください。

(1) 幼稚園児でもわかる結果でしか技術を評価できないマネージャー

大企業のマネージャーはマネージするべき部隊の技術的なバックグラウンドの教養が十分にないケースが非常に多い。

これはたとえ技術職であってもお金と人の管理だけで出世できる日本企業の悪しき風習と、大企業ならではの異動して空いたポストにハマり込むことで出世していく文化が重なって起こっていると思われる。

ただ、業務時間を使って何かを行おうとするとこの人を説得して工数を確保する必要がある。 最初の大きな壁はここにある。

僕たちは機械学習の最新の論文や他社の動向に対する知識があるので、競合他社のエンジンのアウトプットを見ればおおよそどういう技術で実装されているか推測でき、それを凌駕するにはどういうアルゴリズムを採用すれば良く、さらにどうやって発展させれば競合の手が届かないところまで技術を高められるかの計画が立てられる。

だが、こういった技術ベースの内容では課長は一切理解を示してくれず、本当にやりたいなら結果を見せろと言われる。
当然作っていないので結果を見せられないというと、どれくらいの時間で競合と同等の結果が出せて、それからどれくらいの時間で競合に勝つ精度が出せるかのスケジュールを建てろと言われる。

これはつまり、他社を超えられる証拠を見せろということである。論文も読まずに。コードも読まずにである。
これをまずクリアするには、他社のエンジンの定量評価を行う環境を作るところから始め、それによる他社エンジンの弱みが定量・定性的に理解できる資料作りが必要となる。 これに1ヶ月はかかる。はい壁。クソ。

また、スケジュールを建てるということは完遂する以前からオンスケジュールであることを定期的に証明する必要があるということであり、度々現状の動向を非技術レベルで理解できる資料を作って説明する必要があった。
どうせ資料を作って説明しても、出来てたらそのまま進め、出来てなかったらダメじゃんって言うだけなのに。

(2)基礎タスクに対して2週間ごとに目に見える結果を求めるアジャイルおばけ

うちのチームの開発はアジャイルで進められている。
大企業の場合、プロダクトリーダーが課長で、プロダクトマネージャーとしてコードの分からない謎のおじさんがアジャイルのリーダーとして一人挟まっていて、アジャイルのタスク進捗はその謎のおじさんに報告し、そのおじさんが幼稚園課長に報告するというスタイルで仕事が進められている。

アジャイルといっても、まずは(1)をクリアしているので大まかなスケジュールを立てて、それをクリアする様に詳細なタスクレベルまで分解してアジャイルで進めると言うスタイルである。(なので実情は設計のないウォーターフォールの様なお粗末な代物)

そしてスクラム開発の真似事をするので、2週間ごとにプロダクトリーダー(課長)に対して、成果物の説明が求められる。
何かリリースをする様な開発タスクの場合はプロダクトが開発環境で動いているものを見せたり、設計タスクの場合は資料や図を見せたり、検証タスクの場合はグラフ化した資料を作ってそれを見せたりする。

製品開発の場合はこれで説明が成り立つのだが、機械学習の基礎タスクの場合は意味が全然変わってくる。
たとえば、実際の業務では2週間かけて学習環境を立てて、データを整備して、マシンで学習を開始してロスの動きを見て、ハイパーパラメータを修正して、などを行うのだが、ここに成果物の途中経過はない。
ロスが全然収束しなかったり過学習した学習結果に対するアウトプット例を見せたところでなんの意味もないし、ロスがこうだからハイパーパラメータをこうします、といった様な内容を幼稚園児マネージャーにわかる様な資料に落とし込んでいる時間はない。

ただ、これをアジャイルのリーダーは分かってくれない。
2週間ごとには絶対ドキュメント作ってねとか、なんなら3日ごとにタスクを細切れにして途中経過をドキュメントで伝えてスケジュール通り進められてることを納得させてね、とか言ってくる。論文も読まずに。コードも読まずにである。

これをクリアすることはとても困難で、信じてくださいというか、今は結果を出せませんと言って戦うしかなかった。

(3) 基礎タスク担当者に製品化~検証までの責任を負わせるエンジニアリーダー

僕はだいたい機械学習の最新論文の検証など基礎タスクを担当することが多いが、チーム自体はとあるソフトウェアプロダクトを作っており、それに実装するという名目で基礎タスクの工数をそのプロダクトの費用から捻出していた。 つまり、あるソフトウェアの開発チームにリサーチエンジニアと開発運用エンジニアとかがごった煮にされている状態であった。

そのソフトウェアには開発のリーダーとなるおじさんがいて、この人はコードが書ける人で、アジャイルおばけのおじさんと相談してスクラムのタスクを決めたりリリース物の設計をしたりする。

僕もそのソフトウェアのチームに所属しているので、基礎タスクを解きながらもソフトウェアプロダクト自体の開発メンバとしてアサインされ、コードレビューや資料のレビュー、会議等に非常に多くの時間を割かれていた。

さらに、プログラマあるあるだが、だいたいソフトウェア開発のスケジュールは工数削減のためクソみたいに詰め詰めに見積もられていることが多く、リリース前などは毎度のように想定外のタスクが発生し、炎上が起こる。 炎上が起こると、真っ先に検討系のタスクが消されて、炎上対応タスクが増える。つまり僕の工数機械学習でなくCIのエラー対応とかAWSのシステムワークフローの見直しとかに充てられる。

この時点で、(1)で作ったスケジュール通りに基礎タスクが進められるはずはなく、当初作るはずだったエンジンの質は下がり、やりたかったアルゴリズムは実装できず、無理やり結果をうまく見せる様な後処理実装を入れ込んだものが最初に出来上がることになる。

それを見て、課長がエンジン全然ダメじゃん、何やってるのとか言ってくる。 その辺りで、脳内で奇行種の巨人が課長を食べてくれる姿を思いながら、すみませんと言ってまたアップデートスケジュールを立て、(1)からのループに入る。

終わりに

この経験から僕が学んだことは、大企業では時間をかけて既存の技術をアルゴリズムレベルで上書くような業務はまずできないし、説得してスケジュール建ててもめちゃめちゃにされるし、無理して作っても部署内の頭の悪い人間と戦った際のダメージで正当な評価を受けることはない、ということである。

最初にスケジュール立てる時に炎上対応のタスク積んどけばいいじゃんと思うかもしれないが、炎上対応のタスクはそもそも全体のソフトウェア開発のスケジュールに積まれてないから炎上するわけで、事前に積めるはずはなく。。

あと、蛇足的ではあるが、上の学びを裏返すと、既存の技術をなあなあで発展させる分かりきったタスクをあたかも難しいように解釈させる厳格な資料作って長めのスケジュールを建てて、意味のない資料をたくさん作って時間をかけて実装すると大企業では一番評価される。 その経験を積むと嘘をついて工数確保するのがうまい技術力のないサイコパス、もしくは確実な小さい改善を積み続けるだけのつまらないエンジニアが出来上がり、これが大企業のなかで出世して行く技術者ってことになる。

どうしたらいいかというと、分からないのだけど、せめてスケジュール化しなくても作業が進められるいわゆる20%ルールのような物がもう少し大企業にも入ってこれば、少し未来はあるのかなとも思う。

(追記) 本記事は大企業の悪いところだけ抽出しすぎて、これだけ読んだら「いやベンチャー外資に転職すれば良いじゃん」と思われがちだと思って、以下の記事を書きました。

biz-and-deep.hatenablog.com