dbt 資格の難易度：必要スキルと学習時間の目安（Analytics Engineer 向け）

dbt Analytics Engineer 認定は、SQL とデータモデリングを軸に、テスト・ドキュメント・デプロイを含む一連の変換運用を理解しているかを測ります。

本稿は、公式ドキュメントで安定的に説明されている概念をベースに、合格に必要なスキル範囲と学習時間の目安を、実務と両立できるプランとして提示します。

難易度の位置づけ：SQL 実務者には中級、未経験者にはやや難

dbt は「ETL ツール」ではなく、DWH 上で SQL を実行し、モデル（テーブル/ビュー）間の依存関係を管理・テスト・文書化するフレームワークです。認定試験はこれらの基本を、手を動かしている前提で問うため、日常的に SELECT/CTE やスキーマ設計に触れている人には中級レベルの難易度に感じられます。

一方で、SQL が入門レベルだったり Git・Jinja・DWH の実行特性に不慣れだと、出題意図の把握に時間を要します。過去問暗記で解けるタイプではなく、公式ドキュメント記述と一致する原則（ref/source、テストの役割、増分モデルの前提、スナップショットの用途など）を理解しているかが評価されます。

• 前提としての実務度合い：日常的にデータモデリングと SQL 検証を行っているかで体感難易度が変わる
• 暗記だけでは厳しい：機能の選択理由（いつ incremental、いつ snapshot、どこで tests）を説明できる必要
• ベンダー依存は低め：Snowflake/BigQuery/Redshift など間の差異はあるが、dbt の抽象は安定している

必要スキルセット：SQL・Jinja・Git・DWH 実行特性

安定して出題されるのは、dbt の中核 API と運用原則です。SQL は当然として、Jinja によるテンプレート化、テスト・ドキュメントの定義、Git による変更管理、そして DWH の実行特性（コスト/並列/権限/スキーマ）を理解しておきましょう。

特定のクラウドや DWH のコマンド暗記より、dbt の抽象（モデル、ソース、シード、スナップショット、マクロ、パッケージ、ref/source/var/target、ドキュメント、リネージ）と、その使い分けの判断基準が問われます。

• SQL：ウィンドウ関数、CTE、集計、NULL/型の扱い
• Jinja/マクロ：ref(), source(), var(), target, if/for、カスタムマクロの基礎
• テスト/ドキュメント：generic/unique/not_null、schema.yml での宣言、docs 生成
• DAG と依存：モデル間の依存解決、選択フラグ（--select/--state）
• Materialization：view/table/incremental/ephemeral の特徴と選択基準
• 運用：環境分離、Git フロー、レビュー、CI 実行の基本

出題領域と頻出タスク（安定概念ベース）

公式ドキュメントと整合する安定領域として、モデル化、テスト、ドキュメント、ソース管理、マクロ/Jinja、スナップショット、増分更新、パッケージ活用、選択シンタックス、環境/リネージの理解が挙げられます。

個別機能の暗記より、ユースケースに対して「どれを選ぶか」を説明できることが重要です。以下の表に、代表タスクと学習の比重目安をまとめました。

• ref と source の適切な使い分け
• schema.yml での tests/docs 設定と docs generate の位置づけ
• materialization の選択とインパクト（依存・実行時間・コスト）
• スナップショット vs 増分 vs フルリフレッシュの判断軸
• 選択シンタックス（state:modified、+ 演算子）での影響範囲制御

学習時間の目安とプラン（バックグラウンド別）

SQL 実務1年以上で dbt を触ったことがある人：2〜4週間（20〜35時間）が目安。手元のリポジトリで品質機能（tests/docs）と materialization の選択練習に集中すれば十分に戦えます。

SQL はできるが dbt/Jinja/Git が不安な人：4〜6週間（40〜60時間）。チュートリアルで手を動かし、スナップショット・増分・パッケージまで一通り構築してから模擬演習へ。

SQL 初学者：8〜10週間（80〜100時間）。前半は SQL 強化と DWH の基本、後半で dbt 基礎から演習までを段階的に。

• 週次プラン例（4週間）：
• 1週目：チュートリアル完走（models/tests/docs/sources）+ Git 基本
• 2週目：materialization 深掘り（増分/フルリフレッシュ）+ スナップショット
• 3週目：state 選択と CI（pull request で run/test）
• 4週目：模擬演習（ユースケースから手段選択）と復習

実務で鍛える勘所：層構造・CI・環境分離

試験対策と実務の両立には、staging → intermediate → marts の層構造を明確にし、ドメイン境界で依存を減らすことが近道です。CI で変更差分のみを安全に実行できるよう、選択シンタックス（--select state:modified+）を活用します。

環境分離（開発/検証/本番）ではスキーマやデータベース名に target を利用し、PR ごとに独立したスキーマにデプロイしてレビューを容易にします。

• 層ごとの命名規約（stg_, int_, dim_/fact_）を徹底
• state:modified と + の組合せで影響範囲を可視化
• target.database / target.schema を活用した環境分離
• CI では dbt build を基本に、長時間化する場合は run と test を段階化

dbt の層構造と CI 実行の流れ（概念図）

模擬演習の作り方と当日の戦い方

模擬演習は「要件から手段を選ぶ」形式にしましょう。履歴管理が必要なら snapshot、遅延なく結果が欲しいダッシュボード用なら増分 + テスト強化、外部 CSV の取り込みは seed といった具合に、手段選択の理由を声に出して説明できるかを確認します。

試験当日は、設問文の条件（更新パターン、データ鮮度、依存・再計算コスト、監査可能性）を抽出してから、dbt の抽象で最小コストに落とす癖を徹底しましょう。

• ユースケース→手段の対応表を自作しておく
• テストの粒度（not_null/unique/relationships/custom）を言語化
• 増分 vs スナップショットの判断基準を 3行で言えるようにする

小さな演習：増分モデルとテスト・ドキュメント

-- models/mart/orders_daily.sql
{{
  config(
    materialized='incremental',
    unique_key='order_id',
    on_schema_change='sync_all_columns'
  )
}}

with src as (
  select * from {{ source('sales', 'orders') }}
  {% if is_incremental() %}
    where updated_at > (select coalesce(max(updated_at), '1900-01-01') from {{ this }})
  {% endif %}
)
select
  order_id,
  customer_id,
  order_date::date as order_date,
  total_amount,
  updated_at
from src;

-- models/mart/_orders.yml
version: 2
models:
  - name: orders_daily
    description: 日次の受注スナップショット相当を増分で維持
    columns:
      - name: order_id
        tests:
          - not_null
          - unique
      - name: customer_id
        tests:
          - not_null
    tests:
      - dbt_utils.expression_is_true:
          expression: "total_amount >= 0"
    meta:
      owner: analytics

問題で確認

よくある質問