「あの人がいないとデータが出せない」を、dbtはどう解決するか

属人化の本当のコスト

「あの人に聞かないとわからない」。この一言が、組織にどれだけのコストを発生させているか。

Harvard Business Reviewの調査によれば、データサイエンティストは業務時間の 約80% をデータの準備と整形に費やしている¹。Anacondaの2022年の調査でも、データ専門職の 約40% の時間がデータクレンジングと管理に消えていると報告されている²。

この数字の裏には、属人化という構造的な問題がある。特定の担当者だけが知っているSQL、ローカルに保存されたExcelの変換ロジック、口頭でしか伝わらない集計ルール。これらが積み重なると、組織は 「あの人がいないとデータが出せない」 状態に陥る。

問題は個人の能力ではない。仕組みの欠如だ。

「ドキュメントを書けばいい」が失敗する理由

属人化の対策として「ドキュメントを整備しよう」という声が上がる。正しい方向ではある。しかし現実には、ほぼ確実に失敗する。

理由はシンプルで、 ドキュメントとコードは別の場所に存在する からだ。コードを変更したとき、ドキュメントを同時に更新する人はほとんどいない。結果、ドキュメントは数週間で現実と乖離し、「あのドキュメント、もう古いよ」と言われるものになる。

dbtが提示した解決策は根本的だった。 SQLファイルそのものをドキュメントにする という発想だ。

dbtでは、モデル（SQLファイル）にスキーマ定義、テスト、説明文を紐づける。コードを変更すればドキュメントも自動的に更新される。「後でドキュメントを書く」必要がない。なぜなら、コードを書くことがドキュメントを書くことだからだ。

dbtのレイヤーアーキテクチャ

dbtの設計思想を実際のデータ基盤に落とし込むと、以下のようなレイヤー構造になる。

各レイヤーには明確な責務がある。Stagingはデータソースの忠実な写し。Intermediateはビジネスロジックの適用。Martsは分析やレポート用の最終形。そして 各レイヤーにテストとドキュメントが組み込まれる 。

Before / After：何が変わるのか

dbt導入前後で、データ基盤の運用がどう変わるかを整理する。

Beforeでは、障害が起きたら担当者に電話するしかない。Afterでは、テストが異常を自動検知し、Gitの履歴から「いつ、誰が、何を変えたか」が追跡できる。

人間が犯しがちな過ち

dbtを導入すれば属人化が解消される、わけではない。ツールを入れても、使い方を間違えれば同じ問題が再発する。

プロセスの問題をツールで解決しようとする

dbtはテストを書ける。しかし テストを書くかどうかは人間の判断 だ。「dbtを入れたから品質は大丈夫」と思った瞬間、テストのないモデルが量産される。ツールが解決するのは仕組みであって、文化ではない。

ビジネスを理解する前にモデルを設計する

データモデリングの教科書的なアプローチを先に適用して、精緻なスタースキーマを設計する。しかし実際のビジネスの問いがそのモデルに合わない。 「どんな問いに答えたいのか」が先で、モデルは後 だ。

チーム間のデータ契約を軽視する

上流のテーブル定義が予告なく変わり、下流のモデルが壊れる。dbtの source freshness や contract 機能はこの問題を緩和するが、そもそも チーム間で「何を、どの粒度で、いつまでに」という合意 がなければ、技術的な対策だけでは不十分だ。

「後でドキュメントを書く」

書かない。これは経験則ではなく、ほぼ法則だ。dbtの description フィールドをモデル作成時に埋める習慣を最初から作ること。後回しにした瞬間、それは永遠に書かれない。

AI + dbt：可能性と限界

Snowflakeが提供するCortex Code CLIは、自然言語でdbtモデルを操作できる機能を持つ³。dbt Projects on Snowflakeとの統合により、Snowflake内でdbtワークフローが完結する時代になった⁴。

AIがSQLを生成し、テストを提案し、ドキュメントを補完する。生産性は確実に上がる。

しかし AIが生成したデータ変換ロジックを、理解せずに本番に投入すること は危険だ。集計の定義が微妙にずれていたり、JOINの条件が不適切だったりするケースは珍しくない。AIは「それっぽいSQL」を書くのは得意だが、ビジネスコンテキストを完全に理解しているわけではない。

AIは優秀なジュニアエンジニアだと考えるのが妥当だ。書かせて、レビューして、理解した上で採用する。この姿勢が、AIとdbtの組み合わせを最大限に活かすための前提になる。

再現性のある基盤に向けて

データ基盤の属人化は、技術の問題ではなく設計の問題だ。dbtは「SQLをコードとして管理する」という単純な原則で、この問題に構造的な解を提示している。

Snowflakeとの統合が進んだことで、環境構築のハードルは下がった。しかしツールを入れただけでは何も変わらない。テストを書く文化、コードレビューの習慣、チーム間のデータ契約。 仕組みと文化の両方が揃って初めて 、「あの人がいなくても回る」基盤が実現する。

Footnotes

1. Harvard Business Review「Data Scientist: The Sexiest Job of the 21st Century」- データサイエンティストの業務時間の大半がデータ準備に費やされている実態を指摘 ↩

2. Anaconda「State of Data Science 2022」- データ専門職の時間配分に関する調査レポート ↩

3. Snowflake「Cortex Code CLI」- 自然言語によるdbtモデル操作機能 ↩

4. dbt Labs「dbt Projects on Snowflake」- Snowflake内でのdbtワークフロー実行 ↩