「あつまれ Lookerの森 #3」イベントレポート 〜4社のリアルな知見から学ぶ、データ活用の最前線〜

1. はじめに

株式会社 MBK デジタルの古畑です。

2025年6月27日（金）、Google渋谷ストリームオフィスにて、Google Cloudユーザー会「Jagu'e'r」主催の 「あつまれ Lookerの森 #3」 が開催されました。

オフラインでの開催ということもあり、会場はLookerを活用する多くのデータプロフェッショナルたちの熱気に包まれていました。
本記事では、マネーフォワード様、TimeTree様、Hacobu様、LegalOn Technologies様の4社から語られた、Looker活用のリアルな事例とノウハウを詳細にレポートします。

2. イベント内容

オープニング

イベントは主催者からの挨拶で幕を開け、アジェンダが紹介されました。
各社の事例紹介の後には質疑応答や懇親会も予定されており、参加者同士の交流も活発に行われることが期待される雰囲気でスタートしました。

① 株式会社マネーフォワード様『Looker、”単なるBIツール”としての認識を超えて 〜現場で発見した活用へのヒント〜』

トップバッターは、株式会社マネーフォワードの奥野様。
同社における5年間のLooker運用史を振り返り、多くの失敗から得られた貴重な学びを共有してくださいました。

Lookerは「BI + セマンティックレイヤー」

奥野様は、Lookerを導入した当初、他のBIツールと同様の「単なるBIツール」として捉えていたことが、後の多くの失敗につながったと語ります。
Lookerの本質は 「BI機能を持ったセマンティックレイヤー」 であり、このセマンティックレイヤー部分といかに向き合うかが活用の鍵であると強調しました。

3つの失敗談と対策

マネーフォワード様が直面した失敗は、主にセマンティックレイヤーの設計に起因するものだったそうです。

• 同じビジネスイベントを示すExploreの乱立

  • 課題: 「商談」という同じビジネスイベントを分析したいのに、複数の命名規則（例: TFA_23_shodan, sales_shodan）でExploreが作られてしまい、ユーザーがどれを使えば良いか混乱した。
  • 対策: ビジネスイベントとExploreを1対1の関係にするルールを策定。さらに、ドメインごとにLookMLの管理者を配置し、ルールが遵守される体制を構築。

• Lookerで"何でも"可視化しようとする

  • 課題: スポット的な可視化や複雑なデータ加工が必要な場合にまでLookerを使おうとすると、LookMLの改修コストが高く、リードタイムも長くなり、ユーザーの不満につながった。
  • 対策: Lookerの得意・不得意を見極める。定型的な分析や容易に追加できる指標はLookerで、スポット的な分析はLooker Studioなど他のツールに任せることで、うまく使い分ける。

• 指標の二重定義で数字が合わない

  • 課題: 利便性を考え、Lookerのメジャーとデータマート（BigQueryのテーブル）の両方で「月次商談数」などの指標を定義。しかし、仕様変更時に片方しか更新されず、双方の数字が乖離。信頼性が低下し、調査コストが発生した。
  • 対策: 指標は二重管理せず、可能な限りLookerに一元化して保持する。

奥野様は、これらの経験を通してセマンティックレイヤーの重要性を痛感したと締めくくり、Lookerと真摯に向き合うことの大切さを訴えました。

② 株式会社TimeTree様『データモデリングで、もっと使いやすい Looker』

続いて登壇されたのは、株式会社TimeTree様。
「データモデリング」をテーマに、Lookerのパフォーマンスと使いやすさを向上させるための具体的なアプローチを解説してくださいました。

キーワードは「計算は高くつき、ストレージは安い」

発表の核心となる考え方は 「Compute is expensive, Storage is cheap」。
現代のデータウェアハウスでは、都度発生する計算（特にJOIN）のコストは高く、データを保存しておくストレージのコストは比較的安いという事実に基づいています。

JOINのコストとデータモデリングの必要性

Lookerで分析軸を増やしてデータを深掘りする際、複数のテーブルをJOINすることは日常的に発生します。しかし、これはパフォーマンスのボトルネックになりがちです。

• 課題:

  • 巨大なテーブル同士をJOINすると、クエリの実行に時間がかかる。
  • Lookerのエクスプローラで属性を追加していくと、裏側ではJOINが多発し、特に最適化されていないJOINはユーザーの待ち時間を長くする。
  • 正規化されたデータモデル（トランザクション処理に最適化されたモデル）は、分析用途では複数回のJOINが必要になり、非効率。

• 解決策:

  • JOINの回数を減らすため、あらかじめJOIN済みの「中間テーブル」を作成する。ストレージは安いので、コストを抑えつつ計算時間を大幅に短縮できる。

ディメンショナルモデリングへの誘い

では、どのような中間テーブルを作ればよいのでしょうか。その答えが 「ディメンショナルモデリング」 というアプローチです。

• 考え方:

  • ファクト（Fact）を選ぶ: 分析したい中心的なビジネスイベント（例: 注文履歴）を「ファクトテーブル」として定義する。
  • ディメンション（Dimension）を突き止める: ファクトを分析するための軸（例: ユーザー情報、商品情報）を「ディメンションテーブル」としてまとめる。

• 効果:

  • このパターンに沿って中間テーブルを作ることで、開発者は「何を作るべきか」が明確になり、ユーザーは理解しやすく、パフォーマンスの良いExploreを利用できる。
  • Lookerのセマンティックレイヤーが物理的なテーブル構造の変更を吸収してくれるため、恐れずにモデリングを改善していける。

「ディメンショナルモデリングは奥が深いが、まずは自社のデータにとっての専門家である自分たちを信じて、間違ったらやり直すくらいの気持ちで始めてみることが重要」という力強いメッセージでセッションは締めくくられました。

③ 株式会社Hacobu様『「拠点横断アナリティクス」リリースまでの3ヶ月』

3番手は、株式会社Hacobuの立石様。
物流業界向けプロダクトの新機能「拠点横断アナリティクス」を、Lookerを使って3ヶ月という短期間でリリースした際の、リアルなプロジェクトの軌跡を語ってくださいました。

少数精鋭で挑んだ3ヶ月のプロジェクト

このプロジェクトは、PDM、エンジニア、CS（カスタマーサクセス）の3名という少数精鋭でスタート。
既存の社内用ダッシュボードをベースに顧客提供用の機能を開発するという計画でしたが、そこには数々の罠が待ち受けていました。

開発の裏で直面した3つの「罠」

• データ項目に対する認識のズレ

  • 課題: 例えば「稼働時間」という1つの言葉でも、「作業を開始してから終了するまで」「ドライバーが倉庫に到着してから退場するまで」など、関係者間で解釈が異なっていた。このズレが、期待値との乖離を生む原因となった。
  • 教訓: 言葉の定義を明確にすること。図などを用いて関係者間の認識を徹底的に合わせる時間が不可欠。

• 既存データマートのそのままの適用

  • 課題: 社内用ダッシュボードで使っていた複雑なデータマートをそのまま流用しようとした結果、顧客向けの要件（異なる集計軸など）に対応できず、拡張性に乏しいことが判明。パフォーマンスとコストの問題も浮上した。
  • 教訓: データマートは目的に合わせて再設計する。最終的に、従来のデータマートを破棄し、ディメンショナルモデリングに基づいて全面的にリプレイスすることを決断した。

• データスコープを時間軸だけで捉えていた

  • 課題: 「6月2日から3日までのデータを抽出」という単純な要望でも、その期間の基準が「記録日」なのか「予約日」なのかで、抽出されるデータが全く異なってしまう。
  • 教訓: データのスコープを定義する軸（どの時間軸で切るか）を明確に意識する必要がある。

立石様は、「苦労のほとんどはデータ（モデル）に関するものだった」と振り返りつつも、「Lookerのおかげで少人数・短期間でのリリースが実現できた」と、その価値を語りました。

④ 株式会社LegalOn Technologies様『そのLooker構成、世界で戦える？～グローバル展開のための設計術～』

最後のセッションは、株式会社LegalOn Technologiesの菅野様。
日本向けに作られたLooker構成を、グローバル展開に対応させるための高度な設計術についてお話しいただきました。

課題：肥大化とグローバル対応
同社では、プロダクト単位でLookerのプロジェクトを分割していましたが、それでもファイル数が増え、バリデーションに時間がかかるなど開発効率に課題がありました。さらに、サービスのグローバル展開に伴い、リージョンごとに異なるデータソースをどう効率的に扱うかという新たな課題が生まれました。

解決策：プロジェクト分割と動的な参照切り替え
この複雑な課題に対し、2つのテクニックを駆使して解決を図りました。

• Lookerプロジェクトの戦略的な分割

  • 開発効率向上のため、1つのLookerプロジェクトを 「インポート用」と「エクスプローラー用」 に分割。テーブル定義の変更がエクスプローラー側の定義に影響を与えにくくし、バリデーション時間を短縮した。

• local_dependencyによる動的なデータソース切り替え

  • 前提:
    • グローバルで共通のサービスは、リージョン（JP/US）ごとにBigQueryのプロジェクト/データセットが分かれているが、テーブル名と構成は同じ。
  • 仕組み:
    • インポート用プロジェクトのビューファイルでは、テーブル参照時にプロジェクト名やデータセット名を記述しない。
    • エクスプローラー用プロジェクトのモデルファイルで、リージョンごと（JP用/US用）に異なるBigQueryを指すconnectionを定義する。
    • manifest.lkml ファイルで local_dependency を使うと、インポート用プロジェクトのconnectionを、親であるエクスプローラー用プロジェクトのconnectionで上書きできる。
  • 効果:
    • JP用のダッシュボードを見ればJPのデータソースを、US用を見ればUSのデータソースを、単一のインポート用プロジェクトで動的に参照できるようになった。
    • 結果として、リージョンごとにインポート用プロジェクトを作成する必要がなくなり、Lookerプロジェクトの乱立を防ぎ、運用コストを大幅に削減できた。

菅野様は、この設計が実現できたのは、「グローバルサービスではテーブル構成を同じにする」という全社的な意思決定があったからだと述べ、技術だけでなく組織的なルール作りの重要性も示唆しました。

質疑応答ハイライト

Q. LookMLを書けるメンバーをどうやって育成しているか？

TimeTree様:
自作のチュートリアルを提供しているが、なかなか広げるのは難しいと感じている。

Hacobu様:
LookMLの書き方だけでなく、元となるデータモデルの理解もセットで必要。両方を理解できる人を育てていくことが重要。

マネーフォワード様:
Lookerの学習を「BIツールとしての使い方」と「セマンティックレイヤーの構築」に分けて考えるのが良い。
まずはExploreでデータを探索するところから始め、慣れてからLookMLを学ぶというステップが効果的。

まとめ

今回の『Lookerの森』では、4社4様の具体的な課題と、それを乗り越えるための実践的な知見が数多く共有されました。
特に、多くのセッションで共通して語られたのは、「セマンティックレイヤー」と「データモデリング」 の重要性です。

Lookerを単なる可視化ツールとしてではなく、ビジネスの共通言語を定義し、データ活用の基盤となるセマンティックレイヤーを構築するツールとして捉え直すこと。
そして、その基盤となるデータマートを、分析目的に合わせていかに適切にモデリングするか。
この2点が、Looker活用の成否を分ける大きなポイントであることが改めて浮き彫りになりました。

登壇者の皆様、そして主催のJagu'e'r運営の皆様、素晴らしいセッションをありがとうございました！