mercari.go #21 を開催しました #mercarigo
こんにちは。メルペイのデータアナリストチームです。
メルペイはプロダクトの開発フェーズにあり、リリースに向けて全社で頑張っています。
「プロダクトがないのに、データ分析？」と思う方もいらっしゃるはずなので、メルペイのデータアナリストの業務と、力を入れているダッシュボードツール「Looker」の活用について紹介させて頂きます。
プロダクトがないフェーズでの仕事
Lookerの話をする前に、まずは私達の状況を簡単に説明します。
分析チームを抱える企業は沢山ありますが、「プロダクトができる前から活動しているケース」は少ないと思います。
そういった意味では、私達のチームは他の会社と比べてユニークなポジションになっています。
一言で言えば「事業を作るための分析」を行っています。
メルペイの事業が成り立つには「良いプロダクト」を作り、「ステークホルダーとの関係」を築き、「しっかりとした運用」を行うことが大事です。
今のフェーズでの分析内容
データアナリストチームでは、前述の3つに関係する分析を行っています。
- 「良いプロダクト」を目指して
- メルカリの使われ方の分析や、将来に向けたDB設計、ログ設計といった企画や開発の上流から関与
- 「ステークホルダーとの関係」を構築するために
- 数字に基づいた外部への提案や折衝の面で協力
- 「しっかりとした運用」を見極める
- 制度設計やオペレーション変更の影響を定量化して意思決定に貢献
メルペイ独自のプロダクトはまだありませんので、上記の分析はメルカリで蓄積したデータを用いて行っています。見ているデータはメルカリ側の分析チームと同じですが、別の角度、別のアプローチで取り組んでいます。
チームのミッションとして「社内全体で数字に基づいた意思決定を推進する」を掲げており、社内で関わる範囲は非常に広くなっています（メルカリグループ内で会社を横断する分析もあります）。
分析や共有のためのツールは様々ですが、社内の共通言語となるダッシュボードはその中でも特に重要だと考えています。
メルペイでは全面的に「Looker」というダッシュボードツールの導入を進めており、実務での活用も始まっています。
Lookerを選んだ理由
Lookerというツールにあまり馴染みのない方も多いと思います。
周りでも本格的に導入しているという話はまだ聞いたことがなく、日本での普及はこれから、といったところでしょうか。
このツール、実はメルカリUKやメルカリUSで先行して導入しており、実績とさらなる可能性に期待してメルカリJP、メルペイでも導入を決めました。今ではメルカリ、メルペイの分析チームで合同プロジェクトを発足させ、全社的な導入を進めています。
Lookerは一般的なダッシュボードツールよりも「エンジニアに寄り添った設計」になっています。メルカリグループは日本を代表するTech Companyを目指しており、Lookerの紹介を受けた時から相性が良さそうだと感じました。
今までもダッシュボードツールは使っていたのですが、長く使っているうちに「メンテナンス上の問題」が発生していました。
ダッシュボードが増えることは素晴らしいと思うのですが、当然ながらメンテナンスコストも増加してしまいます。
分析チーム内ではダッシュボードの見直しを定期的に行っていましたが、利用者が増えるに連れてだんだんと難しくなっていきました。
- 誰がどんなダッシュボードを作っているのか把握しづらい
- クエリの書き方が人に大きく依存し、読むのに労力が必要になる
- データソースの依存関係が不明で、自動実行クエリを止める判断が難しい
- etc …
Lookerには「メンテナンスコストを現実的なレベルでキープする」という期待もしています。その期待に答えてくれそうな特徴を紹介します。
導入の決め手となった特徴
本格的な導入を前に試用期間を設けたのですが、その中で感じたLookerの良さを紹介します。
（機能的な部分は少し荒く書いていますので、詳しく知りたい方は公式ページでご確認ください）
- ダッシュボードのベースとなる集計クエリをGitHubで管理できる
- ダッシュボードの定義自体もコード化して共有できる
- 演算は外部DBに任せるためBigQueryのスピードを活用できる
- データソースさえ作っておけば簡単にPivotやFilterができる
- ダッシュボードの閲覧状況を簡単にチェックできる
- 柔軟なRole管理、アクセス管理ができる
- 独自拡張が可能なグラフやモダンなUI
- グラフを投稿するなどSlackとの連携も容易
ダッシュボードを作る立場からは「GitHubで管理できる」という点がキーポイントでした。
KPIの定義やクエリなど、バラバラに管理していたものが一元化され、「ダッシュボードのバージョン管理」ができるようになりました。データソースを作成する際にPull Requestを活用することで必ずレビューが実施され、クエリの品質も担保されます。
LookMLのサンプル（ダッシュボードのもとになるデータを作る画面）
ダッシュボードの利用者の観点からは、「GUI操作だけで自由に要素を組み合わせてグラフを作れる」ことが重要でした。
集計期間やフィルタの条件を変更したいという典型的な要望であれば、GUIベースの「Explore」という機能で簡単に実現できます。SQLを書いたことがない人でも「Explore」という文字通り、探索的にデータの理解を深めることができます。
ただ、高機能であるがゆえにダッシュボードをゼロから作る場合、「多少の敷居の高さ」も感じます。
SQLを書くスキルの他、ダッシュボードツールの使用経験、GitHubを使った開発フローの経験が欲しいところです。
データソースを作り、データ同士の連携を定義する作業を念入りにするほど、利用者が快適になるツールという印象です。
Lookerは「誰でも手軽にダッシュボードが作れる！」という類のツールではありませんが、「ダッシュボードのコード管理を実現した」という点でこのジャンルを一歩前進させたと思います。
使いやすいダッシュボードの作成はデータアナリストチームの重要な役割の一つなので、「自分たちの頑張りが全社のデータ活用を滑らかにし、データドリブンな経営に近づく」と考えるとやりがいがあります。
Lookerの活用と今後の展開
メルカリ、メルペイでは重要なKPIをモニタリングするダッシュボードを作って、日々の数字を追っています。メルカリというプラットフォームの様子をきちんとモニタリングしつつ、メルペイ特有の機能やサービスを開発しています。
開発の進捗に伴い企画や機能開発を行っているチームからの要望も増え、Lookerを使ってくれている人が増えています。
最近ではベースとなるデータソースもある程度揃ってきたので、各チームのニーズに合わせて「チーム単位でハンズオン」を開催したり、「個別にレクチャー」をしたりと社内での普及を進めています。
メルペイは決済を軸に、「データドリブンな事業展開」を考えています。決済分野の分析に興味をお持ちの方がいらっしゃったら、データを活用して新しいFintechを一緒に作りませんか？
メルペイではデータアナリストを募集しています！
