dbt platform導⼊前の不安を解消する───リアルな⼀ヶ⽉検証記 Coalesce on the road Tokyo フリー株式会社 ⼩越広⾂ 

　 2 ⼩越広⾂ ● フリー株式会社 ● エンジニアリング基盤本部 データ部アナリティクスチーム ● 中部拠点（名古屋）所属 ● テックリード ● 担当 ○ dbt platform導⼊のリード ○ プロダクト向けのデータ配信に必要な機能の 要求‧要件のとりまとめ ○ スクラムマスター アナリティクスエンジニア Hiroomi Okoshi 

会社名 フリー株式会社 設⽴年⽉⽇ 2012年7⽉9⽇ 所在地 〒141-0032 東京都品川区⼤崎1-2-2 アートヴィレッジ⼤崎セントラルタワー21階 代表取締役 佐々⽊ ⼤輔 上場市場 東京証券取引所 グロース市場 従業員数 1,901⼈（2025年6⽉末時点の連結の正社員総数） 事業内容 クラウド型バックオフィスサービスの開発‧販売 

中部 本社 関⻄ 九州 札幌 沖縄 新潟 拠点所在地 関⻄ 関⻄ 本社 本社 本社 

5 2012/7 freee設立 2013/3 「クラウド会計ソフトfreee (現・freee会計)」 リリース 2014/10 「クラウド給与計算ソフト freee(現・freee人事労務)」 リリース 2017/3 Midセグメントへの サービス提供開始 エンタープライズプラン開始 2019/5 ARR50億円達成 2021/3 ARR100億円達成 2021/4 海外公募増資 2021/4 サイトビジット グループジョイン 2021/6 Taxnote グループジョイン 2021/6 リブランド 2022/7 Mikatus グループジョイン 2019/12 東証マザーズ上場 2023/1 sweeep グループジョイン 2023/6 Why グループジョイン 2023/6 ARR200億円達成 2023/12 pasture グループジョイン 2025/1 YUI グループジョイン 2024/12 ARR300億円達成 2025/4 アポロ株式会社 グループジョイン 2025/7 GMOクリエイターズ ネットワーク グループジョイン 2021/7 LiKHA-iT グループジョイン freeeの沿革(2025.6時点) 

　 ミッション‧ビジョン‧バリュー Mission Vision Value 

　 7 Mission スモールビジネスを、 世界の主役に。 freeeは「スモールビジネスを、世界の主役に。」をミッションに掲げ、 統合型経営プラットフォームを開発‧提供し、 だれもが⾃由に⾃然体で経営できる環境をつくっていきます。 起業やビジネスを育てていくことを、もっと魅⼒的で気軽な⾏為に。 個⼈事業や中⼩企業などのスモールビジネスに携わるすべての⼈が、 じぶんらしく⾃信をもって経営できるように。 ⼤胆にスピード感をもってアイデアを具現化できるスモールビジネスは、 今までにない多様な価値観や⽣き⽅、 新しいイノベーションを⽣み出す起爆剤だと私たちは考えています。 スモールビジネスが⼤企業を刺激し、社会をさらにオモシロク、 世の中全体をより良くする流れを後押ししていきます。 

だれもが⾃由に経営できる 統合型経営プラットフォーム Vision だれもが⾃由に⾃然体で経営できる環境をつくるために、 「統合型経営プラットフォーム」を開発‧提供します。 バックオフィス業務を統合することで、⾃動化と業務全体の効率化。 さらに経営全体を可視化することで、これまでにないスマートかつ 最適なアクションまで実⾏できるプラットフォームへと進化させていきます。 また外部サービスとも連携したオープンプラットフォームとして、多様なビジネスニーズに対応。 ユーザーネットワークの中における相互取引の活性化も強化していきます。 プラットフォームの提供のみならず、スモールビジネスに携わる⼈の環境そのものを より良くしていく取り組みを⾏うことで、世の中の変化を促します。 

　 9 ユーザーにとって本質的な価値があると⾃信を持って⾔えることをする freeeはマジ価値を届けきる集団である マジ価値 

従業員数 1,901⼈ 「働きがいのある会社」 ベストカンパニートップ10に ８年連続でランクイン （2022年2⽉時点） ※従業員数は、2025年6⽉末の連結会社の正社員総数 ※ ※継続して上位ランクインしている為、2022年以降は応募を取りやめ ています 

2019年 6月期 2020年 6月期 2017年 6月期 2018年 6月期 2021年 6月期 有料課⾦ユーザー企業数（件） 有料課⾦ ユーザー企業数(1)は 約 60万事業所 2022年 6月期 45.1万 2023年 6月期 ※（1） 2025年6⽉末時点。有料課⾦ユーザー企業数には個⼈事業主を含む 37.9万 29.3万 22.4万 16万 12.1万 8.3万 ユーザー基盤拡⼤に向けた取り組み 54.7万 2024年 6月期 うち法⼈23.4万社 60万 2025年 6月期 

　 サービス Our Service 

13 その他のプロダクト・サービス
 統合型クラウド(1) 会計ソフト
 請求書 | 経費精算 | 決算書 | 予実管理 | ワークフロー | 内部統制
 スモールビジネス向けに統合型クラウドERPを提供
 2013年3月リリース
 日本のクラウド市場シェ アNo.1 (2) 統合型クラウド人事労務ソフト
 勤怠管理 | 入退社管理 | 給与計算 | 年末調整| マイナンバー管理
 2014年10月リリース
 日本のクラウド市場
 シェアNo.1(3) 1. クラウドサービス：ソフトウェアやハードウェアを所有することなく、ユーザーがインターネットを経由してITシステムにアクセスし利用できるサービスのこと 2. リードプラス株式会社「検索キーワードから紐解く業界分析：クラウド会計ソフト編」(2022年８月公開、2023年６月更新) 3. クラウド給与計算ソフトの市場シェア：株式会社MM総研「日本におけるクラウド給与計算ソフトの利用状況調査に関するWeb調査(2016年3月実施)」(N=4,168) freee カード Unlimited 

14 今⽇お話すること ✓ なぜdbt platformの検証が必要だったのか ✓ 15項⽬を短期間でどう検証したのか ✓ 実際に⾒つけたいくつかの「落とし⽳」 ✓ 体系的な検証フレームの紹介 ✓ 実⽤性の確認結果 

15 dbt platformを導⼊するにあたって、どう検証するか検証⽅法に悩みました 同じ悩みを持つ⽅がいらっしゃるのではないかと思うので知⾒と事例を共有します ✓ 再現可能な検証フレーム → 明⽇から使える4ステップ → 統⼀フォーマットで品質担保 ✓ ⾒送り要因の設定⽅法 → 検証の判断基準を明確化 → 主観を排除した評価軸 ✓ 検証で得られた重要な気づき → データロケーション問題の発⾒ → モノレポ構成の適合性確認 → CI実⾏コストの⾒積もり⽅ この発表で持ち帰れるもの ✓ 実際の検証事例 → 具体的な使⽤感とパフォーマンス → 実⽤性の確認結果 ✓ 詳細な検証結果（ブログ公開中） → 帰ってすぐに参照可能 → 15項⽬の詳細レポート 

　 導⼊の経緯 

17 導⼊前の状況：データ活⽤ニーズの急増 マルチプロダクト戦略の推進 M&A統合による データソース増加 ⾮エンジニアからの 開発環境要求増⼤ 2012/7 freee設立 2013/3 「クラウド会計ソフトfreee (現・freee会計)」 リリース 2014/10 「クラウド給与計算ソフトfreee(現 ・freee人事労務)」 リリース 2017/3 Midセグメントへの サービス提供開始 エンタープライズプラン開始 2019/5 ARR50億円達成 2021/3 ARR100億円達成 2021/4 海外公募増資 2021/4 サイトビジット グループジョイン 2021/6 Taxnote グループジョイン 2021/6 リブランド 2022/7 Mikatus グループジョイン 2019/12 東証マザーズ上場 2023/1 sweeep グループジョイン 2023/6 Why グループジョイン 2023/6 ARR200億円達成 2023/12 pasture グループジョイン 2025/1 YUI グループジョイン 2024/12 ARR300億円達成 2025/4 アポロ株式会社 グループジョイン 2025/7 GMOクリエイターズ ネットワーク グループジョイン 2021/7 LiKHA-iT グループジョイン - 複数のクラウドサービスを展開 - プロダクト横断のデータ分析需要増 - 沿⾰の通り、データソースが爆増 - エンジニアへの依頼が集中 - セルフサービス分析のニーズ 

18 抱えていた課題 ✗ 依存関係が追えない ✗ 影響範囲の把握が困難 ✗ トラブルシューティングに  時間がかかる ✗ データ品質の追跡が困難 データリネージの不透明性 ✗ 異なる定義のデータが存在 ✗ 品質基準が不明確 ✗ データの重複 ✗ データの信頼性が低下 データ品質管理の属⼈化 ✗ 誰が何を作ったか不明 ✗ メンテナンスが属⼈化 ✗ ドキュメントが整備されていな い ✗ 引き継ぎが困難 SQLの属⼈化と保守困難性 これらの課題を放置すると... → データ活⽤の推進が停滞 

19 dbt移⾏すらできていないSQLも存在。リネージを⼿で描いて理解する必要がある。 → これも解決したい → ⾃動化とドキュメント化が急務 dbt移⾏していないSQLも存在 ※こちらのリネージは規模感を感じてもらうためのものなのでわざと⽂字はぼやかしています。 

20 dbt Coreでの現在の取り組み dbt Coreは導⼊済み - モデルの構造化 - SQLのモジュール化 テストの⾃動化 - データ品質テストの実装 - CI/CDパイプライン構築 ドキュメント⾃動⽣成 - dbt docsの活⽤ - GitHub Pagesでの公開 

21 dbt Coreでの現在の取り組み dbt Coreは導⼊済み - モデルの構造化 - SQLのモジュール化 テストの⾃動化 - データ品質テストの実装 - CI/CDパイプライン構築 ドキュメント⾃動⽣成 - dbt docsの活⽤ - GitHub Pagesでの公開 しかし、dbt Coreでも限界を感じていた... 

22 dbt Coreで限界を感じた課題 ✗ エンジニアの運⽤負荷が⾼い → Digdag等の別ツールが必要 → インフラ管理コスト → 設定の複雑さ スケジューリング管理の煩雑性 ✗ GitHub Pagesでの管理が属⼈化 → 更新作業が煩雑 → リアルタイム性に⽋ける → アクセス権限管理が困難 ドキュメント‧リネージの共有 ✗ ⾮エンジニアが⾃⼒で開発環境 を構築保守できない → ローカル環境構築が⾼いハードル → Git操作の学習コスト → エンジニアへの依頼が必要 IDE環境の⽋如 dbt platformへの期待 

23 dbt platformに期待したこと ⾮エンジニアの⾃律的な開発 ✓ ブラウザベースで環境構築不要 ✓ Git操作の簡易化 ✓ ⾮エンジニアの参⼊障壁低減 ドキュメント‧リネージのすばやい可視化 ✓ リアルタイムなリネージ表⽰ ✓ ドキュメントの⾃動⽣成‧公開 ✓ 検索性の向上 ✓ アクセス権限管理 運⽤の⾃動化‧効率化 ✓ ジョブスケジューリング - GUIでの簡単設定 - 依存関係の⾃動管理 ✓ CI/CD統合 - GitHub連携の簡易化 - ⾃動テストの実⾏ ✓ モニタリング‧通知 - Slack通知 - エラーアラート 

24 しかし、⼤きな不安があった データロケーション要件を 満たせるか？ 社内ポリシー: データは⽇本国内※のみ → 各機能のデータフロー確認が必要 → ポリシー違反は避けたい    ※当時東京リージョンは提供されていなかった 既存ワークフローに 適合するか？ モノレポ構成、Git操作、CI/CD連携 → 実際の運⽤をシミュレーション → チームのワークフローに馴染むか？ パフォーマンスは実⽤に 耐えるか？ ⼤規模なSQL、複雑なリネージ表⽰ → 実際の使⽤感による確認が必要 → 著しく悪い点はないか？ だから、検証が必要だった 

25 導⼊⾒送り要因（ノックアウトファクター）の設定 なぜ必要？ 検証の軸を明確にする 主観を排除した判断基準 チーム内での合意形成 時間の無駄を防ぐ 重要な考え⽅ ⼀時的な不具合は除外（修正される前提） 機能改善のロードマップも考慮 致命的な問題のみをノックアウトファクターに リネージ表⽰性能 dbt docsより明らかに遅い データロケーション 社内ポリシー要件違反 使用感・開発効率 dbt Core + VSCodeより劣る コスト 費用対効果が見合わない 

26 導⼊の価値を明確化 ✓ ⼯数削減効果の試算 - ⾮エンジニアの⾃律化によるエンジニア負荷軽減 - 運⽤⾃動化による⼯数削減 - 問い合わせ対応時間の削減 ✓ 開発速度向上 - IDE環境による開発効率化 - CI/CDによるデプロイ効率化 - ドキュメント⾃動⽣成による時間削減 → 稟議資料作成に活⽤ → 経営層への説明材料 → 実現したいことが達成できると実感できる ✓ 品質向上効果 - テスト⾃動化による品質向上 - データの信頼性向上 - インシデント削減 

　 検証の全体像 

28 本資料ではdbt platformの機能を旧名称で表現しています。本資料中では弊社のブログで公開中の資料を参照していま すが、その資料は過去の資料のため旧名称を使⽤しており、⼀致性を優先して旧名称を使⽤しています。新旧の機能名 の対応表は以下の通りです。 機能名の新旧対応表 旧名称 新名称 dbt Cloud CLI dbt Cloud IDE Visual Editor dbt Copilot Manage environments Schedule and run dbt jobs Notifications Run visibility Host & share documentation Supports GitHub, GItLab, AzureDevOps Enable Continuous Integration Security Visualize and orchestrate exposures dbt Semantic Layer Discovery API dbt Exploer dbt CLI dbt Studio IDE dbt Canvas dbt Copilot Manage environments Schedule and run dbt jobs Notifications Run visibility Host & share documentation Supports GitHub, GitLab, AzureDevOps Enable Continuous Integration Security Visualize and orchestrate exposures dbt Semantic Layser Discovery API dbt Catalog ※当時dbt Insightsに該当する機能は⼀覧にはなかったので省略 

29 検証項⽬の全体像 開発環境 (3項⽬) 運⽤管理 (4項⽬) 連携‧共有 (3項⽬) セキュリティ (2項⽬) 可視化 (2項⽬) dbt Cloud CLI(dbt CLI) dbt Cloud IDE(dbt Studio IDE) dbt Copilot Manage environments Schedule and run dbt jobs Notifications Run visibility Host & share documentation Supports GitHub, GitLab,  AzureDevOps Enable CI Security IP制限 dbt Explorer Viewerシート 包括的な評価と判断 注：Visual Editor(dbt Canvas)は当時β版提供で動作が不安定だったためスキップ 検証対象 15 項⽬ 

30 検証の役割分担とタイムライン ✓ 検証体制（計3名体制） エンジニア2名 環境の作成と検証 アナリスト1名 要求‧要件のヒアリング先 ✓ 結果の共有 最後に導⼊可否のミーティング 発⾒事項の共有と対策検討 Week 1 検証項⽬作成 とヒアリング Week 2〜3 検証環境作成 と検証 Week 4 導⼊可否の 評価 なぜ複数⼈？ → 多⾓的な視点での評価 → 実際の利⽤者による検証 → 検証スピードの向上 

31 検証環境の準備 準備リソース dbt platformトライアルアカウント BigQuery検証環境 - asia-northeast1リージョン - 検証専⽤プロジェクト - コスト監視設定 GitHub検証⽤リポジトリ - モノレポ構成での検証 - マルチレポ構成での検証 サンプル - サンプルプロジェクト利⽤ - ダミーデータ dbt Labs社公式サンプル（GitHub） - https://github.com/dbt-labs/ - jaffle-shop-mesh-platform - jaffle-shop-mesh-finance - jaffle-shop-mesh-marketing ⾃社既存プロジェクト - 移⾏可能かのテスト⽤ 

32 検証結果の記録⽅針 ドキュメント形式 後⽇の活⽤ ✓ Google Documentに記録 ✓ 各項⽬で統⼀ フォーマット 使⽤ ✓ スクリーン ショットを多⽤ ✓ アドホックな 使⽤ 記録内容（4ステップ） 1. ⽬的と背景 2. ⼿順の 明⽂化 3. 期待さ れる結果 4. 検証結果 と考察 → 検証が終わっても資産として残る ブログ記事公開 社内ナレッジベース化 稟議資料作成 社内共有資料 

33 3つの重視ポイント： 検証で重視したポイント 1. ドキュメントだけに頼らない ✓ 実際にデータを流して確認 ✓ ログを詳細に確認 ✓ データフローを追跡 → 思い込みを排除 2. 実際の利⽤者が検証 ✓ エンジニアがCLI検証 ✓ 本番に近い使い⽅で評価 → リアルな使⽤感を確認 3. 検証後の振り返り ✓ 検証結果を俯瞰的に⾒直す ✓ ⾒落としがないか再確認 ✓ ドキュメントを再読 → 後で気付けることがある 

　 4ステップ検証フレーム 

35 このフレームで全15項⽬に適⽤しました フレームの全体像 Step 1: ⽬的を明確にする →なぜこの機能を検証するの か？ Step 2: ⼿順を明⽂化する →どのように検証するの か？ Step 3: 期待される結果を設定する → 何をもって合格とするのか？ Step 4: 検証結果を記録し考察する →実際どうだったのか？ 各ステップを詳しくみていきます 

36 Step 1: ⽬的を明確にする 【実例テンプレート】 検証項⽬: dbt Cloud IDE(dbt Studio IDE) ⽬的: ● IDE環境での開発体験の確認 ● dbt Meshでのリネージ表⽰パフォーマンス検証 ● ⾮エンジニアが独⽴して開発可能か確認 ● Git操作の学習コストの評価 背景: ● ⾮エンジニアからの開発環境要求が増加 ● Git未経験者の利⽤を想定 ● 複数⼈の同時開発が前提 ● エンジニア負荷の軽減が⽬的 利⽤シナリオ: ● ⾮エンジニアが使⽤ ● 複数プロジェクトの並⾏開発 ● プロジェクト間参照の動作確認 ● モノレポ構成での運⽤可否確認 なぜこのステップが重要？ ⼀⼈で検証するわけではない チーム全員が⽬的を共有 検証の⽅向性を統⼀ 検証漏れを防ぐ このように明⽂化することでチーム全員が同じ理解を持てる 

37 Step 2: ⼿順を明⽂化する 【実例】CI機能検証の⼿順 1. dbt Cloud CI設定 ● GitHub連携の確認 ● CI Job設定 ● トリガー条件の設定 2. PR作成とCI実⾏確認 ● PRを作成 ● CI⾃動実⾏の確認 ● ジョブログの確認 3. CI実⾏時のデータフロー確認 ● 実⾏ログの詳細確認 ● データ保存先の確認 ● BigQueryスキャン量の確認 4. コスト影響の評価 ● PR更新時の再実⾏確認 ● 1回あたりのコスト確認 ● ⽉間コスト試算 なぜこのステップが重要？ ⽅向性のブレを防ぐ 複数⼈で同じ検証を再現可能 検証漏れを防ぐ 後から⾒返したとき読みやすい ⼿順を明⽂化することで誰でも同じ検証ができる 

38 Step 3: 期待される結果を設定する 【機能⾯‧パフォーマンス⾯‧使⽤感の観点で設定】 1. 機能⾯ ✓ 認識通りに動作すること ● ドキュメントの記載通り、想定ユースケースで動作 ✓ 必要な機能が揃っている ● 不⾜機能がないか、ワークアラウンドが許容範囲か 2. パフォーマンス⾯ ✓ 実⽤上問題ないレスポンス ● 待ち時間が許容範囲でストレスなく操作できる ✓ 著しく悪い点がない ● ノックアウトファクター基準 ✓ ⼤規模データでも実⽤的 ● 実際のデータ量での確認、⽇常的な開発作業で問題なし 3. 使⽤感 ✓ 直感的に使える ● UIがわかりやすい、迷わず操作できる ✓ 学習コストが許容範囲 ● ⾮エンジニアが⾃学可能、ドキュメントが充実 ✓ 既存ワークフローに適合 ● チームの働き⽅に馴染む、⼤きな変更を強いられない なぜこのステップが重要？ 検証の合格基準を明確化 主観的評価を避ける チーム内での判断基準統⼀ ノックアウトファクターとの 整合性の確認 

39 ✅ Good: ❌ Bad: パフォーマンス: 考察: Step 4: 検証結果を記録し考察する 検証フォーマット 【実例】dbt Cloud IDE(dbt Studio IDE)検証結果フォーマット ✅ Good: ━━━━━━━━━━━━━━━━━━ - IDE内リネージからSQLファイル直接表⽰ - Environment設定でprofileを意識不要 - dbtコマンド実⾏がスムーズ - コンパイル結果がリアルタイムで確認可能 - ブラウザベースで環境構築不要 ❌ Bad: ━━━━━━━━━━━━━━━━━━ - gitの細かい操作ができない → cherry-pick, stash等が不可 - プロジェクト全体のgrep検索不可 → ファイル名検索のみ可能 - リネージのテーブル名が途中で途切れる - 他プロジェクトのノード識別が困難 - ⽇本語⼊⼒時のショートカット問題 - ブランチのヒストリー確認不可 パフォーマンス: ━━━━━━━━━━━━━━━━━━ - dbtコマンド実⾏: スムーズ - リネージ初期表⽰: 数⼗秒かかることがある → 警告メッセージで1分程度かかる旨表⽰ → ノード数に関わらず発⽣ - IDEとしてはローカルより使いにくい 考察: ━━━━━━━━━━━━━━━━━━ → ⾮エンジニア向けとしては⼗分 - Git操作が簡易化されている - 環境構築不要が⼤きなメリット - 学習コストは許容範囲 → エンジニアはローカル開発を併⽤推奨 - 細かいGit操作が必要な場合 - grep検索が必要な場合 - 複雑なリファクタリング時 → リネージ初期表⽰は待つ必要あり - 初回のみ時間がかかる - ⽇常的な開発には影響少ない 

40 このフレームを使った実際の検証例（dbt Copilot） 1. ⽬的と背景 2. ⼿順の 明⽂化 3. 期待さ れる結果 4. 検証結果 と考察 ⽬的設定 ● AI⽀援機能の実⽤性確認 ● ⽇本語対応の確認 ● ⽣成コード品質の確認 ● ⾮エンジニアの開発⽀援に使える か ⼿順 1. プロンプト作成ガイドライン設定 2. 様々なプロンプトでテスト ○ 簡単なSELECT⽂ ○ 複雑なJOIN ○ ウィンドウ関数 ○ CTEの⽣成 3. ⽣成コード品質評価 4. レスポンス時間確認 期待結果 ● 適切なSQL⽣成 ● ⽇本語プロンプト対応 ● レスポンスが実⽤的 ● BigQueryへの対応 結果 ★ SQLは概ね適切に⽣成、△ ⼀部関 数選択ミスあり ○ 例: DATE_TRUNC vs DATE ★ ⽇本語対応良好 ★ レスポンスが速い ○ ⻑いプロンプトでも5秒以内 ★ BigQueryに対応 考察 ❖ レビュー前提で⼗分実⽤的 ❖ SQLのスタイルガイドで品質向上 ❖ 初学者の学習ツールとして有効 ❖ コード⽣成の⾼速化に貢献 

41 このフレームを使った実際の検証例（GitHub連携） 1. ⽬的と背景 2. ⼿順の 明⽂化 3. 期待さ れる結果 4. 検証結果 と考察 ⽬的設定 ● GitHubとの連携機能確認 ● モノレポ構成での動作確認 ● Git操作の制限確認 ● CI/CD連携確認 ⼿順 1. GitHub連携設定 2. リポジトリのクローン 3. ブランチ操作の確認 4. コミット‧プッシュの確認 5. PR作成フローの確認 期待結果 ● スムーズな連携 ● 必要なGit操作が可能 ● モノレポでも問題なし 結果 ★ ✓ GitHubとの連携は簡単 ★ ✓ 同期も問題なし ★ △ Git操作に制限あり ○ cherry-pick, stash不可 ★ ✗ モノレポでの課題発⾒ ○ 他プロジェクトが⾒える ○ Gitに慣れていないと誤操作の リスク 考察 ❖ - 基本的なGit操作は可能 ❖ - ⾮エンジニア向けには⼗分 ❖ - モノレポは注意が必要 ➢ マルチレポ構成を検討 

42 このフレームのメリットと検証スピード 実際に得られた効果 ✔15項⽬を2週間で完遂 ●計画的な進⾏管理 ●明確な役割分担 ●並⾏検証が可能に なぜスピーディに完遂できたのか？ その他のメリット 1. 統⼀フォーマットで迷わない →何を書けばいいか明快 →検証品質が均質化 2. 複数⼈で分担しやすい →フォーマットが統⼀ →引き継ぎがスムーズ 3. ⾒送り要因が明確 →優先順位が明確 →時間の無駄がない ナレッジが蓄積できる →統⼀フォーマットでわかりやすい →将来、当時の様⼦がわかる 稟議資料作成がスムーズ →検証結果が整理済み →根拠が明確 →判断材料が揃っている ブログ記事として公開できる →他社への貢献 →知⾒の共有 →コミュニティへの還元 

43 ## 検証項⽬: [機能名] ### ⽬的 - [この機能を検証する⽬的] - [解決したい課題] - [期待する効果] ### 背景 - [なぜこの検証が必要か] - [どのようなユーザーが使うか] - [利⽤シナリオ] ### ⼿順 1. [⼿順1] 2. [⼿順2] 3. [⼿順3] ... このフレームのテンプレート ### 期待される結果 #### 機能⾯ - [期待する動作1] - [期待する動作2] #### パフォーマンス⾯ - [実⽤上問題ないか] - [著しく悪い点はないか] #### 使⽤感 - [直感的に使えるか] - [学習コストは許容範囲か] ### 検証結果 #### Good - [良かった点1] - [良かった点2] #### Bad - [悪かった点1] - [悪かった点2] #### パフォーマンス‧使⽤感 - [実⽤上問題ないか] - [スムーズか、もたつくか] - [感覚的な評価] ### 考察 - [結果に対する考察] - [実運⽤での活⽤⽅法] - [注意点] 

　 検証だからこそ発⾒できた こと 

45 検証を通じて得られた実際に使ってみないと分からなかった重要な発⾒ これらの気づきは検証の価値を証明する 重要な気づきの概要 リポジトリ構成の適合性 → 実際に使ってみて気づけた データロケーションの確認 → マニュアルを俯瞰的に⾒直して気づけた CI実⾏コストの⾒積もり → 動作を⾒て気づけた だから、検証が重要！！！ 

46 気づき #1: データロケーションの確認（発⾒のプロセス） 疑問とポリシー CIで出⼒され る差分のデー タはどこに？ ✓ データは⽇本国内のみに 配置 ✓ データレジデンシー要件 を遵守 考察での発⾒ どこにあるのかを確認 するためマニュアルを 再確認して、 CI実⾏時の差分データ が⽶国リージョンのS3 に保存されることを発 ⾒ 気づきの経緯 マニュアルには 記載あり (最初は⾒落とした) 検証後に俯瞰的に アーキテクチャを 再考察 実証検証での発⾒ → 完全に 理解してい ると思い込 むのは危険 

47 気づき #1: データロケーションの確認（学びと価値） ✓ ドキュメントを読み込んでも⾒落とす → 完全に理解したと思い込まない → 検証後に改めて俯瞰的に⾒直す → チームでレビューし合う 【学び】ドキュメントと実検証の重要性 ✓ 検証の価値: 本番導⼊前に発⾒できた 社内ポリシー違反を回避できた ✓ 実際にデータを流して確認 → ドキュメントだけでは不⼗分 → ログを詳細に確認 → データ保存先を追跡 【アクションと価値】検証プロセスでの実践 ✓ 早期にサポート問い合わせした⽅がよかった → 不明点は迷わず質問 → レスポンスが早い → 詳細な技術情報が得られる ✓ ポリシー違反は最優先検証事項 → 最初に確認すべき項⽬ → ノックアウトファクターに設定 → 本番導⼊前に必ず確認 

48 モノレポ構 成可能かな 気づき #2: リポジトリ構成の適合性（発⾒と課題） 当初の計画 (Before) 発⾒と課題 (After) 理由: ✅ 管理がシンプルそう ✅ 他⼈の書いたSQLを参考にしやすそう ✅ SSoTするならSQLも統⼀管理が良いか迷っていた しかし、実際に使ってみると... 1. Studio IDEでの誤操作リスク ❌ 他プロジェクトが⾒える ❌ 誤編集の可能性 ❌ 押したくなるボタン ✖ 2. Git操作の制限 ❌ cherry-pick、stash等不可 ❌ 細かい操作ができない ✖ 3. コンフリクトリスクの制限 ❌ 同じリポジトリで複数⼈作業 ❌ pull頻度が⾼くなる ❌ dbt_project.ymlの更新作業の競合 ✖ → 実際に使ってみて初めて分かった 

49 気づき #2: リポジトリ構成の適合性（学びと決断） ⾮エンジニアの独⽴性確保 ●⾃分のプロジェクトに集中 ●他への影響を気にしなくていい ●⼼理的安全性の向上 コンフリクトリスク低減 ●リポジトリが独⽴ ●pull頻度が下がる ●他メンバーの影響を受けにくい 誤操作防⽌ ●他プロジェクトが⾒えない ●明確な境界線 ●安⼼して作業できる 最終決断: マルチレポ構成を採⽤ トレードオフ ● 共通コードの管理が複雑化 → あまりないと予想されたので、作らないこと を意識しつつ⼀旦許容 検証の価値: ● 実際に使ってみて気づけた ● 本番導⼊後のトラブルを回避できた 学んだこと: ● dbt Cloud IDE(dbt Studio IDE)の制約を理解して から構成決定 ● ⾮エンジニアのGit習熟度を考慮 ● 運⽤のしやすさを重視 ● シンプルさと柔軟性のバランス 

50 気づき #3: CI実⾏コスト 1. PRを作成 2. ⾃動的にdbt Cloud CIが起動 3. BigQueryでdbt buildを実⾏ 4. PRを更新（コミット追加） 5. 再度CIが⾃動起動 ← ここ！ 6. またBigQueryでdbt build DWHへ課⾦ DWHへ課⾦ 想定: ● エンジニア2名が並⾏開発 ● 1つのPRで平均5回の修正コミット ● ⽉間PR数: 20個 計算: 20PR/⽉ ✖ 5回/PR 🟰 100回/⽉ (CI実⾏回数) → 実際に⽬にして回数の多さに危機感を覚える → 予想以上のコストになる可能性 検証の価値: 実際の動作を⾒て気づけた 本番導⼊前にコスト戦略を⽴てられた 

51 気づき #3: CI実⾏コスト（対策） 検証の価値 実際の動作をみることで、 コスト最適化の具体的な 戦略を⽴案できた。 課題：CI実⾏回数増加によるコスト⾼騰の懸念 対策の検討 構成案 学んだこと ✓ CI実⾏頻度を事前に⾒積もる ✓ Draft PR戦略の重要性 ✓ state:modified の活⽤の有効性 ✓ CI/CD戦略の設計が重要 Draft PRの活⽤ 実⾏対象の制限 ⼩規模データでのCI Draft中はCI実⾏をスキップ 準備ができたら Draft解除してCI実⾏ state:modifiedで変更モデルのみ実⾏。 スキャン量削減。 CI専⽤データセット利⽤。 本番ロジックの再確認とコスト削減。 PR作成 CI実⾏準備 state:modified確認 変更モデルのみ実⾏ (通常PR) 全体CI実⾏ (フルテスト) CIスキップ (Draft) Draft? YES NO 本番直前 

52 これが検証の価値です 気づきのまとめ 【アプローチ】 実際の運⽤を シミュレーション 【発⾒】 検証だからこそ 発⾒できた 【価値】 本番導⼊前に 気づけた価値 ● 本番に近い環境で ● 実際の利⽤者が検証 ● チームでレビュー ● ドキュメントだけでは不⼗分 ● 実際に動かして確認 ● 検証後の俯瞰的な⾒直し ● データロケーション：ポリ シー違反を回避 ● リポジトリ構成：運⽤トラブ ルを回避 ● CI実⾏コスト：コスト最適化 の戦略策定 

53 検証で確認すべきチェックリスト: 【社内ポリシー】 ━━━━━━━━━━━━━━━━━━ □ データロケーション要件の確認 □ データレジデンシーポリシー □ 各機能のデータフロー検証 □ データ保存先の確認 □ 検証後の俯瞰的な⾒直し 【技術的制約】 ━━━━━━━━━━━━━━━━━━ □ リポジトリ構成の決定 → モノレポ vs マルチレポ □ 同時開発者数とGit習熟度 □ CI/CD実⾏頻度とコスト影響 □ VSCode拡張の活⽤⽅針 みなさんの組織で実践する上で確認すべきこと 【パフォーマンス‧実⽤性】 ━━━━━━━━━━━━━━━━━━ □ 実際の使⽤感での確認 → 著しく悪い点はないか □ 許容可能な使⽤感か □ DWHクエリ実⾏コストの把握 □ 実際のデータでの検証 【運⽤】 ━━━━━━━━━━━━━━━━━━ □ 既存ワークフローとの統合 □ デプロイフローの設計 □ サポート体制の確認 □ ドキュメント整備計画 

　 具体的な検証事例 

55 ※実際の検証結果より 事例1: dbt Cloud IDE(dbt Studio IDE)の使⽤感 ✅ Good ✓ IDE内リネージからSQLファイル直接表⽰ → クリック⼀つでファイルが開く → ナビゲーションが便利 ✓ Environment設定でprofileを意識不要 → BigQueryへの接続設定が簡単 → ⾮エンジニアに優しい ✓ dbtコマンド実⾏がスムーズ → CLIと同等の使⽤感 → ストレスなく使える ❌ Bad ✗ プロジェクト全体に対してgrep検索不可 → ファイル名検索のみ可能 → コード検索には不便 ✗ リネージのテーブル名が途中で途切れる（当時だけ？） → カーソルを合わせれば全体表⽰ → 俯瞰的な把握がしにくい ✗ ⽇本語⼊⼒時のショートカット問題 → option+Wで「Σ」が⼊⼒される(閉じてほしかった) → ⽇本語ユーザーには不便 結論 ⾮エンジニア向けとしては⼗分だが多少学習は必要 エンジニアはローカル開発を併⽤推奨 

56 ※実際の検証結果より 事例2: dbt Copilotの精度 ✅ Good ✓ 簡単な指⽰であればプロンプト通りのSQL⽣成 → SELECT⽂、JOIN、集計など ✓ 複雑な処理でも具体的な指⽰で正確 → ウィンドウ関数、CTE⽣成 ✓ レスポンスが速い → ⻑いプロンプトでも5秒以内 → ストレスなく使える ✓ BigQuery⽅⾔に対応 → BQ固有の関数も正しく⽣成 ❌ Bad ✗ Command+Bが反応しないことがある → 時々プロンプトが表⽰されない ✗ ⽇本語変換確定と同時にプロンプト送信 → chatウインドウでの問題 → ⼊⼒ミスの原因に ✗ SQLがコンパイルエラー状態でドキュメント⽣成 → 出鱈⽬なドキュメントが出⼒される → 注意が必要 結論 レビューは必須だが、⼗分実⽤的 モデリングデータ環境の学習ツールとして有効 コード⽣成の⾼速化に貢献 

57 ※実際の検証結果より 事例3: Manage environmentsの使い勝⼿ ✅ Good ✓ 環境の作成や削除が簡単 → GUIで簡単に操作 → 即座に完了 ✓ 環境変数の設定が柔軟 → 環境毎に異なる値を設定可能 → DBT_ENV_SECRET_プレフィックスでマスク ✓ jinjaで参照可能 → モデル内で環境変数を利⽤ → 環境ごとの設定を分離 ✓ secretはSQLから参照できない → jinjaのみで利⽤可能 → セキュリティ上の制約が効いていて安⼼ ❌ Bad 特になし 結論 環境管理は問題なし 環境変数の仕組みが便利 パフォーマンス 環境の作成や削除は即座に完了 待たされることなし 

58 ※実際の検証結果より 事例4: GitHub連携の実⽤性 ✅ Good ✓ 同期が簡単 → ボタン⼀つで同期 → ⾃動同期はないが問題なし ✓ ブランチの変更検知が明確 → ⽂字が⾚くなる → 気づきやすい ✓ CI実⾏後のRerun機能 → dbt Cloud上で設定変更してRerun可能 → トリガーコミット不要 ✓ Rollback to remote機能 → リセットスイッチのような機能 → 緊急時に便利 ❌ Bad ✗ プルリクエスト作成はGitHubサイトへ⾶ばされる → 作業者⾃らPR作成が必要 ✗ モノレポでは他プロジェクトを触れる → 作業ミスに注意が必要 結論 必要⼗分な機能 モノレポでは注意が必要 パフォーマンス GitHubとの通信は5秒前後、VSCodeと同等で問題なし 

59 ※実際の検証結果より 事例5: Schedule and run dbt jobsの動作 ✅ Good ✓ ジョブ作成が簡単 → GUIで直感的に設定 → スケジュール設定も容易 ✓ API実⾏が可能 → プログラムからジョブ実⾏ → ⾃動化に便利 ✓ ジョブログが詳細 → 各ステップの実⾏結果 → トラブルシューティングしやすい ✓ ジョブの中断機能 → 実⾏中のジョブを停⽌可能 → 緊急時に便利 ❌ Bad 特になし 結論 ジョブ管理は⼗分、API連携も問題なし 運⽤に必要な機能が揃っている パフォーマンス ジョブは即座に開始 リクエスト送信後すぐに実⾏ もたつきなし 

60 ※実際の検証結果より 事例6: dbt Explorer(dbt Catalog)のリネージ表⽰ ✅ Good ✓ グラフィカルなリネージ表⽰ → 視覚的にわかりやすい → 依存関係が⼀⽬瞭然 ✓ インタラクティブな操作 → ノードをクリックで詳細表⽰ → SQLファイルへ直接ジャンプ ✓ フィルター機能が充実 → プロジェクト、タグで絞り込み → ⼤規模プロジェクトでも使いやすい ❌ Bad ✗ 初回表⽰に時間がかかる → 数⼗秒 → 警告メッセージあり → ノード数に関わらず発⽣ 結論 初回のみ待つ必要はあるが、リネージ表⽰は⼗分 dbt docsより使いやすい パフォーマンス 初回表⽰以外はスムーズ ⽇常的な使⽤には問題なし 

61 検証事例のまとめ ✓ 全体的に実⽤レベル ● dbt Coreと⽐較して劣化なし ● 著しく悪い点は⾒つからず ● ノックアウトファクターに該当なし ✓ 各機能の特徴を理解すれば適材適所で 活⽤できる ● 適材適所で活⽤できる ● IDE: ⾮エンジニア向け ● CLI: エンジニア向け ● Copilot: ⼀旦学習ツールとして扱えそう（利⽤は 必須ではない） ● Catalog: リネージ可視化に有効 ✓ パフォーマンスは合格 ● 初回表⽰以外は問題なし ● ⽇常的な使⽤で⽀障なし ● ストレスなく使える → 導⼊価値ありと判断 

　 検証してわかったこと 

63 パフォーマンス‧実⽤性の確認結果 検証項目 確認結果 評価 備考 dbt Cloud CLI(dbt CLI) スムーズ ◎ dbt Coreと同等の使用感 dbt Cloud IDE(dbt Studio IDE)コマンド実行 概ね良好 〇 dbtコマンド実行はスムーズ dbt Cloud IDE(dbt Studio IDE)リネージ(初期表示) 初回は時間がかかることがある △ 数十秒程度かかることはある dbt Copilotレスポンス 早い ◎ 長いプロンプトでも5秒以内 環境作成・削除 即座に完了 ◎ 待たされることなし ジョブ実行 即座に開始 ◎ リクエスト送信後すぐにジョブ開始 Slack通知 リアルタイム ◎ チャンネル選択時若干の待機時間があるが、普段使いするもので はないので問題なし Run visibilityの表示 スムーズ ◎ グラフィカルな表示にもたつきなし ドキュメントの表示 dbt Coreと同等 ◎ 同程度のパフォーマンス ✓ リネージ初回表⽰以外は問題なし → ⽇常的な開発作業はスムーズ → ストレスなく使える 注⽬ポイント！ ✓ 著しく悪い点は⾒つからず → ノックアウトファクターに該当 なしで、 実⽤上は⼗分 ✓ dbt Coreと⽐較して劣化なし → 既存環境からの移⾏でも安⼼ ✓ ノックアウトファクターには該当 せず → パフォーマンスは合格 

64 全体評価: 導⼊価値あり ━━━━━━━━━━━━━━━━━━ ● ノックアウトファクターなし ● 期待した機能は概ね満たす ● ⼀部制約はあるが運⽤でカバー可能 機能別の総合評価 機能 評価 使用感 実用性 dbt Cloud CLI(dbt CLI) ◎ dbt Coreと同等 エンジニア向け◎ dbt Cloud IDE(dbt Studio IDE) 〇 初回表示に注意 非エンジニア向け〇、エンジニア向け△ dbt Copilot ◎ レスポンス良好 レビューは必要だが◎、学習ツールとして〇 ジョブスケジューリング ◎ GUI操作が容易 十分 GitHub連携 〇 設定が簡単 良好 CI/CD 〇 良好 コスト戦略の考慮は継続して必要 dbt Explorer(dbt Catalog) ◎ リネージ表示◎ 十分 Slack通知 ◎ リアルタイム チーム連携に最適 ドキュメントの表示 ◎ アクセス管理 十分 Security（SSO、IP制限) ◎ 設定も容易 十分 

65 ✓ プロダクトチームへのエスカレーション ✓ 質問への迅速な回答 予期していなかった⼤きなメリット: サポート体制の素晴らしさ ✓ 英語だが丁寧な対応※ 結果: ● レスポンスが早い（→数⽇以内に回答） ● 詳細な技術情報の提供 （→データフローの詳細、 →内部実装の説明） ● 複数回の問い合わせ、すべて解決 ● コミュニケーションストレスなし ● ニュアンスが正確に伝わる ● 技術⽤語も正確 ● 技術的な深掘りに対応 ● エンジニアとの直接やり取り ● フィードバックが製品改善に反映 ✓ 検証期間中の不安を迅速に解消 ✓ 遅滞なく導⼊を進めれた ✓ トラブルシューティングが容易 これは⼤きな安⼼材料 （→ 本番運⽤でも安⼼） サポート対応の質: ※トライアル期間中のサポート対応は英語のみですが、本運⽤後は⽇本語で 対応していただけます。 

66 検証で得られた副次的効果 意外な副産物： 1. dbt platformへの 深い理解獲得 表⾯的な機能理解を超えて → 内部動作の理解 → アーキテクチャの把握 社内エキスパートの育成 → チーム内に詳しい⼈が増えた → サポートへの依存度低下 2. ドキュメント⽂化の醸成 検証結果が再利⽤可能な資産に → 社内ナレッジベース化 → 新メンバーのオンボーディング資料 ブログ公開で外部貢献も → コミュニティへの貢献 → 企業ブランディングにも効果あり？ 3. チーム全体の知識向上 分担検証でノウハウ共有 → 各⾃の専⾨領域を深掘り → 週次共有で知識が広がる データ基盤への理解深化 → dbt platformを通じて → データエンジニアリング全体の理解 検証⾃体が価値ある活動 → 時間をかける価値があった 

67 最終判断と導⼊決定 ノックアウトファクターなし 期待した機能は概ね満たす ⼀部制約はあるが運⽤で カバー可能 最終判断：導⼊を決定  2025年7⽉から本番導⼊開始 リネージ表⽰性能: 合格 使⽤感‧開発効率: 合格 データロケーション: 制約を理解 して運⽤ コスト: 費⽤対効果あり ⾮エンジニアの⾃律的な開発: ○ 運⽤の⾃動化‧効率: ◎ ドキュメント‧リネージの 可視化: ◎ データロケーション: CI機能の慎 重な評価 モノレポ: マルチレポ構成で対応 CI実⾏コスト: Draft PR、 state:modified活⽤ 

　 みなさんの検証に 活かすために 

69 検証で最も重要だった3つのこと 1. ⾒送り要因を 先に明確化 ノックアウトファクターの設定 検証の優先順位が明確に 主観を排除した判断基準 → 重要な項⽬から検証 → 時間の無駄を防ぐ → チーム内での合意形成 → 客観的な評価 「何があったら ⾒送るか」を 最初に決めておく 2. 体系的な アプローチ 4ステップのフレーム 複数⼈で分担可能 再現可能な検証 1. ⽬的を明確にする 2. ⼿順を明⽂化する 3. 期待される結果を設定する 4. 検証結果を記録し考察する → 統⼀フォーマットで混乱なし → 検証品質の均質化 → 他社でも使える → 後から⾒返せる フレームを作るこ とで品質を担保 3. 完全に理解したと 思い込まない 実際にデータを流して確認 ドキュメントを読み込んでも⾒落とす → 検証後に改めて俯瞰的に⾒直す 想定外の発⾒がある → チームでレビューし合う → ドキュメントだけでは不⼗分 → ログを詳細に確認 → データロケーションの確認 → リポジトリ構成の適合性 → CI実⾏コストの⾒積もり 必ず 実証検証を⾏う 

70 今⽇から始められるアクション 4フェーズのチェックリスト Phase 1 (今週中): ━━━━━━━━━━━━━ □ 導⼊⾒送り要因のリストアップ → 何があったら⾒送るか明⽂化 □ ステークホルダーへのヒアリング → エンジニアの要求 → ⾮エンジニアの要求 → マネージャーの期待値 □ 検証項⽬の洗い出し → 必須項⽬の特定 → Nice-to-have項⽬の整理 Phase 2 (来週): ━━━━━━━━━━━━━ □ 検証シナリオ‧⼿順の作成 → 4ステップフレーム適⽤ □ トライアル環境の申請 → dbt platformトライアル → 検証⽤DWH環境 □ チームメンバーへの役割分担 → 専⾨領域に応じた分担 Phase 3 (再来週から2週間): ━━━━━━━━━━━━━ □ 優先度順に検証実施 → ノックアウトファクターから □ 結果の記録と共有 → 統⼀フォーマットで記録 → 週次で進捗共有 □ 検証後の俯瞰的な⾒直し → ドキュメントを再読 → チームでレビュー Phase 4 (検証完了後): ━━━━━━━━━━━━━ □ 稟議資料の作成 → ビジネス価値の可視化 → コスト試算 □ 導⼊計画の策定 → マイグレーション計画 → トレーニング計画 □ 知⾒の共有 → 社内ドキュメント化 → ブログ公開検討 

71 【ポリシー準拠‧セキュリティ】 ━━━━━━━━━━━━━━━━━━━━━ □ データロケーション要件の確認 □ データレジデンシーポリシー □ 各機能のデータフロー検証 □ データ保存先の確認 □ ドキュメントの複数回読み直し □ 検証後の俯瞰的な⾒直し □ チーム内でのレビュー 【技術的制約】 ━━━━━━━━━━━━━━━━━━━━━ □ リポジトリ構成の決定 → モノレポ vs マルチレポ □ 同時開発者数とGit習熟度 □ CI/CD実⾏頻度とコスト影響 □ VSCode拡張の活⽤⽅針 検証チェックリスト 【パフォーマンス‧実⽤性】 ━━━━━━━━━━━━━━━━━━━━━ □ 実際の使⽤感での確認 → 著しく悪い点はないか □ 許容可能な使⽤感か □ DWHクエリ実⾏コストの把握 □ 実際のデータでの検証 【運⽤】 ━━━━━━━━━━━━━━━━━━━━━ □ 既存ワークフローとの統合 □ デプロイフローの設計 □ サポート体制の確認 □ ドキュメント整備計画 

72 検証結果の公開とコミュニティへの貢献 掲載内容: 15項⽬の詳細検証結果 → ⽬的、⼿順、結果、考察 設定ファイルのサンプル(⼀部) → dbt_project.yml → profiles.yml → CI/CD設定 トラブルシューティング事例 → 発⾒した問題と対処⽅法 スクリーンショット多数 → 実際の画⾯を多数掲載 考察とベストプラクティス → 運⽤上の推奨事項 https://developers.freee.co.jp/entry/dbt_cloud_verification ブログで全検証結果を公開中 皆さんの検証の参考になればと思います。ぜひご覧ください。 

73 最後に伝えたいこと リスクの 事前回避 スムーズ な本番 展開 ⾃信を 持った 導⼊決定 チームの 知識向上 体系的な検証が確実な導⼊への近道 

　 74 フリーではアナリティクスエンジニアとアナリストを募集中です！ 私たちといっしょに仕事をしませんか？ Thank you + Hiring 

スモールビジネスを、世界の主役に。