Downloaded 44 times
![[Cloud OnAir] Google Cloud へのデータ移行 2019年1月24日 放送](https://cdn.slidesharecdn.com/ss_thumbnails/124-190124123019-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
カスタマーサクセスのためのデータ整備人の活動記録
- 1.
- 2. 自己紹介 ● 吉田 康久 ○Twitterやはてなidは@syou6162 / id:syou6162 ● 前職: NTTコミュニケーション科学基礎研究所 ○ 自然言語処理や機械学習の研究に従事 ● 株式会社はてな ○ アプリケーションエンジニアとして入社 ○ はてなブックマーク ○ サーバー管理/監視システムMackerel ■ 教師なし学習による異常検知機能開発 ● 2020年2月よりMackerelチームのCRE(Customer Reliability Engineer) ○ 主にデータ基盤整備 / データ分析 2
- 3.
- 4.
- 5. アジェンダ ● カスタマーサクセス(CRE)とデータ基盤 /データ整備人 ● カスタマーサクセスのためのデータ整備人の活動記録 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ■ データ分析の一歩手前から伴走 ○ ステップ3: 自走できる環境に近づける ■ チームとして継続的にメタデータを整備できるように 5
- 6. MackerelチームのCREについて ● CRE: CustomerReliability Engineer ○ 日本語に直訳すると「顧客信頼性エンジニア」 ○ 2017年に発足 ● ミッション: 顧客に寄り添い、顧客が抱える真の課題にフォーカスし、その課題を技術 を軸として顧客と共に解決を図る ● キーは「カスタマーサクセス」と「エンジニアリング」 ○ ユーザーの課題をエンジニアリングで解決 ■ 例: テクニカルサポート ○ ユーザーの課題をエンジニアリングで発見 ■ 例: データ分析やデータ基盤 6
- 7.
- 8.
- 9.
- 10.
- 11.
- 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.
- 17.
- 18.
- 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.
- 29. 課題: どうやって継続的にメタデータを管理するか ● サービスは生き物であり、メタデータも日々変化 ○変化に「継続的」に追従したい ○ 管理すべきテーブルやカラム数は普通に多い ● データ整備人の気合と根性だけでは無理 ○ 根性ないので、早々に諦めました... 29
- 30.
- 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