EmbedBIで倍速PMFを実現した話

こんにちは。Shintaro Ishikawaです。
今回の記事ではEmbedBIとは何か？導入した結果どんな成果がでたか？についてまとめていこうと思います。

この記事で述べることのまとめ

1. 簡単にセルフサービス分析ができると思うな
2. EmbedBIは素早くPMFするという点において成功した
3. PMFの先に待っているEmbedBIの真実から目を背けてはいけない

EmbedBIとは

弊社スマートドライブでは2020年の3月にLookerを導入し、紆余曲折を経てSmartDrive Fleetという車両管理SaaSサービスにLookerをEmbedして分析オプションサービスを提供するということをはじめました。
現在では多くのお客様に分析オプションサービスをご利用いただいており、主力機能としてほぼすべての商談で1stcallの際に提案されるまでに成長しました。

EmbedBIの始まり

スマートドライブは `移動データ` というグローバルでみてもユースケースが少ないスキーマを扱っています。
どんなデータの見せ方をすると顧客の課題解決につながるのか？という問に答えをだすにはあまりに多くのプロトタイプと検証を必要とし、実際に会社の売上につながるまで時間がかかってしまっていました。
そこでまずはBIで作った簡易的なダッシュボードをプロダクトにEmbedして小さいサイクルで早くたくさん検証ができないかという話が上がったのがことの発端です。

一人目のデータアナリストとして入社したのですが、私が入社当時はほぼTableauをEmbedすることで確定していましたが、「Lookerにリプレイスしましょう」と提案したのを覚えています。

なぜLookerなのか？

いろいろな歴史的経緯はあるのですが、4つにまとめてみます。

1. 長期的にプロダクトの一部としてダッシュボードを開発運用保守する必要があるということ
2. 移動データの分析は高い専門性を必要とし完全なセルフサービス分析では品質の担保ができないということ
3. 深刻な人手（リソース）不足
4. 移動データの分析に膨大なコンピューティングリソースが必要だったこと

上記の1,2,3の課題を解決できるのは、LookMLという独自言語を持ち、集計ロジックからダッシュボードまでをすべてコード化しGithubでバージョン管理およびチームでのレビュー体制をつくることがでたLookerだけでした。
このあたりの詳細は長くなりすぎるため、興味あがる方はこちらの記事を参照してください。

あえて要するのであれば、セルフサービス分析を推奨するBIベンダーは「SQLやシステムの知識がないユーザーでもダッシュボードを作ることができる」という点を売りにしていますが、SQLの知識すら危ういのにデータ分析ができると思うなよ？という点にそもそもの認識の相違があります。熟練のデータアナリストでさえ、複雑な前処理や分析ロジックの構築には気を使うことが多くて四苦八苦しているのが一般的だと思います。
複雑なSQLを抽象化できるlookmlでコード化し、Guthub上でちゃんとレビューしてテストを通ったものだけプロダクトにEmbedする、という至極当たり前な発想を実現できたのは、10以上のBIを比較したなかでもLookerだけでした。

そして4番目にあげた点として、Lookerにはもう一つ秀逸な点があります。LookerはBigQueryの膨大なコンピューティング能力を最大限に発揮できるBIツールであり、しっかりメンテしていればデータが増えるほど処理時間が伸びるなんていうレガシーな課題とはおさらばできるのです。一回のクエリでうんテラバイトを読み込むのが当たり前な我々としてはBIツール自体のパフォーマンスに依存せず、BigQueryの能力の恩恵をそのまま活かせるのは好都合でした。

Embedしてみてどうなったか

実際にlookerの導入が決まってから2年間で作成されたプロトライプのダッシュボードは実に700以上。しかしその中で実際にEmbedされているのは2021年9月現在約20ほどです。
これは実際に700個のプロトタイプを内製で作っていればその97%がPMFできない死に機能として謎にメンテだけしないといけないサンクコストと成り果てるところだったことを意味します。
できるだけ早く失敗し、そこから学んでいくプロセスを高速で回し、素早くユーザーの課題の解決方法をみつけPMFするという点において、当初の目的は達成されたと言っていいと思います。

Embedしたその先

素早くPMFするということを優先した結果、内製開発では生じることはなかったであろう弊害もあります。
プロダクトにEmbedする以上は品質の保証に課題がありました。内製システムであれば一定の異常を検知したらアラートを出したり、そもそも異常が発生する前の段階で未然に検知できるインフラ監視の仕組み構築は事例等も多いのですが、Embedした先にあるBIやBigQueryのインフラ監視が必要でした。このあたりはまた別の記事で書くことにします。

そしてEmbedBIを先進技術事業開発部という部署で独立してスピード重視で行ってきた関係で、プロダクトチームとの間に認識の齟齬が生じたり、リリース時のSalesチームやCSチームとのコミュニケーションのパイプラインを別で構築しないといけなかったりと社内での調整事項もかなりたくさんありました。

まとめ

プロダクト開発といえばエンジニアを雇ってスクラム組んでという考え方が一般的ですが、開発しないでプロダクトが作れるのなら越したことはありません。
しかし、既製品である程度代用できるといっても3倍速で70点までは取れるけど100点までいくのは至難の業みたいな状況になりがちです。
会社のフェーズや課題を踏まえてそれぞれの状況にとって一番ベターな選択をできる胆力が結局大事なんだなとこのプロジェクトを通して思いました。