【データドリブンカンパニー】スマートキャンプでのLooker導入事例

ツール導入前の課題

当時、2021年頃のスマートキャンプでは、データ分析についてはアプリケーションのデータとログをBigQueryに転送し、セルフホスティングしたRedashを利用し経営陣・各部署の方が参照している状態でした。

その頃のスマートキャンプはデータドリブンな意思決定を強く推奨しており、職能関係なくSQLを書いて必要なデータにアクセスする良い文化がありました。

しかし、社員が50名、100名と増える中で、課題も表出してきました。

社員の増加とともにRedashに保存されたクエリ数も増え、1000を超えてきたところだったと思います。これはすべて新規作成されたわけではなく、大半がコピーされたものでした。 そうなるとどれが必要なクエリか判別したり、探したりする手間が大きくなってきました。 また、データ元の構造などが変更になった際にクエリ修正コストが大きいという問題も起きてきました。

そして社員の増加に対し、SQLのトレーニングを徹底したりと文化を維持するのも困難で、ツギハギのSQLを書き誤った数値を元に意思決定してしまっているような事例も見られてきました。

そういった意思決定に関わるデータに対し、高信頼（ミスがおきにくい）で、簡単にアクセスできるようにしたいと考えていました。

弊社提供のSaaSでSisenseを利用させていただいてることもあり、SisenseとLookerとRedashで比較しました。

大きくは2点、機能面で課題が解消できる見込みができたこと、CSが充実しており導入がスムーズだったことが挙げられます。

機能

LookerではLookMLという設定記述言語を利用して、事前にデータを分析しやすいように定義・変換しておくことがキモとなります。

頻出するクエリのパターンについては、LookML上で定義することで利用者からは隠蔽され、安全簡単に利用することができます。

LookMLの編集はGitHubとも連携ができブランチ管理もできるため、レビュー・更新のフローが作りやすいのもメリットと捉えていました。

また、キャッシュ機能も充実しており、適切に設定すればBigQueryのようなクエリ実行による従量課金でもコストを抑えることにつながると感じました。

加えて、弊社でのRedashを利用しているときから、SpreadsheetにExportして追分析をしたり、分析結果を毎日Slackに通知するなどのユースケースもありました。 このあたりもLookerで代替できることを確認することができました。

CS（カスタマーサポート）

導入検討時に、PoC期間を十分取っていただき、テスト環境を自由に使って検証を進めることができました。 PoCの設計についても、解決すべき弊社課題をヒアリングの上まとめていただき、進捗管理もしていただきました。

技術面で壁にぶつかることも何度かありましたが、そちらも担当者の方に手厚くサポートいただき、細かい質問に対しても丁寧な回答が多く、サンプルのLookMLを作成し提示いただき円滑に導入を進めることができました。

また、PoC後については研修プラン（当時名称: JumpStartプラン）を選ばせていただき、ビジネス側・開発側両面でハンズオンなど実施いただき、これも満足度が高かったです。

ハンズオンはカスタマイズ性が高く、弊社だとビジネス側の納得感が重要だったため、そこでのコンテンツを充実させていただきました。ハンズオンをする中で理解度が薄い点が出てくればそこを埋めるようなコンテンツを設計いただけました。

こちらのプランによって、より利用者として納得感がある導入に繋がりました。

• LookMLによるデータ品質向上
• ExploreによるSQL作成依頼コスト低減

改善したかった課題はどれくらい解決したか

LookMLによるデータ品質向上 ではBOXIL上で発生していた“クエリの定義が若干違うことで数字の誤差が生まれていました。 LookMLでデータ定義を合わせれば解決する問題かと思えば違っていて、これに関しては解決までに結構な時間がかかりました。

社内のテックブログにも書かせていただきましたが、Lookerを導入することだけでは課題は解決されずデータ利用者に対して認識合わせを何度も繰り返して解決に向かって行きました。

あとはデータの閲覧ユーザーがこういうデータだと思い込んで利用していた間違った数字もあり、本来必要だった数字を擦り合わせながら定義していけたため品質は高まったかと思います。

どのような成果が得られたか

ExploreによるSQL作成依頼コスト低減に関してはほぼかからなくなっています。

ほぼと書いた理由はデータの定義に対しての質問相談対応は実施いただいています。

エンジニア側の作業コスト削減できており、さらにデータの抽出依頼から対応までの期間は2営業日ほどのため対応速度もこれまでより向上しているはずです。

LookMLは機能も多く、派生テーブルなど柔軟性が高いため、設計が難しいと感じました。 こういった点はカスタマーサポートも手厚く、適宜ドキュメントも提示していただけたりはしますが、考え方を理解するのに一定のデータ分析（SQLやデータモデリング）に関する知識・スキルが求められるかと思います。

エンジニアの導入・運用担当者がアサインできないと導入自体は難しく、データ管理上の恩恵もあまりないと思います。

• 導入時に苦労した点や悩みにも記載済みですが、ツールの導入時にはエンジニアの手が結構必要となる点に注意。
• Looker導入後に実際に利用していく際には布教活動が必要。導入したら終わりではない。
• データを抽出する際にはポチポチと必要な項目を選択すればデータが出てくるものの、ある程度の事業に関わるDBのテーブル構造や中にどんなデータが格納されてどう紐づいているのかのイメージが出来ている必要があります。
• LookMLを1度定義したらほぼ使いまわせるところが便利なのですが、プロダクトでよく使う数字や深掘りたい数字がまとまってきたタイミングでLookMLを再定義することで強くてニューゲームの状態が作れていくのでリプレイスできる体制があると良さそうです。

ダッシュボードを閲覧してくれる人数はかなり増えてきているものの、探索までできる人はかなり少ない状態です。

探索するにはデータの意味と構造に対しての理解が必要となります。さらに探索しても良いかなと思ってもらうモチベーションも必要です。

そのためツールを使ってというよりも、事業でどのようなデータを持っているのか理解度を高めていただけるように布教活動をしていこうと考えています。