データ基盤チームが組織に周知する際に意識したこと

こんにちは、ゲンシュンです。
uniposアドベントカレンダー11日目の記事を今更ですが投稿しますmm(遅くなってスミマセン)

弊社ではデータ基盤の立ち上げが2021年夏に始まりまして、誕生から1年経ちました。データ基盤は作っておしまいではなく「データを使って何をどう意思決定させるのか？」「データで可視化するために、どういうログ要件が　必要なのか」「基盤の保守運用にあたり、システム周りの変更をどう連携するべきか」など、様々なことをいろんな組織と連携を取らなければなりません。
ステークホルダーが多いと、どうもコミュニケーション周りで難しい場面が出てきます。自分が実際に組織に浸透させたこと、周知したこと、どういう事を意識して伝えたのか？をまとめたので軽く振り返ろうと思います。

①ログが正しく取れないが顧客に影響がないものはバグではないという認識を変える

社内ではバグ内容に対してインシデントレベル(即日対応、次回リリースで修正など)を分けてましたが、「バグ=顧客に影響がある」というのが前提にありました。データやログが仕様通りに動かずデータが正しく取れなかったとしても、バグ修正の優先度が決まっていなかったり、そもそも顧客に影響がないならバグではないという認識が多少なりともありました。
これは誰が悪いとかそういう話ではなく、組織内で認識が揃っていないだけの話ではあるので、チーム上司に相談しながら揃えていく動きをしました。

• CTOやマネージャー方面に打診しトップダウンで決めるように進める
  • 「ログに関するバグって、インシデントレベルとか決まってないと思うので決めたいです〜」から打診
  • インシデントレベル(○○なバグは即修正、△△なバグは次のリリースで)の叩き作って決定
  • 開発メンバーへの周知の仕方相談
• 「正しくログ出力出来なかった時のバグ扱いに関するUPDATE」として周知する

決まってなかったことを決めただけなので、周知浸透において困ったことは無かったです。
万一難航しそうになった場合、顧客に影響が無いかもしれないが「データ基盤」を持つ選択をした以上、データから意思決定をする組織であるべきなのに、そのデータが取れないのはマズイのでは！？という意思をぶつける予定でしたが、そこは意思疎通済みだったので良かったです。

実際「バグ」「ISSUE」このあたりの認識って個々に寄る部分があると思ってます。皆さんは「即修正のバグ」と「次回修正用に積まれるISSUE」の線引きは明確になってますでしょうか。

②データ基盤の仕組みを定期的に解説

「ここのプロダクト改修が、データ基盤方面に影響あると思ってなかった！」ってデータ基盤あるあるですよね(あって欲しくないけどｗ
ここへの根本解決って個人的には正直難しいと思ってて、超極論ですが以下2つしかないと思ってます。

• 開発フローを超ガチガチにして、どんなアイテムもデータ基盤への影響がわかるようになる
• データ基盤チームが、システム方面スーパー密に詳しくなって超頑張る

前者は単純に開発スピードが激減するしお互い疲れるだけですが、意図しない変更や取りこぼしは起きません。後者は超大変です。

この問題に対する根本解決には至ってないですが、少しでも楽するために自分は定期的に「データ基盤の仕組み」を、全エンジニアが参加する週1定例の枠をいただいて発表しています。

話す内容としては以下な感じです。

• どこのデータが、どういうふうに集まってるのか(BQのこれが、毎朝取り込まれてるよ〜
• 集まったデータが、どういう場面に活かせてるのか(普段皆さんが見てるLookerにつながってますよ〜
• 前回のインフラ改善で○○が✕✕になったから、つまりデータ基盤も○○を✕✕するように対応したんだよ〜

仕組みとかって1回発表しておしまいになりがちですが、普段の開発で意識しない部分って1回聞いただけじゃ絶対覚えられない把握出来ないと思っているので、定期的に話してます(既に知ってる方が飽きないように切り口を変えてますが)。

狙いとしては「今やってるリファクタやシステム改善がもしかしたらデータ基盤に影響あるんじゃね？」という想起が、一人でも一瞬でも起きたらいいな〜と思ってます。全ケースは無理です。少しでも想起できたら、です。

実際に「○○対応の結果、この値が変わるんですけどデータ基盤に影響ありそうですよね？」とか「△△を、これデータ基盤に影響ないから問題ないと思ってますが一応確認していただけますか？」の問い合わせが気軽に来ているので、効果があったんじゃないかなーと思ってます。

何度も言いますが「ここのプロダクト改修がデータ基盤方面に影響あると思ってなかった！」に対する解決にはなりませんが、少なくとも仕組みに少しでも理解がある人が増えてるのは最終的に助かるので大事だと思ってます。

エンジニアの皆さんに、いつも本当に感謝してます！

③データ基盤チームが何かしら関わるように開発フローに組み込む

新機能がリリースされる前後であるあるだったこと

• ○○機能がリリースされるよ！と直前に周知される
  • データ基盤が未対応なので、超急ぎで対応しなきゃいけなくなる
• データ基盤チームがしらないうちに新機能がリリースされる
  • ログの落とし方やDBの仕様的に、正しく計測出来ないとリリース後にツッコミするしかない

前者は俺の命を削ればなんとか間に合うも、後者は修正リリースが発生するので結構大変です。これは組織体制の変更や、データ基盤チームへの打診タイミングが人ごとに違うなぜなら決まってないから、などが要因でした。

これはトップダウンよりも開発チームの開発フローや、何に困っているのか？具体的な話を聞いた上で案を決めるボトムアップ方式で行った方が良さそう！と思い色々ヒアリングしました。データ基盤チームに期待していることが人によって違ったりしていることも見えてきました。

決めたことは、開発フローにおいてデータ基盤チームが関わる「タイミング」と「やること」だけをまとめて、Notionのテンプレートに保存しました。ざっくり以下。

• 新機能の企画が出る
  • 機能が狙う効果とどういう指標をみるのかを、データ基盤チーム(アナリスト込み)と相談
  • 手段は一切話さず、どうやったら効果が見えるのか？だけを話す
  • Looker(弊社はこれで可視化してます)のダッシュボード要件をこのタイミングで決める
• 開発が始まる
  • 前段で決まったみたい指標をどうやったら見れるようになるのか、エンジニアとデータ基盤チームで相談
  • 本来はエンジニア内だけで決められる内容ですが、ログ出力やDB周りの連携で結局話すのでこのタイミングで関係値築く
• テスト
  • ログ出力などのテスト内容をデータ基盤チームがレビュー
  • 機能の動作確認は当然されますが、ログの確認がされなかったことがあったので(誰が責任をもつのか？が決まってなかったのが原因です)
• リリース
  • ダッシュボード要件で決められたものが見えるはず！やったね！

これはトップダウンで決めていた場合、エンジニア内の課題感や期待値のズレとかがわかっていなかったので、ボトムアップで決められて結果的に良かったです。

原因が「決まってない」ものに関しては決めに行こう！！誰と決めた方がより確実なのか？をその都度考えていった感じです。

④データ基盤で可視化されたものを定期的に提示する

データ基盤とエンジニアの距離感を縮ませたい！！エンジニアが頑張って開発したものがちゃんと利用されてる事実をみんなに知ってもらいたい！！

ただ、データ周りで難しいのが因果と相関周りですね。
例えば○○機能によってある数値がA→Bにあがった場合、要因がその機能なのかどうかをちゃんと分析しないと、○○機能のおかげなのかどうかわかりませんよね。単に週末だったからかもしれないし、クリスマスやらハロウィンやらそういう時期イベントと被ったのかもしれません。

単に数字の発表ではなく要因をしっかり分析したうえで結果を共有するとなると、分析に時間とかかかっちゃうし、ものによってはネガティブフィードバックになりえるので、中々発表出来ないな〜〜と。

でも別に、因果要因相関その手の話一切せずに、数字だけ共有しても良いんじゃね？と思い、Q単位で開発したものの数字共有だけしていくことにしました。
○○機能リリース前の数字はXXXだったけど、リリース後はYYYY。○○機能の寄与はわからんけど、でもYYYYも使ってくれてるんだよ！凄いじゃん！みたいなトーンで数字を伝えるだけです笑

自分が6年ぐらい前にフロントの開発をしていたときに、売上とか利用者とか数字周りに疎かったんですよね(触れる機会が少ないし自分が中々取りにいけなかった)。自分のプロダクト、サービスの利用数とか数字の規模感を知るのは大事だと思っているので、とにかく積極的に伝えるようにしてます。

なのでデータ基盤チームは「因果の話をしない数値だけの共有」「分析した結果の共有」の2つに分けて話すスタイルにしてます。

以上です。ありがとうございました！