この記事は、Merpay Advent Calendar 2022 の17日目の記事です。
こんにちは。メルペイ 機械学習チームでエンジニアリングマネージャーをしているshuukです。
本日は、Machine Learning Platformチーム（以下：ML Platformチーム）をクローズした話をしていこうと思います。

MLの共通基盤という魅力的なアイディア

もしあなたが、複数のMLチーム（またはMLシステム）が並行稼働している組織にいる場合、それらの共通部分を括り出した基盤を作り、MLエンジニアはその基盤の上で作業したほうが効率的だと考えたことはないでしょうか。
実際、MLの構成要素は、おおまかには特徴量計算、学習、予測、サービングといったパーツに分解することができ、共通部分も多いです。
新しいMLシステムをスクラッチで開発する苦労を知っているMLエンジニアにとって、社内共通のML基盤の上で少ないコストでリリースするというアイディアは、一種の抗いがたい魅力を持っているのではないでしょうか。

私達メルペイでも、上記のモチベーションからML Platformという新しいチームを組成し、社内のML基盤を構築しようとしたことがありました。
しかし、結果的にはその試みはうまくいかず、チームもクローズすることになりました。
それから約1年が経ち、何が原因で共通基盤化の試みがうまくいかなかったのかを冷静に言語化できる時期になってきたこともあり、この記事では、ML Platformチームの立ち上げからクローズまでの経緯を振り返りながら、そこから得られた教訓をお伝えしていきたいと思います。
もちろん、これは弊社で起こった一つのケーススタディに過ぎません。あくまで「こんな事例もあったんだな」と、MLの共通基盤を構想・検討している方の参考になれば幸いです。

ML Platformチームの経緯

立ち上げ前の状況

ML Platformチームを組成する前、メルペイのMLには与信と不正検知の2つのチームがありました。
両チームはそれぞれ全く異なるドメインに取り組んでいるだけでなく、チーム文化、Scrumの進め方、システム構成など様々な構成要素が大きく異なっていました。
両チームで特に共通化されたものは（ソフト面・ハード面問わず）ありませんでしたので、開発・メンテナンスのコストはそれぞれかかっていました。また、チーム横断の勉強会はあったものの、ナレッジも分散して蓄積されている状況でした
さらに、3つ目の機械学習チームを作ろうという試みも行われており、マネージャーを中心に与信と不正検知以外でMLがワークするドメインの探索も行われていました。

もしこのまま機械学習チームが増えていくと、開発・メンテナンスのコストはますます増加していき、一方でナレッジが分散することは必定です。
そこで、将来を見据えて共通のML基盤を構築し、全てのチームがその基盤を活用して効率的にMLシステムをリリースできるようにすることが提案され、そのための専門のチームを新たに組成することになりました。
それがML Platformチームです。

チーム立ち上げ期

当初は、データエンジニアリングや開発に長けた1名のメンバーでスタートしました。
ただしこの時点では、2つのチームのこの機能を共通基盤化したい等の、具体的な目標が定義されているわけではありませんでした。
それは、このチームが個別具体の課題から発生したというよりは、将来を見据えての先行投資という位置づけであったことに由来しています。
そこで、まずは各チームの具体的なシステム構成や共通の課題を把握する必要がありました。

最初は各チームから個別開発の依頼を受託的に受け持ち、その取り組みの中で各チーム共通の課題を発見するというアプローチを取りました。
どちらのチームもリリースからせいぜい1年程度しか経っておらず、システム面における課題は多く存在しましたし、エンジニアリング能力の高い人材が不足しているチームでは、ML Platformの開発力は重宝されました。
これ以降ML Platformチームによって開発された機能で、今も稼働しているものは数多くありますので、個別開発というアプローチ自体は一定ワークしていました。

チームの拡大

個別開発が盛り上がるにつれて、その工数も膨れ上がってきました。
そもそも個別開発の本来の目的は、開発そのものではなく将来の基盤構築のための共通課題を発見することだったのですが、それに全く着手できない状況が続きました。
そこで、MLのユースケースを理解しつつも開発力の高い人材を新たに2名採用し、より万全な陣容で基盤構築を検討できるように備えました。
当初はその2名も個別開発を担当していましたが、共通基盤の構築に目を向ける余裕も少しずつ生まれ始めてきました。

チームの存在意義が問われる

リソースも充実してきた一方で、この頃からML Platformチームが共通基盤を構築することの是非について、問われる機会が多くなりました。
それにはいくつかの要因がありました。

1つ目に、チーム立ち上げ以降に、Vertex AIやFeastといった、従来に比べて高レベルのAPIを備えたマネージドサービスやOSSが登場し始めたことです。この事自体は喜ばしいことであるものの、一方でML Platformチームが担いたかった機能が一定カバーされたという面もありました。
チームによっては、これらの技術をいち早く取り込んで基盤の刷新を始めており、ML Platformチームでなければ作れない基盤とは何なのか？という問いに明確な答えを持てない状況になってしまいました。

2つ目が、各チームが独自進化を遂げた結果、システム構成や採用技術が異なりすぎて、共通化が現実的ではないレベルになっていたことです。例えばデータフロー１つとっても、一方のチームではGoogle Cloud Composer(Apache Airflow)で、もう一方のチームではVertex AI Pipelinesを使っているといった具合に、依拠している技術が大きく異なる状況でした。また、リポジトリの設計思想も大きく異なり、両チームに共通のAPIを提供したとしても、それを利用するにはどちらかのチームが（または両方のチームが）大幅な改修を行う必要があることは明白でした。

3つ目は、各チームが成長していった結果、機能の共通化も各チームごとに行われたことです。どちらのチームも複数のMLモデルを保持していたため、それぞれ独自の方法で特徴量計算、学習、予測、サービングといった共通機能を（程度の差はあれ）何らかの形でコンポーネント化していました。その結果、新しい共通基盤によって開発工数が大きく減るというメリットが、ML Platformの立ち上げ期に比べると減衰していました。

チームの奮闘とクローズ

この状況を踏まえて、ML Platformチームの今後の方向性について、ML Platformと既存のMLチームのテックリードを交えてオフサイトミーティングにて議論を実施しました。
このオフサイトでは、ML Platformとして価値提供するための具体的な手段は本当にないのかについて、ゼロベースで議論が行われました。
その中で、次のようなPoCが企画・実施されました。いずれも、チームの寄って立つ基盤が異なるという状況に対してのアプローチでした。

• Vertex AI PipelinesでもGoogle Cloud Composerでも使えるような共通コンポーネントを構築するPoC
  • チームの基盤の違いをレイヤーを一つ設けて吸収するアプローチ
• Vertex AIを導入していないチームに対し、部分的に導入してみるPoC
  • 基盤が違うなら基盤自体を揃えに行くアプローチ

このようなPoCを実施し、Vertex AIの有用性が複数チームに伝播するなどの一定の成果は得られました。一方で、先に挙げたような課題を覆すほどのベネフィットが得られるという確証は得られなかったため、ワークしていた試みは各チームで引き継ぎつつ、ML Platformチーム自体はクローズし、既存のMLチームに吸収統合することが決定しました。

振り返り

ここからは、ML Platform活動の良かったところと反省点を挙げていきます。

良かったところ

個別開発による貢献

ML Platformチームは多くの期間を各チームの個別開発のサポートに費やしたのですが、この時に開発した機能の多くは現在も利用されており、有意義なものでした。

優れたメンバーを集められた

まず、ML Platform TeamのJob Descriptionを見て入社頂いたにも関わらず、結果として別の形で活躍頂く形になってしまったメンバーに対しては、申し訳ない気持ちで一杯です。一方で、当時のメンバーは、そうした状況変化を深く理解し、ML PlatformチームがMLチームに吸収されたあとも、ML開発やデータエンジニアリングの文脈で活躍してくれています。

MLのユースケースを理解しつつSWE力も高い人材は貴重であり、そうした方々を受け入れられたことは、組織全体にとっては一つの大きな恩恵でした。

MLエンジニアのSWE文脈での啓蒙

MLエンジニアは一般的に、分析やモデリングのスキルが求められる分、開発能力にはかなりの個人差があります。ML Platformのメンバーが開発のベストプラクティスや避けるべき落とし穴について啓蒙してくれていたことで、個別開発のサポート以上の貢献をしてくれました。

反省すべきところ

強い仮説の不足

ML Platformは、チーム立ち上げ時点で「この機能を共通化してほしい」などの具体的なニーズ、またはニーズにつながるような課題意識が有るわけでは有りませんでした。
そのため、チーム立ち上げ後に共通基盤構築の糸口をなかなか見出すことができず、結果的に基盤構築を諦めることになりました。
なので理想としては、「各チームのこの部分を共通化すれば、大きなインパクトが得られる」「このチームの試みを他チームにも横展開すればコストが削減できる」などの強い仮説を持った上で、基盤構築の試みを始めるべきであったと思います。

一方で、各チームが独自に動いている以上、共通課題が浮かび上がってくること自体が自然体では起こり得ないのも事実です。だからこそメルペイでは一定トップダウンにML Platformチームを構築したという面はあります。
しかしその場合であっても、チームを組成してから仮説を見つけに行くのではなく、マネージャーやTL陣など中心に仮説を検討してからチーム組成するという選択肢もとれたのではないかと思います。

組織体制の工夫不足

もし仮に明確な課題が最初から見つかっていたとしても、組織体制の問題がこれとは別に存在していました。
チームというものは、自然体でいると必ず個別最適化に進むものです。これ自体は決して悪いことではなく、各チームが学習と適応をし続けているという証でもあります。
逆に言うと、各チームを横断して、共通の課題を見つけたり、共通の仕組みの導入を検討したりすることは、決して簡単ではありません。
ML Platformチームは各MLチームとはレポートラインも異なり、Scrumも独自のものを実施しており、Sprint Planningで各チームの関係者と方向性を決めるというやり方を実施していました。今にして思えば、この体制はチーム間の結合度が低すぎ、各チームで同じ目線で共通の課題を検討しようという機運にそもそもなりづらいという構造がありました。
個別開発の時期が長く続きニーズの調査が十分に行えなかったのも、単に開発タスクが多かったからというだけでなく、このような「共通の課題を考える行為自体を促進する仕組み」が整っていなかったことにも起因していたのではないかと思います。
レポートラインをできるだけ揃える、Scrumを同一にする、taskforceを作る、会議体の頻度を上げるなど、マネージャーを中心にして体制面での工夫をする余地が、存分にあったのではないかと反省しています。

MLエンジニアのJob Descriptionとのバッティング

現場の課題や体制よりも更に前段の話として、採用で用いたJob Descriptionの時点で共通基盤化がうまくいかない種が蒔かれていたとも捉えられます。
メルペイでは、立ち上げ初期から「分析から実装まで一貫して実施」することをJob Descriptionに盛り込んでおり、エンジニアリングスキルの個人差こそあれど、「自分の手でMLシステムを作り上げたい」というモチベーションはどのメンバーも一定以上保持していました。
そのようなメンバーが構成するチームにおいて、基盤の部分だけを括りだして別チームに依頼するという未来像は、そもそも魅力的に映らなかったという心理的な部分も大きかったのではないかと現在は考えています。
実際、チームによってはVertex AIやFeastといった最新技術を自分たちの手で試したい、導入したい、というモチベーションも高く、ML Platform teamが介入する余地が大きくなりづらい構造がありました。

逆に言うと、MLエンジニアの職掌が分析やコンサルに閉じており、システム構築はBackendやSysML専門のエンジニアが実施するという分業体制の組織であれば、共通基盤を整えるための下地を比較的整えやすいということも言えるかもしれません。
Platformを検討するときは、ご自身の会社のMLエンジニアのJob Descriptionも確認しておくと良いと思います。

最後に

以上、メルペイのML Platformチームの成り立ちと顛末をお話してきました。
私は決して、MLの共通基盤化を否定したくてこの記事を書いているのではありません。様々な前提の違いによって、十分に機能するケースはあると思います。
大事なことは、共通基盤化の必要性や実現性について、複数のMLシステムの差分、各チームやメンバーの向かいたい方向性、その時点での最新の技術動向、共通化の上で障害になるような体制上の問題などを、総合的に俯瞰した上で判断する必要があるということです。
この記事が、MLチームの共通基盤化を検討している方々にとって、何がしかの参考になれば幸いです。

明日の記事は abcdefujiさんです。引き続きお楽しみください。