はじめに
ニジボックス データエンジニアリング室で BIエンジニアをしている村上です。
データエンジニアリング室では dbt（data build tool） を重点スキルとして位置づけ、BIエンジニア向けの研修を整備しています。研修は3つのレベル構成（初級、中級、上級）で設計しています。初級研修の作成は完了し、現在メンバーへ展開して運用を開始しつつ、内容のブラッシュアップも続けています。中級・上級研修も今後整備予定で、並行してコンテンツの作成を進めています。
初級研修の整備が一区切りついたタイミングで、研修の設計や開発について振り返ってまとめたいと思います。本記事では、「なぜ dbt に注力するのか」「なぜ自前の研修という手段で進めるのか」の2点についてまとめます。
1. なぜdbtに注力するのか
1-1. 変換層の技術として dbt を選ぶ理由
dbt は、ELT（Extract / Load / Transform）の Transform（変換）層 を担うツールです。DWH にロードされたデータを SQL で加工し、テーブル・ビューとして管理します。BigQuery、Snowflake、Databricks、Redshift など、主要なクラウド DWH に対応しています。
技術的な側面で dbt を選ぶ理由は、大きく次の3点です。
- ソフトウェア開発の手法をデータ変換に持ち込める： 変換ロジックを Git で管理し、テスト・ドキュメントをプロジェクトに載せられる。バージョン管理、自動テスト、ドキュメント生成を、SQL ベースの変換処理に適用できる。
-
エコシステムが成熟している：
dbt_utilsやdbt_expectationsなどのパッケージ、dbt Hub、事例・ドキュメントが揃っており、実装パターンを再利用しやすい。 - チーム開発やデータモデリングと相性が良い： 変換ロジックやメタデータをコードベースで管理できることはチーム開発と親和性が高い。また、依存関係の自動解決やデータリネージ機能は、ディメンショナルモデリングをはじめとするデータモデリングとも整合しやすい。
加えて、2026年6月に発表された dbt Core v2.0（alpha） では、Rust 製の dbt Fusion エンジンのランタイムが Apache 2.0 でオープンソース化されるなど、製品側の開発投資も続いています。
上記のような背景から、クラウド DWH を前提としたデータ基盤の構築・運用において、変換層のツールとして dbt はデファクトスタンダードになりつつある と考えています。エコシステムの厚みと製品投資の継続は、一過性のトレンドではなく、中長期で採用しうる技術基盤であることを示しており、データエンジニアリング室がこの技術に注力する判断の根拠のひとつです。
1-2. 参画領域における dbt の位置づけ
「dbt に注力する」という判断は、技術としての妥当性だけでなく、参画する案件における開発の実態 とも整合している必要があります。
データエンジニアリング室のメンバーは、主なクライアントであるリクルートの様々な事業領域のデータ案件に参画しています。
参画領域では、DWH に Google BigQuery（以下、BigQuery） を、変換層に dbt Core（以下、dbt） を使う構成が中心です。変換処理を含めたパイプラインに dbt を統合している領域もあれば、開発・テストの基盤として段階的に導入したり、パイプライン統合の検討を進めている領域もあります。DWH の選定や dbt の導入状況は領域ごとに異なりますが、ニジボックスが関わる複数の領域において、「dbt × BigQuery」が開発の軸になりつつある ことは、データエンジニアリング室が dbt に注力する判断の、業務上の出発点です。
そのため、メンバーが配属される案件では、既存の dbt プロジェクトでモデル（.sql）やモデルプロパティ（.yml）を読み書きする スキルが前提になります。データエンジニアリング室が dbt に注力するのは、技術としての妥当性に加え、こうした業務前提において、メンバーがいち早く価値を発揮し、データ基盤の進化を主導できるようにするための判断でもあります。
2. なぜ自前の研修という手段で進めるのか
ここまでは、dbt に注力する判断について述べました。重点スキルとして掲げた以上、それをメンバーが身につけられる仕組みも必要と考え、dbt をメンバーに届ける手段として自前の研修を整備することにしました。ここでは、なぜその選択肢を取ったのかをまとめます。
前提として、データエンジニアリング室のメンバーの多くは dbt を体系的に学んだ経験がない メンバーでした。案件の中で部分的に触ったことがある人もいますが、多くは 「触ったことはあるが、知識が断片的」 という段階にありました。
このような状況で、メンバーにスキルを身につける手段としては次の選択肢が考えられました。
| # | 選択肢 | メリット | デメリット |
|---|---|---|---|
| 1 | 現場ごとに都度キャッチアップ（OJT） | ・配属先の業務に即した知識が身につく | ・全員に必要なスキルを揃えにくい ・特定の現場・業務領域の運用知識ばかりが蓄積されがち |
| 2 | dbt公式コースや外部教材を各自受講 | ・コンテンツを一から作る必要がない ・汎用的な dbt 入門は学べる |
・学習内容に過不足が生まれ、参画領域で必要なスキルとしての調整が難しい ・受講料などのコストがかかる |
| 3 | AI・ドキュメントで各自キャッチアップ | ・人ごとにペースや弱点に合わせた学び方がしやすい | ・何を・どの順で経験すべきかが各自に任せられ、ベースラインが揃いにくい |
| 4 | 自前で研修を設計・運用 | ・共通の到達像と順序を定義できる ・配属先に到達点を共有しやすい |
・コンテンツ作成と運用のコスト（人件費）がかかる |
上記の選択肢を比較するうえで重要視した軸は、その時の育成課題に合わせたコンテンツ設計ができるか です。
現在の課題は、前述のとおり知識が断片的なメンバーが多かったことでした。そこで初級では、「複数領域に共通する土台となるスキル・知識が身についた状態」 をベースラインとしました。この軸で見ると、「4. 自前で研修を設計・運用」 が最も適していると判断しました。外部教材や AI も、調べながら進める前提で積極的に使い、狙いに合わせたレベルを揃える部分を自前の研修でカバーしています。
なお、現在整備を進めている中級・上級研修では、別の育成課題に合わせてコンテンツを設計しています。中級の到達像は「dbt でできる基本的なことを一通り理解しており、新規 dbt プロジェクトの設計から入れる状態」、上級は「dbt 公式資格の取得も見据え、スペシャリストとして開発現場を牽引していける状態」です。段階的に技術を身につけていくことで、単なる SQL によるデータ集計に留まらず、データ品質や設計を自律的に担保できるエンジニアとして、それぞれの参画領域にバリューを発揮できるようになります。データエンジニアリング室としての投資であると同時に、各メンバーの市場価値の向上にもつながると考えています。
おわりに
本記事では、dbt に注力する理由と、それをメンバーに届ける手段として自前の研修を作ることを選んだ理由について述べました。「何を学ぶか」「どう進めるか」は、次回以降の記事で扱います。