Slide 1
Slide 1 text
1
メルカリにおけるDashboard Replacementの事例
~ Looker統治の成功までに伝えたこと、決めたこと、やったこと ~
hase-ryo
Data Analyst / Data Manager @ merpay.inc
Slide 2
Slide 2 text
2
Looker導入を決めてからの話です
● 導入を決めてからのタスク
● コミュニケーション
● ユーザーの反応
これらのイメージをつけることの一助になれば幸いです
他のBIツールからの乗り換え ＆
どうやって社内に浸透させたか？が主題
Slide 3
Slide 3 text
3
自己紹介
hase-ryo
Slide 4
Slide 4 text
4
Data Analyst 兼 Data Manager
長谷川 亮 @ merpay.inc
データマネジメント >> データ分析
データ「を」どうにかする仕事
Lookerでデータの民主化
データガバナンス
MicroService環境におけるデータ統合
セキュリティ
etc..
マーケティングリサーチ WEBメディア BtoBtoC メルペイ
Slide 5
Slide 5 text
メルカリのご紹介
Slide 6
Slide 6 text
6
メルカリ
国内No.1フリマアプリ「メルカリ」
Slide 7
Slide 7 text
7
メルカリの流通総額
約
4,902億円 / 年間
Slide 8
Slide 8 text
8
利用実績推移（JP／通期）
2,320
3,468
GMV¹
4,902億円
単位：億円
FY
2017.6
FY
2018.6
212
334
売上高
462億円
単位：億円
FY
2017.6
FY
2018.6
845
1,075
MAU²
1,357万人
単位：万人
FY
2017.6
FY
2018.6
出典：会社資料。JP版メルカリ事業の通期決算概況（FY2019.6）より。
1. キャンセル等を考慮後の取引高の合計
2. Monthly Active Userの略であり、1ヶ月に一度以上利用した登録ユーザーの数
4,902
FY
2019.6
462
FY
2019.6
1,357
FY
2019.6
Slide 9
Slide 9 text
メルペイのご紹介
Slide 10
Slide 10 text
10
メルペイ＝キャッシュレス スマホ決済
Slide 11
Slide 11 text
メルカリ
「メルカリ」アプリでそのまま使える
Slide 12
Slide 12 text
「メルカリ」の売上金がすぐに使える
Slide 13
Slide 13 text
13
代表的な加盟店
Slide 14
Slide 14 text
14
Looker移行の始まり
Agenda
もくもく移行計画
その後の世界
02
03
01
Slide 15
Slide 15 text
15
Looker移行の始まり
Slide 16
Slide 16 text
16
US & UKで既に浸透していたLooker
UK mercari
JP mercari &
merpay US mercari
すごくいいよ！ 最高だよ！
Slide 17
Slide 17 text
17
UK mercari
JP mercari &
merpay US mercari
Lookerやります！
Slide 18
Slide 18 text
18
既存のBIツールはかなり作り込んでいた。だが辛い点も
見出し データソースを追加できる弊害
分析にSQLが必須
● クエリレベルのばらつき
● TB級の危険なクエリ発行
● 俺の考える最強の中間テー
ブルがいくつも生まれる
● 車輪の再発明
● ローカル定義の氾濫
● 何が正解かわからない
グラフのデータをいじれる弊害
Slide 19
Slide 19 text
19
Lookerは辛みを解決してくれそう！
見出し データソースを追加できる弊害
分析にSQLが必須
● クエリレベルのばらつき
● TB級の危険なクエリ発行
● 俺の考える最強の中間テー
ブルがいくつも生まれる
● 車輪の再発明
● ローカル定義の氾濫
● 何が正解かわからない
グラフのデータをいじれる弊害
● ExploreでSQL不要の分析
● 抽出範囲の最適化
● View単位でデータソースを
統制
● View同士をJoinして拡張
● Githubと連携して定義を
バージョン管理
● PR->Reviewで変更監視
Slide 20
Slide 20 text
20
Lookerは辛みを解決してくれそう！
見出し データソースを追加できる弊害
分析にSQLが必須
● クエリレベルのばらつき
● TB級の危険なクエリ発行
● 俺の考える最強の中間テー
ブルがいくつも生まれる
● 車輪の再発明
● ローカル定義の氾濫
● 何が正解かわからない
グラフのデータをいじれる弊害
● ExploreでSQL不要の分析
● 抽出範囲の最適化
● View単位でデータソースを
統制
● View同士をJoinして拡張
● Githubと連携して定義を
バージョン管理
● PR->Reviewで変更監視
データを見る側は知ったこっちゃない
Slide 21
Slide 21 text
21
Lookerは作り手にとって優しいツールだが・・・？
データを見ている側は
今まで見ていたものが見れなくなる
ことの方が大事件
Slide 22
Slide 22 text
22
意思決定を阻害しない
データの価値は意思決定！
見ていたデータが見れなくなる
→意思決定できない！
という状況は避けたい・・・
→○○にあってLookerにはない情報を殲滅
→必要なものは全て移行するという決定
Slide 23
Slide 23 text
23
大変だけど断捨離のいい機会だった
移行は大変だけど・・・
● 重要なデータの洗い出し
● 指標のロジック確認
● アーキテクチャの再構成
組織としてデータの扱い方を見直
すいい機会だった
Slide 24
Slide 24 text
24
もくもく移行計画
Slide 25
Slide 25 text
25
トップダウンで締め切りを決める
移行計画のポイント
全体周知とダッシュボードの洗い出し
初期構築はデータのプロフェッショナルで
02
03
01
Slide 26
Slide 26 text
26
トップダウンで締め切りを決める
ボトムアップでは移行が終わらない
ユーザーは使い慣れたものを好む
→定義とデータソースが統合できない
導入したい組織単位でやり切る約束をする
（全社、部門、チーム、...）
→リーダーのコミットが必要
Slide 27
Slide 27 text
27
全体周知とダッシュボードの洗い出し
移行計画をデータを使う全社員相手に告知
「今見ているダッシュボードがあれば教えて」
と対象を洗い出す期間を設定
→挙げられたダッシュボードは全て移行対象に
期間内に挙げられなかったダッシュボードは
見られていないと判断。移行しない
Slide 28
Slide 28 text
28
初期構築はデータのプロフェッショナルで
Lookerの最初の構築はハードルが高い
効率的なクエリを書けるSQL力
Githubの知識
LookMLの仕様を理解
etc…
→BIチーム全員で初期構築
→LookMLの書き方やダッシュボードの作り
方のベストプラクティスを確立
Slide 29
Slide 29 text
29
移行のスケジュール
Slide 30
Slide 30 text
30
その後の世界
Slide 31
Slide 31 text
31
細かい要望は移行完了後に
実際に動いているものを見ると触りたくなる
グラフを作りたい
Slackに投稿したい
こんなデータも見れるようにしたい
etc…
→なんでも質問できるSlackチャンネル作成
→Slack BotでExplore権限取得できるように
→wikiにベストプラクティスを集約
→トレーニング実施
Slide 32
Slide 32 text
32
ユーザー数は移行開始から8倍
1.3
万
x8.0
User
Looker
移行開始
Slide 33
Slide 33 text
33
Lookerを使う領域が増えた
会計分析
プロダクト分析
テストパフォーマンス
可視化
運用モニタリング 開発効率分析 HR分析
Slide 34
Slide 34 text
34
Looker環境も巨大に
1600+
Dashboard
300+
View
600+ Looks
9 project
Slide 35
Slide 35 text
35
Looker利用状況のモニタリング
活用が広がった分、生まれた課題もある
適切なユーザーグループと権限管理
LookML開発スキルの底上げ
02
03
01
Slide 36
Slide 36 text
36
Thank you!