プロダクト用途から始まった、ヤプリのBigQuery導入事例
株式会社ヤプリ / yamamoto-yuta
メンバー / データエンジニア / 従業員規模: 101名〜300名
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
オンデマンド/容量ベース | 10名以下 | 2020年7月 | B to B |
| 利用プラン | オンデマンド/容量ベース |
|---|---|
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2020年7月 |
| 事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
弊社では、「プロダクト用」と「ビジネス用」の2つのデータ基盤を運用しています。
プロダクト用データ基盤
- 目的: 「Yappli」から生成されるデータを収集・加工し、Yappli管理画面のダッシュボード表示や、顧客への生データ提供サービス「Yappli Data Hub」を支えています
- 意図・工夫: データの①取り込み、②加工、③提供の3フェーズを完全に分離しました
- 取り込み・提供はエンジニアチーム、加工はデータチームが担当する分業体制
- これにより、データチームは加工処理の改修に集中しやすくなり、エンジニアチームの工数削減に繋がっています
ビジネス用データ基盤
- 目的: 営業やCS(カスタマーサクセス)などのビジネス活動から生まれるデータを収集・加工し、営業利益やチャーンレートなどのビジネス指標をモニタリングします
- 意図・工夫: TROCCO®、BigQuery、Lookerを活用し、信頼できる唯一の情報源(Single Source of Truth: SSOT)の実現を目指しました
- 以前はSalesforceレポートの乱立やスプレッドシート管理によるデータのサイロ化で、信頼できるデータが不明瞭でした
- BigQueryにSalesforceやスプレッドシートのデータを集約し、分析時にはLooker上のデータモデルのみをデータソースとして使用することで、SSOTが保たれるようにしています
💡 詳細はこちらに掲載されておりますので、よろしければご覧ください: ヤプリのプロダクトとビジネスを支える2系統のデータアーキテクチャ
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
弊社のアプリ開発プラットフォーム「Yappli」では、アプリの運用状況(アクティブユーザー数の推移、スクリーン閲覧状況、プッシュ通知の開封率など)をモニタリングできるダッシュボードを提供しています。このダッシュボードを提供するために、アプリ内の行動データ(スクリーン閲覧、ボタンタップなどのイベントログ)をトラッキングしています。
BigQuery導入前は、このトラッキングをGoogle Analytics(当時のUniversal Analytics版)で実現していました。しかし、以下の課題に直面していました。
- データ取得の限界: Google Analyticsでは取得できない情報があり、パーソナライズされたアクション(例: 特定のウェブサイトを閲覧したアプリユーザへプッシュ通知を送る)を提供することが困難でした
- データ活用の限界: データが自社に蓄積されないため、より深いデータ分析や、顧客保有データとの連携といった高度なデータ活用が困難でした
これらの課題を解決するため、自社でデータをトラッキング&蓄積することにしました。
💡 導入背景については、こちらの記事にもう少し詳しい話が掲載されておりますので、よろしければご覧ください: 株式会社ヤプリの導入事例 | Google Cloud Documentation
どのような状態を目指していたか
目指したのは、「Yappli」というプラットフォームを通して以下の状態を実現することを実現することです。
- データドリブンな施策: 顧客がデータからビジネス上のチャンスやボトルネックを特定し、それをアプリでの具体的な施策へと繋げられる状態
- データ連携と拡張: 弊社で蓄積したデータを顧客が保有するデータと連携できるようにし、顧客が新たな施策を実現可能な状態
選定理由
ほぼBigQuery一択でした。理由は以下の通りです。
- 集計速度が速い
- ストレージ単価が安い(データ量がある程度あれば)
- データパイプライン構築が同じGoogle Cloud内で完結でき、運用保守がしやすい
導入の成果
弊社が提供している各種ダッシュボード・アナリティクスサービスは現在、多くのお客様にご利用いただいています。
- Yappliの管理画面のダッシュボード: 月間およそ6,000PV
- Yappli Analytics: 月間およそ30,000 PV
- Yappli Data Hubのデータ連携の利用顧客数: 50顧客以上
※ 2025/11/14時点の数値です
また現在では、アプリ内行動データといったプロダクト用データだけでなく、Salesforce内のデータなどビジネスデータもBigQueryへ蓄積されるようになっており、ビジネス部門(マーケティング、セールス、カスタマーサクセスなど)の業務改善に役立てられています。
導入に向けた社内への説明
上長・チームへの説明
当時は、「導入背景」のセクションで記載した内容に加えてUniversal Analyticsからの移行アナウンスが出ていたこともあり、何かしら新しいツールを導入する前提で話は進んでいました。そのため、BigQueryを導入することもスムーズに決まりました。
活用方法
よく使う機能
- コンソール画面
- ちょっとした分析・データ抽出の際にサッとクエリを書いて実行できるので重宝しています
- この使い方が一番多いと思います
- Data Transfer Service
- データチームではありませんが、SREチームではストレージの安さと分析のしやすさから、AWS上のログをData Transfer Serviceで流し込むといった使い方をしています
- コンピューティング料金の料金モデルの使い分け
- プロダクト用の集計処理は日々の処理量が安定しており、費用予測もしやすいため、オンデマンド課金のGoogle Cloudプロジェクトで対応しています
- アドホック用途は安心してクエリできるよう、料金を定額にできる容量ベース課金のGoogle Cloudプロジェクトで対応しています
- INFORMATION_SCHEMA
- 日々のBigQuery利用状況のモニタリングやテーブルの参照状況の把握などで重宝しています
- スプレッドシート連携(コネクテッドシート・外部テーブル)
- コネクテッドシートは、アドホックな分析や簡易的な定期更新ダッシュボードの作成で重宝しています
- 外部テーブルは、人が入力する運用のスプレッドシートをBigQueryへ取り込む際に重宝しています。これにより、スプレッドシートのデータと他のBigQuery上にあるデータをクエリ上で組み合わせられます
ツールの良い点
- データ連携の容易さ
- スプレッドシート、Looker Studio、LookerなどGoogle製BIツールへ簡単に連携できるのをとても便利に感じています
- 特にスプレッドシートの「コネクテッドシート」は、定期更新するダッシュボードを簡単に構築できたり、そこからGoogle Apps ScriptやSlackワークフローと連携させてアラートシステムを簡単に構築できたりするので、とても助かっています
- 大規模データの高速処理
- 大規模データをサクサククエリできるのはシンプルに便利です
- 外部ツールの対応
- TROCCOやdbtなど、外部のデータ系ツールが大体BigQueryに対応してくれているため、「ツール側がBigQuery未対応で困る」というケースがほぼ発生しませんでした
ツールの課題点
- テーブルの検索性
- コンソール画面で目的のテーブルがなかなか見つからず、毎度微妙に手間取ってしまっています
- この辺りは、Dataplex Universal Catalogを導入すると改善するのかな…?と思いつつ、弊社ではまだ検証していません
- コンソール画面で目的のテーブルがなかなか見つからず、毎度微妙に手間取ってしまっています
株式会社ヤプリ / yamamoto-yuta
メンバー / データエンジニア / 従業員規模: 101名〜300名
よく見られているレビュー
株式会社ヤプリ / yamamoto-yuta
メンバー / データエンジニア / 従業員規模: 101名〜300名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法

