【データドリブンカンパニー】スマートキャンプでのLooker導入事例
スマートキャンプ株式会社 / kumanomi
メンバー / エンジニア以外 / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|
11名〜50名 | 2021年9月 | B to B |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
当時、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やデータモデリング)に関する知識・スキルが求められるかと思います。
エンジニアの導入・運用担当者がアサインできないと導入自体は難しく、データ管理上の恩恵もあまりないと思います。
導入に向けた社内への説明
上長・チームへの説明
導入当時考えていたメリットは以下です。
- LookMLによるデータ品質向上
- ExploreによるSQL作成依頼コスト低減
「LookMLによるデータ品質向上」はすでにRedashを利用する中で既知の課題となっていたため、改めてデータ集計の品質が低いことによって起きうるビジネス上の不利益を整理・説明することで納得感を得ることができました。
定性情報だけでなく、実際にエンジニアがクエリを整理したり、新規作成依頼を受けて作成するなどコストがかかっていたため、「ExploreによるSQL作成依頼コスト低減」も定量的な効果として説明しました。
Redashを活用するのとあまり運用上変わらないことと、分析の使い心地(Explore)が向上している点もポジティブに働いたと思います。
活用方法
BOXILというプロダクトでLookerを利用しています。 BOXILにはマーケ・メディア・セールス・プロダクト開発・経営企画室・コンテンツガバナンス等のさまざまな部署が存在し、各部署でのデータの確認に利用いただいています。
(例)プロダクト開発チーム
毎日朝の数分ですがデータの確認をしています。 プロダクトの健康状態を把握することを目的とし、数字感を書くメンバーで育みプロダクトに対する理解度向上に寄与しています。
(例)メディアチーム
ABテストの効果検証や、各記事のPV数、CV数、個人目標との乖離を把握できるダッシュボードを整備し各担当者の方の進捗報告に利用いただいています。
(例)セールスチーム
KPIの定義をLookML行い、共通化された定義の状態でスプレッドシートに毎日データを書き出すようにしています。そのデータを用いて社外の提案資料に反映いただくようにしています。
(例)マーケチーム
こちらもセールスチーム同様に共通化された定義のデータをスプレッドシートに書き出し、そのデータを使っていただくようにしています。 元々LookerStudioを使っていた関係で、BIはLookerStudioを利用しています。 データの出力元をLookerで作ったデータになるようにし定義の一元化をしています。
よく使う機能
- データの探索
- KPIのSlack通知
- 異常なデータ発生や、定期バッジで作られているデータが生成されているかのアラート
- スプレッドシートへのデータ書き出し
- 永続的な中間テーブルへBigQueryに書き出し機能(データのキャッシュ機能)
ツールの良い点
- データ定義を一元化
- 弊社では利用していないが、複数のデータソースに対応している(BigQuery,Redshift,Snowflake)
- 通知等のスケジューラー設定が楽
- 他のツールの知見がないが、データ探索時の使い勝手が良いと感じる
- Exploreで探索した結果同士をマージすることができる
ツールの課題点
- ちょこちょこ日本語が不自由な表現がある
- 日付のフィルター機能で
全月
みたいな項目があったりして最初はなんだろう?となる。
- 日付のフィルター機能で
- 金額面(ちょっとお高い)で社員全員にアカウントを気軽に発行できないため全社的にデータ民主化を推進していくことが難しい
ツールを検討されている方へ
- 導入時に苦労した点や悩みにも記載済みですが、ツールの導入時にはエンジニアの手が結構必要となる点に注意。
- Looker導入後に実際に利用していく際には布教活動が必要。導入したら終わりではない。
- データを抽出する際にはポチポチと必要な項目を選択すればデータが出てくるものの、ある程度の事業に関わるDBのテーブル構造や中にどんなデータが格納されてどう紐づいているのかのイメージが出来ている必要があります。
- LookMLを1度定義したらほぼ使いまわせるところが便利なのですが、プロダクトでよく使う数字や深掘りたい数字がまとまってきたタイミングでLookMLを再定義することで
強くてニューゲーム
の状態が作れていくのでリプレイスできる体制があると良さそうです。
今後の展望
ダッシュボードを閲覧してくれる人数はかなり増えてきているものの、探索までできる人はかなり少ない状態です。
探索するにはデータの意味と構造に対しての理解が必要となります。さらに探索しても良いかなと思ってもらうモチベーションも必要です。
そのためツールを使ってというよりも、事業でどのようなデータを持っているのか理解度を高めていただけるように布教活動をしていこうと考えています。
スマートキャンプ株式会社 / kumanomi
メンバー / エンジニア以外 / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
システム受託開発企業に入社しスタートアップ企業でフロントエンジニアを経験。その後クーポン配布アプリのAndroidとサーバーサイドエンジニアを経験し、マッチングアプリのAndroid、iOSエンジニアを担当した後に分析業務を担当。 スマートキャンプではデータアナリストとして活動中。
よく見られているレビュー
スマートキャンプ株式会社 / kumanomi
メンバー / エンジニア以外 / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
システム受託開発企業に入社しスタートアッ...