はじめに
先日、Google Cloud Next Tokyoにて、「Lookerで挑む！ふるさと納税サイト『ふるさとチョイス』のデータ活用改革」と題されたセッションを聴講しました。本記事では、このセッションで得られた知見を、私の学びを深めるためにブログ記事としてまとめてみたいと思います。
セッションの概要
このセッションの目標は、参加者が「Looker、うちでも使えるかも！」と感じることだったと述べられていました。セッションでは、データ活用における共通の「あるある」課題として、「この数値、どのデータが正しいのか？」「分析依頼したけど、いつ返ってくるのか？」「似たようなダッシュボードが大量にあって、どれを見ればいいか分からない…」といった点が挙げられていました。これらの課題に対し、Lookerがどのように解決策を提供するのかが示されました。
セッションの内容
このセッションでは、大手ふるさと納税サイト「ふるさとチョイス」を運営する企業が直面していたデータ活用に関する具体的な課題と、それらをLookerの導入によってどのように解決し、データ活用文化を改革したかが詳しく語られました。
ふるさとチョイスにおけるデータ活用の課題
まず、セッションでは企業がデータ活用において直面していた課題が4つ挙げられていました。
- アナリストへの依存とデータ抽出のスピード不足
- データ抽出にはアナリストしかSQLを使えず、スピード感に課題があったと説明されました。
- 「ふるさとチョイス事業部」の各チーム（Aチーム、Bチームなど）や「コーポレート部門」の広報など、全部門からのデータ抽出依頼がアナリストに集中しており、年間で600件以上の依頼が匿名で行われていたと示されました。
- 自由なデータ分析環境の欠如
- 全部門が自由にデータ分析できる環境がなかったと述べられました。
- 分析の切り口が、あらかじめ用意されたフィルターでしかできない状況だったと説明されていました。
- 指標定義の複雑さと乱立
- 指標の定義が複数存在し、管理が複雑だったと指摘されていました。
- 例えば、「ふるさとチョイス事業部」内で、Aチームは「条件Xに当てはまり、Yの値を除いた売上」を見たいと考えている一方で、Bチームは「条件Zに当てはまり、Yの値を含んだ売上」を見たいと考えており、その結果、社内に様々な「売上」がはびこっていたとのことでした。
- 類似ダッシュボードの乱立
- 似たようなダッシュボードが乱立しており、部署最適化はできても全体最適化は困難だったと説明されました。
- 具体的な例として、Aチームは「自治体ごとの申し込みベースの売上」、Bチームは「新規ユーザー✕自治体ごとの決済ベースの売上」、Cチームは「自治体ごとの月別売上」といったように、各チームが異なる目的で類似のダッシュボードを作成していた状況が示されました。
Lookerへの挑戦と移行の道のり
これらの課題を解決するために、Lookerの導入に至る経緯と移行の道のりが紹介されました。
- Looker導入の理由
- Lookerを選んだ理由は、その思想が直面していた課題に完璧にフィットしたからだと述べられました。
- Lookerは、BI機能も持つデータ活用プラットフォームであり、キーワードは「SSOT（Single Source of Truth）」であると強調されました。
- SSOTとは、指標や項目、定義を一元管理し、データの信頼性を担保する仕組みのことだと説明されました。
- Looker導入前は、各ユーザーが個別のデータを用いて分析を行っていたため、データの参照元が複数存在し、信頼性に課題があった状況が示されました。一方、Looker導入後は共通のデータマートを介してLookerが唯一の信頼できるデータソース（SSOT）となり、データの参照元が統一されることで信頼性が向上したと説明されました。
- PoC（概念実証）で見えた解決策
- LookerのPoC（概念実証）を実施した結果、課題が解決できると確信し、既存のBIツールからの移行を決定したと語られました。
- Lookerがもたらす解決策としては、以下の点が挙げられました。
- 「アナリストしかSQLでデータを抽出できず、スピード感に課題」という問題に対し、「汎用的な事業データを誰もが自由に活用できる」ようになったこと。
- 「あらゆるデータを各部署が自由にデータ分析する環境がない」「指標の定義が複数存在し、管理が複雑」という問題に対し、「統一されたデータ定義の元、正しい事業判断」が可能になったこと。
- 「似たようなダッシュボードが乱立」という問題に対し、「ダッシュボードの棚卸しと、Looker Studioとの併用」が進んだこと。
- Looker移行のタイムライン
- 具体的な移行スケジュールも示されました。2024年3月にLooker PoCを実施し、社内検討を経て本格導入を決定したとのことです。
- 2024年9月には既存ダッシュボードの棚卸しを行い、全社的な指標のダッシュボードはLookerへ、各部署で見るダッシュボードはLooker Studioへ移行を進めました。これにより、乱立していた200超のダッシュボードを3分の1に絞り込んだと説明されました。
- 2024年10月から11月にかけては、主要な指標や分析軸を洗い出し、定義を決定しました。
- そして、2024年11月から2025年3月にかけて、3名で5ヶ月かけて本格的な移行を実施したと語られました。
- Looker移行後のデータアーキテクチャ
- Looker移行後のデータアーキテクチャは、Google Cloud製品を中心に構築されていると紹介されました。
- 「ふるさとチョイス」のデータベースからのデータと、Google AnalyticsからのアクセスデータはCloud Storageに集約されます。
- データレイクはCloud Storage、データウェアハウスはBigQueryが利用されており、Dataformで分析用変換バッチ、Cloud Composerでデータロードバッチが実行されるとのことです。
- Lookerはデータモデル定義と事業部共通のレポートに用いられ、Looker Studioは部署ごとのデータ可視化に利用されていると説明されました。
- さらに、データ分析にはVertex AIが活用されていると示されました。
Looker移行で何が変わったか
Looker移行によって具体的に何が変わったのかが、以前のBIツールとの比較で示されました。
- 表示速度: 以前は2,000万件を超えるデータが動かなかったのに対し、Looker移行後は1億件を超えるデータも数秒で動くようになったと報告されました。
- データの信頼性: 以前は部署ベースのデータマートが乱立し、信頼性に課題があったものの、Looker導入後はSSOT（Single Source of Truth）により信頼できるデータが提供されるようになったとのことです。
- ビジュアライズ: 以前は集計データからの可視化が難しかったが、Looker移行後は一通りでき、ビジュアライズが容易になったと述べられました。
- 文化: 以前は集計データの依頼やダッシュボードの作成依頼に頼る文化だったが、Looker移行後は汎用データマートを用いて、セルフで抽出することが容易になったと強調されました。
その他にも、Lookerの利点として以下の点が挙げられました。
- LookerのデータをLooker Studioから参照できること。
- SSOTにより信頼できるデータかつ汎用的に使えるローデータが得られること。
- 各部署がSQLを書かずに自由に分析できるようになったこと。
- Looker APIを使ってLookerのメタデータをBigQueryに送れること。
- 常に最新の信頼できるデータ定義を一元管理でき、BigQuery内で自然言語でクエリを書くことにも活かせること。
今後の展望 Looker x Gemini
セッションの最後には、LookerとGeminiの連携による今後の展望が語られました。
- 自然言語での時系列集計と分析情報の提供が可能になるとのことです。
- 例として、「〇〇エリアは一貫して高い合計注文数を記録しており、20XX年12月にはピークを迎えています。これは、この地域の堅調な販売実績を示しています。」といった分析情報が自動で提供される様子が示されました。
- また、「△△エリアは、観測期間を通じて他の地域と比較して常に最も低い合計注文数を示しています。」といった分析も可能になるとのことでした。
- ディメンションごとの集計も、自然言語で行えるようになると述べられました。
- 「〇〇エリアは魚介類の注文数が最も高く、一方、△△エリアは肉の売上が上位を占めています。」や「〇〇エリアと□□エリアでは、米の注文数が同程度です。」といった具体的な分析例が示されました。
まとめ
このセッションを聴講して、Lookerが単なるBIツールではなく、データ活用文化そのものを変革するプラットフォームであるという点が非常に印象的でした。ふるさとチョイスの事例からは、データ活用に関する組織の様々な課題が、LookerのSSOT思想や柔軟な分析環境によってどのように解決されていくのかが具体的に理解できました。LookerとGeminiの連携による自然言語でのデータ分析の未来は非常に興味深く、データにアクセスできる人の幅がさらに広がり、より多くの人がデータに基づいた意思決定を行えるようになる可能性を感じました。
簡単30秒