freee流 マルチプロダクト×⾼信頼なデータモデリングと品質保証の実践 マルチプロダクトでのデータ活⽤推進の課題とdbt Cloudの導⼊ Data Engineering Summit 

　 2 ⼩越広⾂ プロフィール ● 1.5年前までWebエンジニア ● フリー株式会社中部拠点所属 ● 岐⾩県下呂市出⾝ ⽇々のお仕事 ● 分析に必要なデータを収集するシステムやインフ ラの開発‧運⽤ マイブーム ● ポータブルオーディオ ● お酒 アナリティクスエンジニア Hiroomi Okoshi 

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

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

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

　 6 本資料では弊社におけるマルチプロダクト戦略をとる当社ならではのデータ活⽤の推進に関する課題と、課題解決の ために選択したdbt Cloudの技術選定の検証プロセス、スタースキーマでモデリングしたデータの提供⽅法についてご 紹介いたします。 特にdbt Cloudの技術選定の検証プロセスは社内で⾼い評価を得たため、その進め⽅、判断基準、およびそこから得ら れた知⾒を整理いたしました。dbt Cloudの導⼊を検討されている⽅、あるいはSaaSの評価‧検証に携わる⽅々にとっ て、本資料がご参考になれば幸いです。 はじめに 

　 freeeのデータ活⽤推進の 課題 

8 ● 当社は、フリーのマルチプロダクト戦略を推進しており、多様なプロダクト施策をデータ活⽤で⽀えている。 ● ⻑年運⽤されているプロダクトに加え、M&Aによって加わった企業のプロダクトも含まれるため、様々な環境で データ活⽤のニーズが存在する。 ● 各プロダクト環境のデータを相互に参照するニーズがある。 フリーのマルチプロダクト戦略におけるデータ活⽤の推進 データ 集計 参照 

9 データ活⽤を推進するにあたり、現状を把握したところ、以下の課題が明らかになった。 ● サイロ化: ○ 各プロダクトが独⾃の⽅法でデータを連携しており、⾮効率な「⾞輪の再発明」が散⾒される。 ● DWHの不⾜: ○ プロダクトが活⽤可能な状態にあるデータが不⾜している。 これらを解決する環境を⽤意する必要がある。 データの活⽤の推進にあたっての課題 

10 以下のような要因が当時の課題を引き起こしていると考えられた。 ● 既存データの有無が不明確 ● 膨⼤なデータソースから成るSQLの複雑化による集計テーブル変更の困難さ ● 他プロダクトのデータスキーマ調査に時間を要し、プロダクトで活⽤可能なデータ集計まで進まない ● データ集計環境構築の⼈材リソース不⾜ また、dbt Coreを使って構築した既存の集計環境におけるライブラリアップデートなどの保守が、今後のボトルネッ クとなることが予想された。 要因の分析 既存のSQLやdbt Coreといったツールを活⽤できるdbt Cloudを全社的なモデリング環境に採⽤することで、データ集 計環境の統⼀とデータモデリング環境の容易な構築を実現し、課題を解決できると考えた。 

　 課題解決に向けた dbt Cloudの可能性と 全機能検証の背景 

12 ● dbt Core資産の活⽤：既存資産を活かし、モダンデータスタックへのスムーズな移⾏と最新プラクティスの迅速な 導⼊を実現。 ● GUIによる統合開発環境：dbt CloudのGUIはSQLのみでデータ変換を可能にし、モデルの依存関係可視化や迅速な エラー対応を実現。エンジニア不要でデータアナリストが迅速にデータを作成。 ● 統⼀されたツールと標準化：全社でdbt Cloudを統⼀利⽤することで、重複するデータ作成を防ぎ、分析軸の定義を 容易に。データ品質と⼀貫性が向上し、データに基づいた意思決定を促進。 ● マネージドサービス：クラウドベースのdbt Cloudは、環境整備、バージョンアップ、サーバー保守が不要。迅速な 分析データ作成を可能にし、エンジニアの⼯数を⼤幅に削減。 dbt Cloudに期待すること 

13 ● dbt Cloudを導⼊する際は、ドキュメントを正確に理解し、ガバナンスの効いた運⽤体制を構築し、適切な契約プ ランを選定することが重要。 ● 当社のデータ活⽤の要求に基づいて必要な要件を整理していくと、結果的にほぼすべての機能を網羅的に検証する 必要があった。 ● 全機能の検証といっても、詳細な機能まで検証するわけではないため、dbt Labs社が公開しているThe dbt platform features (※) に記載されている機能の粒度で、使⽤感やパフォーマンスを記録しながら検証を進めた。 ○ 当時β版として提供されていたものに関しても使えるなら使いたいと考えて検証している。 dbt Cloud導⼊における考慮事項 ※ https://docs.getdbt.com/docs/cloud/about-cloud/dbt-cloud-features 

　 dbt Cloud 主要機能の検証 と評価の仕⽅の紹介 

15 この検証はdbt Cloudを採⽤して問題ないかを確認するもの。そのために予め採⽤を⾒送る要因を考えておく。 以下が、今回当社が導⼊を⾒送る可能性がある要因として挙げたもの。 ● リネージの表⽰パフォーマンスが遅く、dbt Coreでの運⽤が効率的と判断される場合。 ● 当社のSaaSセキュリティ基準を満たさない場合。 ● dbt Cloud CLIやIDEの表⽰パフォーマンスが悪く、dbt CoreとVisual Studio Codeでの開発が効率的と判断される 場合（検証後の議論が必要）。 ⾒送り要因の整理 

16 ● 各機能の検証⽬的を明確にする。ドキュメントを参考に、どう使⽤したいかという意思を交える必要があり、ド キュメント通りの動作確認だけでは意味がない。 ● 例: ○ dbt Cloud CLIの検証⽬的は、「dbt Cloud CLIの基本的な操作性と、dbt Coreとの使⽤感の違いを検証する。」 ○ Enable Continuous Integrationの検証⽬的は、「dbt Cloudの継続的インテグレーション機能が正常に動作し、 コードの変更が⾃動的にテストされ、デプロイ前の品質保証が適切に⾏われることを確認する。特に、変更前 後の差分確認機能が期待通りに機能し、意図しない変更が本番環境に影響を与えないことを検証する。」 要求と利⽤シナリオを明確にする 

17 ● 検証前の段階: ドキュメントを参考に実現⼿順を明確化し、実現可能性を判断した上で記⼊完了。 ● 検証中の記録: ○ 実際の⼿順や⼊⼒を詳細に記録し、スクリーンショットを検証ドキュメントに添付。 ○ dbt Cloudの頻繁な更新に対応するため、過去の操作と現在の状態の変化を把握。 ○ サポートへの問い合わせをスムーズにし、記憶への依存を排除。 ● 記録の重要性: ○ ⾮常に⼿間がかかるが、検証後の議論における根拠構築に⼤きく貢献。 ○ APIトークンなどの機密情報を含む場合は、スクリーンショットのマスクなどの配慮が必要。 ⼿順を明確にする 

18 期待される結果は、機能によって主に以下の観点でどれか⼀つ、あるいは複数を組み合わせて設定している。 ● 機能の正確な動作: 各機能が意図した通りに、エラーなく正しく動作すること。 ● パフォーマンス: 処理速度や応答時間など、システムが効率的に動作し、ユーザーがストレスなく利⽤できること。 ● 使いやすさ‧操作性: ユーザーが直感的に操作でき、既存のワークフローからの移⾏がスムーズであるかなど、ユー ザーエクスペリエンスを考慮。 ● ⾃動化と効率化: ⼿作業を削減し、プロセスを⾃動化することで、開発や運⽤が効率的に進められること。 ● 品質保証とリスク管理: 意図しない変更による問題を防ぎ、システムの品質を維持すること。 これらの基準は、単に機能が利⽤可能であるかだけでなく、実際のビジネス運⽤においてどれだけ効果的で、安全 で、効率的であるかを評価する意図がある。 期待される結果を設定する 

19 ● 全体評価の焦点: ユーザー視点での使いやすさやワークフローへの適合性を重視した「使⽤感」と、技術的な処理 速度や効率性を重視した「パフォーマンス」に焦点を当てて記述。 ● 機能検証結果の記述: 単なる合否だけでなく、使⽤を通じて得られた知⾒や応⽤アイデアも詳細に記述。 ● パフォーマンス評価基準: 具体的な時間基準は設けず、作業に⽀障のないレベルであれば「問題ないレベル」と評 価。 ● 外部SaaS連携項⽬: 「BigQueryの性能に依存するため問題なし」といった形で評価。 ● 内部メカニズムの考察: 公式ドキュメントには明記されていないが、使⽤経験から推測される内部メカニズムにつ いても考察。 検証結果を記⼊する 

20 検証結果の⼀部の紹介 (全170⾴) こちらでも公開中 https://developers.freee.co.jp/entry/dbt_cloud_verification 

　 モデリング 

22 dbt Cloudの導⼊検証が完了し、本番環境への導⼊が実現した。 導⼊後間もない期間ではあるが、データモデリング環境の整備にかかる時間は⼤幅に削減された。 しかし、dbt Cloudの導⼊では実現できなかったこととして、データ活⽤におけるプラクティスの不⾜という課題の解 決も必要であった。 ● 従来のワイドテーブル形式のモデルはデータ活⽤の視点では扱いにくい課題がある ● プロダクト側の要求に対して迅速な意思決定を⽀援するモデリング⼿法が不可⽋であると認識 ● アジャイルデータモデリング(ISBN:9784065330784)の思想を取り⼊れ、スタースキーマの採⽤を決定 スタースキーマの採⽤ 

23 ● 設計の曖昧さ ● 複数⼈による同様のモデリングでの定義の不統⼀ ● 粒度の定義の不統⼀ ● 考え⽅の属⼈化 ● メトリクスとディメンション参照キーの混在 従来のモデリングの課題 

24 スタースキーマの考え⽅として「何を使って」「何を知りたいのか」を直感的に理解し、迷わず正確にデータを分析で きるようにする⼯夫 ● SQLコメントで「ディメンション参照キー」と「メトリクス」を区別し、スタースキーマの意図を実装レベルで明 確化。 ● ドキュメントに結合例を提⽰し、ディメンションとファクトの関係を理解しやすくする。 「個⼈の職⼈技」に頼るのではなく、「誰でも理解し、安⼼して使える共有資産」にするための仕組みづくり ● 命名規則、主キー制約、外部キー参照、粒度の明確化の4つの柱で属⼈化を防⽌。 ● 履歴管理のため、DWHのgitリポジトリにMarkdownでドキュメントを格納。 ● 開発プロセスにドキュメント整備を組み込み、仕様のずれを防⽌。 ● ドキュメントとSQLの仕様の⼀致性をAIで確認しやすくし、ドキュメントの正確性を維持。 モデリングする上で意識しているプラクティス 

　 新たな課題 

26 ● データデリバリー⽅法に課題が浮上。 ○ スタースキーマでの設計により、利⽤者にデータを提供する際、スキーマが露呈。その結果、データ集計側の都 合による変更が困難になった。 ○ データコントラクトによる合意はあるものの、社内のアジリティの維持のためには細⼼の注意が必要。 ● データのデリバリーにはサービングするためのレイヤーを設け、インターフェースを定義することでプロダクト側 からのデータ利⽤を容易にしていきたいと考えている。 新たに発⽣した課題と今後の展望 

　 まとめと今後の展望 

28 ● マルチプロダクト環境で、統⼀されたモデリング環境構築のためdbt Cloudを導⼊した。 ● dbt Cloud導⼊により、エンジニアの負担軽減とデータモデリング環境の改善を実現。 ● ⼊念な検証の結果、dbt Cloudはマルチプロダクト環境におけるデータ統合と効率的な運⽤に有効であることを確 認。 ● データの品質と⼀貫性が向上し、データに基づいた意思決定を促進できるようになった。 ● 今後はデータデリバリーの課題解決と利⽤者拡⼤を⽬指し、アジリティの維持を⽬指す。 まとめ 

　 29 dbt Cloudの検証に関しては、「dbt年次イベント Coalesce on the road Tokyo」でもお話させていただきます。よろ しければこちらもご参加ください。 お知らせ 

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