Dataformで始めるデータエンジニアリングの第一歩
コネヒト株式会社 / 野澤哲照
メンバー / 機械学習エンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2024年3月 | B to C |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2024年3月 |
| 事業形態 | B to C |
アーキテクチャ

導入の背景・解決したかった問題
導入背景
コネヒトではママリというモバイルアプリを開発・運営しています。
ママリのログデータはFirebase Analyticsに送信しており、BigQuery Export機能を使ってBigQueryに転送しています。
このFirebaseからExportされるRAWデータは以下のような特徴があります。
- event_paramsカラムがネスト構造になっている
- event_paramsの型が動的(STRING、INT、DOUBLE、FLOATの4種類)
- データ到着遅延がある(最大72時間程度)
これらの特徴もあり、RAWデータをそのままクエリするのは非効率であり現実的ではありません。
当時はスケジュールクエリ機能を使って分析しやすい形に整形はしていたのですが、運用上の課題が山積みでした。
このような背景もあり、2024年あたりから少しずつデータ基盤の整備を進めてきました。
ツール導入前の課題
前述したように、RAWデータをそのままクエリするのは現実的ではありませんでした。そこで、BigQueryのスケジュールクエリ機能を使い、分析しやすい形にTransformして分析を行っていました。
しかし、このスケジュールクエリに関しては以下のような課題がありました。
- クエリ間の依存関係を制御できず「テーブルAの更新後にテーブルBを更新する」という定義ができなかった。そのため「Aを2:00、Bを2:30に実行」のように、時刻のバッファで管理していた
- コード管理ができておらず、履歴管理もできていなかった
- Data Lineageが見れず、「このテーブルの定義を変えたいけど、どこに影響が出るかわからない」といった、所謂データのサイロ化・ブラックボックス化が起こっていた
- 特定のクエリが失敗した際のオペレーションとして、依存する下流のクエリを順次手動で再実行する、という操作を手動でやる必要があったが、この影響範囲を探すのも一苦労だった
そこで、スケジュールクエリ撲滅PJを立ち上げ、徐々にデータパイプライン管理ツールであるDataformに移行させていきました。
比較検討したサービス
- dbt
選定理由
弊社に関しては以下のような背景がありました。
- 専属データエンジニアがいない状況であり、なるべく学習・実装・運用コストを下げたい
- 最低限の機能として、前述した「クエリの依存関係制御」「コード管理(GitHub)」「Data Lineageの把握」という課題が解決できればOK
Dataformは、SQLベースで記述できる点や、Google Cloudに統合されておりJOB実行の料金が発生しない点(BigQueryのクエリ料金のみ)が魅力でした。導入ハードルや運用コストの低さにも優れており、スモールスタートしやすいという観点で採用しました。
導入の成果
Dataformの導入とDataformのローカル開発環境により、主に以下のような成果を得ることができました。
データパイプライン開発の民主化と属人化の解消
ローカルでの開発環境を整備したため、Coding Agentを活用することで専属のデータエンジニアでなくとも、一定の品質でPRを出せる状態を作ることができました。
アサーション機能によるデータ品質の自動担保
データに異変があった場合は、アサーション機能によって検知し、自動でSlackに通知される仕組みを構築しました。これにより、データの信頼性を常に高い状態で維持できています。
運用オペレーション負荷の大幅な削減
依存関係が明確になったことで、スケジュールクエリ時代に苦労していた「エラー時に手動で影響範囲を特定し、依存する下流のクエリを順次手動で再実行」といった煩雑なオペレーションが不要になり、運用管理の手間が軽減されました。
導入時の苦労・悩み
DataformはGoogle Cloudのコンソール上で開発を行うことができます。
GitHubと連携することで、ワークスペースという、いわゆるブランチのようなものを切って開発し、PRを出す、といったフローを踏むことができます。
メリットとしては、特に開発環境などを整備しなくともSQLさえ知っていれば誰でも開発しやすい点が挙げられますが、運用していくと以下のような課題が出てきました。
- エディタが使いづらい
- タブの左右分割表示ができない
- フォーマッターの自動フォーマットがいけてない
- サジェスト機能が貧弱、など
- コードレビュー時、毎回コンソールにアクセスし対象のワークスペースを開き、SQLのコンパイルなどが問題ないか確認する必要がある
- Claude Codeなど、Coding Agentの恩恵を受けられない
特にこれからの時代、Coding Agentの恩恵を受けられないことは重要な課題だったため、弊社ではローカルで開発できる環境を構築しました。
導入に向けた社内への説明
上長・チームへの説明
dbtとDataformのPros/Consを書き出した上で判断しました。もともとの課題感が大きく、かつDataformであれば追加料金もかからないため、大きなハードルはなく導入することができました。
活用方法
よく使う機能
- タグによるワークフロー管理
- アサーション機能によるデータ品質のモニタリング
- Dataform Tools VS Code Extension
- ローカルでの開発時に使っています
ツールの良い点
- 運用コストが低い(Dataform自体の料金は無料なので)
- SQLさえ知っていれば導入できるので、導入コストも低い
ツールの課題点
- 必要最低限の機能しかないため、痒いところに手が届かないことがある
コネヒト株式会社 / 野澤哲照
メンバー / 機械学習エンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
よく見られているレビュー
コネヒト株式会社 / 野澤哲照
メンバー / 機械学習エンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法

