「データマネジメント新年会」登壇資料解説

こんにちは！ゲンシュンと申します。
今年1月の「データマネジメント新年会 〜去年のしくじりを共有し、正月ボケを解消する〜」に登壇させていただきました。登壇翌日に資料を投下する予定でしたが気づいたら半年も放置してしまい、、、ようやく正月ボケが解消されたので投下します笑
ちなみにデータ基盤関連ではオフライン登壇は初でしたが、オフラインの方が会場の熱が伝わりやすくて楽しかったです。

お品書き

• 当日話した要点だけ箇条書きでまとめます
• 当時のデータ基盤アーキテクチャについては過去の登壇イベントにて解説してます

しくじり①　機械学習使ったのに運用に乗らなかった解約予測

• プロダクトのデータとSalesForceなどのビジネスデータを利用
• BQMLを使い、高い精度で解約予想出来そうなところまで出来た
• この領域は社内アナリストが一人でやりきってくれました、ありがとう！

• 半年経過したが、ほぼCSに使われていないこと発覚。え、マジ！？

• 精度の高さを追い求めた結果特徴量が非常に細かく、CSが具体のアクションにつなげつらい指標だった
• CSへの浸透や、CSの具体のアクションの紐づけるアクションを一緒に考える必要があった
• そもそも、CSに使われているかどうかちゃんと把握出来ていないのも良くなかった
• よって精度を捨て、指標とCSアクションが具体で繋がるような解約予想を作ってます(現在進行系)
  • これ失敗したら、来年のしくじり登壇でお話します笑

しくじり② 人依存のまま運用が回っていると錯覚してた

• サーバーサイドの言語が変わる対応

• 通称「嗅覚」と呼ばれる、slackでいい感じにスキーマ変更や影響範囲を拾って対応してた
• 当時の目標面談は「バグ０で大幅移行作業やります」と宣言

• データ基盤のリリース後、とある数値が0になってるところから取りこぼし発覚
• あんなに自信あったのに単純な取りこぼしで欠損してしまった

• 仕組み化絶対必要。俺は何だかんだ凄い、人力でイケるんだ、は勘違い
  • 自分が拾う、開発メンバーに教えてもらう、隔週共有会でカバーの三重網でケアするようにした
• そもそも目標の立て方が脳筋すぎる。具体のアクションは「頑張ります！」になっちゃう
  • 「データ基盤のバグ発覚から2日以内に治す対応方針でいきます」の方が、具体的なアクションに繋げやすい
• これをきっかけに、データ基盤のSLOを決める動きも出来た、いい機会だった

しくじり③ ビジネスプロセスに向き合わず目先の改修に専念

• 前提情報。全てのテーブルに登場する概念

• 前提情報。memberのステータスはプロダクトmemberデータ単体で判別できない。まぁ、あるある話

• 前提情報。解約からの再開になると、プロダクトデータが上書きされてしまう。まぁ、あるある話

• 前提情報。Looker側の実装都合で、Looker側で全部joinしてることになってた

• 改善しました！Looker側頑張りすぎたので、DWHのstg層で色々頑張るようにした

• ビジネス側の都合が後から諸々発覚し、そのたびにデータ基盤の改修頑張ってた
• 結局、dim_teamテーブルって何なん？このいたちごっこは何だったのか

• 「◯◯は特殊なパターン、例外」ではなく、「ビジネス的には割と発生する通常フロー」だった
• プロダクト側のDBが、ビジネスプロセスを現せていない課題が浮き彫りに

• 根本解決としてintermediate層を設けた

• これは単に「めんどくさい処理のための中間層用意した」じゃない
• ビジネスプロセスを咀嚼し各レイヤーの責務を言語化した
  • 事業フェーズによって、売り方ってコロコロ変わる
  • でもプロダクトのデータってそんな簡単に追従出来ない
  • ビジネス都合でデータの扱い方すら変わりうるteamとmemberだけ特別対応しよう
• 最初から「実装都合のため中間層用意しよう」と「ビジネスプロセスを考慮して中間層を用意しよう」だと結果一緒でも中身全然違うはず
• ビジネスプロセスに向き合うことが大事

まとめ

• 失敗しておしまいだと勿体ない。学び、改善を経てより良い物が出来るはず
• 失敗はしたくないが、2024年もたくさん失敗して、たくさん学びたい
• ありがとうございました！