1. カスタマーサクセスのための
データ整備人の活動記録
id:syou6162
2020/05/14
第3回 データアーキテクト（データ整備人）を ”前向きに”考える会 登壇資料

2. 自己紹介
● 吉田 康久
○ Twitterやはてなidは@syou6162 / id:syou6162
● 前職: NTTコミュニケーション科学基礎研究所
○ 自然言語処理や機械学習の研究に従事
● 株式会社はてな
○ アプリケーションエンジニアとして入社
○ はてなブックマーク
○ サーバー管理/監視システムMackerel
■ 教師なし学習による異常検知機能開発
● 2020年2月よりMackerelチームのCRE(Customer Reliability Engineer)
○ 主にデータ基盤整備 / データ分析
2

3. お願い: フィードバック、お待ちしております!!!
3

4. https://mackerel.io/ja/
Mackerel: SaaS型の
サーバー監視/管理
サービス
Agentがサーバーの
メトリックを収集、
グラフで可視化 4

5. アジェンダ
● カスタマーサクセス(CRE)とデータ基盤 / データ整備人
● カスタマーサクセスのためのデータ整備人の活動記録
○ ステップ1: 主要KPI計算のためのデータパイプラインの整備
○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう
■ データ分析の一歩手前から伴走
○ ステップ3: 自走できる環境に近づける
■ チームとして継続的にメタデータを整備できるように
5

6. MackerelチームのCREについて
● CRE: Customer Reliability Engineer
○ 日本語に直訳すると「顧客信頼性エンジニア」
○ 2017年に発足
● ミッション: 顧客に寄り添い、顧客が抱える真の課題にフォーカスし、その課題を技術
を軸として顧客と共に解決を図る
● キーは「カスタマーサクセス」と「エンジニアリング」
○ ユーザーの課題をエンジニアリングで解決
■ 例: テクニカルサポート
○ ユーザーの課題をエンジニアリングで発見
■ 例: データ分析やデータ基盤
6

7. カスタマーサクセスを視野に入れたプロダクトの価値
参考：カスタマーサクセスとは何か
プロダクトの機能
そのもの
プロダクトを正しく使いこ
なすことで
得られる価値(成功)
Mackerelを取り巻く顧
客の体験

8. カスタマーサクセスを視野に入れたプロダクトの価値
参考：カスタマーサクセスとは何か
プロダクトの機能
そのもの
プロダクトを正しく使いこ
なすことで
得られる価値(成功)
Mackerelを取り巻く顧
客の体験
CREチームは、カスタマーの成功にフォーカスしつつ、
プロダクトの価値全体を最大化したい

9. カスタマーサクセスを視野に入れたプロダクトの価値
CREチームは、カスタマーの成功にフォーカスしつつ、
プロダクトの価値全体を最大化したい
プロダクト
サクセス
カスタマーの目線でプロ
ダクトの機能そのものを
価値を得やすいものにし
ていく

10. カスタマーサクセスを視野に入れたプロダクトの価値
CREチームは、カスタマーの成功にフォーカスしつつ、
プロダクトの価値全体を最大化したい
プロダクト
サクセス
ハイタッチ
テクニカル
サポート
カスタマーの目線でプロ
ダクトの機能そのものを
価値を得やすいものにし
ていく
プロダクトを正しく使いこなす、Mackerelを取り巻く
体験をより高める支援をする
ハイタッチ：顧客との対面に近い、ハイコストだけど親密
で濃度の高いコミュニケーション
テクニカルサポート：オンラインのスピーディーなコミュニ
ケーション（エフォートレス）

11. カスタマーサクセスを視野に入れたプロダクトの価値
CREチームは、カスタマーの成功にフォーカスしつつ、
プロダクトの価値全体を最大化したい
プロダクト
サクセス
ハイタッチ
テクニカル
サポート
データ分析基盤
CREチーム（広くMackerelチームが）がより効果の高いアクション・意思決定がで
きるようデータ基盤/ データ分析で下支えする。
私の主担当

12. 最近は活用の幅が少し広がりつつある
プロダクトの価値全体を最大化
プロダクト
サクセス
ハイタッチ
テクニカル
サポート
データ分析基盤
セールス /
マーケティング
開発チーム
プロダクト
オーナー

13. 注意: 私のトークでは話さないこと
● 大規模なチーム、すでにデータ基盤がある程度形になっている状況下でのデータ整
備人
○ データ整備人の担当領域がすでに明確に決まっているケース
● チームメンバー全員で↓くらいの規模での話をします(Mackerel Day 2の集合写真)
13
データ整備人の定義によると
このくらいの割合で働いています
データエンジニア = 3
データ整備人 = 4
データアナリスト = 3

14. アジェンダ
● カスタマーサクセス(CRE)とデータ基盤 / データ整備人
● カスタマーサクセスのためのデータ整備人の活動記録
○ ステップ1: 主要KPI計算のためのデータパイプラインの整備
○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう
■ データ分析の一歩手前から伴走
○ ステップ3: 自走できる環境に近づける
■ チームとして継続的にメタデータを整備できるように
14

15. ステップ1: 主要KPI計算のためのデータパイプラインの整備
● 当初: BigQueryもデータウェアハウスもないゼロからのスタート
○ ゼロからって、それって本当?
○ そんなことはない!
● 経営陣向けの主要KPIダッシュボード(スプレッドシート)は存在
○ これが最初のデータ基盤
15
● 方針: このダッシュボードから整備しよう!
○ このダッシュボードは絶対見られる
○ 主要KPIを分解しないと、細かい施策の善し悪しや影響度が分からない
データレイク
RDBからtsvにしたのをシートにコピー
データウェアハウス
生データを(何段階かで)集計
データマート
グラフ表示用のシート

16. 着手以前の状況
16
スタート地点のRDB
のテーブル
ゴールの主要KPIダッ
シュボード

17. 着手以前の状況
17
スタート地点のRDB
のテーブル
ゴールの主要KPIダッ
シュボード
スプレッドシートの依存関係が多段で
発生!
着手以前はそもそもこの依存関係が明
らかではなかった

18. 着手以前の状況
18
Aさん: XXXの分析したかった
けど、KPIダッシュボードが壊れ
るのは怖い...
詳細分析はまた今度にしよう
スタート地点のRDB
のテーブル
ゴールの主要KPIダッ
シュボード
Aさん: XXXを追加分析したい
から変更を加えよう!!
Bさん: ダッシュボード、壊れ
て見れなくなってる?!

19. ● チームメンバーと一緒に既存のKPI算出までのフローを「全部」追った
○ スプレッドシートの依存関係を可視化
● 今回やるスコープを決める
○ 全部一気にやるのは無理
○ まずはKPI系から着手
改善: データワークフローの可視化
19
経理系(請求書関係)
KPI系 => まずこちらから!

20. 改善: ワークフローの簡素化と(部分的な)自動化
● スプレッドシートをスクリプトに置き換え
○ 依存関係のグラフを見ながら、後段に影響が出ないように
○ 「このデータって今見ていますか?」というのを利用者にヒアリング
■ 利用者: プロデューサー、経営陣、経理部、事務チーム
■ 削れるところは可能な限り削ってシンプルに
● 自動化が理想的ではあるものの、特殊なプランも存在する
○ エンジニアなので自動化は大好き...
○ 完全な自動化に必要以上には拘らない
20

21. アジェンダ
● カスタマーサクセス(CRE)とデータ基盤 / データ整備人
● カスタマーサクセスのためのデータ整備人の活動記録
○ ステップ1: 主要KPI計算のためのデータパイプラインの整備
○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう
■ データ分析の一歩手前から伴走
○ ステップ3: 自走できる環境に近づける
■ チームとして継続的にメタデータを整備できるように
21

22. ステップ2: データ基盤で出せる価値を感じてもらう
● データ基盤を整備しても、分析によって価値を生まなければ無意味
○ データ分析の文化醸成はまだまだこれから、という段階
● データ基盤 / データ分析でどこで価値が出せそうか、分析を進めたい人がどこにい
るか、ひたすらヒアリングやミーティング聴講
○ 主要KPIのデータフロー整備の経験が生きた
22

23. 価値が出る & 分析可能なところはどこか
● 例えばこういうミーティングに参加
○ 来期以降の施策を考えるリーダー合宿
○ ペルソナ策定会
○ カスタマージャーニーマップ作成会
○ プロダクトエンゲージメントスコア作成会
○ デザイン相談会
● ミーティングの前にアジェンダが出ていれば、簡単な分析やダッシュボードを持ち込
む
○ データに興味を持ってもらう!
23
事例: ジャーニーマップ
会話例: この設定でつまずく人が多
いって本当ですか? 条件に合うユー
ザーの利用統計見ませんか ?

24. 分析したい人が分析できるスキルを: ペアプロ & 100本ノック
● 「この分析をしたいのであれば、ここに生データがあって、こういう感じで分析ができ
ますよ」という簡単な分析を私が示す
○ 私で全部はやらない
○ 深掘り分析をしたい人に伴走する
● SQLのペアプロ
○ 東京と京都をGoogle Meetで画面共有しながら
● 頻出題材については、SQL100本ノックに取り入れる
○ 参考: 営業さんまで、社員全員がSQLを使う 「越境型組織」 ができるまでの3+1
のポイント | リブセンス
24

25. 意思決定の場所に自分から行く
25
会話例: こちらのデータソースを使
うと、より適切に効果を測定できそ
うですね
会話例: この施策については定量
データよりも定性データのほうが
適切かも?
ペルソナに近いユーザーにインタ
ビューしてみませんか ?
会話例: このKPIを計測する
データは今はないです。
リリース前にログを仕込んでお
きましょう
メルカリさんの事例を参考にさせてもらいました
会話例: 最初はこの分析やった
ほうがよさそうに思っていたけ
ど、優先度低いことが分かりま
したね。
今回はこの分析やらないことに
しましょう

26. アジェンダ
● カスタマーサクセス(CRE)とデータ基盤 / データ整備人
● カスタマーサクセスのためのデータ整備人の活動記録
○ ステップ1: 主要KPI計算のためのデータパイプラインの整備
○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう
■ データ分析の一歩手前から伴走
○ ステップ3: 自走できる環境に近づける
■ チームとして継続的にメタデータを整備できるように
26

27. ステップ3: 自走できる環境に近づける
● 初期は分析者が少人数だったので個別回答で何とかなったが、明らかにスケールし
ない...
○ 解決案: データに対する知識をメタデータに持たせていこう
● BigQueryの{テーブル, カラム}のdescriptionに{テクニカル, ビジネス}メタデータを記
述、Data Catalogでメタデータに対する検索
27
カラムAとB、似てるけどどっちを使うといいですか ?
XXXを調べたいけど、どのテーブルを見ればいいですか ?
この料金って税込ですか、税抜ですか ?
データ整備人(私) 分析したい人

28. Data Catalogで検索
28
先日GAになりました🎉
マネージドサービスなので、データ整備人が 1人
でも運用可能!

29. 課題: どうやって継続的にメタデータを管理するか
● サービスは生き物であり、メタデータも日々変化
○ 変化に「継続的」に追従したい
○ 管理すべきテーブルやカラム数は普通に多い
● データ整備人の気合と根性だけでは無理
○ 根性ないので、早々に諦めました...
29

30. ゆずたそさんからのアドバイス
30
https://twitter.com/yuzutas0/status/12
14772931751841792

31. メタデータ付与、実践!
● 既存カラムへのコメント付与
○ 私が付与
■ 元アプリケーションエンジニアでもあるので、低コストで調査可能
○ 全テーブル / 全カラムにまんべんなく付与するのはコスパが悪いので、発行さ
れたSQLの統計量を元に利用回数の多いものから着手
■ データドリブンに改善
● 新規のカラムの追加 / 既存カラムの変更
○ 実装直後で一番知見があるので、開発チームへ依頼
○ Pull Requestのテンプレートに確認項目を追加
31
typeカラム: 0は仮登録、1は登録済み、2は退会
XXXカラム: 2020年より前はNULL、YYY施策で
集計値が入るようになった。集計条件は〜

32. 開発チームがメタデータを付与するインセンティブ
● 「ALTER TABLE時はメタデータも付与してね!」とお願いするのは簡単
○ 面倒な雑用を押し付けているだけ?
● 開発チームへのメリットを提示
○ 開発チームに最近入ったメンバーにとっても、DBにメタデータがあることは開発
タスクへのオンボーディングを早める意味でも有用
○ エンジニアへのデータ調査依頼の削減
○ SREなど普段アプリケーションのコードを触らない人もいるので、そういった人た
ちに向けても重要な情報を提供できる
● データ整備人だけでなく、「チーム」でメタデータを育てていく環境を作ることを意識
32

33. RDBからBigQueryへのメタデータの組み込みフロー
33
開発チーム + 私で
コメントDDLを付与
メタデータを
自由に検索
● コメントDDLはtblsを使うと便利
○ スキーマ情報をjsonで取り扱える
● tblsで抽出した情報をjqで加工、bqコマンドでスキーマを流し込めば完成!
○ 詳細はこちら
○ コメントの付与率をMackerelで可視化することでモチベーション維持
付与率を可視化
BigQueryだけで何とか
するのは大変しんどい !!

34. まとめ
34
● カスタマーサクセス(CRE)とデータ基盤 / データ整備人
● カスタマーサクセスのためのデータ整備人の活動記録
○ ステップ1: 主要KPI計算のためのデータパイプラインの整備
○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう
■ データ分析の一歩手前から伴走
○ ステップ3: 自走できる環境に近づける
■ チームとして継続的にメタデータを整備できるように
私が思うデータ整備人の役割:
データの活用者(意思決定者など)を助けたり、データを取り巻く環境がどうある
べきかを定義し、データの生成者(=エンジニアなど)と協力して、あるべき姿へ
近づけていくこと

35. 参考
● データ基盤関係
○ データマネジメント知識体系ガイド
○ データマネジメントが30分でわかる本
○ データ基盤のメタデータを継続的に管理できる仕組みを作る - Hatena
Developer Blog
○ データ基盤の3分類と進化的データモデリング
● カスタマーサクセス関係
○ セールスエンジニア 改め Customer Reliability Engineer (CRE) になりました -
Hatena Developer Blog
○ カスタマーサクセスとは何か――日本企業にこそ必要な「これからの顧客との
付き合い方」
35