こんにちは、ダイニーのデータチームでソフトウェアエンジニアをしている かわみつ です。
本記事では、複数のデータソースを組み合わせたPoC(Proof of Concept)を高速に構築するための手法として、Looker StudioとDataformを活用した事例をご紹介します。
1. なぜ分析プロダクトのPoC開発が必要なのか
データを可視化・分析して業務を改善したいというニーズは、社内外を問わず常に寄せられます。特に、
- 「複数の指標の相関性があるかを見たい」
- e.g. 日々の売り上げと、アンケートの清潔感のスコアの相関性があるか
- 「ユーザーが入力する新規のデータと自社のサービスデータを掛け合わせて分析したい」
- 「使用している複数のシステム上のデータを照らし合わせて分析を行いたい」
- e.g. POSシステム上で管理している売上データと、勤怠システム上で管理している人件費データを使って生産性の分析を行いたい
といったように多種多様なデータを素早く連携して可視化、分析したい場面は多いと思います。
しかし、実際に利用者の分析のニーズを理解しプロダクトに落とし込むまでには、データ基盤の定義やビジュアライゼーションの実装含めかなり時間がかかってしまいます。
そのため、顧客の分析のニーズを学習しながら検証するためにも分析プロダクトのPoC開発はビジネスの観点からも重要です。
例えば、加盟店（飲食店）の店長や経理担当者が求めるデータは、まだ一般的な形式として定まっていない場合も少なくありません。そのため、顧客と対話を重ねながら、必要なデータを定義していくことが重要です。また、日々の業務に役立つ形でデータを提示する必要があるため、集計やビジュアライゼーションについても柔軟に対応できる体制が求められます。
ダイニーは飲食店のプロダクトをすべて自社で開発する All in One Platform 戦略を採っているため、そこから生まれる飲食にまつわるあらゆる一次データが日々蓄積されています。例えば、POSのデータと勤怠のデータを掛け合わせてデータを可視化、分析したいなどの要望も増えています。
そういった要望に応えていきながら、製品化するまでの顧客の分析ニーズの学習を進めるために Looker Studio, Dataform, BigQueryやその他Googleエコシステムで完結するPoCの開発を行っています。
画像は実際に開発した分析プロダクトPoCの一例です。(データは仮の数値です)
2. PoCに最適なLooker Studioのメリット
2-1. 高速なBI構築
Looker Studioは、Googleアカウントがあればすぐにレポートを作成できる手軽さが魅力です。権限管理も比較的シンプルなため、PoC（概念実証）をスムーズに進めやすいのも大きなメリットです。
- ダッシュボードやチャートのテンプレートが豊富
- UIが直感的
- ほぼノーコードでフィルタや計算フィールドを追加できる
- データソースのアーキテクチャに依存しないクエリの記述
これらのポイントが、PoCのスピードアップに大きく貢献します。
ダイニーでは複数のプロダクトドメインによるDBがありますが、それらの構造に依存せずデータをそれぞれ柔軟に取得できるところも重宝している点の一つです。
2-2. Google FormやGoogle スプレッドシートとの連携
PoCでは、「まだデータベースに存在しない情報」 を取り込みたいケースも少なくありません。
たとえば、
- ユーザーに簡単なアンケートを取りたい → Googleフォームで実施
- 新しく手に入れたCSVデータを調整したい → Googleスプレッドシートにアップロード
といった形で、手軽にデータを集めて可視化まで持っていきたい場面があります。
Looker Studioなら、Googleフォームやスプレッドシートなど、同じGoogle Workspace内のツールと連携してデータを直接取得できるため、
「試しに入力 → 即ダッシュボードで可視化」 といった一連の流れをスムーズに実現できます。
3. DataformでELTパイプラインを構築
3-1. データプラットフォーム構築からPoCまで同じ手法が使える
ダイニーでは、全社的なデータプラットフォーム構築にDataformを活用しており、PoCの開発でも同じフローを利用しています。
なぜDataformを使っているかについてですが、ダイニーではFull TypeScriptで全てのプロダクトの開発を行っており、DataformはTypeScript製ということもあり技術スタックの面で親和性が高いこともありData Transformation Toolとして採用しています。
- PoCで実装したデータマートの定義スクリプトをProduction環境でもある程度流用が可能
- 後々の運用まで見据えたリソースの一元管理
PoCをやるたびにフローを組み直す必要がないので、長期的にも大きな手間削減につながります。
3-2. クエリ効率向上でレスポンスを改善
PoCといえど、ダッシュボードの表示速度が遅いと検証に支障が出ることがあります。
今回の実装ではより高速に表示するために、以下の対応で実現しました。
- Dataformでクエリロジックを予め集計・加工
- BigQueryに最適化されたテーブル/ビューを定義
- Looker Studioからは集計後のデータセットを参照するだけ
以下はDataformのSQLXサンプルです。
config {
type: "table",
database: constants.PROJECT_ID,
schema: "datamart",
name: "dailyShopSales",
bigquery: {
partitionBy: "businessDate",
clusterBy: ["shopId"],
},
columns: {
shopId: "店舗ID",
businessDate: "営業日",
totalTaxIncludedAmount: "税込合計売上金額",
totalTaxExcludedAmount: "税抜合計売上金額"
}
}
SELECT
sales.shopId,
sales.businessDate,
SUM(sales.totalTaxExcludedAmount) AS totalTaxExcludedAmount,
SUM(sales.totalTaxIncludedAmount) AS totalTaxIncludedAmount
FROM
`my_project.sales` AS sales
JOIN `my_project.targetShop` AS shop ON shop.shopId = sales.shopId
GROUP BY
sales.shopId,
sales.businessDate
このように必要に応じてpartitioningなどを行うことによって、ローデータに直接アクセスして集計するより高速なビジュアライゼーションが可能になります。
4. 実装手順
今回実装したPoC全体のアーキテクチャはこのようになっています。
ここからは、具体的なPoC開発フローのステップをざっくり紹介します。
-
Google Formやスプレッドシートで入力データを準備
- 既存データに加えて、ユーザーへ新規アンケートを取得したい場合などはFormやシートを用意。
- BigQueryなどに取り込む仕組み（自動スクリプト化など）を早めに検討。
-
Dataformでデータパイプラインを定義
- ローデータから必要なカラムやロジックを抽出＆加工。
- JOIN・集計・フィルタなどをまとめて定義し、PoC用データセットを生成。
- 大規模になるほどクエリチューニングが重要になるので、段階的にスクリプトを分割＆最適化。
-
Looker Studioでダッシュボードを作成
- Dataformで作成したBigQueryテーブルと接続。
- Google Formやスプレッドシートのデータを追加で参照したい場合は、別のデータソースとして同じダッシュボードへ取り込む。
- テンプレートをベースにドリルダウンやフィルターを設定して、仮説検証しやすいレポートを作る。
-
PoCのフィードバックを即座に反映
- 新しい指標やグラフを追加したい場合も、Looker Studio上で簡単に修正が可能。
- データの加工や集計ロジックを変えたければDataform側のスクリプトを修正 → BigQueryテーブルを更新 → ダッシュボードに即反映。
5. 運用や本番移行を意識したTips
-
チームで共同開発
DataformもLooker Studioも権限設定やバージョン管理（Git連携など）を考慮し、チームで同時に作業できる環境を整備しておくと良いです。
-
PoCから本番運用へのスムーズな移行
PoCで作ったテーブル定義をそのままProduction環境へ再利用できると工数削減につながります。
- Dataformのディレクトリ構成やネーミングを統一しておく
- Looker Studioのレポート接続先を切り替える際のルールをドキュメント化
-
コスト管理
BigQueryのクエリやストレージ、Looker Studioの一部有料機能（カスタムコネクタなど）を使う場合はコストが発生するので注意。PoC段階で実行クエリ量の見積もりをするクセをつけておくと安心です。
6. まとめ
元々自前で実装する想定では3ヶ月以上かかる見込みでしたが、今回の実装方針では約1週間ほどで構築ができ、顧客への開示後も細かい修正などを柔軟に行えることで検証がかなり進みました。
ダイニーではマルチプロダクトから生まれる大量の一次データを活用し、どんな切り口でもサクサク分析できるプラットフォームの提供を目指しています。そのためにも、今回ご紹介したような軸にしたPoCのスピーディな開発は欠かせないと考えています。
もし社内外でデータ分析ニーズが増え、「PoCを回す頻度が多い」「新しいデータをどんどん試したい」という場合は、ぜひこのワークフローを検討してみてください。
ダイニーでは飲食店のあらゆるデータを活用し、プロダクトとしてさらに次の価値創造にコミットするような活動も行っています。
データを使った顧客の価値最大化チャレンジに興味のある方はぜひお話ししましょう！
Discussion