「指標」を支えるエンジニアリング: DataOpsNight #1

「指標」を支えるエンジニアリング
株式会社 MonotaRO: 竹野峻輔
1
2022.02.17 Data Ops Night #1
© 2020 MonotaRO Co., Ltd. All Rights Reserved.

発表者: 竹野峻輔
2
ソフトウェアエンジニア
株式会社 MonotaRO (2021年2月より) ← ベンチャー
推薦システムの開発/分析やってます。
Web開発〜データ基盤あたりが守備範囲です
興味あること
- 継続的実験: いかに組織的に素早く実験を回せるか
- データアーキテクティング

3
事業:
- toBのEC事業. 売上1900億 (2021)
- YoY+約20%: 3~4年で2倍
組織:
- 490 ~ (のべ1680）人の規模
MonotaRO: 事業とデータの関わり
2021年12月期決算発表より
モノタロウエンジニア採用情報
MonotaRO、データマイニングツールに KXENを採用 (2008)
常識破りのデータドリブン企業・モノタロウが分析から施策まで
を直結させ、PDCAを3倍速にできた理由(2019)
売り上げ5000億円を支えるシステムを目指して (2019)

「指標」は「プロダクト」
● 組織で最も使われるデータアプリケーション
○ 事業サービスのパフォーマンスのモニタリング
○ チームや個人でのKPIやKGI, OKRといったコミュニケーション
○ ABテストでの評価
● 開発者/ユーザ、どちらも増えると大変になる
○ 開発の観点: 属人化。一貫性や整合性。
○ ユーザの観点: 認知負荷の問題
○ 流行り廃りが激しい
4

INSIDE Metric System: OVERVIEW
BIツール
DWH SaaS
App ユーザ
「指標」を支えるのは複数の長大なシステムの依存関係。
指標
1〜K
神ダッシュボード
（壊れると世が乱れる）
指標K+1
指標K+2
神の子ダッシュボード
DRYではない大量の集計SQL
(指標にも依存関係がある)
有象無象
…
Transaction Tables
Frontend App
Backend App
RDB
Event Tables

6
INSIDE Metric System: FACT TABLES
Transaction Tables
有象無象
BIツール
App
Frontend App
Backend App
RDB
ユーザ
Event Tables
ディメンショナルモデリングを通じた
スノーフレーク/スタースキーマによる実装
セグメントと集計テーブルに分けて正規化
FACT
FACT
FACT
DWH SaaS
Dims
Dimension tables
Fact table

7
INSIDE Metric System: WIDE TABLES
Transaction Tables
有象無象
BIツール
App
Frontend App
Backend App
RDB
ユーザ
WIDE
TABLE
Event Tables
ディメンジョンは非正規化された
結合操作が不要の集計テーブル
DWH SaaS
WIDE

8
FACT TABLES V.S. WIDE TABLES
ユーザの利便性の観点:
中長期の開発・運用に向いている
- テーブル数は多い
- 再利用性が高い
- 認知負荷は低い
- セグメント追加/削除はコスト低い
短期的の開発・運用に向いている
- テーブル数は単一
- 再利用性は低い
- テーブルの認知負荷は高い
- セグメントの追加/削除はコスト高い
探索用途に向いている
- ユーザによる実装コストは低い
- 複雑なフィルタ操作が実現可能
- 集計は都度必要
モニタリング用途に向いている
- ユーザによる実装コストは低い
- フィルタ操作は択一
- 集計が不要
開発の利便性の観点:

9
INSIDE Metric System: HYBRID Model
Transaction Tables
有象無象
BIツール
App
Frontend App
Backend App
RDB
ユーザ
Event Tables
ファクトテーブルとワイドテーブルのいいところを
取れればどのような用途でも対応できる！
WIDE
TABLE
FACT
FACT
FACT
DWH SaaS
Dims

10
こうして世界は救われた... fin.

世界は救われた...？
11
ユーザの観点では実はそんなに便利になってない可能性が高い。
- ユーザが生産者＆消費者 → 役割分担によるサイロ化
- 依存構造の適切な把握、指標の集計パイプラインの認知負荷の問題こう分割しがち

世界は救われた...？
12
ユーザの観点では実はそんなに便利になってない可能性が高い
- ユーザが生産者＆消費者 → 役割分担によるサイロ化
- 依存構造の適切な把握、指標の集計パイプラインの認知負荷の問題
ダッシュボードAでは+Xだけど
ダッシュボードBでは+Yなんだけどなんで？
ダッシュボードAは
「Xページランディング異常値処理として
過去12週間の売上上位0.1%を除去して
推薦枠のポジションバイアスを系。
訪問セッション回数が分母、クリックセッション回数が分
子のユーザ別CTR平均をブートストラップ平均法」により
算出してます

13
指標テーブルは再利用可能か？
チーム用ダッシュボード
全社用ダッシュボード
社外用ダッシュボード
施策用ダッシュボード
1. ダッシュボードのライフサイクルに応じたステージング戦略が必要
2. コンテキストや用途よって同じ指標でも作り分けが必要
3. 事業フェーズに応じた指標の開発が必要
コンバージョンとは？
検索サービスのファネル
新規ユーザのファネル
異常値処理
オフライン/ABテストの指標
長期指標の代替指標の開発
指標の介入容易性・検出力の評価
ガードレール/デバッグメトリクス
計測とは何か(JIS): 指標をとりまくサイエンスの観点:
“特定の目的をもって，事物を量的にとらえるための方法・手段を考究し，実施し，
その結果を用い所期の目的を達成させること。” https://kikakurui.com/z8/Z8103-2000-01.html
用途計測の目的目的達成のための方法・手段
→ 「指標」テーブルは実は再利用性が高くない

14
「指標」のためにすべきこと
データの流れに対して水平分割はサイロ化をうみやすい。垂直分割化が理想
- 標準化と標準の上のツール開発が必要
- 指標の命名、処理のモジュール化、I/Fの定義、ドキュメンテーション
- 透過的なバッチシステムの用意
- 集計済みテーブルよりも集計前のシグナル / エンティティのテーブルの整備
- シグナル: 検索や新規ユーザのファネルイベント. イベントとunion可能
- エンティティ: ディメンジョン(階層構造）や状態遷移(Slowly Changing D.)
指標
1〜K
指標K+1
指標K+2
有象無象
…
Transaction
Frontend App
Backend App
RDB
Event
シグナル
エンティティ
探索向け

15
シグナル, エンティティの開発 (時間があれば)
- エンティティ: イベントに関わるオブジェクト。クリーンな命名
- 単位の整理: 顧客 ~ ブラウザ, 会員ID, 会員ID[デバイス別] …
- 属性やセグメント、それに伴う状態管理(Slowly Changing Dimension)
- シグナル: 着目するエンティティの重要な動きの定義、重みづけ。
おすすめ: ファネルをイベントテーブルとして作る
- 検索用ファネル: 検索 → クエリ入力 → 結果表示 → クリック → カートイン [成功]
- 新規登録のファネル: 未登録 → 訪問 → 購入手続き → 情報入力 → アクティベート[成功]
→ 集計: 分析単位シグナルとエンティティがあれば集計の仕方は大体一緒
- 異常値の除去などはしない処理前のテーブル

本日の発表まとめ
「指標」をエンジニアリングの観点を紹介
○ ファクトテーブル / ワイドテーブル
だけ用意すればよいわけではない → 罠にハマるかも
「指標」の再利用は容易ではない
○ 計測 = 用途 x 計測の目的 x 方法・手段
○ 標準化/開発が大事
16

参考資料:
● [レポート] モダンデータウェアハウスにおける「キンボール」〜残す価値のあるもの、ないもの
#dbtcoalesce
● Keynote: The Metric System: #dbtcoalesce
● 過去 - 発表資料など
○ ベンチャー企業におけるDWH DevOps @ Retty
○ カルチャーとエンジニアリングをつなぐデータプラットフォーム
○ toC企業におけるデータ活用
17

「指標」を支えるエンジニアリング: DataOpsNight #1

More Related Content

What's hot

More from 株式会社MonotaRO Tech Team

「指標」を支えるエンジニアリング: DataOpsNight #1