SQLも「コード」として管理する時代。
結論
「このSQL、誰がいつ変えた？」問題は、dbt + Git で解決できる。
よくある問題
問題1：誰が変えたか分からない
担当者A「このSQLいつの間にか変わってる...」
担当者B「俺じゃないよ」
担当者C「私も触ってない」問題2：なぜ変えたか分からない
変更履歴がないから、意図が分からない。
「これ消していいのか…？」と誰も判断できない。
問題3：壊れたときに戻せない
「先週動いてたのに…」
バックアップがないから、元に戻せない。
解決策：dbt + Git
dbtとは
dbtは、SQLをコードとして管理するツールです。
- SQLファイルをGitで管理
- 変更履歴が残る
- PRベースでレビュー
具体的な流れ
1. SQLを修正
2. PRを作成
3. レビューを受ける
4. マージ
5. 自動で本番に反映Before/After
Before
1. 本番のSQLを直接編集
2. 「動いたからOK」
3. 3ヶ月後「誰が変えた？」
4. 原因特定に半日After
1. PRで変更内容を説明
2. レビューを受ける
3. マージ
4. 3ヶ月後「git logで確認」
5. 原因特定に5分実装のポイント
ポイント1：コミットメッセージを書く
❌ fix
❌ update
❌ 修正
✅ 売上計算から返品を除外するよう修正
✅ 顧客セグメントの定義を追加ポイント2：PRにはWhyを書く
## 変更内容
売上計算から返品を除外
## 理由
経理部からの依頼。返品を含めると実態と乖離するため。
## 影響範囲
- 月次売上レポート
- ダッシュボードの売上グラフポイント3：小さく頻繁にコミット
1週間分の変更をまとめてコミットしない。
1つの変更 = 1つのコミット。
dbt導入のステップ
Step 1：既存SQLをdbtに移行
まずは既存のSQLファイルをdbtプロジェクトに移す。
Step 2：GitHubリポジトリを作成
コードを管理するリポジトリを作成。
Step 3：PRルールを決める
「本番への直接コミット禁止」をルール化。
まとめ
SQLも「コード」として管理する時代。
dbt + Gitで、「誰がいつ変えた？」問題から解放されましょう。