MonotaRO(モノタロウ)では、全社的にデータ活用研修を行うなど、数字に基づいた意思決定を行うデータドリブンな経営が根付いています。事業者向けECサイトとして、モノを買う時にかかる手間や時間を短縮し、顧客である事業者の時間を創出することが、モノタロウの提供価値です。この価値をさらに高めるため、「ほしいものがすぐ見つかる」という顧客体験の向上に注力しています。
その中心的な役割を担うのが、機械学習（ML）を活用した顧客体験の最適化です。MLエンジニアリング（MLE）チームは、この重要なテーマの最前線に立ち、日々革新的なソリューションの開発に取り組んでいます。
データサイエンスのアルゴリズムを実用的なサービスへと昇華させる重要な役割を果たすMLEチーム。高度な検索・推薦システムの構築から、大規模データパイプラインの設計、リアルタイムユーザー行動データを用いた実装まで、幅広い技術的課題にチャレンジしています。特に商品購入の効率化を上げるためのリアルタイムパーソナライゼーションに注力しており、ユーザーが求める商品を推定する仕組みの高度化を進めています。
本記事では、MLEチームリーダーの川口とデータサイエンスグループ長の青井に、チームのミッション、現在進行中のプロジェクト、そして今後の展望について詳しく伺いました。モノタロウがどのようにして最先端の技術スタックを駆使し、次世代のEC基盤を構築しようとしているのか、その舞台裏に迫ります。
データサイエンスとWebサービスを橋渡しするMLEチーム
——MLEチームの組織構造と、モノタロウ全体における位置づけについて教えてください。
川口： MLEチームは、CXマネジメント部門内のデータサイエンス（DS）-Bグループに所属しています。現在5名体制で運営しており、私がチームリーダーを務めています。CXマネジメント部門全体としては、「優れた顧客体験を提供し続けることで、LTV(顧客生涯価値)最大化を実現する」というミッションのもと、さまざまな取り組みを展開しています。
青井： 私はDS-Bグループのグループ長を務めています。当グループには、MLEチームに加えて2つの推薦アルゴリズムチームが属しています。
モノタロウ全体のミッションである「資材調達ネットワークを変革する」に基づき、当社ではセールス、マーケティング、商品調達、サプライチェーンまで一貫したサービスを提供しています。モノタロウでは、これらすべての領域においてDSの活用を推進しており、私たちのグループでは検索推薦におけるDSの活用を主に担っています。
近年、検索や推薦サービスにおける需給マッチングにおいて機械学習（ML）の重要性が高まっています。モノタロウではマーケティングや推薦サービスを中心に以前からMLの活用に取り組んできましたが、MLの適用領域拡大やサービスの高度化に向けてMLEチームを発足させました。
——MLEチームの具体的なミッションや役割について、もう少し詳しくお聞かせいただけますか。
川口： MLEチームの主な領域は、ECサイトの機能・サービス開発と基盤開発の2つです。私たちの役割は、データサイエンティストチームが考案した施策を実際のユーザーに届けるまでの橋渡し役です。つまり、エンジニアリングを専門領域としていないデータサイエンティストチームと、Webサービス開発に特化したエンジニアリングチームの間を埋める存在だといえます。
チーム発足後、我々は2つの具体的なミッションを定めました。1つ目は「DSアルゴリズムを高速かつ最大限にユーザーへデリバリーする」こと。これは、DSチームが開発したアルゴリズムを効果的にユーザーに提供するという意味です。2つ目は「DSチームがアルゴリズムを構築できる環境を整備する」こと。具体的には、バッチスケジューラーやVMインスタンスの整備など、アルゴリズムの検証に必要な環境の開発・運用を行っています。
MLEチームの部門横断型開発スタイル
——MLEチーム内の普段のコミュニケーションはどのようにされていますか。
川口： 前提として、私は東京在住で、他のチームメンバーは皆大阪在住です。なので、基本的にミーティングはオンラインとなっていて、毎日Zoomにて朝会を行うことで1日のコミュニケーションを始めています。メンバーが困った際には、スポットでオンラインミーティングを入れたり、チャットツールで相談をしたりしています。
青井： また、開発手法としてはスクラムを採用しているので、2週間ごとにレビューとプランニングの時間を設けて、チーム全体の進捗確認をするようにしています。
——開発期間はだいたいどれくらいになりますか。
川口： プロジェクトの規模や複雑さによって開発期間は大きく異なります。一般的には1〜2か月程度で完了することが多いです。
たとえば、アルゴリズムがすでに確定していて、既存システムの更新を行う場合は、1か月以内で完了することが多いです。新規システムの構築を含む場合は、余裕を持って2か月程度を見積もります。
一方で、些細な変更であれば1週間もかからずに完了することもあります。しかし、システム性能を維持しつつ大規模なデータを扱うような複雑なプロジェクトになると、半年程度の期間を要することもあります。
実際の開発現場では、これらの異なる規模や期間のプロジェクトが常に並行して進行しているイメージですね。
——MLEチームは他のチームとどのように連携していますか。
川口： 社内の複数の部門・チームと密接に連携しています。主なステークホルダーとしては、まずCXマネジメント部門内のプロダクトオーナーや案件オーナーがいます。また、ECサイトの開発を担当するECシステムエンジニアリング（ECSE）部門、そして共通システムの開発や開発効率の向上を担うプラットフォームエンジニアリング（PE）部門とも緊密に協働しています。
青井： MLEチームには、顧客体験の向上という観点からシステム設計や機能開発を行うことを期待しています。そのため、単独で動くのではなく、さまざまな専門性を持つメンバーと協力して取り組むことが重要です。
具体的には、各ビジネスドメインごとに、エンジニア、デザイナー、データサイエンティストがクロスファンクショナルにチームを組んで「プロデュースチーム」を構成しています。このチームの中で、プロダクトの価値向上について活発な議論を行い、それぞれの専門性を活かしたアイデアを出し合っています。
——他チームとの連携が多いということですが、実際の開発プロセスはどのように進行するのでしょうか。
川口： 検索や推薦サービスの開発プロセスは通常、プロデューサーやデータサイエンティストによる施策立案から始まります。彼らが作成する企画書（Design Doc）には、施策の概要、目的、そしてユーザー視点での機能説明などが記載されます。
このDesign DocをMLEチームが受け取った後、サイトを開発しているECSE部門とミーティングを行い、詳細なシステム要件を決定します。この段階では、インターフェース設計やWebサービス側のサーバーと我々のサーバーの連携方法などの技術的な詳細を詰めていきます。これらの内容もDesign Docに追記し、設計が完了した時点で実装フェーズに移ります。
開発においては、チームメンバーにある程度の裁量を持たせています。細かな改善や調整は、メンバー間でのコードレビューを通じて進めていきます。
MLEチームが開発を担うマイクロサービスを対象とした場合、最終的にはECSE部門にAPIを提供することで開発が完了します。
——案件を進めるうえで、どのようなことに気をつけていますか。
川口： チームリーダーとしては、メンバーの開発体験を重視し、私自身が案件を抱え込みすぎたりスタックしたりしないよう注意しています。また、MLEチームは、部門をまたいだコミュニケーションが多く発生する部署なので、メンバーには各々のチームの開発体験をWin-Winにするような観点を持ってほしいと伝えています。我々はデータサイエンティストとエンジニアの橋渡しを行う組織なので、他部門との良好な関係維持が極めて重要です。MLEチームの対応が原因で他部門の開発体験が悪化すると、将来的に案件を依頼されなくなるリスクがあります。
さらに、MLEチームはさまざまな領域をカバーしているため、開発プロセス全体の非効率な部分も見えやすい立場にあります。そのため、積極的に課題を発見し、解決策を提案・共有することで、組織全体の改善に貢献できると考えています。
リアルタイムデータで顧客体験を変える
——MLEチームの現在の主要プロジェクトについて、詳しくお聞かせください。特に機能・サービス開発の面ではどのような取り組みをされていますか。
青井： 直近の最重要課題は、検索・推薦システムにMLを活用し、機能の高度化を通じてサービスの利便性を向上させることです。特に注力しているのは、ユーザーの属性や行動をリアルタイムで分析し、それに基づいて必要な情報を即座に提供する仕組みの構築です。
MLの活用は3段階で進化してきました。まず、事前にMLで計算したデータを利用する方法から始まり、MLEチーム発足後は、APIを提供することでECサイトに訪問した顧客にリアルタイムで検索・推薦結果を返せるようになりました。さらに現在は、ユーザーのリアルタイムの行動を基にMLモデルによる検索・推薦結果を作成できるまでに進化しています。これにより、初めてサイトを訪れたユーザーでも、その場での行動を分析し、最適な商品を提案することが可能になりました。
川口： 既存システムが抱える問題の解決にも取り組む必要があります。純粋に検索・推薦をサービスとして提供するシステムは既存のものが存在していますが、より高度なMLアルゴリズムを導入し、大量のデータを処理しようとすると、既存システムの複雑性と規模が急激に増大してしまう問題がありました。
この課題に対処するため、現在はマイクロサービスアーキテクチャを採用しています。具体的には、APIを新たに構築し、既存システムからこのAPIを呼び出すことで、推薦したい商品一覧の生成や検索結果のリランキングなどを行っています。
——基盤開発の面では、どのような取り組みが行われていますか。
青井： 検索・推薦を中心としたプロダクト開発においては、MLモデル自体はもちろん、それにデータを供給するデータパイプライン、そしてMLモデルを定期的に更新するための基盤整備が非常に重要です。これらは提供するサービスの品質と関わりが大きく、自社の競争力につながるものだと考えています。
川口： 当社のデータパイプラインは、バッチデータ用とリアルタイムデータ用の大きく2種類があります。弊社のバッチ用のデータパイプラインでは、データレイクにログを集約し、ログを整備したのち、構造化したログデータをデータウェアハウス（DWH）に蓄積、最後に用途に応じたデータの一部を抽出しデータストアに格納するという流れになっています（下記の図を参照）。
DWHにはGoogle BigQueryを採用していますが、BigQueryは高速なデータ解析が可能である一方、データ取得に時間がかかる場合があります。そのため、ユーザー体験を損なわないよう、BigQueryを直接APIで呼び出すことは避け、BigQueryから必要なデータを抽出し、高速なデータ取得に特化したデータストアへ転送しています。いわゆる、Reverse ETLです。これにより、データ取得のパフォーマンスを確保しています。
一方、リアルタイムデータ用のデータパイプラインでは、DWHを介在させずに、整備済みユーザ行動データをリアルタイムにデータストアであるBigtableへ格納することで、リアルタイム性を向上させています。しかし、リアルタイムデータ用パイプラインは下記の図の通り、Streaming Reverse ETLをデータ種別毎に構築しなければならず、また常に稼働しているので、バッチデータと比較して開発/運用コストが高いという欠点があります。
——MLEチームが扱っているデータの種類や特性について、詳しく教えていただけますか。
川口： バッチデータは、たとえば1日前のユーザー行動データを集計し、それを基にサービスを提供するといった使い方をしています。これはもともと用いられていた手法です。
一方、リアルタイムデータは、より即時性の高い情報を提供するために使用します。典型的な例としては、あるWebページで閲覧した商品情報を、次に遷移したページの表示内容に即座に反映させるといったものがあります。時間としてはだいたい数十秒程度です。このように、リアルタイムデータの扱いは非常にシビアですが、それだけ顧客体験の向上に大きく貢献する可能性を秘めています。
——リアルタイムデータの有効性はどのように確認したのでしょうか
青井： 当初、検索・推薦サービスは主に過去の注文履歴などのバッチデータを基に構築されていました。しかし、サービスの利便性をさらに向上させるには、リアルタイム性の高い情報を元にした推薦が必要だと考えました。
そこで約5年前に、ユーザーの行動をリアルタイムで捉え、それを即座に検索・推薦に反映させる取り組みを開始しました。最初のステップとして、リアルタイムデータをMLモデルに反映させるPoCを行い、その有効性を確認しました。
この手法を用いることで、初めてモノタロウを訪れたお客さまでも、その場での行動を分析し、真に必要としている商品をWebページ上で提案することが可能となります。実際にPoCを通じて、お客さまの利用率向上も確認できました。この成功を受けて、MLEチームを新設し、MLモデルの適用範囲を拡大してきました。
MLOpsの深化に向け、モノタロウ独自のアプローチを模索する
——現在のMLEチームに至るまでに、特に成功した取り組みや、苦労しながらも成果を上げた経験などがあれば教えていただけますか。
青井： MLの活用領域を見出すうえでは、小さなPoCから始めるアプローチが非常に効果的でした。APIやデータパイプラインの構築には相当な工数がかかるため、事前にその有効性を確認することが極めて重要です。成功事例が蓄積され、現在ではMLを活用できる領域が大幅に拡大しています。
川口： チーム発足から日が浅いにもかかわらず、社内の他チームとの信頼関係構築に成功したことも大きな成果だと考えています。我々のチームには、深いドメイン知識を持ち、システムの核心に迫る議論ができるメンバーがいます。そのため、システムの刷新やリファクタリングの際にもリーダーシップを発揮できています。こうした活動を通じて、MLEチームへの信頼感を高めることができました。
——その一方で、困難に直面して試行錯誤を重ねた経験もあったのではないでしょうか。
青井： PoCで開発したシステムを本番環境に移行する際、「小さく始めて徐々に拡大する」という方針を実現するための仕組みづくりに苦心しました。システムの数を増やすなかで、共通機能の標準化に取り組みつつ、DevOps・MLOps導入に向けた動きも進めてきました。
川口： MLOpsの実践においては、車輪の再開発を避けるため、さまざまな取り組みを行いました。たとえば、頻繁に使用されるデータを格納するデータストアの構築・整備、MLモデル運用の方針策定などです。これらの努力を通じて、徐々に効率的な仕組みが整いつつあります。
青井： データエンジニアリングの面でも、データの加工処理や管理を共通化する取り組みなど、さまざまな試行錯誤がありました。
——そうした取り組みは、チーム内での独自の議論から生まれるものなのでしょうか。それとも業界で確立されたベストプラクティスを採用されているのですか。
青井： 既存のフレームワークや事例を参考にはしていますが、そのまま適用できるケースは実際には少ないのが現状です。そのため、モノタロウ特有のドメインや課題をどのように解決すべきかを重点的に考えています。
川口： 特にMLOpsに関しては、業界全体でも定義や実践方法が企業ごとに異なり、明確な「正解」が存在しない状況です。DevOpsと比較すると、MLOpsを積極的に導入している企業はまだ少なく、参考にできる事例も限られています。そのため、MLOpsの範囲や具体的な施策については、私たちで独自に定義し、考えていく必要があります。
青井： プロダクト開発の面でも、モノタロウ特有の要素を考慮することが非常に重要です。当社の特徴は、顧客層と取り扱う商材の多様性にあります。たとえば、顧客の商品ページの閲覧パターンや注文行動を分析する際も、データストアでのデータ処理に関して多くの選択肢を検討する必要があります。
さらに、効果的なサービス開発のためのロジック構築や、顧客の行動に合わせたリアルタイムでのサービス提供など、モノタロウならではの課題が数多く存在します。これらの課題に対して、既存のソリューションをそのまま適用するのではなく、当社の特性に合わせたアプローチを常に模索しています。
MLEチームが描く次世代EC基盤の未来
——MLEチームの今後の展望や、中長期的な目標についてお聞かせください。
川口：MLEチームの展望は大きく2つの方向性があります。1つは既存領域の深化と拡大、もう1つは新規領域への展開です。
既存領域では、現在注力している検索・推薦システムのさらなる高度化を進めます。これは当社の強みをより強固にするための重要な取り組みです。同時に、この領域でのML活用をさらに拡大し、リアルタイムパーソナライゼーションの強化にも取り組んでいきます。
もう1つの新規領域としては、販促、広告などの分野へのML適用を計画しています。たとえば販促・広告では、ROIの最適化やターゲティング精度向上などが具体的な目標となります。これまでは事前にバッチで集計した情報をもとに販促の対象ユーザーや推薦の最適化を行っていましたが、APIが提供する情報をもとにリアルタイムで販促を最適化することができるようになります。
青井： こうした展開に伴い、MLEチームの規模拡大は必須だと考えています。特に、検索・推薦以外の新しいドメインが増えていくことを見据えると、各専門領域をリードできる人材が必要になってきます。そのため、各ドメインを牽引できるリーダー的存在の獲得や育成も重要な課題です。
これにより、新機能の開発や技術的負債への対応など、各チームが自らのプロダクトの効率化を主体的に進めることができます。今後も、会社全体の目標とチームの活動を紐づけて、システムをドメインごとに分け、各チームの役割をより明確にしていく方針です。
——次世代EC基盤の実現に向けた技術的な挑戦やおもしろさはどこにありますか。
川口：主な技術的チャレンジは、データパイプラインへの要求の多様化とMLモデル運用の高度化の2点です。
１.データパイプラインへの要求の多様化
青井：データパイプラインについては、データ量・種類の増加への対応はもちろん、それらを利用する検索・推薦サービスが増えることによって影響範囲が拡大するため、より高い水準の品質管理が求められるようになります。
たとえば、我々が開発したAPIを参照するサービスが増えるなかで最適化を進めようとすると、データベースに求められる要件も多様化していきます。そのため、要件に応じたデータベースの使い分けや設定見直しの必要性が増しており、適切なデータベース設計が重要になっています。
２. MLモデルのサービング
青井：モデル自体の増加やサイズの拡大に伴い、APIのレイテンシが重要な課題となっています。MLモデルのサイズや取得する特徴量データの規模と、検索・推薦結果の表示速度とのバランスを取りながら、いかに体験の良いサービスを提供できるかが大きなチャレンジです。
また、MLモデルの品質保証も重要な課題です。現在は、MLモデルへの入出力データの分布変化の監視をはじめ、MLモデルの予測性能を継続的に担保するための仕組みづくりや独自のモニタリング手法の開発にも取り組んでいます。MLモデルの高度化にあたっては、監視すべき要素がさらに増えていくため、MLモデルの利用方法に応じた品質保証の仕組みを設計していく必要があると考えています。
——検索・推薦以外のドメインにML活用を展開していくにあたってのチャレンジはありますか。
青井：新たなドメインへの展開です。たとえば、販促や広告では広告出稿におけるROIの最適化のためのML手法、物流では入荷する商品の属性に応じた需要予測のための時系列解析など、検索・推薦とは異なる知識や手法が求められます。それらを実現するためのデータアーキテクチャやMLシステムの選定についても、検索・推薦とは異なる部分が多いと考えています。
さらに、複数ドメインを並列して管理していくこと自体が新たなチャレンジとなります。検索・推薦という限定された領域においてすら、ドメイン知識の共有やシステムの共通化は簡単ではありません。これをさらに別の複数ドメインに展開していくにあたって、どのようにデータ設計していくかは、技術的にも組織的にも新たな挑戦が待っていると思っています。
——そこに向けて、MLEチームのメンバーとしてはどのような知識や経験が求められるでしょうか。
川口： APIやWebサービスの開発経験、特にバックエンド開発のスキルが重要です。即戦力として活躍していただくためには、これらの経験は必須といえるでしょう。
クラウドの経験はあるとよいですが、クラウドプラットフォームについては特定の技術に限定せず柔軟に考えています。
私自身の経験を例にあげると、現在はKubernetesなどを用いてデータパイプラインをはじめとするさまざまな開発に携わっています。しかし、入社以前はそれらの技術に関する知識は全くない状態で、入社後に業務を通じて多様な知識を学びました。現状のスキルや知識というよりは、新しい技術に柔軟に対応し、学び続ける姿勢が大切です。
また、データサイエンスや機械学習への興味は重要な要素です。少しでもこうした分野への関心があれば、チームの施策改善により積極的に関わっていただけると考えています。
青井： MLEチームでは、チームでのシステム運用開発経験をお持ちの方を求めています。私たちは、単に個人の技術力だけでなく、チームとしてサービス開発を進められる協調性も重視しています。
また、システムの改善活動に積極的に取り組む姿勢も大切だと考えています。しかし、それ以上に重要なのは、事業開発への興味です。技術面だけでなく、ビジネスの観点からも改善提案ができる方は、チームにとって大きな力になると信じています。
——記事を読んでいただいた方に最後に一言お願いいたします。 現在、開発領域や案件数が拡大しており、チームとしても拡大時期に入ってきております。技術を通じてビジネスに貢献したいとお考えの方、データサイエンスをエンジニアリングから支えていきたいとお考えの方であれば、私たちのチームは良い選択肢になるかもしれません。ご興味があれば、是非カジュアル面談のご応募ください。モノタロウの次世代のEC体験を一緒に創造していく仲間として、MLEチームに来てくださる方をお待ちしております。
当記事を通じてMonotaROに興味を持っていただいた方は、カジュアル面談もやっていますのでぜひご連絡ください。 チームの採用募集も合わせてご覧ください。
