Zenn
🌳

Jagu'e'r データ利活用分科会 「あつまれ Lookerの森 #3」

に公開
Looker
idea

この記事のポイント

  • Lookerは「BI + セマンティックレイヤー」: Lookerを単なるBIツールとしてではなく、データガバナンスの中核を担うセマンティックレイヤーとして捉えることが大切
  • データモデリングの重要性: 特にディメンショナルモデリングのアプローチは、パフォーマンスとメンテナンス性に優れたLooker環境を構築する上で非常に有効
  • 定義の明確化と合意形成: 「稼働時間」といった一見単純な指標でも、関係者間で定義が異なると混乱を招きます。図を用いるなどして、認識を丁寧に合わせることが不可欠
  • アーキテクチャの工夫: 開発効率やグローバル展開など、自社の課題に応じてLookerのプロジェクト構成を工夫することで運用コストを大幅に削減

はじめに

先日開催されたLookerのユーザーイベントでは、Lookerを活用する企業4社から、日々の運用における実践的な知見や学びが共有されました。本記事では、その発表内容を基に、Looker運用の成功の鍵と、よくある失敗を回避するためのヒントを解説します。

イベント概要

本イベントでは、以下の4社がそれぞれの取り組みについて発表しました。

敬称略、発表順

  • 株式会社 マネーフォワード: Looker、”単なるBIツール”としての認識を超えて 〜現場で発見した活用へのヒント〜
  • 株式会社 TimeTree: データモデリングで、もっと使いやすい Looker
  • 株式会社 Hacobu : 拠点横断アナリティクス」リリースまでの3ヶ月
  • 株式会社 LegalOn Technologies: そのLooker構成、世界で戦える？～グローバル展開のための設計術～

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

マネーフォワード社では、約5年前からLookerを導入していますが、その道のりは順風満帆ではなかったといいます。
発表では、Lookerを単なるBIツールではなく「BI + セマンティックレイヤー」と捉えることの重要性と、セマンティックレイヤーの設計に起因した3つの具体的な失敗談が共有されました。

失敗談1：同じビジネスイベントを示すExploreの乱立
「商談」のような同じビジネスイベントを指すExploreが複数作られてしまい、ユーザーがどれを使えば良いか分からなくなる事態が発生しました。
対策: ビジネスイベントとExploreを1対1の関係になるようルール化し、ドメインごとに管理者を置いてそのルールが守られる体制を構築しました。

失敗談2：Lookerで何でも可視化しようとする
スポット的な可視化など、Lookerが得意としない用途で無理に使おうとすると、LookMLの改修コストが見合わなくなるケースがありました。
対策: Lookerが得意なこと（指標管理など）に集中させ、スポット的な可視化はLooker Studioなど他のツールに任せることで、うまく役割分担をしています。

失敗談3：指標の二重定義で数字が合わない
利便性を考え、Lookerとデータマート（BigQuery）の両方で同じ指標を定義したところ、片方の定義しか更新されず、数字が合わなくなる問題が発生しました。
対策: 信頼性を担保するため、指標の定義は可能な限りLooker側に集約する方針としました。

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

タイムツリー社からは、Looker導入から約1年の経験を基に、データモデリングによってLookerをより使いやすくするためのアプローチが紹介されました。キーワードは「計算は高くつき、ストレージは安い」です。

JOINを減らすための非正規化
クエリパフォーマンスのボトルネックになりがちなJOIN処理を減らすため、あらかじめJOINした結果を中間テーブルとして保持する「非正規化」が有効です。ストレージコストが安価になった現代では、非常に現実的な選択肢となります。

ディメンショナルモデリングのアプローチ
無秩序に中間テーブルを作るとメンテナンスが困難になるため、「ディメンショナルモデリング」という一貫した設計アプローチが役立ちます。
ビジネスイベント（ファクト）を特定する: 「注文」「契約」など、分析の中心となる関心事を定めます。
分析の切り口（ディメンション）を特定する: 「いつ」「誰が」「何を」といった、イベントを分析するための属性情報を整理します。
このアプローチにより、複雑な分析ニーズにも対応しやすく、開発者にとっても見通しの良い構成を維持できると述べられました。

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

Hacobu社は、物流業界向けのプラットフォーム「Hacobu MOVO」の一機能として、Lookerの埋め込み機能を活用した顧客向け分析ツール「拠点横断アナリティクス」をリリースしました。既存の社内用ダッシュボードを基に、3ヶ月という短期間で開発した際の苦労と学びが共有されました。

苦労した点1：データ項目に対する認識のズレ
「稼働時間」という一つの単語でも、どの時点からどの時点までを指すのか、関係者間での解釈が異なっていました。このような認識のズレは、期待値のズレに直結するため、図を描くなどして丁寧に定義を明確化し、合意形成に時間をかけたそうです。

苦労した点2：データマートの目的外利用
当初、社内向けに最適化された複雑なデータマートをそのまま顧客向け機能に流用しようとしましたが、拡張性の問題に直面しました。最終的には、ディメンショナルモデリングに基づいてデータマートをフルリプレイスする決断を下しました。

苦労した点3：データスコープの捉え方
「特定の期間のデータ」を抽出する際も、どのタイムスタンプ（例：予約日時、作業完了日時）を基準にするかで結果が大きく変わる問題がありました。時間軸の定義を明確にすることが重要だと述べられました。

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

リーガルオンテクノロジーズ社ではサービスのグローバル展開に伴い、日本国内向けに構築したLooker環境を、いかに効率よく多言語・多リージョンに対応させるかという課題に取り組みました。

課題：開発効率と運用コスト

プロジェクト内のファイル数が増えることによるバリデーション時間の増大や、リージョンごとにプロジェクトを単純にコピーしていくことによる運用コストの肥大化が懸念されていました。

解決策1：Lookerプロジェクトの分割
テーブル定義をインポートするだけのプロジェクトと、Exploreなどを定義するプロジェクトに分割。これにより、バリデーション時間を30秒から3〜4秒へと大幅に短縮し、開発効率を向上させました。

解決策2：local_dependencyによる参照元の動的切り替え
local_dependencyという仕組みを利用し、Explore側のプロジェクトで設定されたデータソース接続情報（Connection）で、インポート側の接続情報を上書きできるようにしました。これにより、グローバルでテーブル構成が共通なサービスについては、インポート用プロジェクトを一つに集約でき、リージョンごとにプロジェクトを増やす必要がなくなり、運用コストを削減できました。

まとめ

今回の4社の発表からは、Lookerを効果的に活用するための共通したテーマが見えてきました。
それは、Lookerを単なる「点を描画するツール」ではなく、データ活用の土台となる「セマンティックレイヤー」として捉え、その設計にこそ注力することの重要性です。

本イベントで語られた内容を簡単にまとめると次のようになります。

  • データモデリングを制する者がLookerを制す
  • 言葉の定義を疎かにしない
  • Lookerのアーキテクチャを深く知る

これらの知見は、Lookerの導入を検討している企業からすでに運用で悩んでいる企業まですべてのLookerユーザーにとって価値ある指針となります。

データモデリングを制する者がLookerを制す

パフォーマンスやメンテナンス性を考慮したデータマート、中間テーブルの設計がユーザーにとっての使いやすさに直結します。

言葉の定義を疎かにしない

ビジネスサイドと開発サイドが協力し、指標や用語の定義を明確にし、認識を合わせるプロセスが、手戻りや信頼性の低下を防ぎます。

Lookerのアーキテクチャを深く知る

プロジェクト分割や依存関係の定義など、Lookerが持つ機能を理解し活用することで、開発効率や運用コストといった課題を解決できます。

Discussion