メルペイのデータ分析環境ってどう？　エンジニアとアナリストを支える「データマネージャー」の存在

決済サービスとしてスタートしたメルペイですが、その特徴は「膨大なデータが存在すること」にもあります。決済をしてもらってはじめてデータが集まるのではなく、既にメルカリで取引をされているお客さまの膨大な量のデータがあります。それらのデータを上手く活用すること＝サービスの成長だといっても過言ではありません。

そこで欠かせないのが、データを活用するMLエンジニアやデータアナリストの存在。そして彼らがデータ活用の成果を最大限発揮するためには、データを整備・管理する「データマネージャー」の支えも重要です。実際に、Machine Learning（以下、ML）チームのエンジニア@shuukや、DataAnyalystチームのデータアナリスト@yamashinも、データマネージャーには「とても助けられている」と言います。

一体彼らはどうやって連携しているのか？データマネージャーってどんな存在？

そんな疑問を解消すべく、データをマネジメントするData & MLグループのエンジニアリングマネージャー@takafujiも加え、データを活用する側・管理する側の視点からそれぞれ話してもらいました。

データを“運ぶ”データプラットフォームチーム、“管理する”データマネジメントチーム

ーまずは@takafujiさん、メルペイのデータマネジメント体制と役割分担を教えてください。

@takafuji：前提として、メルカリやメルペイ、ソウゾウなどを含めたメルカリグループのほとんどのデータは「データウェアハウス（以下、DWH）」に集約しています。このDWHにデータを運ぶためのメカニズムやシステム作りに特化しているのが「データプラットフォームチーム」です。データを運ぶための“パイプライン”を作るようなイメージですね。

そしてDWHに集まったデータを、データ活用者たちがより活用しやすくなるようにデータの整備をしたり、DWHの管理をしたりするのが「データマネジメントチーム」です。それぞれのデータの仕様をきちんと把握したうえで、分析者とデータの発生元を上手く繋ぎます。そして私たちが用意したデータを最前線で活用しているのが、@shuukさんがいるMLチームや@yamashinさんが所属するDataAnyalystチームです。

藤木貴之（Takayuki Fujiki、@takafuji）

ーなるほど。データプラットフォームチームとデータマネジメントチームの違いを、もう少し詳しく聞いてもいいですか？

@takafuji：まず、データが発生する元は社内にも社外にもあって、さまざまなデータソースが存在しています。ただ、データが散らばっていると横断での分析ができない。そのため、さまざまなデータソースからDWHにデータをセントラライズするための仕組みづくりが必要になります。そのデータ集約をするためのDataPipelineの開発をデータプラットフォームチームが担っています。

DWHにデータを運ぶ際には「ETL（Extract、Transform、Load）」という、データソースから抽出したデータを加工したあとにDWHにロードする方式が取られている環境も多いと思います。一方メルペイでは、一部例外はありますが「ELT（Extract、Load、Transform）」という方式でデータの整備を行っています。ELTでは、データベースから抽出したデータをほぼローデータの状態でDWHにロードします。ただ、ローデータのまま保存されたデータはエンジニアや分析者からすると仕様の把握が難しく、解釈に困ったり、使いづらかったりするケースがあるんです。特にバックエンドサービスでは、あくまでもシステムに最適化されたデータベース設計になっているので、分析者として欲しいビジネスメトリックがあったときに、複雑な仕様の理解やSQLの作成をしなければいけないといった問題が往々にして発生します。

そのため、分析者が求めているビジネスメトリクスまでなるべく短いステップでわかりやすく辿り着けるように、「データマート」と呼ばれるデータを解釈しやすい形に加工する工程を、データマネジメントチームが行っています。つまり、ELTのExtract、Loadまではデータプラットフォームチーム、Transformからはデータマネジメントチームが行うイメージですね。

ーMLチームやDataAnyalystチームにとって、こういった動きは“大助かり”だと。

@yamashin：はい。DataAnyalystチームでその力を借りていない人は「いない」といっても過言ではないですね。

@shuuk：大きな機能やサービスが一つ出ただけで複雑なテーブルが大量に生まれるので、そのままだと、クエリをどう書いたらいいかがわからない状況なんです。そこをデータマネージャーが、サービスを作っているエンジニアにガッツリとヒアリングをして仕様をまとめ、かつ中間テーブルを使いやすい状態に加工してくれる。MLチームでも、それがないととてもMLサービスを作れない状況です。

作業の効率化＆ミス軽減に欠かせない「中間テーブル」

ー改めて、@shuukさん、@yamashinのお2人がデータマネージャーについて「助かる」と思うのはどんなところなんですか？

@shuuk：金融という失敗が許されない領域ということもあると思いますが、マイクロサービスのデータ仕様は汎用性確保のためにエンティティの抽象度が高かったり、逆に非常に細かいビジネスロジックが盛り込まれていたりして、一筋縄では読み解けないんですよね。未加工のデータをいきなり目の前にしても、すぐに正確なクエリは書けないんです。たとえば定額払いがリリースしたときは、分析者がクエリを書けるようになるまでに2ヵ月くらいかかったような…。

@shuuk

@yamashin：それくらいでしたね（笑）。

@shuuk：そこをデータマネージャーが直感的にクエリを書けるように中間テーブルにきちんと加工してくれるので、今はすごく楽になりました。

@yamashin：しかも、特別に条件を付けくわえないと意図しない数字が出てくるなど、けっこう落とし穴もあって。だから、テーブルの知識がないままクエリを書くと大事故につながることがあるんです。今のように「中間テーブル」ができるまでは、ある程度マイクロサービスに対する知識がないとデータを出すことはできない状態でしたよね。

@shuuk：実際に、それで軽くトラブルが起きたこともありました。だから、きちんとデータの仕様を把握したうえで使いやすく加工してくれるのは、エンジニアやアナリストにとって本当に価値があることなんです。それがないと、DataAnyalystチーム、MLチームでそれぞれ複雑なクエリを作って運用することになってしまう。そこもちゃんと一元化されてきましたし、非常に助かっています。

@yamashin：直近で言うと、やっぱり「定額払い」ですね。定額払いは、利用を管理するサービス、債権を管理するサービスなど、複数のマイクロサービス間でデータのやり取りをして、それを繋ぎ合わせてデータを取る必要があるんです。それには知識がないと、テーブル同士をどうくっつけてデータを集計すればいいかわからないし、構造自体を理解していたとしても、いくつものテーブルをくっつけてやっとデータが取れる状態になります。だけど中間テーブルを用意してもらうことによって、テーブルを1〜2個くっつけただけでかなり汎用性のあるデータが取れるようになる。分析時間の短縮にもつながりますし、ミスの減少にもつながって作業効率が上がりました。

山田 伸也（Shinya Yamada、@yamashin）

@shuuk：メルカリグループがマイクロサービスを導入していることは、システムのスケーラビリティを上げていくという観点では必須のことです。一方で分析者目線では、一個の機能が複数マイクロサービスで実現されているとテーブルが色んなところにあって、それを統合的に見るのは常人技ではない。そこを誰かが責任を持ってまとめてくれるのは、マイクロサービスを導入している会社としてあるべき姿かなと思います。

ー@takafujiさん目線だとどう感じますか？

@takafuji：すごく褒めていただいて、チーム冥利につきますね（笑）。お2人のようなデータを活用するメンバーが最大効率で成果を上げられるように、データの整備をしていくのがデータマネジメントチームの最大のミッションなので。作ったデータマートを活用していただき、評価もしてもらえるのはうれしいです。

ー反対に、課題に感じているところはありますか？

@shuuk：私は純粋に、中間テーブルがもっとほしいです（笑）。際限がないですけど、新しい機能が出るたびに中間テーブルがほしくなる。とはいえ、作るのは簡単じゃないと思うので、データマネジメントチームの方々の間でどうしても優先順位をつけなきゃいけないんだろう…とは思っているんですけど。

@takafuji：まさにその通りで、中間テーブルの課題はこれがすごく大きいと思います。ローデータを使いやすくするために中間テーブルが便利なのは間違いない。しかし、マイクロサービスでは事業が拡大すればするほど、それに伴ってデータマネジメントチームも無限にスケールをしていかないと、すべてのデータに対してのニーズに応えるのは難しいと思います。さらに、これまでつくりあげたテーブルも保守して、仕様が変わればメンテナンスし、新規の中間テーブルもつくって…となると、本当に際限がないですよね。

だから@shuukさんが話していた「優先順位づけ」は、私たちのチームで考えていかなければならない重要なテーマです。データ活用者の方たちのニーズを聞きながら順位をつけていくとか、なるべく低コストでその辺りを実現できるようにするとか。

@yamashin：私は、使い慣れているテーブルでも仕様が変わると使えなくなったり、アップデートを待たなきゃいけなかったりというのが、少し不便に感じています。あとはテーブルの数が多すぎて、自分では把握できていないテーブルがけっこう出てきていることです。「こういうデータを取りたいんですけど」とデータマネジメントチームに相談したときに、めちゃくちゃ便利な中間テーブルを紹介してもらったときは、「こんなのあったんだ、早く教えてよ！」と思ってしまうことがありました（笑）。

@takafuji：@yamashinさんの言う通り、データ活用者の方たちが求めているテーブルに辿り着くのをサポートするメカニズム、いわゆる「データディスカバリー」と言われている領域は、私たちも課題に感じているところです。基本的にそこも人がデータを解釈して説明を補足していかなければいけなくて、どうしても機械だけではできない部分があるので。

ーデータ連携の頻度についてはどうですか？

@shuuk：MLチームの不正検知はスピード勝負。「リアルタイムでデータにアクセスしたい！」ということが多く、鮮度が非常に大事なので、協力してもらっていることも多いです。今後MLプロダクトが増えれば、こういうニーズはさらに増えていくと思います。

@takafuji：ただ、リアルタイムのデータ連携は、システム的な開発や運用のコストの連携頻度が低いものに比べてすごく高くなるし、データのクオリティを担保するのもハードルが上がってしまう。実際に、データマネジメントチームにもデータプラットフォームチームにも、四半期に何度も「このデータの連携頻度を上げてくれないか」という依頼がくることは多いです。

ーそこも課題に感じている部分なんですね。

@takafuji：そうですね。基盤目線では、リアルタイム性とクオリティを両立したいところですが、システム的な難易度ではトレードオフになるケースがけっこうあります。リアルタイム性を求めると、いかにそこのクオリティを担保するかが課題になっていくので…。特に不正検知などはクオリティの担保が重要になるので、そこも今後取り組みたいテーマです。

@yamashin：DataAnyalystチームでもよくある話ですね。活用する施策自体がリアルタイム性を求めるものであればあるほど、そこの頻度を早めてもらう必要が出てくる。でも今はそういった依頼は分析する側、作る側から見ても出しやすい環境になっているので、ありがたいです。

@shuuk：分析者目線で言うと、何を頼んでも快く相談に乗ってもらえるので、すごく助かっています。もちろん優先順位や難易度などで「今すぐできません」ということも当然ありますけど、まずはちゃんと話を聞いてくださるのがありがたいです。

なんでも相談できるデータマネージャーは“戦友”？

ーでは、みなさんが業務で連携するときに意識していることはありますか？

@takafuji：先ほど@shuukさんが言っていた「話を聞く」ところはすごく意識しています。実は私たちのようなプラットフォームや基盤をつくるチームは、どうしてもチーム単体で価値を出しにくいんです。あくまでデータを活用してくれるメンバーを通して、会社やお客さまに価値を届けられる存在なので。だから、ユースケースや相談ごとには常にアンテナを高くしておかないといけないと思っています。

@shuuk：分析者は分析者で、新機能の企画段階などニーズが発生しそうな段階で早めにお伝えするようにしていますね。「今こういうことをやりたいので、そのうちお願いするかもしれません」とSlackやmtgで軽く頭出ししています。気軽にお願いできると言っても、ニーズが顕在化してから「これすぐやってほしい」のようなスタンスだとworkしないと思っています。

@yamashin：私は、できる限りデータマネジメントチームとの距離感をなくそうとしています。普段からコミュニケーションを取っておくことで、大きな相談ごとではなく「ちょっと不便だな」と感じたときでも気軽に話しかけられるので。少しでもわからないことがあるときに、気兼ねなく相談できる関係性を持つことは大事だと思います。

@takafuji：相談を受ける側からしても、リスペクトしながら依頼してくれているのが、すごく感じられます。たとえば、過去に@oshiemonさんが作ったテーブルを「神テーブル」と言ってすごく持ち上げてくれて（笑）。私たちは直接お客さまから声をいただけるチームではないので、お客さま＝データ活用者の方たちになるんです。なので、そういったところはすごく励みになりますね。

@shuuk：新しいマイクロサービスが次々にできる中、分析者もデータマネージャーに丸投げするのではなく、データ利用者の立場からデータの解明に一緒に取り組んでいる。だから私は、データマネージャーを戦友のように感じています（笑）。

@yamashin：たしかに！私もそうですね（笑）。

メルペイはアナリスト・エンジニアの成果を最大化できる場所

ー最後に、メルペイの分析環境の「こんなところが良い！」と思うポイントを教えてください。

@shuuk：市場のMLエンジニア全般に関して言うと、今のメルペイのデータマネジメントチームやデータプラットフォームチームが行っているような分析基盤づくりを、相当程度自分たちで実施するケースも多いかと思います。私も以前までは“分析が1割、準備が9割”という状態でした。それはそれでやりがいがあるものの、データ準備の相当の部分が省かれる現在の環境では、ビジネス貢献できる精度の高いモデルを作ることにより注力できるんです。そういう意味では、メルペイはMLエンジニアとして「モデリングの腕をもっと発揮したい、ビジネスKPIに貢献するためにビジネス部門とディスカッションする時間をもっと作りたい」といった方には、とても良い環境だと思います。

@yamashin：@shuukさんが言うように、メルペイが分析者として分析に集中できる環境というのは、私たちアナリストもすごく感じています。データマネージャーにお願いすればとても良い中間テーブルができあがってくるし、分析の結果のモデル化はMLチームの方におまかせできる。自分たち分析者が分析という業務に集中できるからこそ、クオリティも上げられる。ここまで良い環境は、他の組織ではあまりないんじゃないかと思います。

@takafuji：メルカリグループのようなデータマネジメントのチームって、現状で言うとまだない会社の方が多いはず。メルカリグループは事業の拡大にともなってあらゆるデータが大規模になっていくなかで、データマネジメントが今後ますます重要な役割になってくると思います。そんな中、今からデータマネジメントに先進的に取り組めるのは非常に魅力的だと思います。

とはいえ、「いかにデータ活用のスピードを落とさずにきちんと管理していくか」など、私たちのチームもまだまだ課題がたくさんあります。だからこそチームとして今後もきちんと取り組んでいきたい。ぜひこれから仲間になってくださる方も、みんなで一緒にデータ活用の成果の最大化をしていきましょう！

採用イベント情報

今回の記事に登場したメルペイのデータアナリストが登壇する採用イベントも予定しています。気になる方は是非お気軽に参加ください！