dbt移行プロジェクトを振り返ってみた[連載2/3] #dbtでデータの民主化
こんにちは、グルメサイトRettyでデータアナリストをしているdaikichiです。
こちらの記事はRetty分析チームの連載「#dbtでデータの民主化」の2週目の記事です！
前回はデータアナリストの上野によるデータアナリストがdbtを使って育てるデータマネジメントでした。
次回はアナリティクスエンジニアの井下田によるDWHの管理を内製からdbtに移行した話です。
この記事では、dbt移行プロジェクト（以下PJ）の進め方を時系列順に振り返った上で、学びを整理していきます。
5月「PJマネジメントしないとやばい！」
dbt移行自体は4月下旬から始まりました。開発環境やCI/CDの構築は事前に済ませており、既存のデータモデルを維持したままの移行を完了させる計画でした。
また、Rettyの分析チームではスクラムを採用しているためバックログで優先度を決めています。
そのため、最初はPJではなく日々のタスクの1つとして、簡単なテーブルの移行からスタートしました。
しかし、徐々に移行が難しいテーブルが増えていき、メンバーによって理解度やタスクにかかる時間に差が生まれてきました。
また、dbtに関係していたメンバーの入れ替わりがあり、何がゴールでどのくらいの時間がかかるかなどを誰も把握できていない状態になりました。
上のような経緯があり、dbt移行PJとしてPJ化することが決まりました。
6月「開発に時間が取れない！」
dbt移行PJは6月からスタートしました。
最初の1週間はPJ全体のゴール（受け入れ条件とアウトカム）の設定、ゴールを達成するためのタスクの洗い出し、タスクの順序、PJメンバーがdbt開発にさける工数の確認や、マイルストーンの設定などをしました。
2週目からは業務委託メンバーも巻き込んで開発をスタートしました。
しかし、dbt開発に十分な時間を割けない問題が発生しました。
理由としては、開発メンバーがデータアナリストが中心で、主業務であるデータ分析業務の優先順位が高かったためです。
なかなか開発に時間が取れない中、実施した取り組みは、dbt開発DAYを週1で行うことでした。
dbt開発DAYである木曜日は基本的に差し込みの対応やデータ分析の業務は行わずにdbtの開発に集中することになりました。
そうすることで、まとまった開発時間を確保でき、開発スピードが向上しました。また、同期的に開発を行えたことでメンバー間でタスクのサポートや、モブプロによる知識の共有ができました。
7月「認識のずれが増えた！」
7月はシニアEMやPMを振り返り会に巻き込むことで、振り返り会で出すTRYの質を向上させるなど、プロジェクト進行が上手くいき始めました。
また、今回のPJは社内の BigQueryユーザー全員（社員の約60%）に協力してもらう必要があったため、社内勉強会でdbtに関する発表（現状の分析基盤の課題とdbtがどう解決するか）を行いました。
その一方、開発メンバー間の開発方針の認識のずれやタスクにつけていたストーリーポイントが過大過小であったりするなどの問題が起きました。
上のような問題が増える中で行った施策は、dbt朝会でした。毎朝、PjMと開発指揮をしていたメンバーの2人で、①方針がふわふわしている事柄ともやもやしていることをブレスト②それらを優先度順に議論することをしました。
そうすることで、起きていた問題に加えて、今後起こりうる問題なども先手を打って考えることができたため、開発スピードが一段と速くなりました。
8月「サポートがうまくできない！」
8月は9割の開発を終え、あとは抜け漏れていた開発やPJ外のメンバーに協力いただくことのサポートを主に行いました。
しかし、PJ外のメンバーに協力いただくことが多く複雑で、協力してもらう内容を書いたドキュメントを配るだけでは対応できなくなってしまいました。
そんな中行った施策はオフィスアワーです。分析チームでは、普段から毎週水曜日の18時に分析やデータ出しなどなんでも相談できる場としてオフィスアワーを設定していました。
それに倣って、今回のPJでもdbtオフィスアワーと称して、毎日18時から30分間をdbtに関する相談をなんでも受けるという時間を設定しました。
そうすることで、協力いただく方に対して、マンツーマンで柔軟なサポートをすることができました。
8月上旬には業務委託の新メンバーが増えましたが、それ以前に整備していたドキュメントのおかげでday1から開発を進めていただくことができました。
そして8月下旬に全体ゴールの達成を確認し、PJを終了しました。
学び
最終的にデッドラインであった9月末から1ヶ月早くPJを終えることができました。なぜうまくいったかを振り返ります。
①そもそもPJ化したから
PJ化する前は、分析基盤を内製ツールからdbtに移行することでどんな状態にしたいかという認識をチームで揃えることができていませんでした。重要でしたが、重いボールで、開発メンバーの誰かが持つには困難だったからです。
そういった状況の中、PJ化することでPJ進行の責任者が決まり、ゴールの定義づけをする人を生む仕組み化ができました。
その結果、1ヶ月早くPJ終了が実現できたと思います。
②チーム内でゴール達成のための仕組み化ができた
仕組み化できたこととして大きく2つ。
チームイベントの設定とナレッジの共有です。
チームイベントを設定することで、認識のズレを埋めて、PJの進め方と進捗状況などをPJ内で認識を揃えることができました。（主なイベントは以下の通り）
また、ナレッジの共有をすることで、短期的には他の開発メンバーの開発スピードを上げ、長期的には途中でPJにジョインされた方や未来の自分達のキャッチアップコストを大幅に下げることができました。
③チーム外から応援されるPJにできたから
dbt移行PJは前述の通り、社内の BigQueryユーザー全員（社員の約60%）に協力してもらう必要があるため、社内を大きく巻き込む必要性がありました。
また自分自身、開発プロジェクトは初めての経験でした。そのため、経験のある有識者にエンジニアリングの知識やPJ進行のためのスキルをサポートしてもらう必要があると考えました。
具体的にやったことは大きく以下の2つです。
社内勉強会についてはこちらのnoteに詳しく記載があります。
終わりに
今回はdbt移行PJをプロジェクトマネジメント面で振り返ってみました。
今思うと、5月は本当に大変な状況でしたが、最終的にゴールを達成できてよかったです。
Rettyのデータアナリストは、意思決定のための分析以外にも社内で分析の民主化を進めています。
もっと具体的に話を聞いてみたい、興味を持った方がいればdaikichiまでお気軽にDMをどうぞ！
また、分析チームのマネージャーやデータアナリストのMeetyも公開されているのでこちらも併せてどうぞ！
この記事が気に入ったらサポートをしてみませんか？