Lookerの「応用的な利用方法」が運用を複雑にしてしまった
その頃、クラシコムでは受注データや会員データなどのデータはAWS上に置き、行動ログはGoogle Analytics 4で取得してFirebase Analyticsに蓄積していた。顧客対応データはZendeskに貯まっていて、予算データなどの一部のデータはスプレッドシートに保存していた。このように分散したデータはtroccoを使ってBigQueryに統合していた。そして統合したデータをLookerで加工集計して、ダッシュボードを作っていたそうだ。
ここで、クラシコムではLookerのフォーラムに投稿されているテクニックを使用して、データマートを作成していた。クラシコムも非常に便利に使っていたと高尾氏は語る。Lookerは本来BIツールだが、応用的に利用して集計ツールとしても使っていたということだ。
しかしクラシコムもLookerを便利に使いすぎて、運用が複雑になっているとも感じていた。そこで、風音屋の横山氏にシステムを見てもらったところ、Lookerのディレクトリ構成やカラムの生成ロジックなどについて問題点を指摘された。ここで高尾氏は問題を正確に把握することができた。
実は高尾氏は、横山氏に相談する以前からデータ分析のユーザーとしても、システムに問題があると感じていた。すでに、複数のデータマートを参照してデータマートを生成するとき、データ連携のタイミングがずれると生成に失敗するという問題を把握していた。さらに、その時点のシステムが分かりにくい構造になっており、設計者でなければ修正が難しいものになっていることも感じていた。
そこで、Lookerで加工集計をしていたところを、troccoのdbt連携機能（dbt on trocco）に加工集計機能を移すことを決めた。そのプロジェクトに参加したのがこのセッションに登壇している4名だ。プロジェクトは2023年夏ごろに完了を目指しているがすでに効果は出始めており、利用頻度の高いテーブルをdbtに移行させたことでデータマート生成が失敗することが少なくなってきた。
