観光DMOのためのdbt導入90日ロードマップ

はじめに——「dbtを入れたい」その次の一歩

第1回では、観光データが信頼されない原因は「定義の不統一」にあることをお伝えしました。

第2回では、dbtがその問題を解決する「How」のツールであることを解説しました。

では、実際にdbtを導入するには、 何から始めればいいのでしょうか 。

今回は、観光DMO向けに 90日間で「信頼できるデータ基盤」を構築するロードマップ をお伝えします。

結論——90日で「小さく始めて、確実に動かす」

dbt導入の鉄則は、 「小さく始めて、確実に動かす」 ことです。

いきなり全データを移行しようとしない。まず1つの指標（例：来訪者数）を、dbtで管理できるようにする。

90日後のゴールは、 「来訪者数の定義がコードで管理され、誰がいつ実行しても同じ数字が出る状態」 です。

モダンデータスタックとは何か

「モダンデータスタック」という言葉を聞いたことがあるでしょうか。

これは、現代のデータ分析基盤における ベストプラクティスの組み合わせ を指します。特徴は、各ツールがそれぞれの役割に特化していること。柔軟性が高く、将来的な拡張も容易です。

私たちが推奨する最小構成は以下の通りです。

レイヤー	ツール	役割
データウェアハウス	BigQuery	あらゆるデータを一元保管する「巨大な倉庫」
データ変換	dbt	生データを信頼できる指標に加工する「品質管理付き工場」
可視化	Metabase	誰もが簡単に分析できる「インサイトの陳列棚」

なぜこの組み合わせか

BigQuery: Googleの従量課金制DWH。膨大なデータを高速処理でき、小規模なら無料枠で運用可能
dbt: オープンソースで無料。SQL知識があれば始められる。前回解説した4つの機能（変換、テスト、ドキュメント、バージョン管理）を提供
Metabase: オープンソースで無料。非エンジニアでもダッシュボード作成可能

「小さく始める」ために、コストを最小化 しています。全社的な大規模改革ではなく、まず具体的な課題を一つ解決し、目に見える成果を出すことから始めましょう。

Phase 1（1〜30日目）: 基盤構築と最重要指標のモデル化

最初の30日間は、技術基盤を整備し、組織内で最も課題となっている指標1つの信頼性を担保します。

Week 1-2: 環境構築

やること:

BigQueryプロジェクトの作成
dbt Cloudアカウントの作成（無料プランで十分）
GitHubリポジトリの作成

成果物:

dbtがBigQueryに接続できる状態

Week 3-4: 最初のモデル作成

やること:

最も定義が揺れており、かつ重要度の高い指標を 最初のターゲット と定める
1つのデータソース（例：GPSデータ）をBigQueryに取り込む
dbtでその指標の定義をSQLで記述する
基本的なテストを設定する

なぜ「1つ」から始めるのか:

全社的な大規模改革として始めると、時間もコストもかかります。まず具体的な課題を1つ解決し、目に見える成果を出すことが重要です。

成果物:

models/marts/visitors.sql が動く状態

-- models/marts/visitors.sql
SELECT
  visit_date,
  COUNT(DISTINCT visitor_id) AS unique_visitors
FROM {{ ref('stg_gps_data') }}
WHERE stay_duration_minutes >= 30
GROUP BY visit_date

Phase 1のチェックリスト

BigQueryプロジェクトが稼働している
dbt Cloudがセットアップされている
GitHubリポジトリが作成されている
最初のモデル（ターゲット指標）が動いている
基本的なテストが通っている

Phase 2（31〜60日目）: パイロットダッシュボードの構築と評価

次の30日間は、dbtで作成した信頼できる指標を可視化し、ビジネス現場からのフィードバックを得ることで、その価値を実証します。

Week 5-6: テストの拡充とダッシュボード構築

やること:

データ品質テストを追加する
異常値検知のルールを設定する
Metabaseをセットアップし、パイロット版ダッシュボードを作成する

成果物:

品質に問題があれば、自動で検知できる状態
実際に業務で使えるダッシュボード

# models/marts/schema.yml
models:
  - name: visitors
    columns:
      - name: unique_visitors
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0
              max_value: 1000000
      - name: visit_date
        tests:
          - not_null
          - unique

Week 7-8: フィードバック収集とドキュメント整備

やること:

ダッシュボードをマーケティング部など実務部門に提供し、利用してもらう
指標の定義やデータの見せ方に関するフィードバックを収集する
dbtのモデルを改善するサイクルを回す
dbt docsを生成し、「指標の辞書」としてチームに共有する

成果物:

「この数字の定義は？」に答えられるドキュメント
改善されたダッシュボード

Phase 2のチェックリスト

データ品質テストが拡充されている
異常値検知が設定されている
Metabaseダッシュボードが作成されている
実務部門からフィードバックを収集した
dbt docsが生成されている
定義がドキュメント化されている

Phase 3（61〜90日目）: 横展開と組織への定着

最後の30日間は、最初の成功事例を基に対象指標を拡大し、データガバナンスのプロセスを組織に根付かせます。

Week 9-10: 自動実行と指標の拡大

やること:

dbtの定期実行（日次/週次）を設定する
実行結果の通知（Slack等）を設定する
エラー発生時の対応フローを決める
次の重要指標（例：消費額）をdbtでのモデル化対象に追加する

成果物:

毎日自動でデータが更新される状態
複数の信頼できる指標

Week 11-12: 組織への定着

やること:

dbtのドキュメント機能を活用し、公式な「指標の辞書」としての運用を開始する
関連部署向けに勉強会を開催し、取り組みの成果を共有する
データガバナンスの重要性について組織内で啓蒙する

成果物:

経営層が見られるダッシュボード
組織全体でのデータ活用文化の醸成

Phase 3のチェックリスト

dbtが日次で自動実行されている
実行結果がSlack等に通知されている
エラー対応フローが決まっている
2つ目以降の指標がモデル化されている
勉強会を開催し、組織内に周知した
経営層がダッシュボードにアクセスできる

90日後の姿——「集計会」から「判断会」へ

90日後、あなたの組織には以下の変化が起きているはずです。

Before（導入前）:

会議のたびに「この数字の定義は？」から始まる
担当者が変わると、過去の集計方法がわからなくなる
数字が合わないと、議論が進まない

After（導入後）:

「来訪者数」の定義はコードで管理されている
誰がいつ実行しても、同じ数字が出る
会議は「この数字を見て、次にどうするか」から始まる

これが、私たちが目指す 「集計会」から「判断会」への転換 です。

導入を成功させるためのチェックリスト

dbtは強力なツールですが、その導入を成功させるには、技術だけでなく組織的な準備が不可欠です。以下のチェックリストで準備状況を確認してください。

組織・戦略編

データ活用を主導する責任者（データオーナー）が明確に任命されているか
主要なKPIの定義と算出ロジックについて、関係部署間の合意は形成されているか
データガバナンスに関する基本的な方針やルールは存在するか
データ基盤構築の目的と、それによって解決したいビジネス課題が明確か

技術・基盤編

クラウドベースのデータウェアハウス（BigQuery等）は導入済み、または導入計画があるか
Gitリポジトリ（GitHub等）は利用可能か
BIツール（Metabase等）は整備されているか

運用・文化編

データモデルの命名規則やコーディング規約を策定する計画はあるか
データを実際に利用する職員向けにトレーニングを計画しているか
定期的にデータモデルのレビューを実施し、改善していく意思があるか
データに関する質問や議論をオープンに行えるコミュニケーションチャネルは整備されているか

よくある質問

Q: SQL書ける人がいないのですが

dbt自体はSQLで記述しますが、最初は外部の支援を受けながら始めることをお勧めします。重要なのは、 「定義をコードで管理する」という思想を組織に根付かせること です。SQLは後から学べます。

Q: 90日で本当にできますか

「小さく始める」ことが前提です。全データを移行するのではなく、まず1つの指標を動かすことに集中すれば、90日で十分可能です。

おわりに——「信頼」は積み重ね、続けることで育つ

3回にわたって、データ基盤の構築についてお伝えしてきました。

第1回: データが信頼されない原因は「定義の不統一」
第2回: dbtは「信頼の礎」を築くツール——4つの機能とレイヤ設計
第3回: 90日で「小さく始めて、確実に動かす」

データへの信頼は、一朝一夕には生まれません。

しかし、90日間コツコツと積み重ねれば、 「数字が合わない」という不毛な議論から解放される 日が来ます。

本当に大切なのは、続けること

データ基盤は、一度作って終わりではありません。

ビジネスの変化
データソースの更新
新しい分析ニーズ

これらに対応しつつ、品質を維持し続けることが求められます。dbtの真価は、この「継続」を支える仕組みにあります。テストが品質を守り、ドキュメントが知識を継承し、バージョン管理が変更を追跡する。

90日間は、あくまでスタートラインです。その先にあるのは、データに基づいた意思決定ができる組織。そして、その組織を維持し、育てていく継続的な取り組みです。

【観光データ基盤シリーズ】

第1回: 「来訪者数」の定義、社内で揃っていますか？
第2回: dbtが観光データに「信頼の礎」を築く理由
第3回: 観光DMOのためのdbt導入90日ロードマップ（本記事）

dbtの導入、データ基盤の構築について、もし課題を感じていらっしゃるなら、ぜひお話を聞かせてください。私たちも、まだまだ学びの途中です。一緒に考えていければ嬉しいです。