Retty株式会社のdbt-coreとdbt Cloudの導入事例

ツール導入前の課題

1. 内製ツールの不具合が多く、復旧に時間がかかる

これまでは内製ツールを利用していましたが、ツールの作成者やソースコードを熟知しているメンバーの退職により、メンテナンスが十分に行われていない状態でした。
そのため、内製ツールで不具合が発生した際の復旧に時間がかかる等、ブラックボックスが多い状態となっていました。

2. データ分析基盤内に問題が起きた際、原因特定に時間がかかる

Rettyでは2020年から「分析の民主化」を掲げ、データウェアハウスやデータマートが数多く作成されていました。テーブル量も多くなっているうえに、テーブル同士の依存関係を把握するための可視化もされていない状態でした。
したがって、プロダクトやセールスの各部門から、ダッシュボードやテーブルのデータに関する質問が発生した際に、クエリを読んで辿るしか方法がなく、原因特定に時間がかかり、日々の分析業務（意思決定支援）の進行が遅れる形で徐々に課題が顕在化していました。

3. データマネジメント職種の採用の難しさ

Rettyでは既にある程度、データ分析基盤を含むデータパイプラインは整備されていたものの、事業のフェーズとともに分析要望の幅や複雑性が増し、開発や運用をアップデートするニーズが継続して発生している状態でした。
しかし、データパイプライン全体の見直しを行う場合、一定のエンジニアリング知識が必要となることが予想され、1や2で記載した課題やその他の業務と並行しての対応や、データエンジニアやアナリティクスエンジニアを採用し組織立てていくためのリソースの確保が難しい状態でした。

そこで、dbtを導入することで「DWHの管理を内製ツールから置き換え、開発効率を向上させる」ことを目標とし、データアナリストが中心に内製ツールからdbtへの移行を進めることにしました。

dbt-core と dbt Cloud の導入により、内製ツールを使っていたことで生じていた不安感の払拭と、データ分析基盤の開発生産性の向上と問題発生した際の原因特定の効率向上を実現できました。
実際に、新しく入ったデータマネジメントの業務委託メンバーがday1から基盤開発に関わることができ、導入の効果を実感しました。
また、BIツールとしてdbtのYAMLファイルを元に開発・運用が行えるLightdashの採用にも繋がり、BIツールの開発生産性と保守運用の向上・利用コスト削減も実現できました（詳細は、Lightdashのレビュー記事をご参照ください）。

YAMLファイルでのテストの記述方法

dbt標準・dbt_utilsに具体例が載っていないテストの実装を行う際のエラーハンドリングに時間がかかったことがありました。
（例.クォーテーションマークやカッコを入れる箇所が誤っていたり、そもそも入れ損ねていたりしました）
※現在はドキュメントやノウハウ記事が充実していたり、CopilotやAIエージェントなどを活用しやすくなっていたりするため、エラーハンドリングにかかる時間が短縮しやすくなっていると思われます。

dbtへ移行前の環境で使っていたデータセットの削除

dbt移行に伴いデータセット名の命名規則を変更しました。
新環境と旧環境を並行稼働させる期間を設け、データ分析基盤利用者へ新環境への移行を促したものの、抜け漏れが発生しアドホッククエリやバッチクエリでエラーが生じる事態が発生し、関係各所への事前の共有やチェックを念入りに行う重要性や、dbtで依存関係を管理できるようになることのありがたみを実感しました。

dbt移行のための工数確保

dbtへの移行はデータアナリストが担っていたため、主業務のデータ分析と並行してdbt移行も進める必要があり苦労しました。
各メンバーが依頼者と合意を取った上で、dbt移行のための日（dbt開発day）を週1日確保することでプロジェクトの進捗を生みやすくなりました。