dbt Platform (旧Cloud)スタートアップでの導入事例

ツール導入前の課題

enechainでは複数プロダクトのデータをBigQuery上で横断的に管理していましたが、データ変換処理はdbt Coreによるモデリングと、BigQuery Scheduled Queryによる処理が混在している状態でした。特に以下の課題がありました。

• ジョブスケジューリングやCI/CDを自前で構築・運用する必要があり、少人数チームのリソースを圧迫していた。
• Scheduled Queryで管理しているパイプラインはGit管理されておらず、変更時のテストは本番クエリをコピーして手元で修正し、両方の結果を目視比較するという手動プロセスに頼っていた。
• 重要なデータ集計の変更にレビュープロセスが存在せず、誰でもレビューなしで変更を反映できる状態だった。これがITGC上のリスクであると同時に、ロジックの属人化を招いていた。
• リネージやドキュメントを別途管理する必要があった。

どのような状態を目指していたか

• マネージド環境でジョブスケジューリング・CI/CD・リネージ可視化が一元管理できる状態
• 全データ変換を一つのフレームワークで管理し、Scheduled Queryで散在していたパイプラインも統合できる状態
• テストやレビュープロセスを標準化し、変更の品質を担保できる状態
• Semantic LayerやMCPなどの最新機能を活用し、データ活用の幅を広げられる状態

• dbt Core
• dbt Cloud（現 dbt Platform）
• Dataform

• ジョブスケジューリング機能が十分か
• 権限管理・環境管理のマネージド機能が整っているか
• テストやレビュープロセスによる品質担保が実現できるか（CI機能、Compare機能など）
• 少人数チームで費用対効果が見合うか

既に社内で先行してdbt Coreを利用していたのもあり、同一エコシステム内でマネージド環境に移行できるdbt Platformが最も自然な選択肢でした。要件を満たしているかの検証を行った結果、個別に実装が必要な部分が少なく、スピードを優先した判断として採用を決定しました。

• dbt Coreからの移行コストが最小限で済む。
• CI/CD、ジョブスケジューリング、Explorer（リネージ可視化）がマネージドで提供される。
• 要件を満たしており、個別実装が少なくて済むことが検証で判明。
• 公式サポートが手厚く、レスポンスも早い。

改善したかった課題はどれくらい解決されたか

マネージドなCI/CDとジョブスケジューリングにより、自前でのインフラ運用が不要になり、チームのリソースをデータモデリングに集中できるようになりました。Explorer機能によるリネージの可視化で、データ変換の依存関係を誰でも把握できる状態が実現し、障害時の原因特定が効率化しました。

どのような成果が得られたか

• GitHubでのPRレビューとdbt CloudのCI機能により、重要なデータ集計の変更に対してレビュープロセスが確立された。以前のScheduled Query時代にはレビューなしで変更が反映されていた属人的な運用が解消された。
• ユニットテストを既存のロジックに追加した結果、想定以上にテストが失敗するケースが見つかり、潜在的なバグの発見やロジック修正につながった。手動での目視比較に頼っていたテスト運用から脱却できた。
• staging → intermediate → martsの3層構成でデータ変換ロジックの責務が明確化し、開発効率が向上した。
• marts層でのcontract enforcement導入により、下流への破壊的変更を防止できるようになった。
• persist docsによりBigQuery上でもカラムの説明が参照可能となり、セルフサービス分析が促進された。
• dbt Platformがマネージドな実行環境を提供するため、チームごとのdbtプロジェクトや実行環境を自前で構築・管理する必要がなくなり、基盤構築・運用の工数が大幅に削減された。ただし、dbt Platform全体の設定やプロジェクト構成を把握するadmin的な役割の開発者は最低限1名必要。
• Scheduled Queryで散在していたパイプラインもdbtに統合し、全変換処理の一元管理を実現した。

Enterprise Planを選定して結局どうだったか

導入を検討していたタイミングで既に複数サービスにまたがるdbtプロジェクトの必要性が見えており、1プロジェクトしか作成できないTeam Planでは不十分でした。全社展開を見据えると必然的にEnterprise Planの選択となります。Enterprise Planにより以下の機能が利用可能となっています。

• マルチプロジェクト: サービスごとに独立したdbtプロジェクトを運用でき、デプロイサイクルやアクセス権限を分離できる。
• Audit Log: データ変換の実行履歴や変更履歴を追跡でき、ガバナンス要件への対応が容易になった。
• dbt Mesh: プロジェクト間でのモデル参照が可能となり、共通ロジックの再利用やデータの一貫性を確保できる。

• Scheduled Queryからdbtへの移行では、ドキュメントが存在しない既存クエリのロジック解読に時間がかかりました。属人化していたクエリの意図を理解し、staging/intermediate/martsの適切な粒度に分割する設計作業は想定以上に工数を要しました。
• dbt Coreからdbt Platformへの移行では、設定ファイルの違いや環境変数・varsの受け渡しなど、凝った構成を実現しようとすると一部自前実装が必要でした。

dbt Coreは無料で始められるため、まずはローカルでdbtの開発体験を試すことをお勧めします。チーム規模が拡大し、CI/CDやジョブスケジューリング、リネージの可視化などマネージド機能が必要になったタイミングでdbt Platformへの移行を検討するのがよいと思います。ただし、ライセンスコストは開発者人数に比例するため、少人数チームでは費用対効果の試算を事前にしっかり行うことをお勧めします。また、dbt Platformはワークフローエンジンではなく、マネージドな実行環境として捉えるのが適切です。複雑なワークフロー制御を期待すると物足りなさを感じる場面があるため、ワークフローの要件が強い場合は別途オーケストレーションツールとの併用を視野に入れるとよいと思います

dbt Fusionエンジンへの移行を進めており、ローカル開発体験の大幅な改善を見込んでいます。また、dbt MCPを活用したAIツール連携の深化により、自然言語でのデータ探索やモデル開発のワークフローを発展させていきたいと考えています。Semantic Layerの活用範囲を広げ、組織全体でメトリクスの定義を統一していくことも今後の重要なテーマです。