爆速1時間！trocco×BQ×Looker Studioで行う、KPIモニタリングに必要なデータ集計＆可視化実践

この記事はデータエンジニアのためのSaaS「trocco(トロッコ)」の[アドベントカレンダー 2021](https://qiita.com/advent-calendar/2022/trocco)の23日目の記事になります！
# はじめに

troccoのHead of Customer Successをしている、[中村](https://twitter.com/_y_nakamu_)と申します。
いつもは[trocco](https://trocco.io/lp/index.html)のご提案/ご支援を始め、チームマネジメントを行っております。
また、データエンジニアとして、自社のデータ分析基盤の一部構築や運用も行っています。

弊社はtrocco×BQでデータ分析基盤を構築しており、何かあればそこから適宜データを抽出して、利活用を行っています。
今回はこの分析基盤を使って、1時間でデータ抽出とKPI可視化を実現した話をお話します。

サクサクっとまとめておりますので、「ここをもっと詳しく！」といった点ございましたら、ご指摘ください🙏

### 1時間でやったこと

- KPI可視化に必要なデータの抽出
- KPI集計
- データパイプラインの構築/スケジューリング
- BIツールでの可視化

### 1時間でやってないこと

- KPIの定義策定
- KPIデータの集計ロジックの策定と認識合わせ

# 背景

CSをはじめ、マネージャー層が皆悩むのがKPIモニタリングだと思います。
弊社はこの一年で一気にメンバーが増えたことに伴い、チームごとのKPIへの意識付けがより重要視されてきました。
一方、肝心のKPI管理はスプレッドシートで手メンテされていたり、確認・報告が必要なタイミングでの抽出が行われていたりと、非効率な状態となっていました。

私の管轄するCSチームも例外ではなく、お客様のご利用状況の可視化・モニタリングはデータ抽出含め自動化されていましたが、KPIは未着手という状態でした。
今後のさらなるチーム拡充や、シンプルに都度対応の工数を鑑み、重い腰を上げKPI可視化に取り組むことにしました。


# 弊社のデータ分析基盤のイメージと、最終構成

弊社はデータ分析基盤が構築されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/8777e580-78b5-e90a-a752-e968dcc46e85.png)


- MySQL(サービスデータ)、Salesforce(顧客データ)のデータを自社SaaS「trocco」を用いて抽出し、Google BigQueryに連携
- BigQueryに蓄積されたデータを元に、troccoを用いて分析用テーブルを作成
- 切り出された分析用テーブルはLooker Studioで可視化

今回は既にBigQueryに溜まっているデータとtroccoを用いて、新しくデータパイプラインを構築し、KPI可視化を実施しました。

### 最終的なデータパイプライン

![workflow.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/d18f255f-2586-c976-079a-28a42484870e.jpeg)


### 最終的なKPI可視化

![dashboard.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/3360311b-7823-86cd-a581-f631dd1e9f0e.jpeg)

# 爆速！ 1時間でKPI集計＆可視化

それでは実際にどのような手順でKPI集計と可視化を達成したのか、順に説明してまいります！

### KPI可視化に必要なデータの抽出(0分)

こちらは既にデータ分析基盤に必要なデータが蓄積されていたので、作業は不要でした。
仮に新規抽出が必要な場合でもtroccoを用いれば3STEPで簡単に実装ができるので、大した工数はかからないものとなります。自社SaaSながら本当に楽…

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/0f35ac4a-5ac8-6065-ab57-2578e64c359b.png)



また、troccoの機能であるデータカタログを用いることで、BigQueryテーブルのメタデータを素早く確認することができるため、
「このテーブルのこのカラムは、具体的にどのような情報が入っていたかな？」といった確認も容易です。
わざわざSF管理者に相談することも不要、分析・集計する側からすると本当にありがたいです…

![datacatalog.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/d030b428-707b-52ba-acf9-c0e25e66f78b.jpeg)


### KPI集計(20分)

次に、肝であるKPI集計です。
分析用テーブルを作成する必要がありますが、BigQueryに蓄積されているデータを用いてガシガシSQLを書き、troccoのデータマート機能を用いて実行できるように進めました。

![datamart.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/4edfca85-724b-5d93-6703-96d5b935f9dc.jpeg)


troccoではSQLさえかければサクッと分析テーブルを用意することが出来ることも強みです。
※普通にコードを書いても実現はできますが、別に無駄にコード書いても実行環境含めた保守工数が増えるだけなので、こういったSaaSで集中管理したほうが良い主義です。

また、1本のクエリで一気に最終ゴールの形式まで集計をかけることも出来ましたが、今後のKPI変更や拡張性を考慮し、以下のようにいくつか層を切って構築しています。

- 当該データの整形 …①
- ①のデータを元に、dailyで集計 …②
- ②のデータを元に、monthlyで集計


SQLを書くことだけに集中できるので、途中出て戻りが発生しても、3本のSQL(合計50行くらい)は20分くらいで作成できました。


### データパイプラインの構築/スケジューリング(10分)

KPI用の分析テーブルができるまでに中間テーブルが作られる必要があるため、別途データパイプラインを作成する必要があります。
こちらはtroccoのワークフロー機能を用いて実現しました。
ワークフロー機能はGUI上で簡単に実行順序を定義することができる機能です。
以下のようなフローをサクッと作成することが可能です。

![workflow.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/740ac0bc-7ccb-9938-faac-3fdb3a2cdb4f.jpeg)


今回は実装しませんでしたが、より複雑なKPI集計を行う場合は、中間チェックとして「BigQueryデータチェック機能」を利用することも出来ます。
ワークフローの途中でBigQueryにクエリを実行し、その結果に応じてワークフローを停止させることが可能です。

また、このワークフローを1日1回実行するようなスケジュール設定も、画面上から簡単に定義することが出来ます。
今回は1日1回にしましたが、更新頻度によっては1時間に1回なども問題なく設定可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/95d0c4f7-a038-eda7-d9fa-bff9ea2981db.png)




このあたりは本当にサクサクっと実装が終わり、ものの10分くらいで完成しました。

試しにジョブとして実行すると、問題なく処理が完了し、BigQuery側にも正常にテーブルが生成されていることが確認できました。
(モザイクだらけですが)集計されたデータも問題なく格納されています！
![bigquery_result.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/eb59780a-3547-467b-cb85-5e2e8619d480.jpeg)




### BIツールでの可視化(30分)

ここまできたら、あとは可視化のみです。
今回は私が慣れ親しんでいるLooker Studioで実装しました。

![dashboard.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2345826/25c3c289-5195-507d-c959-f97b96e8be30.jpeg)


自分での実装が久しぶりだったので、ここが一番時間がかかりました😇
ただ、必要なデータは適切な形でBigQueryにある状態だったので、「どうやってわかりやすく表現しようか」に脳内リソースを集中できたのは良かったです。
色々な考え方がありますが、やはりデータを扱えるスキルが有るならば、BIツールに持ってくる手前の部分（今回ならBigQuery）でデータは整形しておくべきだなと痛感しました。

今回は以下観点で可視化を行いました。

- KPIサマリ
　- 月別実績の実数値
　- 期別実績の実数値
- KPI集計対象ごとの個別実績
　- 案件単位での実績など
- 集計ロジックの明文化　★

今回工夫したポイントは★の「集計ロジックの明文化」です。
KPI集計の自動化とモニタリングが達成された後は、長い長〜い運用フェーズが始まります。
このフェーズで必ず他のメンバーから言われるのは「ここ、どういうルールで集計してるんだっけ？」です。
この対応に~~うんざり~~工数をかけないために、BIツール上に敢えて出す試みをしました。
既に効果は出ており、ほとんど質問が私に来なくなりました🙏




# KPI可視化を行うために改めて重要だと感じたこと

以上、各種ツールを使うことで実装部分をかなり高速に行うことが出来ました！
今回は私主導でKPIの集計ロジック・定義を決められたこともあり、一気通貫で漏れなくやりたいことを達成できたかなと思っております。

実装も大変な部分はありますが、やはりそれ以上に重要なのはKPIの集計ロジック・定義だと痛感しました。
裏を返すと、集計ロジック・定義がないことには自動化・モニタリングは難しいな、、、とも感じました。
トップダウンでKPIが降りてきて「それじゃ、頑張って！」といった体制ではより難易度が上がるので、集計ロジック・定義部分を偉い人たちと確り握っておくことが重要ですね。

一方、中長期で見るとKPIは変わるものなので、集計ロジック・定義の柔軟さも意識しておく必要があります。
例えば、集計元のデータソースが変わる・増えるなどは、容易に想像できるのではないでしょうか。
※現場からしたらやめてくれぇとなりますね😇

そういった柔軟さを達成できるように、自動化の仕組みを整える段階で考慮に入れておくことも大切だなぁと身を持って感じることが出来ました。

# 現在と今後

現在、構築したパイプラインは安定稼働しており、高品質なモニタリングを継続達成できています。
おかげで都度都度抽出のような無駄な作業から開放されることができました…（泣）

一方、上記可視化は全体のKPIのうちのまだ一部分であり、いくつかの追加構築が残っています。
しかし、今回爆速で成功体験を得られ、その価値も享受することができたので、今後も継続して取り組んでいけるかなと思っております！(成功体験、大事)

この記事が、KPI可視化と抽出に悩む人に少しでも参考になれば幸いです。
最後までお読みいただき、有難うございました！