テックタッチアドベントカレンダー15 日目担当の teru です。今年の個人的ベスト家電はスマートフォンで見れるネットワークカメラでした。子ども達が寝室で寝ている様子を確認しながら家事ができるのでとても便利です。
きっかけ
13 日目の記事 でも触れているように、弊社でデータ分析基盤のモデリング用途に dbt の利用が始まりました。私の所属する分析運用チームでもこの流れに乗って、dbt を使って分析業務に関わる範囲のデータテーブル構築を自分たち自身で行えるように取り組むことにしました。
分析運用チームには、この記事を書いている時点で私を含む 2 名が在籍していました。二人とも BI ツールを用いて SQL クエリを書いたりレポートを作成したりといったデータアナリストの業務経験はありましたが、dbt についてはまったく経験がない状態でした。データ基盤チームのメンバーから dbt の説明とハンズオンを受け、とりあえず使い始められる状態にはなりましたが、さてこれから dbt をどう使っていこうかと全体設計や移行計画、開発フローを考えなければならない状況となりました。
大まかな開発・運用・デプロイフローはデータ基盤チームが考えてくれていたのでそれに乗っかることとして、既存の DWH、データマートを dbt に移行していく手順については dbt のドキュメント、特にベストプラクティスなどを読みながら進めていけばなんとなくはできそうに感じました。しかし、これまでの before dbt な世界のデータ基盤構築において中間テーブルの依存階層が深すぎたり計算ロジックが入り乱れていたり、データレイヤやグルーピングの概念があいまいであったりなど自ら苦労する技術的負債を生み出していた現状のことを思い出し、オフィシャルなドキュメントの内容を正しく理解して dbt の思想に準じた洗練されたデータ基盤を構築すべきであると思い直しました。
加えて、チームとして dbt の理解をきちんとせずに進めた場合、以下のような課題が生まれる懸念がありました。
- メンバー間で dbt やデータ基盤の設計、実装するコードの基本構造についてなどの認識の差やずれがあると、各々で異なる構造や思想の SQL クエリやコードを書いてしまう
- コードレビュー時にも衝突が発生してしまう
- 全くコードを書いて手を動かさずにドキュメントだけを読んでも、理論と実践のサイクルを回すことができず認識が深まらない
- 現場の開発体験や運用に沿わない設計をしてしまう
これらの課題をクリアしながら進める方法をチーム内で相談した結果、「dbt のベストプラクティスや業務上で掘りたくなったトピックをピックアップして、1 日 1 ページ 30 分で輪読会をやろう」と進めることにしました。
輪読会の準備
チームで dbt の理解を深めていこう、と考えた時から輪読会が適していそうだな、とは思ったのですが、一方で準備が大変だったりして開催が途絶えてしまったり誰かが置いて行かれてしまったり、期間が開いてモチベーションが下がったりしてはもったいないなと思いました。そのため、運用と効果のバランスを考えて以下の内容としました。
- 1 日 1 ページだけやる（分量が多い場合は分割も可）
- 30 分でコンパクトに納める
- 記事を読んで、ほぼ直訳で訳すだけ。サマリ作成などはしない
- 発表は当番制（2 人なので交互）
- 平日に毎日やる。リスケはありだがスキップはできるだけしない
弊チームの場合、開発フローはカンバン方式で、まだ結成してからの日にちも浅くメンバーの疎通向上を目的として朝会と昼会を毎日開催していたので、昼会の後に実施をするのがちょうど良さそうだったので Google カレンダーに繰り返しの予定として登録しました。
Notion にも輪読会のページを作成し、向こう 2 週間の当番表も埋めました。退路は絶つスタイル。
輪読会の実施
発表の当番は開始時間までに記事の翻訳を Notion に書いておき、時間になったらオンラインで集合して内容を読み上げる形で発表していきます。（個人的には、翻訳が間に合わない時は原文のまま読むとか訳しながら読むとかでもよいやという気持ちで臨んでいますが、幸いなことに今のところはきちんと記事を準備して開催できています）
基本は斜め読みしながら重要なところをじっくり読んだり、前と被る部分は読み飛ばしたり、外部リンクや動画は開いて見て気になるところは確認してみたり。業務と絡む部分や実体験と重なる部分（あるいは異なる部分）など感想も交えたりしながら読み進めていって、最後まで読んでコメントを共有したら一日分の開催は終了となります。
記事を読む中でこのページは深堀りしたいとか、最近の業務でこの機能を使ったので知りたいなど新しいトピックが見つかると当番表に追加したり翌日に差し込んだりして適宜内容を追加していっています。
やってみてどうだったか
この記事を書いている時点でまだ実施 3 週目突入したばかりですが、概ね期待通りの効果が出ていると感じています。
良かった点
- dbt のドキュメントがデータ分析運用の業務に即していて、整理もされており読みやすい
- 無理なく理解しながら業務の進行とバランスを取りながら進められる
- 公式などのドキュメントを根拠にした建設的なディスカッションが行える
短期集中タイプの人やもともとデータプロセスの開発に明るい人などであれば一気にドキュメントを読み通して設計や実装まで一気に駆け抜けることもできそうな内容ですが、弊チームではこの 30 分輪読会での読み進め方がちょうどよいペースでハマりました。
コードレビューにおいてもドキュメントをベースにした建設的な議論を行える場面が多く、実装者あるいはレビュアーの無理解や押しつけとなるような実装で進んでしまうようなこともほとんどなく進められています。（という自分の思い込みでなければよいのですが...）
気になった点
- 業務の作業時間が減少する
- 輪読会の準備や実施でコンテキストスイッチのコストが若干発生する
始める時点ですぐ想像できるトレードオフではあるのですが、定期に輪読会に時間が取られるので業務の作業時間が減少しコンテキストスイッチのコストも発生していると感じます。開発の調子が乗ると 1 日とか集中したくなる時もやはりあるので、一定の量までドキュメントを読み進めたら勉強会の頻度を減らしたり開催を終了するなどの変更も必要になりそうです。とはいえオンボーディング期のチームの効率を高めているメリットと比べれば大きな問題ではないので、チームの習熟度を見てしかるべきタイミングで調整していけばよさそうです。
終わりに
分析運用チームでの dbt の導入と、それを定着させるための毎日 30 分の輪読会という取り組みについての紹介でした。ほかの開発チームにも同様の取り組みが適用できるかはチームメンバーの傾向や開発のフロー、取り扱う題材などによって変わりますが、特に立ち上がったばかりなど認識や目線合わせが必要となるチームにおいては効果を発揮できるのではないかと思います。
