Blog

<p>「MERCARI GEARS Lecture Series」は、株式会社メルカリをはじめとするメルカリグループ各社が、これから目指す方向や、技術的なチャレンジについて紹介するエンジニア向けの動画シリーズです。</p>
<p>今回のMERCARI GEARSでは、メルカリのEdge AIチームが開発する、iOSとWebのリアルタイム商品スキャン機能について紹介しています。</p>
<p><center><br />
<iframe loading="lazy" width="560" height="315" src="https://www.youtube.com/embed/cKBzwB5StLY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><br />
Edge AI - Realtime Item Scan for iOS and Web [AI@Mercari]<br />
</center></p>
<p>メルカリでは「AI出品」と呼ばれる、出品する商品写真をアップロードした際、そのアイテムのカテゴリやブランド、売れやすい価格などを提案する機能があります。</p>
<p>「AI出品」でレコメンドを行うには、商品写真を撮影・アップロードする必要があったのですが、今回Edge AIチームは、カメラを起動し、商品にピントを合わせた時点でアイテムのレコメンドを可能にしました。</p>
<p>より素早く・快適な出品体験を実現するために、近年のスマートフォンの進化を利用した計算コストの低いMLモデルを実現しました。その結果、計算サーバーと往復させることなく、スマートフォン上で直接提案を行うことができるようになりました。</p>
<p>学習モデルへの量子化の適応・推論を行うための処理時間・デバイスとの相性の改善、実装後のパフォーマンスモニタリングのツール開発…等、さまざまなポイントに関して工夫を行っており、動画内で詳しく解説をしております。ぜひご覧ください。</p>


Edge AIチームが実現する、iOSとWebのリアルタイム出品スキャン

<p>「<a href="https://medium.com/mercari-engineering" title="Making Mercari">Making Mercari</a>」は、メルカリのUS事業のエンジニアリングブログです。今後、「Making Mercari」に投稿されたAI関連の投稿について、本Webサイトでもご紹介していきます。</p>
<hr />
<p>今回は、メルカリUSのマシンラーニングプラットフォームのソフトウェアエンジニア・Abhishek Munagekarによる投稿を紹介します。本ブログポストでは、機械学習のトレーニングのためのコンピューティングリソースのコストを最適化した方法について紹介しています。具体的には、機械学習のトレーニング用のKubernetesクラスターのダウンスケールに課題があり、PodDisruptionBudget、専用のnode pool、Gatekeeper Assign CRDを組み合わせて利用することでそれを解決しています。</p>
<p><a href="https://medium.com/mercari-engineering/how-we-optimized-our-machine-learning-training-infrastructure-costs-c2a64f7451bb" title="**How we optimized our Machine Learning Training Infrastructure Costs | by Abhishek Munagekar | Making Mercari | Apr, 2022 | Medium**"><strong>How we optimized our Machine Learning Training Infrastructure Costs | by Abhishek Munagekar | Making Mercari | Apr, 2022 | Medium</strong></a><br />
※こちらの記事は英語でのポストとなっています</p>


メルカリUSで機械学習のトレーニングインフラコストを最適化した方法

Interview

<p><a href="https://ai.mercari.com/articles/ai/suadd_kimuras_1/">「AI出品、パーソナライゼーション… CEO 山田進太郎・Director 木村俊也が振り返る、メルカリのAI活用の歩み」</a>では、メルカリが2017年からリリースした「AI出品」「おすすめタイムライン」「画像検索」など、AI技術を搭載した様々な機能を振り返り、当時メルカリがAI活用を積極的に進めた背景や課題ついて、対話が繰り広げられました。本記事では、メルカリの考える循環型社会を達成するためのAI倫理、そして具体的な道筋について議論しています。</p>
<h2>メルカリが「循環型社会」というキーワードにたどり着くまで</h2>
<p>木村俊也（以下、木村）：メルカリはいつから「循環型社会」をキーワードとして掲げ始めたのでしょうか。</p>
<p>山田進太郎（以下、山田）：2019年9月頃からでしょうか。これまでも課題意識は組織としてもっていましたが、2019年の1月頃にESGに関する社内議論を本格的に開始。循環型社会はメルカリがど真ん中で取り組むべき課題であると感じました。まずは、メルカリとしてのマテリアリティの特定と、やるべきことの課題化を行い、第一弾のサステナビリティレポートを出しました。</p>
<p>メルカリの現在のお客さまの数は月間2,000万人以上。今後、3,000万人、4,000万人…と多くの方に使っていただけるサービスになるにあたって「あったら便利」を超えて「社会になくてはならない」存在になるべきだと考えています。そのために昨年以来有識者とのディスカッションを経て、我々のプラットフォームとしての思想や、マーケットプレイスの基本原則を定めました。メルカリが循環型社会への貢献責任を果たすことは、我々のビジネス上の成長にも繋がっていく、という道筋が見えてきました。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/02/4d2363c1-image1-1024x683.jpg" alt="" /></p>
<p>この数年で、コロナの影響もあって自然環境への関心は急速に高まっています。温暖化の進行や、大量廃棄も大きな問題になってきてます。資源を無駄に使っている状況は、社会全体で対応すべき問題ですよね。モノ自体が使えるうちは、きちんと循環させて使っていくべき、という世界になるべきだと考えています。そうした循環型社会において、メルカリがどう必要不可欠な存在になれるかを常に考えています。メルカリのサービスのどういう点が、今の社会に対してバリューを出せるのかを考えた時、「循環型社会」に対する貢献は、特に大きなキーワードになると思います。</p>
<h2>145兆円分の差を埋めるために、解消すべき摩擦とは</h2>
<p>木村：モノのリユースの加速という意味では、メルカリはある程度貢献していると思います。でも、進太郎さんにとっては、まだまだなのでしょうか？</p>
<p>山田：まだまだですね。食品などリユースでないモノも含めて、日本における販売総額は小売だけでも約年間146兆円なんですよね。メルカリの総取引金額は1兆円なので、1％にも届いていません。この差が表す通り、二次流通の市場に乗らず、廃棄されているものや、死蔵しているモノがまだたくさんあると考えています。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/02/1b4220f5-image5-1024x683.jpg" alt="" /></p>
<p>例えば、家にあるものがすべてデータ化されており、一瞬で出品が完了できたら、メルカリへの出品はさらに楽になりますよね。今はまだ色々と考えて、手間をかけないと出品できない。発送方法などもまだ複雑な面がありますよね。現状のそうした摩擦を取り除ければ、もっと出品が増える。メルペイがあることでお金のやりとりも、さらにシームレスにできる。「これを買うから、これを出品してみようかな」と、さらにモノが循環するサービスにできるのではと思っています。</p>
<p>今は売り買いを能動的にやらないといけないのですが、ここはAIが威力を発揮するところだと考えています。「これを買うなら、これを売ったら？」といったらサジェスチョンを行うなど。メルカリを通じて、資源の有効活用を進められれば、より循環型社会を加速化できますよね。</p>
<h2>二次流通だけでは解決しない。一次流通との連携を進める背景</h2>
<p>木村：循環型社会にAIが貢献するというのは非常にしっくりきます。メルカリのお客さまは、自分がほしいものは自ら検索するけど、潜在的に必要なものは能動的に探していなかったりする。そうした、お客さまが潜在的に必要なものをメルカリがAIを活用して示唆する。また、お客さまの手元にあるモノの需要を示唆することで、出品するチャンスも作れますよね。メルカリはCtoC、さらにはネットショップサービス「メルカリShops」の登場によってBtoCまでも領域を拡充しています。いまは個人間のフリマアプリを超え、巨大なマーケットプレイスになりつつある。より一層、売る側も買う側のどちらも加速しないと循環していきません。マッチングの数値はビジネス戦略上でも重要視しています。そして循環型社会に貢献していくためには、一次流通の方々のご協力も必須となります。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/02/569af45c-image3-1024x683.jpg" alt="" /></p>
<p>山田：そうですね。今後この課題に対応していくためには、二次流通のマーケットが発展するだけでは難しいと考えています。二次流通市場では、何が支持されているかといったデータを、一次流通に伝えていくアプローチも進めています。モノだけではなく、データも循環させた結果、メーカーの方々は必要なプロダクトを必要な量だけ生産し、お客さまはそれを使えるだけ使う世界に少しずつ近づけられるのではと考えています。</p>
<p>現在、メーカーの方々とのデータ連携も徐々に開始しています。まだまだですが、ある程度バリューを出せる部分が見えてきました。身の回りのモノのデータ化は二次流通だけでは難しいところがどうしてもありますよね。我々メルカリが、自分たちのフィールドで全部やるのではなく、カタログ(SKU)連携を含め、データプライバシーに配慮しながら、一次流通のマーケットとさらに繋がっていくことは必要不可欠です。</p>
<h2>「AI倫理」をどう捉えるか。メルカリにおける倫理的課題</h2>
<p>木村：AIの活用は今後もメルカリを発展していく上でとても重要なテクノロジーであることは議論できましたが、AI活用の検討と同じくらい「AIをどのように倫理観を守って扱っていくか」の議論も重要だと考えています。例えば、おすすめ機能についても、お客さまのプライバシーを侵害してしまうようなデータの扱い方や、不快に思われるようなことは推薦を行ってはいけないですよね。必要なことは推薦するけれど、不必要な情報は押し付けないなどです。</p>
<p>山田：不必要な情報を押し付けないのは大事ですよね。そして、今後さらに意識していきたいのは「人類のためになるかどうか」という点です。たとえそのお客さまにとって必要なモノであっても、メルカリはメルペイでお金の部分も扱っているからこそ、より高い倫理観を持つべきです。だからこそ、例えば、返済能力を超えて、借金までしてご購入していただく状態になってはならない。メルカリは売り買いのプラットフォームで、一見すると広告分野やSNSに比べて、倫理的な問題は発生しづらいですが、ビジネス上の成長のために、どんどん買わせる、という仕組み作りは憚（はばか）られるべき。そういう意味でも、メルカリにおけるAI開発は面白い経験ができる場所ですね。過去に、誰も考えたことがないような倫理的な課題にぶつかる可能性も高いと思います。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/02/f72b46c6-image2-1024x683.jpg" alt="" /></p>
<p>木村：最近でもAIの倫理観について社内で議論をしている時に、おすすめ機能というものは、お客さまが次に購入していただけるであろう商品を予測できますが、それがお客様にとって知られたくない趣味であったり、プライバシーを阻害してしまうような推薦をしてしまうと、お客さまにとって不快感や不信感を抱かせてしまうというセンシティブな問題も起こり得るという話をしていました。</p>
<p>山田：確かに、セレンディピティとレコメンデーションのバランスが極端に偏ると気持ち悪いですよね。メルカリのアクティビティだけが全てではないので。日常的にキャンプに行っているけれど、メルカリ上ではキャンプグッズを売買していないとかはあり得ます。どのお客さまにどういった商品をおすすめするのか、倫理観を要求される。これからの課題ですね。</p>
<h2>データで本質的な価値に迫ることができる。メルカリでAIをやる面白さと道筋</h2>
<p>木村：僕らは循環型社会を実現するために、AIで需要と供給を推定し、必要なものを必要なだけ届けることを目標に掲げて取り組んでいます。しかし、正直まだ道半ばです。AIのモデル作り、そしてパーソナライズの実験を高速に進める必要があり、今後も引き続き取り組んでいきます。</p>
<p>山田：やれることも、試したいこともいっぱいありますよね。ビッグ・テックのように大勢のAI/MLエンジニアがいるわけでもありません。一方、メルカリが扱っているデータには、お客さまが撮影した商品画像やキャプション、そして値段といった、お客さまとの距離が近い情報を多く持っています。こうしたデータを持っている会社やサービスは少ないので、イノベーションを起こせる可能性はあると考えています。</p>
<p>木村：普通のECとはデータの種類も性質も違いますよね。本質的なモノの価値が分かる、というのはメルカリでAIをやる上で非常に面白いポイントです。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/02/a8b8d5d0-image4-1024x683.jpg" alt="" /></p>
<p>山田：メルペイやメルカリShopsのデータも対象ですしね。今はデータ基盤も確立され、色々と面白い挑戦ができるタイミングだと言えます。メルカリのデータ・メルカリのサービスによって何ができるか、クリエイティブに考えなければならない。</p>
<p>同時に中長期で物事を捉え、そして失敗も許容できる組織です。ロングスパンでデータをつくり変えてたり、データ基盤づくりを進めたり、人材の意味では、インド工科大学（IITs） をはじめとした各国の新卒メンバーも多い。そういう環境では、MLエンジニアを育てる風土もあると思います。共通して言えることとしては、今すぐの効果ではなく。中長期で考えているということ。そのためにAI倫理など含めて腰を据えて取り組んでいきたいですね。</p>
<p>2017年から始まったメルカリのAI活用。UI/UX改善だけでなく、メルカリをより安心・安全に使える機能を開発・提供してきました。<br />
関連記事：<a href="https://ai.mercari.com/articles/ai/suadd_kimuras_1/">AI出品、パーソナライゼーション… CEO 山田進太郎・Director 木村俊也が振り返る、メルカリのAI活用の歩み</a></p>
<p>そして今後はさらに「AIで循環型社会に貢献する」ことを目指し、新たなイノベーションを模索していきます。メルカリのAIチームは、さらなる挑戦を続けていきます。</p>
<p>Photo : Shun Nakayama (<a href="https://shunnakayama.myportfolio.com/">Web</a>/<a href="https://twitter.com/shunnakayama_">Twitter</a>)<br />
Text : Ayumi Iga (<a href="https://twitter.com/aymmm_i">Twitter</a>)</p>


循環型社会に貢献するために。メルカリのAI技術が克服すべき課題 CEO 山田進太郎×Director 木村俊也

<p>メルカリでは2017年〜2018年の間に「AI出品」「おすすめタイムライン」「画像検索」など、AI技術を搭載した様々な機能をリリースしました。これらは今でもメルカリのコア機能となっています。</p>
<p>では、その過程に何があったのか？メルカリがAI活用を積極的に進めた背景、当時の課題や組織変化について、代表取締役社長 CEOの山田進太郎と、Director of AI&amp;Searchの木村俊也が振り返ります。</p>
<h2>メルカリにはもともとデータドリブンな意思決定の土壌があった</h2>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/01/6dd58f3a-image1-1024x683.jpg" alt="" /></p>
<div style="text-align: center;">木村俊也 Director of AI&Search</div>
<p>木村俊也（以下、木村）：メルカリではこれまでもAIの活用に力をいれてきましたが、進太郎さんとしてはいつからAIを力をいれていくぞ、というスイッチが入ったんでしょうか。</p>
<p>山田進太郎（以下、山田）：メルカリはもともとゲーム開発をしていたメンバーが多く参加している会社でした。僕もZyngaという会社にいましたし、特にメルカリ創業当時はディー・エヌ・エーやミクシィから入社したメンバーも多くいて。ガラケーのゲームサービスをつくっていた時代から、スマホ文化に移行しても、引き続きデータを用いる重要性はみんなが感じていたんですよね。だからA/Bテストを行って、データドリブンな意思決定・プロダクト開発を行ってきました。</p>
<p>木村：進太郎さん自身の原体験からの影響もあるのでしょうか？</p>
<p>山田：Zyngaにいたころ、システム開発を進めるうえで、ボタンの色の選定や新しいゲームシステムの試行などにA/Bテストを積極的に活用していました。PDCAをまわすことでお客さまのリテンションが向上したり、売上も上がるなど、ビジネス上のインパクトを実感していました。メルカリをリリースした2013年当時は、まだBigQueryもなかったのですが、データエンハンスメントは最初から行っていましたね。それらのシステムを活用して、より付加価値が高いデータの活用法が見えてきて、その中にAIと機械学習（マシンラーニング）もありました。</p>
<p>木村：それはいつ頃の出来事ですか？</p>
<p>山田：AIの中でもディープラーニングの積極的な活用が世の中に広く認知され始めたのは2015〜2016年頃だったと記憶しています。自分たちもAIを使って色々な機能を開発できるのでは？と考え、開発を開始し、2017年にはAI出品など、機械学習を取り入れたプロダクト開発を開始しました。</p>
<h2>AI活用が進んだきっかけは、中国企業のデータ活用を目の当たりにしたこと</h2>
<p>木村：進太郎さん自身が、個人的にAIの力を感じ、積極的にAI利活用を進めたいと考えられたのは何かきっかけなどもあったんでしょうか。<br />
山田：社内の動きを振り返ると今お話ししたような流れですが、個人的には、中国で様々なサービスがAIを活用していたことが強く印象に残っています。当時はメルペイの立ち上げ期で、中国に限らず、色々な国のFinTechサービスのリサーチに行くメンバーが多く、社内で数多くレポートあがってきていました。2017年の夏には、私も入社前の青柳（青柳直樹・メルペイ代表取締役 CEO 兼 株式会社メルコイン代表取締役 CEO）と中国を訪れました。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/01/1581af58-image5-1024x683.jpg" alt="" /><br />
<strong></p>
<div style="text-align: center;">山田進太郎 メルカリ代表取締役CEO（社長）</div>
<p></strong></p>
<p>その後、日本でもTikTokで有名になるByteDanceでは、头条（トウティアオ）というディープラーニングを活用してパーソナライズされたニュースサービスを展開していました。日本だとSmartNewsに似たサービスですね。美団（メイタン）は食べログのようなグルメサイト、大衆点評（ダージョンディエンピン）を展開し、その後は食品デリバリー、さらにライドシェアへ進出。どちらもAI活用が進んでいました。百度（バイドゥ）による検索サービスもすごかったですね。</p>
<p>彼らに共通していたのは、利用者のデータを集め、そのデータをビジネスストラテジーの中心に据え、どう活用できるか、何ができるか考えてサービスを展開していた点です。美団（メイタン）の場合、食品デリバリーのバイクの走行データなどを用いて、ライドシェアに参入したところでした。</p>
<p>当時見た中国で勢いのある会社が、優れたデータ活用を行っている、データカンパニーだったことで「こうするといろんな事業展開ができるんだ」という実感を持てました。WeChatPayやAlipayなどを見ても、この先に新しい金融の形ができるのでは、と。</p>
<p>木村：たしかに、2017年当時の中国企業のデータ活用は衝撃がありましたよね。</p>
<h2>「おすすめタイムライン」「AI出品」メルカリのコア機能の実装を開始</h2>
<p>木村：メルカリでのAI活用はまず、「AI出品」という機能が開発されました。これは写真を撮影すると、商品の情報のサジェストし、さらには値段の推定までも行ってくれる機能です。世の中にインパクトを与え、今でもこの機能がメルカリのいいところだという声もあるほど、便利な機能だと感じています。進太郎さんは当時どう感じられたのでしょうか。</p>
<p>山田：まず単純に「AIってここまで来ているんだな」と感じました。商品を携帯で撮影し、商品やブランドの識別、さらに値段の推定まで行うものでした。機能の概要を聞いた時は、正直そこまでの精度は出ないだろうと思っていた自分がいました。しかしプロダクト側の提案を受けて実装を進め、実際の機能を触ってみたところ、想定以上に精度が高く出ており、本当に驚きました。画像認識の技術をきちんと実装し、メルカリにマッチする形で機能に落とし込む。実際に、出品画面が表示されてから、出品完了するまでの出品完了率も明確に向上しましたね。この一連の経験を経て、これからにさらに技術投資の必要性を感じました。</p>
<p><iframe loading="lazy" width="560" height="315" src="https://www.youtube.com/embed/NHxc2m3SEL8?controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p>
<p><strong></p>
<div style="text-align: center;">AI出品機能の紹介動画</div>
<p></strong></p>
<p>その後は、タイムラインに表示される商品の並び順をパーソナライズする「おすすめタイムライン」の実装を行いましたよね。当時メルカリはタイムラインはすべての商品カテゴリを新着順で表示するだけだったんですが、お客さまの閲覧履歴から興味のあるジャンルを推定して、タイムラインに出す機能をリリースしました。この機能は非常に効果があり、総取引金額の面でも大きなインパクトがありました。</p>
<p>木村：自分が買いたいと思えるモノの一歩先、あるいは斜め先のようなサジェストをしてくれるのがAIの醍醐味ですよね。</p>
<p>山田：AIの良いところは、人間によるルールベースの表示順を構成するわけではなく、様々なデータを扱って処理を行い、適切なアウトプットを自動で導くことができる点だと考えています。どのセグメントのお客さまに対して、どのカテゴリの数字を変えるのか。反応が優れない時にはどう調整するのか。そうした複雑なオートメーションを行えるのが、AIの優れた点です。头条（トウティアオ）や美団（メイタン）がやってきた、パーソナライズサービスにもアイディアを受けています。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/01/2f7d3cdf-image4-1024x683.jpg" alt="" /></p>
<h2>急拡大する組織ではあえて足並みは揃えず、必要な時にシナジーを生む</h2>
<p>山田：木村さんが入社された当時、組織面はどんな状況でしたか？</p>
<p>木村：僕が入社した2017年7月、当時はエンジニア今ほど多くありませんでした。まだAIチームもなかったですね。AIを活用した開発は、現在はMLエンジニアとして活躍していますが、以前はバックエンドエンジニアが開発を担当していました。AIチームができたのは2018年初頭だったと記憶しています。違反検知やAI出品・写真検索・プライスサジェスチョンや、US版メルカリの重量推定や配送方法推薦といったさまざまなプロジェクトにAIエンジニアがアサインされていました。</p>
<p>当時メルペイもできたりと、組織としては大きくなりつつも、同時にプロジェクトは細分化していました。MLエンジニアも、メルペイやUS版メルカリといった各組織に所属が分かれていきました。そうした中で、AI開発の足並みをあえて揃えず、各組織で開発を進めていきました。連携を密にするあまり、開発が遅くなるよりも、それぞれの組織が独立して開発を進めつつ、ゆるくつながる。スピードを重視しつつ、必要な場面でシナジーを生む。メルカリのサービスが多様化・グローバル化する状況の中で、それぞれの組織がAIを活用した開発を行うこの状況は非常に面白いなと思っています。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/01/3caec9fc-image3-1024x683.jpg" alt="" /></p>
<h2>AI活用を進める上で大きな課題となった、データ整備のプロジェクトとは</h2>
<p>山田：当時から考えるとかなり人も増えましたよね。今は数百人というエンジニアが所属しています。A/Bテストの枠がいっぱいになってしまい、コンフリクトしはじめてしまった時期もありました。その頃から、A/Bテストの自動化は必須だなと課題に感じていたんです。また、そのフェーズに至るまでにデータ取得の仕組みが整理されていることは、極めて大事だなと感じました。</p>
<p>2019年当時、メルカリはすでに、多くのお客さまに使っていただいているサービスに成長していたのですが、  データの取得方法が統一されていなかったり、データの保存箇所がばらばらであったり、といった課題がありました。その後、データ取得体制を刷新するためのプロジェクトを開始しましたよね。</p>
<p>木村：きちんとしたデータ基盤の整備は2019年頃に初めて取り組みましたね。背景として、データドリブンな意思決定を促進したり、AI開発の期待値が高まっていたことから、データの正確性や即時性を高める必要性が全社的にも高まっていた。AI活用やデータドリブンな意思決定を強化するためにも、現状メルカリの取得しているデータの構造や取得方法を再整備する必要が生まれたのです。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/01/222f69c7-image6-1024x683.jpg" alt="" /></p>
<p>当時は、分析の柔軟性を重視していたために、データの保存がかなり自由で簡単にできる仕組みでした。そのため、大量なデータがデータベースに保存されるようになって、データのメンテナンスやマネージメントが徐々に困難になってきたのです。データマネジメントについても議論が起こっており、リーガル観点、エンジニア観点、アナリティクス観点でそれぞれのステークホルダーに独自の意見がある。そんな中でメルペイの開発も開始し、状況はかなり複雑化していきました。</p>
<p>これは現在でも全社的に取り組む必要がある＝ステークホルダーも非常に多い課題です。次期メルカリジャパンCEOのJeffが取りまとめを行いって、実装を進め、全社的なコンセンサスを得て、その後はデータの取得法や保存方法が統一され、かつリアルタイムにデータを保存ができる、より堅牢性が高いデータプラットフォームとなりました。さらに現在はデータガバナンスも整えるプロジェクトが全社的にも進んでいます。</p>
<p><img src="https://storage.googleapis.com/prd-ai-asset/2022/01/a7895e3d-image2-1024x683.jpg" alt="" /></p>
<p>関連記事：<br />
<a href="https://ai.mercari.com/articles/ai/suadd_kimuras_2/">循環型社会に貢献するために。メルカリのAI技術が克服すべき課題とは CEO 山田進太郎×Director 木村俊也</a></p>
<p>Photo : Shun Nakayama (<a href="https://shunnakayama.myportfolio.com/">Web</a>/<a href="https://twitter.com/shunnakayama_">Twitter</a>)<br />
Text : Ayumi Iga (<a href="https://twitter.com/aymmm_i">Twitter</a>)</p>


AI出品、画像検索… CEO 山田進太郎・Director 木村俊也が振り返る、メルカリのAI活用の歩み

<p>「MERCARI GEARS Lecture Series」は、株式会社メルカリをはじめとするメルカリグループ各社が、これから目指す方向や、これから取り組む技術的なチャレンジについて紹介するエンジニア向けの動画シリーズです。</p>
<p>今回のMERCARI GEARSでは、メルカリのTnSチーム（Trust and Safetyチーム）が開発する、モデレーションシステムの構築について焦点を当てて紹介しています。</p>
<p><center><br />
<iframe loading="lazy" width="560" height="315" src="https://www.youtube.com/embed/STmIHmDCnfI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><br />
Violation Detection Using Machine Learning at Mercari [AI@Mercari]<br />
</center></p>
<p>モデレーションシステムとは、あんしん・あんぜんなマーケットプレイスを提供するためにCS（Customer Success）チームが使用するシステムで、マーケットポリシーに違反する可能性があるアイテムを機械学習を用いて検知しています。</p>
<p>より安全なマーケットプレイスを実現するために、モデレーションシステムのシステムアーキテクチャ・マーケットポリシーごとの別々のモデル・CSと連携したリクエスト処理等の工夫をしており、動画ではその説明をしていますのでぜひご覧ください。</p>
<p>関連プロジェクト：<br />
<a href="https://ai.mercari.com/projects/auto-content-moderation-for-trust-safety/" title="http://あんしん・あんぜんのための自動違反検知">あんしん・あんぜんのための自動違反検知</a></p>


あんしん・あんぜんなマーケットプレイスのために 機械学習を活用した違反検知

<p>「MERCARI GEARS Lecture Series」は、株式会社メルカリをはじめとするメルカリグループ各社が、これから目指す方向や、これから取り組む技術的なチャレンジについて紹介するエンジニア向けの動画シリーズです。</p>
<p>今回のMERCARI GEARSでは、メルカリのCRM（カスタマー・リレーションシップ・マネジメント）MLチーム*が、機械学習や因果関係の推論を活用し、より良いマーケティング体験の提供、またキャンペーン効果を向上させる方法について紹介しています。</p>
<p>*現在はMarketing Data Scienceチームに名称変更</p>
<p><center><br />
<iframe loading="lazy" width="560" height="315" src="https://www.youtube.com/embed/g1r67WFVKUU" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><br />
Optimizing Marketing Campaigns using Artificial Intelligence [AI@Mercari #1]</center></p>
<p>メルカリのクーポン配布の効率は、クーポン配布のセグメンテーション定義に機械学習モデルを取り入れたことで、大きく改善されました。メルカリのAIチームでは、AIを活用してより良いカスタマーエクスペリエンスを実現するための実践を行っています。</p>
<p>関連プロジェクト：<br />
<a href="https://ai.mercari.com/projects/eaf0a7f389/" title="顧客満足度を高め、マーケティング活動を効率化するためのUplift Modelingの適用">顧客満足度を高め、マーケティング活動を効率化するためのUplift Modelingの適用</a></p>


CRMへのAI活用〜より良いマーケティング体験の提供とキャンペーン効果を向上させる方法について

<p>機械学習のためにラベルを作るのは大変な手間と時間がかかります。ラベル無しで機械学習モデルに学習させることができたら良いと思いませんか？自己教師あり学習ではそれができます。</p>
<p>私はAI/MLチームの<a href="https://www.linkedin.com/in/paul-willot-903a6b5b/">ポール・ウィロット（Paul Willot）</a>です。私たちは、メルカリのデータを利用することでラベル無しで済むための実験を行いました。本稿では、その実験についてご紹介いたします。</p>
<p>それでは、始めましょう！</p>
<h2>自己教師あり学習</h2>
<p>自己教師あり学習(Self-Supervised Learning、略してSSL)は、外部の教師ラベルを必要としない学習方法です。その代わり、ラベルが<b>プロキシタスク</b>から生成されます。このタスクを解くには、後続の応用タスクに<b>適用可能な表現を学習モデルに学ばせる</b>必要があります。</p>
<p>もちろん難しいのは、そのプロキシタスクを定義することです！作成方法を説明する前に、そもそもSSLがなぜ便利なのかを見ていきましょう！</p>
<h3>なぜ、SSLか？</h3>
<p>要約すると、<b>良いラベルを集めるのは大変</b>ですが、生データは豊富にあるということです。SSLでは、大量のデータセットを使用して機械学習モデルを作成開始することができ、ほんの少しの高品質なサンプルを微調整するだけで済むのです。</p>
<p>具体的な例を挙げてみましょう。</p>
<p>メルカリに出品をする際、その商品をなるべく買い手が簡単に見つけられるように最適なカテゴリーを選ぶことができます。しかし、正しいカテゴリーを選ぶのは面倒です。<br />
機械学習（ML）は、商品画像から適切なカテゴリーを即時に提案してくれます。この課題は、単純な分類問題として定義され、一般的な機械学習のタスクです。素晴らしいですね！</p>
<p>ただし、既存のカテゴリー、つまり現在あるラベルにはいくつか課題があります。とりわけ問題となるのが、クラスの不均衡、、<b>ラベルノイズ</b>（複数ある中から選ぶのが難しい）、<b>曖昧性</b>（商品によっては、適切なカテゴリーが複数あるため）です。また、他のタスクへの適用が難しい<b>タスク特有の表現</b>を学習モデルに学習させることも課題です。</p>
<p>これら課題は、そもそもラベルが必要であるから存在するのであり、その必要性がなければそれに越したことはないのです。そこで役立つのが自己教師あり学習です。</p>
<h2>プロキシタスクの定義</h2>
<p>多様なプロキシタスクがSSL用に作られてきました。例えば、<a href="https://arxiv.org/abs/1603.09246">ジグソーパズルを解く</a>、<a href="https://arxiv.org/abs/1803.07728">画像回転を予測する</a>などです。<br />
最近の最先端の方法は、ランダムに変換された画像をつかったプロキシタスクに注目しており、そのタスクは視覚的な変形にもかかわらず一貫した表現を取得することとして定義されています。<br />
例えば、以下のゴールデンレトリーバーの画像ですが、変更が加えられた後も、変換された画像ひとつひとつ（ビューと呼ばれる）にその犬を認識できる断片が含まれています。</p>
<p><img src="https://storage.googleapis.com/prd-engineering-asset/2021/10/0ca9bd87-augmented_views.png" alt="augmented views" /></p>
<p style="text-align: center;font-style: italic">Augmented views</p>
</p>
<p>ただし、どの拡張データを使用するかを決めるのは簡単ではありません。学習モデルが、役に立つ表現を学習できる程度に難しくする必要がありますが、とはいえ難し過ぎても学習することができません。データ拡張によりデザインの選択肢が増え、正しいものを選択することが<a href="https://link.springer.com/article/10.1186/s40537-019-0197-0?code=a6ae644c-3bfc-43d9-b292-82d77d5890d5">現在の研究課題</a>となっています。</p>
<p>理想を言えば、実際に存在するビューを使用したいものです。</p>
<p><img src="https://storage.googleapis.com/prd-engineering-asset/2021/10/bdb3912f-natural_views.png" alt="natural views" /></p>
<p style="text-align: center;font-style: italic">Natural views</p>
<p>幸いなことに、メルカリには数十億ものビューがあります！</p>
<p>商品を売る際、様々な角度から撮影した画像を投稿すると商品に対する買手の印象は良くなります。そのため、大半の出品物には複数のビューがあります。ごく自然な設定で商品の様々な側面を見せるために撮られた画像ということから、私たちは<b>「ナチュラルビュー」</b>と呼んでいます。</p>
<p>ここで留意すべきことは、ビューの違いは単にカメラのアングルが違うのでは？というだけではないことです。例えば、上の画像の靴は、箱の上で様々な角度に置かれています。これはベストです！ある特定の構図に縛られることのない共通の表現を学習モデルに学習できるのです。</p>
<p>ビューの組合せによっては、関連付けるのがより難しい場合もあります。例えば、別々に撮影されたある商品とそれを入れるための箱です。実際のところ、これは、比較的まれなことなので大した問題とはなりませんでした。</p>
<h2>Contrastive learning</h2>
<p><img src="https://storage.googleapis.com/prd-engineering-asset/2021/10/58783b48-contrastive_example.png" alt="Contrastive learning" /></p>
<p style="text-align: center;font-style: italic">Contrastive learning on a pair of images (credit: <a href="https://ai.googleblog.com/2020/04/advancing-self-supervised-and-semi.html">SimCLR</a>)</p>
<p>ところで、それらのビューがあれば<b>Contrastive learning</b>b&gt;を通じて学習対象を定義することができます。つまり、<b>同じビューはより似通った表現となり</b>、<b>異なるビューは似ていない表現となる</b>b&gt;ということです。上記の図で示す通り、同じ商品は、見た目が近いビューという表現になり、異なる商品は、見た目が違うビューという表現になるのです。</p>
<p>尚、「埋め込み」と「表現」は、意味上では同義として使用されており、両方ともSSL環境下では、1次元のスカラー×ベクトルを表します。</p>
<p>Contrastive learningは、<a href="https://proceedings.neurips.cc/paper/1993/file/288cc0ff022877bd3df94bc9360b9c5d-Paper.pdf">シャムネットワーク</a>に関係する古いタイプの機械学習法ですが、この2年間、ImageNet のベンチマークで、教師あり学習との間にできた差を縮めてきている<a href="https://arxiv.org/abs/1911.05722">多く</a>の<a href="https://arxiv.org/abs/2002.05709">方法</a>と共に人気を取り戻してきています。この<a href="https://ai.googleblog.com/2020/04/advancing-self-supervised-and-semi.html">SimCLR ブログ記事</a>は、この件に関して、さらに深く掘り下げて考察するのにちょうど良い記事です。</p>
<p>「<a href="https://arxiv.org/abs/2006.07733">Bootstrap Your Own Latent</a>」という論文で紹介されてからというもの、最近では、モーメンタムをベースとした技法も見られるようになってきました。それらの技法は、ポジティブペアのみを使用することで実装を簡略化し、バッチサイズが大きくなるという問題を解消します。モーメンタム学習について理解するには、<a href="https://arxiv.org/abs/2011.10566">SimSiamに関する論文</a>をお勧めします。</p>
<p><img src="https://storage.googleapis.com/prd-engineering-asset/2021/10/8d036056-ssl_moby_structure.png" alt="MoBY self-supervised method" /></p>
<p style="text-align: center;font-style: italic">contrastive損失関数やモーメンタム学習のあるSSLは、MoBYという別名で知られています。 (credit: <a href="https://arxiv.org/abs/2105.04553">Self-Supervised Learning with Swin Transformers</a>)</p>
<p>最新の研究では、この２つを結びつけたりもします。その良い例が、私たちが実験で使用した<a href="https://arxiv.org/abs/2105.04553">MoBY</a>です。</p>
<p>これらの方法における重要なポイントは、<b>複数ビューの対象に関する一貫した表現</b>を獲得する学習モデルの作成が可能になるということです。</p>
<p><img src="https://storage.googleapis.com/prd-engineering-asset/2021/10/afdedcb6-similarity_listings_ssl.png" alt="Distance of representations within and between listings" /></p>
<p style="text-align: center;font-style: italic">リスト内外のビューを表現する間の距離</br>各四分円は1つのリストで、最も内側のリンクはリスト間です</br> 緑＝類似、赤＝非類似を表しています
</p>
<p>上記の通り、私たちのデータセットでこのことを確認することができました。学習後、商品は構図が大きく変わっていようと、または細部が拡大表示されていようと、ことなった商品間よりもある一つの商品内においてのほうがより互いに似たものとなります。</p>
<p>今回の実験で、学習に関して役立った情報は以下の通りです。</p>
<ul>
<li>サイズの大きいデータセットは、いかなる非自明なタスクにも必要。何百万ものサンプルを考慮するべきである</li>
<li>学習については、事前学習済みの重みがあれば、GPUで数日、そうでなければ1～2週間かかる</li>
<li>大きな学習モデルのほうが学習させやすく、ResNet-50は、2021年の時点でもベースラインとしていまだ信頼性が高い</li>
<li>単純な方法は大いに役立つ。<a href="https://github.com/lucidrains/byol-pytorch#byol--simsiam">SimSiam</a>から始めよう</li>
<li>SSLは素晴らしいが、既にラベルがあるのであれば、それを使用するべきだ。より正確に早く学習させることができる</li>
</ul>
<h2>学習済み表現の使用</h2>
<p>これらの画像から得られた表現を使用して、後続の応用タスクを開発するための方法がいくつかあります。</p>
<p>ラベルを使用して、<b>ある特定の学習モデルを埋め込み後に</b>学習させることができますが、入力スペースがより小さく単純なため、必要サンプル数は（生の画像と比較して）より少なくてすみます。</p>
<p>また、あるサンプルから<a href="https://en.wikipedia.org/wiki/K-nearest_neighbors_algorithm">最も近い表現を最近傍探索</a>で見つけることで、そのサンプルの特性を推論することができます。その利点は、追加的な学習が必要なく、そのサンプルに最も近いものでさえあれば、構造が不十分であってもその特性を利用することができるということです。</p>
<p>私たちは、コサイン類似度を算出、（又は一対のサンプル間で<a href="https://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_divergence">直接相違</a>を測定）することができましたが、メルカリの規模では、すぐに計算処理ができなくなります。代わりに、<a href="https://github.com/facebookresearch/faiss">FAISS</a>や<a href="https://github.com/google-research/google-research/tree/master/scann">ScaNN</a>のように、既存のデータベースを利用したベクトル類似性検索をし、わずか数ミリ秒で何百万ものサンプルを検索することができます。</p>
<h3>結論</h3>
<p>たとえラベルがなくても、手元にあるデータの既存構造を利用することで利便性の高い学習モデルに学習させることができます。</p>
<p>メルカリでは、<a href="https://engineering.mercari.com/en/blog/entry/pricing-guidance-system/">価格の推定</a>、<a href="https://engineering.mercari.com/en/blog/entry/2019-09-12-130000/">不正出品の特定</a>、<a href="https://engineering.mercari.com/en/blog/entry/20210702-develop-general-customer-profiling-platform-to-host-machine-learning-models/">顧客別プロフィール設定</a>、<a href="https://engineering.mercari.com/blog/entry/20201202-mediapipe">エッジでの物体検出</a>など、あらゆる場面で機械学習を利用しています。</p>
<p>コストのかかるラベルを使用せず、画像から直接、汎用性の高い表現を獲得することで、これら多様なタスクの処理がしやすくなります。</p>
<p>お読みいただき、ありがとうございました！</p>


自己教師あり学習のナチュラルビュー

<h2>はじめに</h2>
<p>こんにちは。メルカリでエンジニアリングマネージャを担当しております<a href="https://twitter.com/kentanDX" title="kentan">kentan</a>です。</p>
<p>メルカリのCustomer Reliability Engineeringチームでは、違反出品物などを機械学習やルールなどを用いて検出するためのModeration Systemと呼ばれるシステムを開発しています。Moderation Systemは、メルカリのmarket placeとシステム的に接続しつつ、違反を取り締まる業務を行うCustomer Support向けのWeb UIを備えているという特徴があります。フロントエンド、Backend、機械学習の技術要素を含んでおり、機能の複雑性も大きくなっております。</p>
<p>メルカリでは、歴史的にバックエンドエンジニアのチーム、フロントエンジニアのチーム、機械学習エンジニアのチームと職能ごとにチームを分けておりました。そのため、Moderation Systemの開発開始時点では、複数の職能チームでプロジェクトチームを構成し、連携して開発を行う必要がありました。</p>
<p>開始時点では、既存の4チームがModeration Systemの開発に参画することになりました。これは、それぞれのチームが担当している技術分野が、Moderation Systemに不可欠であったためです。</p>
<ul>
<li>Backend Aチーム</li>
<li>Backend Bチーム</li>
<li>機械学習 Aチーム</li>
<li>機械学習 Bチーム</li>
</ul>
<p><img src="https://storage.googleapis.com/prd-engineering-asset/2021/09/12a53968-journey-to-a-feature-oriented-team-.png" alt="" /></p>
<p>プロジェクト発足当初から、4チームが関わることによるコミュニケーションの難しさは容易に想像できました。そのため、プロジェクトの参画メンバがきちんと同じゴールを向けるように、チームを横断したマイルストーンを作成したり、チーム間コミュニケーションのフォーマットを整えたりしました。これらはとても効果的に機能したのですが、やはり本質的に開発している機能の大きさに対し関わるチームの数が多いという問題を無視できなくなってきました。また、メンバの離職などにより、1チームあたりのエンジニアも少なくなり、チーム構成の見直し自体も必要とされる状況でした。</p>
<p>また、メンバの異動や離職により、3チームすべてのProduct Ownerを一人のプロダクトマネージャ(PdM)が担当することになりました。一人のPdMが3チーム分のスクラムイベントに参加していたため、負荷の低減が必要とされていました。</p>
<h2>チーム構成とマイクロサービスのオーナーシップ</h2>
<p>問題の解決にあたっては、チーム構成の見直しと同時に、既存のチーム体制のままマイクロサービスのオーナーシップを見直す、というアプローチも検討しました。4チームがそのまま存続したとしても、Moderation Systemの開発に関わるマイクロサービスを3チーム、あるいは2チームに集約することによって問題が解決・軽減できると期待されたからです。</p>
<p>議論の結果、ひとまずオーナーシップの移管よりもチーム構成の見直しを先に行うことにしました。理由は主に2つありました。</p>
<ul>
<li>それぞれのチームが少人数であるため、これ以上マイクロサービスの開発を担当できない。</li>
<li>職能ごとに別れたチームであるために、スキルセットの違うチームのマイクロサービスを引き受けられない。(Backendチームが機械学習のチームのマイクロサービスを引き受けることはできない)</li>
</ul>
<p>そのため、マイクロサービスのオーナーシップの整理はひとまず手を付けずに、チーム構成を見直すことにしました。</p>
<h2>チームの構成の見直し</h2>
<p>チーム構成の見直しは、まず単純に組み直しの効果が一番大きそうなところを手を付けることにしました。その結果、Backend Aチームと機械学習Aチームを一つにまとめることになりました。チーム選定の理由は概ね次のようなものになります。</p>
<ul>
<li>Backend Aチームは違反出品の検知に関するルールの登録・変更・適用などの機能を担当している。一方、機械学習 Bチームは違反出品物を特定するMLモデルの開発・運用を行っている。エンジニアリングの専門性に違いはあるが、ビジネスドメインとしては極めて近い分野を担当しており、チームの統合によるシナジー効果がとても大きいと期待される</li>
<li>機械学習 AチームのエンジニアがBackend領域に専門性を広げることに興味を持っていた。ソフトウェア開発は人材の能力・意欲がほぼ全てと言えるので、モチベーションを持っているのは効果的に働くと期待できる</li>
<li>Backend Aチームと機械学習 AチームはPdMが同一人物であり、PdM業務観点でも統合の効果が高いことが期待される</li>
</ul>
<h2>どうやってチーム統合をすすめたのか</h2>
<h3>Phase 0. メンバのモチベーションの確認</h3>
<p>統合にあたって、それぞれのメンバに意図を説明し、意向を伺ったところ、どのメンバも新しい領域にチャレンジできると言うことで、意欲的でした。機械学習エンジニアからすると、Backendの領域に専門性を広げられ、またBackendのエンジニアも機械学習に専門性を広げられます。</p>
<p>チームの統合はPhaseを4つに区切って行いました。</p>
<h3>Phase 1. ドメイン知識の習得 EM編</h3>
<p>統合されたチームのEngineering ManagerはBackend AチームのEMであった私が担当することになりました。私自身は、Backendを中心としたフルスタックエンジニアとしての経験しかなく、機械学習周りに関する業務経験は全くない状態でした。また、機械学習 Aチームの開発に関するドメイン知識もありませんでした。そのため、ここの知識の獲得が最優先でありました。</p>
<h4>Goal</h4>
<ul>
<li>EMが機械学習Aチームのプロジェクトを理解する.</li>
<li>EMが機械学習Aチームの開発プロセス・スクラムプラクティスを理解する</li>
<li>EMが機械学習Aチームのメンバのパーソナリティ、skill set、強み・弱み、モチベーションやキャリアプランなどを理解する</li>
<li>EMがメンバと会話ができるように、機械学習の基礎を習得する。</li>
</ul>
<h4>Non-Goal</h4>
<ul>
<li>メンバに関するゴールは設定しない</li>
</ul>
<h4>やったこと</h4>
<ul>
<li>Sprint planningやRetrospectiveなどのスクラムイベントに参加した。</li>
<li>MLエンジニアが所属するDivisionのEMミーティングに参加した。</li>
<li>過去のDesign docやPull Requestを読んだ。</li>
<li>過去1年くらいのSlackの会話を追いかけて、議論していたことの概要を掴んだ。</li>
<li>機械学習Aチームのオンボーディングドキュメントを読んだ。不足していたり、古くなっていたりしたので、必要に応じて作成・更新した。</li>
<li>機械学習Aチームが開発しているプロジェクトでPull Requestを作成した</li>
<li>MLのモデルを新規作成・向上させるときに行ったExperimentに関するレポートを読んだ</li>
<li>メンバとの1on1を通して、信頼関係の構築に努めた。</li>
<li>その他、書籍やオンラインコースなどで機械学習の知識を習得した。</li>
</ul>
<h3>Phase 2. ドメイン知識の習得 メンバ編</h3>
<p>続いて、それぞれのチームのメンバがドメイン知識を習得しました。</p>
<h4>Goal</h4>
<ul>
<li>Backendエンジニアが機械学習Aチームのプロジェクトを理解する</li>
<li>Backendエンジニアが機械学習Aチームの開発プロセス・スクラムプラクティスを理解する。また、そこで使われている言語であるPythonを習得する。</li>
<li>機械学習エンジニアがBackendAチームのプロジェクトを理解する</li>
<li>機械学習エンジニアがBackendAチームの開発プロセス・スクラムプラクティスを理解する。また、そこで使われている言語であるGoを習得する。</li>
</ul>
<h4>Non-Goal</h4>
<ul>
<li>開発への貢献はゴールとしない。(知識の習得に集中してよい)</li>
</ul>
<h4>やったこと</h4>
<ul>
<li>Slackにオープンチャネルを作って、機械学習・Backendに関する質問や勉強などを行えるようにした。</li>
<li>2チームで共同の勉強会を開いて、ドメイン知識を教授しあった。</li>
<li>機械学習チームのTech LeadがBackendチームのスクラムスプリントに参加して開発を行った。</li>
</ul>
<h3>Phase 3 スクラムの一本化</h3>
<p>メンバがそれぞれのドメイン知識を得た後、スクラムプロセスを一本化することにしました。Sprint RefinementやPlanningを一つにするので、本格的に一つの開発チームらしくなっていきます。</p>
<h4>Goal</h4>
<ul>
<li>2チームで別々に回していたスクラムプロセスを一つにする</li>
<li>BackendエンジニアがMLプロジェクトの開発を行う</li>
<li>機械学習エンジニアがBackendのプロジェクトの開発を行う</li>
</ul>
<h4>Non-Goal</h4>
<p>Backendエンジニアによる機械学習モデルの作成・向上</p>
<h4>やったこと</h4>
<ul>
<li>EMがScrum Masterとして、一本化したスクラムチームのスクラム運営をリードした。同時にメンバにScrum Masterのロールを引き継げるように、スクラムプロセスを定義していった。</li>
<li>JIRAの開発チケットの背景を理解するための、勉強会を開催した。JIRAの開発チケットはどうしてもHigh Contextであるため、新しく入った人がそれ自体をみて全容を理解することが難しいです。それを補うために、その開発チケットの詳細や、なぜその開発が必要なのか、そしてその背景にある開発のビジネス的理由などの理解に努めた。</li>
</ul>
<h3>Phase 4 オンコールの一本化</h3>
<p>そして最後にオンコールを一つにしました。メンバとしてはオンコールの担当の頻度が半分になるので、負担が劇的に減ります。また、オンコールに伴う手当などもだいたい半分になるので、会社としても開発費の効率の向上に繋がります。</p>
<h4>Goal</h4>
<ul>
<li>Backendメンバが機械学習チームのプロジェクトに対してオンコールを取れる</li>
<li>機械学習メンバがBackendチームのプロジェクトに対してオンコールを取れる</li>
</ul>
<h4>Non-Goal</h4>
<ul>
<li>なし(Phase4が最後のphaseのため)</li>
</ul>
<h4>やったこと</h4>
<ul>
<li>TLを中心に、全メンバが安心してオンコールを取れるために何が必要か議論を行った。そしてそのためにしなければいけないことについて議論を行い、Strategy documentを作成した。</li>
<li>インシデントの発生を想定した予行練習を行った</li>
<li>それぞれのマイクロサービスについてOncallのhandbookを作成した</li>
</ul>
<h2>今後の展望</h2>
<p>新しく組成したFeature チームにてFrontendの開発を開始しています。Customer Supportの業務はとても複雑な機能群からなり、UIもリッチなものになっております。Moderation System開発に占めるFrontendの割合も大きく、必要な開発をすべてチームで行うというFeatureチームのコンセプトに照らし合わせるとぜひとも達成したいゴールです。</p>
<p>また、本格的にフロントエンド開発を行うためには、やはり、フロントエンドに強いエンジニアが必要となります。こちらは採用と平行して進めております。興味のある方はぜひ<a href="https://twitter.com/kentanDX" title="ご連絡ください">ご連絡ください</a>。</p>
<h2>終わりに</h2>
<p>Backendエンジニアと機械学習エンジニアというスキルセットの全く異なる２つのチームを1チームにするのは、やはり簡単ではありませんでした。そのような中で、無事統合が成功できたのは、チームメンバが主体性を持って統合の実現に動いてくれたのが、一番の成功の理由であったように思えます。 Phase 4のオンコールの一本化に関しては具体的なプランニングから実行までテックリードが中心となって、ほぼEMの私の介入なく完了することができました。</p>
<p>また、一般的にはアンチパターンに分類されることもありますが、EMがスクラムマスターのロールを担ったことも効果的であったように思えます。日々のStandup meetingの進行の仕方やTicketの書き方など、乱暴に言ってしまえば、どちらの流儀でも大差が無いようなものに関しては、EMが意思決定をしていくのが一番波風が立たないやり方でありました。一旦、決めてしまって、運用を開始した後、スクラム開発を続ける上で実態に合わなくなってきたものは、その都度、Sprint retrospectiveで改善を議論しています。</p>
<p>課題としては、私を含めたBackendのバックグラウンドを持つエンジニアが機械学習の専門知識を完全には習得できておらず、機械学習のモデルを作成できる状態になっていないという点があります。現状は、機械学習プロジェクトのシステム部分・アプリケーション部分の開発を担当していますが、機械学習のモデルを作成できるようになるためにはさらなる仕掛けが必要でしょう。</p>


機械学習TeamとBackend Teamを1つにしてFeature Teamを作った話

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

メルカリAIチームのブログです。AI技術や組織にまつわる情報などを日々発信していきます。

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

Articles

Edge AIチームが実現する、iOSとWebのリアルタイム出品スキャン

メルカリUSで機械学習のトレーニングインフラコストを最適化した方法

循環型社会に貢献するために。メルカリのAI技術が克服すべき課題 CEO 山田進太郎×Director 木村俊也

AI出品、画像検索… CEO 山田進太郎・Director 木村俊也が振り返る、メルカリのAI活用の歩み

あんしん・あんぜんなマーケットプレイスのために機械学習を活用した違反検知

CRMへのAI活用〜より良いマーケティング体験の提供とキャンペーン効果を向上させる方法について

自己教師あり学習のナチュラルビュー

機械学習TeamとBackend Teamを1つにしてFeature Teamを作った話

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

メルカリAIチームの研究「Strategic Coupon Allocation for Increasing Providers’ Sales Experiences in Two-sided Marketplaces」がKDD2024 TSMO 2024 Workshop採択されました

メルカリAIチームの研究「LLMs as an Interactive Database Interface for Designing Large Queries」がSIGMOD 2024のHILDA Workshopに採択されました

メルカリのMLチームは組織課題をどう解決してきた？エンジニアが社内横断Guildを立ち上げた話

メルカリのAIチームがNLP2024にてポスター発表を行いました『過去クエリを介した関連文書検索システム』

LLMを活用した大規模商品カテゴリ分類への取り組み

Articles

Edge AIチームが実現する、iOSとWebのリアルタイム出品スキャン

メルカリUSで機械学習のトレーニングインフラコストを最適化した方法

循環型社会に貢献するために。メルカリのAI技術が克服すべき課題 CEO 山田進太郎×Director 木村俊也

AI出品、画像検索… CEO 山田進太郎・Director 木村俊也が振り返る、メルカリのAI活用の歩み

あんしん・あんぜんなマーケットプレイスのために 機械学習を活用した違反検知

CRMへのAI活用〜より良いマーケティング体験の提供とキャンペーン効果を向上させる方法について

自己教師あり学習のナチュラルビュー

機械学習TeamとBackend Teamを1つにしてFeature Teamを作った話

あんしん・あんぜんなマーケットプレイスのために機械学習を活用した違反検知