メルカリのデータ分析チームでやったことの振り返り

樫田光 | Hikaru Kashida

こんにちは。

データアナリスト 兼 チームのマネージャ としてメルカリという会社に4年ほど勤めていたのですが、色々やった気はするが、思い返してみると結局の所何をしたんだっけ？という気持ちに突然なりました。僕は忘れっぽいので、今後もこういう瞬間は何度も訪れそうな気がしています。

ということで、この4月から新しいことを始めるこのモーメントに自分が何をしたのかをちゃんと書き残しておくことにしました。

自分自身の記憶のアーカイブの役割とともに、誰かの参考になれば望外の喜びです。

大体2016−2019年くらいの話です（今のメルカリのデータ分析チームはもっと進化していますのであしからず。）

LTVの概念を導入した

2022年現在となってみると非常に不可解ではあるが、私がメルカリに入社した2016年頃には、社内では「LTVを見る」という概念はなかった。

ゆえに、投資がリクープ（回収）できているかどうかをあまり意識せずにそれなりの広告費を投下していたという実態があった。

かくいう私も、恥ずかしながら当時は、WebサービスではLTVをちゃんと計測して獲得コストとのバランスを見るものだ、ということをよくわかっていなかった。

とあるタイミングで「US事業の広告投資ってリクープしているんだっけ」という議論が持ち上がり、それを機にLTVをちゃんと見ようという機運が高まったため、その分析をリードした。

その時の雰囲気はなんとなくここにまとまっている。

この分析を元に、全社の最注力目標を意味する「KR1」が即座に切り替わったのは印象深い出来事だった。

そこから、メルカリUS事業のセンターピンを"リテンション"に定めて改善 & 分析 を重ねていった時の話はこちらのSpeakerdeckに詳しい。


アサイン性のチーム構成にした

僕の入った頃のメルカリ分析チームは「アサイン」という概念がなく、なんとなくチーム全体に投げられた依頼をふわっと分担してこなしているような状態だった。

そのため、事業に対してあまり積極的な形での関与ができていなかった。事業の動きが早く、また事業を構成する各チーム内での専門性が高いため、深く文脈を理解していない外様からでは、十分な解像度の提案をすることが難しいためだった。

要は受け身一辺倒だった。

この状況を打開するために、各事業を構成するプロジェクトごとに、チームからデータアナリストを「専属アサイン」するような形を取った。

参考

画像1

このような形が常に最適解かはわからないが、この当時のメルカリの事業のフェーズとしてはワークするやり方だったと思う。

これ以降、似たような図を他社でも見かけるようになった気がした。真似をされるというのがいかなる称賛にも勝る。


チームのロゴを作った

分析チームの「チームロゴ」を作った。

当時、僕の隣に座っていたチーフデザイナーにお願いして、知の省庁であるフクロウをモチーフにしたかわいいロゴを作ってもらった。

これは趣味の範囲のように思われるかもしれないが、実は意外と効用があった。例えば、社内のスライド（Google Slide）において、分析チームが作ったアウトプットは、このロゴを用いた表紙のテンプレートを使う、という文化が生まれた。

これにより、社内メンバーはBI Team Certifiedな（=客観情報として参考になる公式な）資料を見つけやすくなった。

また、チームの社内ブランディングにもなった。分析チーム自身はもちろんのこと、データドリブンに賛同する社員や、後述にでてくるデータの民主化運動に参加するメンバーなどは積極的にこのロゴのシールをMacに貼りつけて仕事をしていた。

社内のデータドリブン化に協力しろと、自分の上司（VP of Product）にこのシールを貼り付けさせたりもした。

画像2

当時の僕のMacにもしっかりと貼ってある〜かわいい


ダッシュボード文化を根付かせた

メルカリでは大体、新たな期（Quarter）が始まると、チームごとにそのチームが担うKR・KPIに応じたダッシュボードを作成し、それを羅針盤にチームの運営が行われることが多い。

いつ頃からかわからないが、社内ではそれがごく当たり前、という感じになっていた。

社内を歩いている時、いろんなチームの人のモニタに、分析チームの作ったダッシュボードが映されているのを見るのは嬉しいものだった。

売り上げ、出品数、継続率、問い合わせ件数、カテゴリ別伸び率、いろんな切り口があった。

また、事業の主要なKPIを全部集めた「Perfect Dashboard」（当時の上司だった執行役員の命名）というものを作ったのはいい思い出。


売り上げ目標をディープに追う仕組みを作った

ダッシュボード芸が深まってくると、「今月の売上着地予想と目標の乖離を簡単に検知するボード」や「今日の売上推移をセミリアルタイムで表示するボード」などが作られた。

その日の午前にはだいたい、日の売上着地がわかるようになり、強い施策を打った10分後にはその反応がグラフに即座に現れるのは、見ていて爽快ではあった。

これは功罪あるが、これによって売り上げ責任を持っているグロースチームはより数値への感度を高め、スピード感を持って日々意思決定ができるようになった。

めちゃくちゃ楽しかったが、あまりディープに数値を追い求めすぎると脳がバグる可能性があるので、強くオススメはできない（僕は好き）。


いくつかの重要な指標の概念を普及させた

社内で広く使われるようになったオリジナルのKPIを起案した。こういうのはとても尊いと思っている。データアナリストは、KPIやモデルと言う形で新しい概念を発明し、社内に普及することに力を使うべきだと、いつも強く思っている。

代表的なところでは「n-STR（Sell Through Rate）」など。出品された商品がn日以内に売れる確率という意味のKPIで、メルカリのビジネスモデル上は極めて重要な指標だった。

内容としてはなんてことがない簡単なKPIだが、

・わかりやすい名称がつくこと
・誰かが頑張って普及すること
・n日という基準を揃えること

などの要素が噛み合って、初めて数値には魂が吹き込まれる。KPIとは、起案することには意味はなく、当然のように社内で使われるようになることでようやく意味を持つ。

そういう意味では、「コーポレートバリュー」と近いものがあるかもしれないと思っている。

上場とか広報とかを手伝った

メルカリは広報が強い会社。
インフォグラフィックと使ったデータ広報や上場時含む投資家コミュニケーションのIRに使うようなデータ分析をちょくちょく手伝ったりした。


データ分析の民主化運動を行った

社内でデータドリブンな考え方が根付き、データ分析の需要が高まるとデータ分析チームだけではすべての分析ニーズに応えられなくなった。

そこで、チームメンバーの一人を「データの民主担当」に任命したところ、彼が縦横無尽に動いてなんとかしてくれた。

分析の研修的なプログラムが実施されたり、専用のslackチャンネルが設立されたり、コンテンツマーケ（社内）が行われたり、いろんなことが起こっていた。すげー。


Lookerを導入した

社内使うダッシュボードツールを、海外で話題になっていた「Looker」にリプレースした。近年は国内でもLookerの導入事例が増えてきているようだが、当時は国内ではほぼファーストペンギンに近い状態だった。

元々使っていたChartioが、運用の長さからかなりガバナンスが乱れており、作られるレポートの増加やDWH（BigQuery）側への負荷増加などの理由から、新しいツールで一度仕切り直しすることを決めた。

当時のことは導入を先頭に立って進めてくれた @haseryoが書いた下記のSpeakerdeckに詳しい。


セグメント戦略を立案し根付かせた

サービスが成長している中で、ユーザ向けのCRMや、予算効率などが論点として大きくなっていった。

そこで、それまでのように全てのユーザを一律のものとして扱うのではなく、ユーザセグメントを策定し、セグメントごとに戦略を分けてグロースプランを練っていくやり方を起案した。

この手法は、グロースの効率を高める上で、サービスのユーザ基盤の構成を理解する上で、投資説明を果たす上で、それぞれ大きく役に立った。

また事業計画を策定する上でも使えるモデルにしたため、かなりリーズナブルな形で事業目標などを設定する際にも使えた。

詳しい内容については、下記の講演資料に残している。

このセグメントはその進化版がメルペイでも使われ、ある期のKRとして特定セグメントのグロースが経営目標として設定されたこともある。


機械学習 × グロースに挑戦（して失敗した）

セグメント × CRMという文脈から、更に一歩踏み込んで、機械学習エンジニアを巻き込んでより効率的なCRMモデルを作り実行しようとして、検証段階で頓挫した。

効率を求めてセグメントを強く絞り込もうとすると、最終的に適応できるボリュームが小さくなり、事業インパクトが小さくなる。

大事にすべきことは、効率やターゲティングの精度の追求ではなく、事業のスケールに本当に資するアクションだけを取ること。

そのあたりの思想語りは、このnoteにぶちこんでおいた。

ちなみにこのとき一緒に取り組んでくれた機械学習エンジニアは本当に優秀な方だった。このプロジェクトではその才能を活かせずに申し訳なく思った。

行動ログの標準化に挑戦（して失敗した）

長くやっているサービスあるある、行動ログの定義が散らかる問題。
いろいろな行動ログが定義されたが、それらの一覧がGoogle Sheetで管理され、更新や追記は実装したチームの善意に委ねられる状態になっていた。

この問題を解決しようと、そもそもの行動ログの実装時点の要件定義書をprogramatic readableなものにして、要件定義書から行動イベント一覧の仕様書を自動生成するフローを導入しようとしたが、うまくいかなかった。

会社が大きくなり、他のデータ整備の勢力との折衝がうまく行かなかった。そのチームと英語でやり取りするのに苦戦したというのもある。

定性 × データ分析に挑んだ（主にチームメンバーが）

最近は定性（インタビューなど）×定量（データ分析）がやや流行り始めているが、当時のメルカリではそういった動きはそこまでなされていなかった。

僕は入社した年に、USのサービスのためにアメリカ現地でインタビューを行い、そこで得た仮説をデータで分析したりしていた。良い試みだったが、正直に言うと散発的でその後も継続的に続くようなムーブメントにはできなかった。

この定量×定性の活動は、のちに2018年にチームにジョインしてくれた @shakezo によって加速されることになる。彼には出品者のペイン解消という難しいイシューに挑んでもらった。アンケート・インタビュー・データ分析を縦横無尽に駆使する彼の姿はまさに定量×定性のインサイトアナリストの走りであった。

彼の姿勢はのちに僕が移籍したメルペイでも活かさせてもらっていた。データとUXリサーチを組みあわせた「User-Maruhadaka」というプロジェクトを立ち上げて、QR決済に潜むペインの解明に挑んだ。

採用を頑張った

チームメンバーの採用は苦労したが、頑張ったと思う。
色んな会社からエースクラスの分析人材を集めた。

マネージャになってからは、リソースの30-40%は採用に使っていたと思う。

元々自分は自分勝手な一匹狼タイプで、チームのことを考えるのは苦手な人種で採用やチーム作りは正直性に合わないと思っていた。また職種としてのレアリティから採用は大変だったが、その面白さと達成感にはすっかりハマっていた。

チームのブランディングをした etc.

2018-2019あたりは兎に角、社外への露出を増やした。
自分としては忌避意識のあるイベント登壇おじさんの役回りも頑張り（苦手ではないが）、メディアにもたくさん出た。

一気に露出を増やすことでこそチームとしての認知を得られるのだ

採用のあれこれはよく考えたら以前まとめたことがあったのでこちらを読んでください。

データ分析者のイベントを立ち上げた

Data Analyst Meetup TokyoとData Leaders Talk、2つのイベントを立ち上げた。どちらも募集に対して応募が大きく上回る人気イベントになった。データ分析という分野の会合に思った以上に需要があることを感じた。

これらは、運営のアレやコレや含め、めちゃくちゃ楽しかった。運営に関わってくれたメンバーが本当にいいやつばかりだった。

今はもう継続されていないが、運営・開催に興味がある方がいましたら、喜んで暖簾を譲りますので、ご連絡ください。


反省点

そんなこんなで、在籍約4年の間に色々なことをやったのだが、反省点もたくさんある。書けばきりがないので特に悔やんでいることをいくつか。

データエンジニアリングにあまり積極的に投資をしなかったこと。
多くの人材を採用したが、ほぼ全て「データアナリスト」であった。そのため、データのパイプラインを組んで分析の生産性を上げたり、データの定義のガバナンスを効かせたり質の担保をするような機能がチーム内になかった。

のちに、遅れながらもメルカリに来てくれた、yuzutas0やhaseryoといった優秀なデータエンジニア人材たちと働くことで、データエンジニアを軽視していた自分のチーム組成戦略を悔いることになった。

メルカリのデータは比較的シンプルかつ初期のエンジニアたちの気遣いもあり、キレイな形で存在していたという境遇の恵みもあっただろう。

チームとしての組成をちゃんとしなかったこと。
マネージャとして採用には力を入れたが、採用・アサイン・評価という点にだけ全力を使い、普段の業務は完全に個々に任せるというスタイルを取っていた。そのため集団としての活動・メンバー間のコラボレーションが少なく、チーム感は薄かった。The スタンドアローンだった。

これは完全にマネージャである自分の差配によって生み出された環境だったと思う。そのために発揮できなかった個々人の歪み（=良い意味での個性）も多くあったと思う。

間違ってはいなかったと思うが、あの時に戻ってもう一度やるなら「チーム感」を当時の1.8xくらいはあるような組織を目指したいと思うだろう。


データリテラシーの低い経営メンバーを避けたこと。
とある事業のリーダーシップ（いわゆるCxO）のデータリテラシーが低く、また経営者としての資質に疑問を持っていたので、積極的な接触を避けていた。

そういった背景があったので、彼のデータ教育のような取り組みを財務部のメンバーに持ちかけられた時に、にべもなく断った。あまり関係を持ちたくなかった。

いま考えるとこれは幼稚だった。彼のデータリテラシーを多少なりとも上げることは、全社的なインパクトを考えると大いに意味があったはずだった。結局、多くのことがマネジメント層のジャッジによって左右される。そこに適切にアプローチし、全社を少しでも正しい方向に導く機会をしっかりと掴むべきだった。自分の私的な好き嫌いで考えるのではなく。

やや極端な言い方になるが、結局の所、専門職に大事なのは「優しさと愛情」だと考えるようになった。データや数値なんて、わからない人からすれば怖いだけだ。リテラシーが低い人に対して、硬直化した態度を取っても何も事態は改善しない。

不安と疎外感がこの世に争いをもたらす。それを救えるのは、同じ目線に立って一緒に歩く姿勢を見せることだけだろう。あの日の自分を殴りたい。


いつも読んでくださってありがとうございます。 サポートいただいたお代は、執筆時に使っている近所のお気に入りのカフェへのお布施にさせていただきます。