この記事の結論
- dbt(data build tool)は、ひと言でいうと 「ストアドプロシージャの進化版」
- SQLが書ければ十分。SIer出身者にとって、最も学習コストが低いモダンデータスタックのツール
- まずは公式の jaffle_shop チュートリアル(dbt Cloud無料)を30分試すのが最短ルート
「dbtって何?データエンジニアの求人にやたら出てくるけど…」
dbt(data build tool)は、SQLでデータ変換を定義するツールです。SIer出身でSQLが書ける人にとっては、実は一番とっつきやすいモダンデータスタックのツールです。
この記事では、dbtの基本概念をSIerの経験に置き換えながら、最速で実務感を掴むためのガイドとして解説します。
dbtとは何か、SIerの言葉で説明する
一言でいうと、**dbtは「ストアドプロシージャの進化版」**です。
SIerで「ストアドプロシージャでデータを加工して、別テーブルに格納する」という処理を書いたことがある人は多いと思います。dbtがやっていることは本質的にこれと同じです。
違いは、ストアドプロシージャがデータベース内部に閉じているのに対して、dbtはSQLファイルをGitで管理して、テスト・ドキュメント生成・依存関係の管理まで自動でやってくれる点です。
SIer用語 ↔ dbt用語の対応表
| SIerでよく使う概念 | dbtでの呼び方 | 役割 |
|---|---|---|
| ストアドプロシージャ/ビュー | dbt model(.sqlファイル) | データ変換の最小単位 |
| データの結合テスト | dbt test(YAMLで定義) | NULL/ユニーク/参照整合性の自動チェック |
| 設計書/ER図 | dbt docs(自動生成) | テーブル間のリネージをビジュアル表示 |
| ジョブの依存関係(JP1等) | ref関数 {{ ref('...') }} | dbtがビルド順序を自動解決 |
| ステージングテーブル | sources / staging | 生データとクレンジング層 |
| データマート | marts | ビジネスユーザーが見る最終テーブル |
この対応表を頭に入れるだけで、dbt公式ドキュメントの理解スピードが倍以上違います。
ストアドプロシージャ vs dbt(実務での違い)
| 観点 | ストアドプロシージャ | dbt |
|---|---|---|
| 記述言語 | PL/SQL、T-SQL等(DB依存) | 標準SQL + Jinjaテンプレート |
| バージョン管理 | DBに直接保存(履歴管理が困難) | Gitで管理、PR/レビュー可能 |
| テスト | 手動またはアプリ側 | YAMLで宣言的に定義、CIで自動実行 |
| ドキュメント | Excel/手動 | 自動生成、リネージ図付き |
| 依存関係 | 人間が管理 | ref関数で自動解決 |
| DBポータビリティ | 低い(DBロックイン) | 高い(SnowflakeでもBigQueryでも動く) |
SIer時代のストアドプロシージャ運用で「Excelの設計書とDBの実装が乖離」「依存関係の更新漏れで本番障害」という痛い目に遭った経験がある人なら、dbtの価値は刺さります。
dbtのアーキテクチャ(ETL → ELT)
dbtは「T(Transform)」だけを担当するツールです。
データの取得(Extract)やロード(Load)はFivetranやAirbyteが担当し、取り込まれたデータの変換(Transform)をdbtが担当します。つまり、ETLの「T」に特化したツールです。
最近は「ELT」という順番が主流で、まず生データをそのままクラウドDWHにロードして、その後dbtで変換するという流れが一般的です。
SIerでよくある「ステージングテーブルに生データを入れて、加工テーブルに変換結果を格納する」というパターンと同じです。dbtではこれを以下のレイヤーに分けます。
sources(ソース): Fivetranなどで取り込まれた生データ。SIerでいうステージングテーブルです。
staging(ステージング): ソースデータのクレンジングや型変換。カラム名の統一やNULL処理をここで行います。
intermediate(中間): 複数のステージングモデルを結合した中間テーブル。複雑な変換ロジックを分割して可読性を上げます。
marts(マート): ビジネスユーザーが直接参照する最終テーブル。SIerでいうデータマートです。BIツールやアナリストはここを見ます。
最初のdbt model はこう書く(コード例)
実際のdbt modelは、SELECT文を書くだけです。CREATE TABLEは不要。
-- models/staging/stg_orders.sql
SELECT
order_id,
customer_id,
order_date,
status,
LOWER(TRIM(channel)) AS channel -- 値の正規化
FROM {{ source('raw', 'orders') }}
WHERE order_date >= '2024-01-01'
-- models/marts/fct_customer_orders.sql
SELECT
o.customer_id,
COUNT(*) AS order_count,
SUM(o.amount) AS total_amount,
MAX(o.order_date) AS last_order_date
FROM {{ ref('stg_orders') }} AS o -- ref関数でstg_ordersを参照
GROUP BY 1
{{ ref('stg_orders') }} と書くだけで、dbtが「stg_orders を先にビルドしてから fct_customer_orders をビルドする」という順序を自動で解決してくれます。
テスト定義も簡潔。
# models/staging/schema.yml
models:
- name: stg_orders
columns:
- name: order_id
tests:
- unique
- not_null
- name: customer_id
tests:
- not_null
これだけで、dbt test 実行時に「order_idが一意でNULLでないこと」「customer_idがNULLでないこと」を自動チェックします。
💡 dbtを学び始めたら、市場にシグナルを送る
dbtの基礎を理解しただけでも、データエンジニアの求人市場では評価されます。スカウト型サービスのプロフィールに「dbt学習中」と書くだけで、dbt導入を検討している企業からオファーが届くことがあります。
実際にdbtを触ってみる(30分で完了)
最速で体感するなら、dbtの公式チュートリアル 「jaffle_shop」 がおすすめです。
dbt Cloudの無料アカウントを作れば、ブラウザ上でdbtを試せます。ローカル環境の構築が不要なので、30分で最初のモデルを動かせます。
jaffle_shopチュートリアルでは、注文データと顧客データを使って、ステージング→マートの変換パイプラインを構築します。SQLが書ける人なら、チュートリアルの内容で躓くことはほとんどないはずです。
SIer経験者がdbtで戸惑うポイント
DDLを書かない。 SIer出身者は「まずCREATE TABLEしてからINSERT」に慣れていますが、dbtではSELECT文だけ書けばOKです。テーブルの作成はdbtが自動で行います。
YAMLの設定ファイル。 dbtではテスト定義やドキュメントをYAMLで書きます。SIerではExcelで管理していた情報が、すべてコードとしてGit管理されます。最初は違和感がありますが、慣れると圧倒的に効率的です。
Jinja テンプレート。 dbtではSQLの中に{{ }}や{% %}でJinjaテンプレートを書けます。動的SQLを生成するための仕組みで、最初は見慣れない構文に戸惑いますが、基本的なref関数とif文が使えれば実務は回ります。
ローカル開発でなくクラウド前提。 SIerでは「ローカルDBで開発→本番へ」が一般的ですが、dbtは基本的にSnowflake等のクラウドDWHに直接接続して開発します。
dbtを学ぶメリット
転職市場でのdbtの需要は急速に伸びています。データエンジニアの求人で「dbt経験歓迎」「dbt導入経験」という記載を見ない日はないほどです。
ただし、dbtの実務経験者はまだ少ないため、チュートリアルを完了して基本概念を理解しているだけでも、「dbtを知っている人」として評価されます。
SQLが書けるSIer出身者にとって、dbtは最も学習コストが低いモダンデータスタックのツールです。まずはjaffle_shopチュートリアルから始めてみてください。
よくある質問(FAQ)
Q. dbtはdbt Cloud(有料)と dbt Core(無料)どちらを使うべき?
A. 学習目的なら dbt Cloud の無料プラン(Developer Plan)が最速です。ローカル環境構築不要で、ブラウザだけで完結します。実務では会社の方針次第ですが、個人検証 → dbt Core、チーム運用 → dbt Cloud という選び方が一般的。
Q. dbtを使うのにPythonの知識は必要ですか?
A. 基本的に不要です。dbtはSQL + YAML + Jinja で完結します。Python知識が必要になるのはdbt Python modelsを使う場合のみで、これは応用編。
Q. dbtとAirflowの違いは?
A. 役割が違います。dbtは「データ変換(T)」を担当、Airflowは「ジョブのオーケストレーション」を担当。実務では「Airflowが日次でdbtを実行する」という連携パターンが一般的です。
Q. 個人で学習する場合のおすすめDB環境は?
A. Snowflakeの30日無料トライアル + dbt Cloud の無料プラン の組み合わせがベストです。両方とも個人で完結でき、本番に近い環境で学習できます。
Q. dbt経験を職務経歴書にどう書けばいい?
A. 「jaffle_shopチュートリアルを完了し、ステージング・マートの基本構成を理解」「個人プロジェクトで○○APIのデータをdbtで変換」など、具体的な範囲を明示してください。実務未経験を隠す必要はありません。詳細は SIer出身者向けの職務経歴書の書き方 を参照。
「dbtのチュートリアルを完了しているだけでも評価される」
これは実際に面接で言われた言葉です。学習中でも市場からの評価は得られます。
▼ 関連記事
- 【2026年版】データエンジニアのロードマップ|未経験から必要なスキルと学習順序
- Snowflake未経験でもデータエンジニアに転職できた理由
- SIer→データエンジニア転職の職務経歴書|書き換え例&テンプレ付き
- 【2026年版】データエンジニアの年収相場は?SIer転職で100万円アップした実体験
※この記事にはアフィリエイトリンクが含まれています。筆者が実際に利用したサービスのみ紹介しています。


コメント