こんにちは。データエンジニアの田頭( @tagasyksk )です。 ファインディのデータ基盤は、CTO室データソリューションチームが事業部横断で開発・運用を担っています。事業の拡大に伴ってプロダクト数が急増し、当初採用していたデータメッシュのアーキテクチャでは管理コストの増大やサイロ化といった課題が顕在化してきました。 本記事では、Google Cloudプロジェクトの統合や共通化と分権のバランス再設計など、データ基盤をプラットフォームへと進化させている途上の取り組みについてご紹介します。まだ道半ばではありますが、同様の課題に向き合っている方の参考になれば幸いです。 これまでのデータ基盤のあゆみ データメッシュの採用 責任分界点の設計 事業拡大で直面した課題 プロダクトの急増 Google Cloudプロジェクトの増殖 技術選定のサイロ化 プロジェクト間データ連携の複雑化 どう解決したか データメッシュの再解釈とプロジェクト統合 フェデレーテッド・ガバナンスの確立 dbtランタイムの共通化 Lookerによる事業部横断の指標管理 今後の展望 終わりに これまでのデータ基盤のあゆみ データメッシュの採用 ファインディのデータ基盤は、分散型のデータウェアハウスアーキテクチャであるデータメッシュを採用していました。 データメッシュは、各事業部がデータの所有権を持ち自律的にデータを管理するアーキテクチャです。ファインディでは次のような方針で運用してきました。 事業部ごとにGoogle Cloudプロジェクト及びBigQueryを分離 各事業部がそれぞれのデータを管理し、アクセス権を事業部単位で制御 事業部間のデータ共有にはBigQuery Sharingを利用 責任分界点の設計 データチームでは、レイヤーごとに責任分界点を定め、各チームが自律的にデータを活用できる体制を整えていました。データチームはソースデータの取り込みや共通のデータモデルを整備し、各事業部はその上に独自の分析用モデルを構築する形です。 データメッシュの運用については、過去に別の登壇でも発表しています。 事業拡大で直面した課題 プロダクトの急増 ファインディでは2026年に「生成AI時代の事業戦略2026」として、Findy InsightsやFindy AI+など4つの新規AI事業を同時に発表しました。 prtimes.jp これにより、当初の設計で前提としていた「プロダクト数がある程度限られている」状態が崩れ、いくつかの課題が表面化しました。 Google Cloudプロジェクトの増殖 当初の設計思想に則り、プロダクトごとにGoogle Cloudプロジェクトを分離していたため、プロダクトが増えるたびにプロジェクトも増え続ける構造になっていました。IAM、予算、リソースの管理がプロジェクトの数に比例して煩雑になり、新しいプロダクトが追加されるたびに同じようなインフラ構築作業が発生していました。 技術選定のサイロ化 データメッシュではデータに関わる技術選定も各事業部に委ねていたため、ツールや実行環境が事業部ごとにバラバラになっていました。データ変換にはdbtとDataformが混在し、BIもスプレッドシートとLooker Studioが併存、dbtの実行環境もDocker・GitHub Actions・ローカル実行と統一されていない状態でした。中央で統制しづらく、会社として共通のノウハウを蓄積しにくいことが課題になっていました。 プロジェクト間データ連携の複雑化 事業部横断でのデータ活用ニーズも増えてきました。各プロダクトのCRMに蓄積された顧客情報をBigQueryに集約した「共通企業マスタ」の構築や、MCPとAIエージェントを組み合わせたSlackからの横断検索など、プロダクトを跨いだデータ連携の取り組みが広がっています。 tech.findy.co.jp しかし、プロジェクトが分離された構成のままでは、プロダクトが増えるたびに連携先も倍々で増加し、管理が追いつかなくなることが見えていました。 どう解決したか データメッシュの再解釈とプロジェクト統合 方針転換の核となったのは、「データメッシュにおけるドメイン分離の単位をプロジェクトからデータセットに変える」という判断です。 Google Cloudプロジェクトを一つに統合し、BigQueryのデータセット単位でドメインを分離する構成に移行しました。これにより、プロジェクト管理のオーバーヘッドを大幅に削減しつつ、ドメインごとのデータの独立性は維持しています。 フェデレーテッド・ガバナンスの確立 フェデレーテッド・ガバナンスとは、全社共通で統制すべきルールと各事業部に委ねるルールを明確に分け、中央集権と分権を両立させるガバナンスモデルです。プロジェクト統合に伴い、このモデルに沿ってガバナンスの境界を整理しました。 IAM管理、Cloud DLP、BigQuery Policy Tagなどのセキュリティ・コンプライアンス領域は元々共通化していたものです。事業拡大を機に、CI検査項目、Formatter・Linter、dbtの実行環境(ランタイム)を新たに標準化しました。一方で、事業ドメイン、ビジネスイベント、データモデリングといったビジネスに近い領域は引き続き各事業部に委譲しています。 共通化すべきものと分権すべきものの線引きが明確になったことで、データチームと事業部チームの双方が迷いなく動けるようになりました。 dbtランタイムの共通化 バラバラだったdbtの実行環境をDockerに統一しました。共通のDockerイメージをArtifact Registryで管理し、各リポジトリはGitHub Reusable Workflowを通じて共通のワークフローを呼び出す形にしています。 jobs : dbt-build : uses : org/shared-workflows/.github/workflows/dbt.yml@main with : image_tag : "0.0.0" mount_path : "." dbt_args : "build --target prod" また、ローカル開発時の共通コマンドにはTaskfileのincludes機能を活用しています。各リポジトリは共通Taskfileを参照するだけで、lint、test、buildなどの操作を統一されたインターフェースで実行できます。 includes : common : taskfile : ./path/to/shared/Taskfile.yml tasks : lint : cmds : - task : common:lint test : cmds : - task : common:test 新しいプロダクトが追加された場合も、共通のワークフローとTaskfileを参照するだけでdbt環境が整うため、立ち上げのリードタイムが大きく下がりました。バージョンアップやdependabotへの対応も、事業部の数だけ必要だったものが共通イメージ1つの更新で済むようになっています。 Lookerによる事業部横断の指標管理 データ基盤のリアーキテクチャとあわせて、BIツールの見直しも行いました。これまで事業部ごとにスプレッドシートやLooker Studioで管理していた指標を、Lookerに集約しています。 Lookerのセマンティックレイヤーを活用することで、全社で共通のビジネスロジックを定義し、指標の一貫性を担保できるようになりました。一方で、指標の定義そのものは各事業部に委譲しています。実際に、全体のダッシュボードの68%がデータエンジニア以外のメンバーによって作成されており、中央に寄せつつも現場のデータ活用はむしろ活発になっています。Looker導入の詳細については次の記事で紹介しています。 tech.findy.co.jp 今後の展望 プラットフォーム化の取り組みはまだ道半ばです。今後は次の2つの方向で進化を続けていきます。 1つ目は、セルフサービスかつAI Readyなデータ基盤です。事業部のメンバーやAIが自らデータを探索・分析できる仕組みをさらに拡充し、データチームへの依存を減らしていきたいと考えています。 2つ目は、メタデータの整備です。今後事業やプロダクトが増えても低コストでデータを探し利用できるようにし、事業や組織間のシナジーをデータで生み出していくことがチームのミッションとして求められています。 終わりに 本記事では、データメッシュからプラットフォームへとデータ基盤を進化させた取り組みについて紹介しました。 事業の成長フェーズによって、最適なアーキテクチャは変わります。ファインディでは、データメッシュの考え方自体を捨てたわけではなく、「プロジェクト分離」から「データセット分離」へとドメイン境界の粒度を見直すことで、スケーラビリティと自律性のバランスを取り直しました。 データ基盤は一度作って終わりではなく、事業の成長に合わせて進化し続けるものです。今回紹介したリアーキテクチャもまだ道半ばで、セルフサービス化やメタデータ整備など取り組むべきテーマは山積みです。この記事が、同様の課題に向き合っている方の参考になれば嬉しいです。 ファインディではこのデータ基盤を一緒に育てていくメンバーを募集しています。少しでも興味が湧いた方はカジュアル面談お待ちしております！ herp.careers

こんにちは。ファインディでデータエンジニアをやっている 開（hiracky16） です。 ファインディでは事業の成長に伴い、スプレッドシートで管理していたKPIダッシュボードの複雑さが限界を迎えつつありました。この記事ではLookerを導入し、 derived_table→mart→dim/fact と段階的にデータモデリングを進化させてきた過程を紹介します。ファインディが大切にしているバリューの一つであるスピードを損なわずにガバナンスを整えていくノウハウとして、参考になれば幸いです。 ファインディにおけるKPIダッシュボードの重要性と複雑性 Looker導入の背景 段階的なデータモデリングの最適化 derived_tableからの出発 martレイヤーの導入 dim/factモデルへの移行 移行時のガードレール整備 データアナリストの自律化と利用状況の変化 まとめ ファインディにおけるKPIダッシュボードの重要性と複雑性 ファインディは主に4つの事業と8つのサービスを展開しています。事業ごとに追うべきKPIが異なるため、事業部内のメンバーはもちろん、複数チームや事業を横断して見る部長や役員にとっても、各事業の健康状態を把握できるダッシュボードの必要性が以前と比べて増しています。事業によって売上が発生するまでの経路やリードタイムが異なり、ユーザーや企業を独自のセグメントで切り分けて分析する必要もあります。こうした複雑さは事業が成長するごとに増していきます。 たとえばファインディの祖業である転職事業では、職種・経験年数・アクセス頻度などといった属性値をもとに多軸で分析を行っています。さらに、転職に至るまでにはスカウト・応募・面談といった複数のファネルが並行して進むため、単純な線形のファネル分析では実態を捉えきれない難しさがあります。 Looker導入の背景 こうした重要性や複雑性を踏まえつつ、既存のスプレッドシートとBigQuery構成でKPIを管理する方法にはいくつかの課題が生じていました。 まず、事業やチームごとにスプレッドシートが増え続け、それぞれが独自フォーマットで作られているため、チームを横断した利用ができない状態でした。期が変わるたびに指標が追加されていくと、今期追うべき指標の整理も難しくなります。さらに、スプレッドシートごとにセグメントの切り方や集計ロジックが異なり、同じ指標のはずなのに数値が一致しないといった問題も起きていました。加えて、データ量の増加に伴いスプレッドシートの表示速度が低下し、売上管理の集計結果表示で障害が発生するなど、安定性の面でも限界が見え始めていました。 こうした課題を解決するために、LookMLで指標定義をコード管理しGitHubでレビューできるLookerを導入しました。BigQueryとネイティブに連携できるためデータ量が増えても表示速度が安定すること、チーム内にLookerの経験者がいて立ち上げコストを抑えられること、そしてGoogleの担当の方による丁寧なPoCで運用イメージが具体化できたことが導入の決め手になりました。 段階的なデータモデリングの最適化 導入後、まずは主要なKPIがLookerに集まっている状態を目指しました。ただし、利用者がBIツールに求めているのはいち早く事業数値を確認することであり、指標の定義を統一したいというデータチーム側の課題意識とは温度差があります。スプレッドシートからの移行でスピード感を落とさないことを重視しつつ、段階的にデータモデリングを進化させていきました。 全体の流れを図にすると次のようになります。 derived_tableからの出発 最初のステップとして採用したのが、LookMLの derived_table です。 derived_table はSQLベースでビューを定義できるため、BigQueryのSQLに慣れ親しんだメンバーにとってはダッシュボードやLook構築までのリードタイムが最も短い方法でした。ファインディではデータ変換にDataform（プロジェクトによってはdbt）を使っていますが、LookMLとは別リポジトリで管理する必要があり、両方を行き来すると開発速度が落ちてしまいます。その点 derived_table であればLookMLリポジトリだけで完結するため、スプレッドシートからの移行初期にはこの手軽さが大きな武器になりました。 一方で、 derived_table はExploreが実行されるたびにBigQueryへクエリが走るため、データ量が増えるにつれて表示速度が遅くなり、クエリコストもかさむという課題が見えてきました。 たとえばDAU（Daily Active User）を集計するビューは次のようなイメージです。 view: daily_active_user { derived_table: { sql: WITH calendar AS ( ... ), page_view AS ( ... ), users AS ( ... ) SELECT calendar.report_date, users.user_job_segment, users.user_id FROM calendar LEFT OUTER JOIN page_view ON ... LEFT OUTER JOIN users ON ... ;;} dimension_group: report { ... } dimension: user_job_segment { ... } measure: dau { ... } } explore: daily_active_user {} martレイヤーの導入 derived_table の課題を解消するため、SQLのロジックをDataformへ移行し、事前に計算済みのmartテーブルとしてBigQuery上に実体化しました。LookML側は derived_table のSQL定義を削除し、 sql_table_name でmartテーブルを参照する形に書き換えます。Exploreからは計算済みのテーブルを読むだけになるため、表示速度とクエリコストの両方が改善されます。 先ほどのDAUの例をmartに移行すると、LookML側は次のようにシンプルになります。 view: daily_active_user { sql_table_name: `project.mart.daily_active_user` ;; dimension_group: report { ... } dimension: user_job_segment { ... } measure: dau { ... } } explore: daily_active_user {} derived_table のSQL定義がなくなり、 sql_table_name でmartテーブルを参照するだけになっています。ただし、martテーブルはスケジュール実行で更新するため、データの鮮度には注意が必要です。先ほどのDAUの例であれば日次の集計で十分なので、Dataformのスケジュール実行で一日一回テーブルを更新しています。 dim/factモデルへの移行 martテーブルが複数できあがってきたタイミングで、ディメンショナルモデリングへ進みます。ここで重要なのは、すでに動いているレポートが複数ある状態でモデリングを行うことです。実際のレポートから共通する軸を抽出できるため、机上の設計よりも実態に即したモデルを組み立てられます。 たとえば、先ほどのDAUレポートに加えて、コンバージョンを日次で追うレポートも職種セグメント別に組み立てられているとします。この場合、 user_job_segment は複数のレポートで共通して使われる適合ディメンション（Conformed Dimension）になります。日付軸も同様です。 こうした共通軸を整理していくと、ユーザーディメンション・カレンダーディメンション・ページビューファクトという形に分解できます。ディメンションとファクトに分けたことで、新しいレポートを追加する際も既存のディメンションを再利用でき、定義のばらつきを防げるようになりました。 分解後のLookMLは次のようになります。 # カレンダーディメンション view: dim_calendar { sql_table_name: `project.dim.calendar` ;; dimension_group: report { ... } } # ユーザーディメンション view: dim_user { sql_table_name: `project.dim.users` ;; # サロゲートキーを作成 dimension: user_key { ... } dimension: user_job_segment { ... } } # ページビューファクト view: fct_page_view { sql_table_name: `project.fct.fct_page_views` ;; dimension: user_key { ... } dimension: user_id { ... } dimension: access_date { ... } measure: dau { ... } } # コンバージョンファクト view: fct_conversion { sql_table_name: `project.fct.fct_conversions` ;; dimension: user_key { ... } dimension: conversion_date { ... } measure: conversions { ... } } # Explore でディメンションとファクトを結合 explore: fct_page_view { label: "ページビュー分析" join: dim_calendar { ... } join: dim_user { ... } } explore: fct_conversion { label: "コンバージョン分析" join: dim_calendar { ... } join: dim_user { ... } } fct_conversion のExploreでも dim_calendar と dim_user をそのまま再利用しています。ファクトテーブルが増えてもディメンションを使い回せるため、定義の重複が起きません。 移行時のガードレール整備 dim/factモデルへの移行ではBigQueryのテーブル構造とLookMLの両方に修正が入るため、意図せずダッシュボードが壊れるリスクがあります。ファインディではDataform上でのmartテーブルとdim/factテーブルの整合性テスト、LookerのCIによるLookMLバリデーション、そしてLooker APIを使ったExplore実行テストの3つをガードレールとして整備しました。 zenn.dev 特にDataformやLookMLはClaude Codeなどのコーディングエージェントを活用して開発する場面が増えており、こうしたガードレールがあることで開発速度を維持しながら安全に移行を進められています。 データアナリストの自律化と利用状況の変化 導入から1年弱が経った現在、全体のダッシュボードのうち68%がデータエンジニア以外のメンバーによって作成されたものになりました。データアナリストや事業部のメンバーがExploreを使って自らダッシュボードを組み立てられるようになり、「データを見たいときにデータチームへ依頼する」というボトルネックが解消されつつあります。 利用率も好調で、登録ユーザーの約7割が毎週ログインしてダッシュボードを確認しています。ただしLookerはライセンス費用がかかるため、現時点ではアカウントを発行できているのは一部のメンバーに限られています。今後はアカウント数を増やしつつ、SQLを触れないメンバーにもExploreを使って独自のコンテンツを作ってもらえるよう支援を広げていきたいと考えています。 こうした利用状況の把握にはLookerのSystem Activityを活用しています。System ActivityはLooker自体の利用データをそのままExploreとして扱えるため、誰がどのダッシュボードをどれくらい使っているかを日々モニタリングできます。Lookerは高機能な分コストもかかるからこそ、利用状況を定量的に可視化して成果をアピールし続けることが重要です。 まとめ derived_table→mart→dim/fact と段階を踏むことで、利用者のスピード感を損なわずにガバナンスを整えられました。ダッシュボードの68%がデータエンジニア以外のメンバーによる作成となり、データチームへの依頼ボトルネックの解消につながっています。 また整えた指標をチームや事業を越えて利用するシーンも増えてきた反面、モデリングの変更が広範囲に影響するようになりました。ガードレールの重要性は今後さらに増していくと感じています。LookMLで指標定義を整えてきた土台は、Lookerの会話分析のような生成AI機能の精度にも直結するため、モデリングの品質を高め続けることがデータ活用全体の鍵になると考えています。 ファインディでは絶賛データエンジニアを募集中です。 LookMLを使ったガバナンス強化やファインディの展開している事業領域におけるデータモデリングに興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに Lookerとは セルフサービスExploreとは 分析に利用するログデータ BigQuery INFORMATION_SCHEMA.JOBS_BY_PROJECT Looker System Activity BigQuery×Lookerログ連携構成 やってみよう BigQueryからログデータを抽出する Lookerへファイルをアップロードする Exploreで分析してみる System Activityと連携させる意義 クエリ統合を使う 注意点 おわりに はじめに はじめまして、入社1年目の井上です。 普段はGoogle Cloudを用いたデータ分析基盤の保守運用、生成AIも…