Lookerの導入効果をレビューでご紹介(ayase-y-株式会社スペースマーケット)
株式会社スペースマーケット / ayase-y
従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
利用プラン | ツールの利用規模 | ツールの利用開始時期 |
---|---|---|
Platform Standard | 11名〜50名 | 2020年9月 |
アーキテクチャ
![アーキテクチャ図](https://cdn.findy-tools.io/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBEZz09IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--b11184a76312a15b64e2239686e752c54792c4c9/looker_35.png?disposition=inline)
アーキテクチャの意図・工夫
Looker導入時点ではDWHが存在しておりませんでしたが、導入と同時にDWHの環境選定も行いました。結果として、業務ツールであるGoogle製品との相性が良いことや、GCPのMLなどの付随機能が優れている点などを鑑みてBQを採用しました。そして、DWHができたことでGoogleAnalyticsやAmplitude 、Zendeskなど社内で使用していた様々なサードパーティツールのデータをBQに集約しLookerで可視化する、というスキームが構築できました。
導入の背景・解決したかった問題
導入背景
導入前の状況ととして、データ活用環境として2017年頃からRedashを導入し、Bizサイド含めて各社員がSQLを記述しデータを抽出・利用していました。また、主要KPIについてはエンジニアが内製BIダッシュボードを開発しモニタリング環境を構築しています。事業や組織の成長に伴い、以下2つの大きな課題が顕在化していました。
- データの『信頼性』が担保できない
- データ仕様に対する理解度の差
- 特にビジネスユーザーがあらゆるデータ仕様を正しく把握するのは難しい
- 仕様書やER図などのドキュメントが存在しないorメンテされていない 等
- SQLの記述に対するスキルの差
- Query Snippets 等を使っても求める品質の担保は難しい
- データ定義や運用ルール等の整備不足
- 『売上』は税込or税抜か、『予約数』はキャンセル込みor除くか 等
- データ仕様に対する理解度の差
⇒抽出したデータに対して疑心暗鬼になり、データに基づく意思決定に自信を持てない
- データマネジメントに対するリソース不足
- 内製BIダッシュボードのメンテナンス
- 指標の追加・変更
- ロジック修正
- 柔軟なドリルダウン等への対応 等
⇒サービス開発や緊急対応が優先され、データマネジメントに貴重なリソースが割けない
- 内製BIダッシュボードのメンテナンス
トライアル(PoC)に関して
検証内容:主な要件である以下2点を検証しました
- 「既存のBIダッシュボードと同様の機能を再現できるか」
- 「ビジネスユーザーが活用できそうか(活用イメージを持てるか)」
実施期間
- 開発:約3週間
- ユーザビリティテスト:約1週間
PoCでの検証の結果
- 以下3点が最大の検証ポイントでしたが、限られた時間の中で一定の環境を構築でき、GUIで直感的に操作できる点がユーザビリティテストでも好感を得られたことで導入に至りました。
- BigQueryにDWHをスムーズに構築できるか
- LookMLの学習コスト
- 非常に複雑な売上金額の計算ロジックをLookMLで再現・実装できるか
- 以下3点が最大の検証ポイントでしたが、限られた時間の中で一定の環境を構築でき、GUIで直感的に操作できる点がユーザビリティテストでも好感を得られたことで導入に至りました。
比較検討したサービス
- Tableau
- DOMO
- Amazon Redshift など
選定理由
運用的観点
- データガバナンスを担保できる
- LookMLでデータを定義し一元的に管理するため、ユーザー間の定義のズレを防止できる
- ACLに対して詳細かつ柔軟なアクセス管理ができる
- 『データの民主化』をドライブできる
- ユーザーはSQLを記述することなく正しいデータを簡単かつ柔軟に利用できるため、 データ活用の活性化が期待できる
- データの価値を最大化できる
- 多様なインテグレーションによって、抽出・可視化したデータを既存のワークフローやアプリケーションに組み込んで幅広く活用できる
- 多様なインテグレーションによって、抽出・可視化したデータを既存のワークフローやアプリケーションに組み込んで幅広く活用できる
技術的観点
- データソースの自由度
- Looker 自体がデータを持たないため、アップロードが不要かつ最適なDBを利用できる データ分析基盤を構築する上で、今後のデータ利活用を考えてBigQuery のようにサービスとして実績があり、かつエコシステムが整っているプロダクトを採用できる
- 自社のIT環境との親和性
- 基本的に業務アプリケーションにはクラウドを採用しており、IT 運用の負荷を最小限に、かつユーザーの利用障壁が低く、スムーズな導入を期待できる
- 開発環境の充実
- データモデルの開発環境が洗練されており、Git によるバージョン管理も弊社の開発スタイルにあっていることから、スピード感のある開発を期待できる
導入の成果
機能の充実度や使い勝手、インテグレーションの豊富さなど機能面については概ね満足しています。強いて課題を上げるなら、 Explore上で定義したデータをベースにドリルダウンするなどの柔軟性や、ビジュアリゼーションのバリエーションに欠ける点です。また、アカウント数に応じて従量課金のため、現在のところ、コスト的に全従業員にアカウントを開放できていない点も課題に感じています。
導入に向けた社内への説明
上長・チームへの説明
元々CxO陣などを中心に「データをもっと活用したいが上手く活用しきれていない」という課題感があったため、私がデータアナリストとして入社後、BIツール導入を提案しLookerのPoCを経て導入の意思決定に至るまで、あまり説得に苦労したという場面はありませんでした。
費用対効果の算出
- コスト面に関して
- 当時Redashや内製BIツールの保守・メンテナンスなどに約1人月のエンジニアリソースを割いていたため、Lookerを導入することでそれらの開発リソースがほぼペイできる
- 複数のビジネスユーザーのSQL学習コストを削減できる
- データの活用促進のよるメリット
- Lookerの導入によって、データ活用が促進されることによる売上向上や生産性向上などの効果が期待できる点を説明した
活用方法
よく使う機能
開発・運用観点でいうと、ビジネスユーザーの利用状況に関する各種ダッシュボード(クエリ実行数、Look数、スケジュール数、エラー数など)PDTの接続・実行状況に関する各種ダッシュボードなどをよく見ています。また、それらは定期的にSlack通知して管理するようにしています。
ツールの良い点
- ビジネスユーザーが使いやすい
- ユーザーがSQLを記述することなく正しいデータを簡単かつ柔軟に利用可能で、ツール導入前後の良い変化でいうと、ビジネスユーザーのデータ活用が進んだことや生産性が向上したことが最も大きいです。
- データ定義のガバナンスを担保できる
- LookMLでデータを定義し一元的に管理するため、ユーザー間の定義のズレを防止できます。
- ACLに対して詳細かつ柔軟なアクセス管理ができます。
- 開発がしやすい
- データソースの自由度
- Looker 自体がデータを持たないため、アップロード不要かつ最適なDBを利用できます。
- データ分析基盤を構築する上で、今後のデータ利活用を考えて BigQuery のようにサービスとして実績があり、かつエコシステムが整っているプロダクトを採用できます。
- 開発環境の充実
- データモデルの開発環境が洗練されており、Git によるバージョン管理も弊社の開発スタイルにあっていることから、スピード感のある開発を期待できます。
- データソースの自由度
- Google製品との相性が良い
- Googleが買収したことでGoogle製品との相性が良くなったことも、開発者及びビジネスユーザー双方にメリットが大きいかと思います。たとえば、Lookerをデータコネクトで連携しスプレッドシート上で直接データを抽出しピボットテーブルで加工できたり、Looker上からBigQueryを操作できたりなど、他のBIツールにはあまりない利便性も魅力です。
ツールの課題点
- 柔軟性やビジュアリゼーションの豊富さにやや欠ける
- Explore上で定義したデータをベースにドリルダウンするなどの柔軟性やビジュアリゼーションのバリエーションは非常に豊富とまでは言えないかなと感じます。(とはいえ、どんなツールもある程度は目的特化型の方がシャープで良いと思うので問題とは思いませんが。)
注意点として、Explore設計の仕方によってビジネスユーザーの利便性が大きく変わるためビジネス要件を取り入れて工夫することが大事かと思います。
- Explore上で定義したデータをベースにドリルダウンするなどの柔軟性やビジュアリゼーションのバリエーションは非常に豊富とまでは言えないかなと感じます。(とはいえ、どんなツールもある程度は目的特化型の方がシャープで良いと思うので問題とは思いませんが。)
- アカウント数による従量課金
- Lookerはアカウント数に応じた従量課金という料金体系をとっているため、現在のところ、コストの観点で全従業員へのアカウント開放ができていない点にやや課題感を覚えています。
株式会社スペースマーケット / ayase-y
従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
2016年に株式会社LiBに入社し、複数部門を経た後にデータ分析グループの立ち上げに従事。2020年6月に第一号データアナリストとしてスペースマーケットにジョイン。データ分析基盤構築の一環としてLooker導入プロジェクトなどを推進。2023年からはマーケティングGrへ異動しWeb広告運用、プロモーション企画・実行、CRMなどに従事。
よく見られているレビュー
株式会社スペースマーケット / ayase-y
従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
2016年に株式会社LiBに入社し、複数...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法