【2026年版】dbt入門:SIer出身者が最速で理解するためのガイド【SQL書ける人向け】

転職体験談

この記事の結論

  • 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を触ってみる(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を覚えたから年収が上がる、という単純な話ではないからです。私自身、現職(大手食品メーカー系IT子会社のデータアーキテクト)でSnowflake中心の基盤を扱う中でdbtの周辺ツールに触れていますが、評価されるのはツール名そのものより「なぜこのレイヤー設計にしたか」を説明できることの方です。

一方で、実務経験者がまだ潤沢とは言えない領域なので、チュートリアルを完了して基本概念を一通り説明できる状態は、書類や面接で話の取っかかりにはなります。少なくとも私が転職活動をしたとき(SIer5年目・年収約400万 → 事業会社のデータエンジニアで500万)、面接では「ツールを使ったことがあるか」より「前月比を出すSQLをその場で書けるか」のような、基礎の地力を問われました。新しいツール名は、その地力を補強する材料の一つくらいに捉えておくのが現実的だと思います。

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そのものを手を動かして触ってみるのが、一番確実な次の一歩だと思います。


▼ 関連記事


コメント

タイトルとURLをコピーしました