社内利用浸透しきったLookerを1ヶ月でLookerStudioに移行した話

こんにちは！ゲンシュンです。

Looker解約することになり、LookerStudioへの移行対応をした話を書きます！

背景

Lookerはプロダクト部ビジネス部も満遍なく利用しきっていますが、円安関連でコスト高騰してキツイな〜という状況でもありました。解約意思決定が自分に伝達されたのが6月下旬、移行対応に即アサインされ、そこから諸々準備し、8月頭でのLookerStudio利用開始までわずか1ヶ月という短期決戦プロジェクト開幕です。

各部門の業務フローにゴリゴリ組み込まれているぐらい利用浸透してて、DWH↔Lookerの設計周りもかなりいい感じに出来てて、こんなに愛した俺達のLookerがコスト理由だけで移行せざるを得ないのは、ぶっっっっちゃけモヤモヤが大きかったです。が、やりきればうんびゃくまん以上の凄まじいコスト改善が出来るので、これは凄い事業インパクトだ！やり切るしか無い！やろう！

LookerStudio→Lookerの記事はたくさんあるのに逆パターンは殆ど無く、Lookerの仕様もわからない中こんなに社内に利用浸透しきったBIツールを別ツールに移行するのは結構大変でした。この過程で考えたこと、悩んだこと、得られた学びなどをまとめます。この記事では、プロジェクト進行全般、LookerStudio設計実装、社内周知や浸透周りをお話します。他に検討したBIツールやLookerStudio選定理由などは話さないです。

データ基盤とBIツールの設計概要

データ基盤とLooker

• Lookerの用途をざっくりまとめると
  • プロダクト部は機能利用やデータ探索
  • カスタマーサクセスでは、顧客データ出し、個社分析、解約分析、利用状況把握など
  • 各ダッシュボードを顧客単位のslackチャンネルに配信したり、全体利用を全社周知したり
  • 各ダッシュボードをSalesForceに埋め込み、個社単位で見れる状態に

全社的に利活用進んでいるので、Looker辞めるインパクトデカすぎる、やめたくない(切実)

データ基盤とLookerStudio

概ねLookerでやれたことをほぼ再現できました。グレーになっている部分が一部諦めた部分です。LookerのExplore相当のものをLookerStudio側で実装するのが厳しく、テーブルとして切り分けて基盤側で再実装しました。

移行プロジェクト進行

やったこと、意識したこと、スケジュール感を時系列でまとめます。

移行のゴール決め

LookerStudioはLooker相当の機能があることは事前に聞いていました。大体は再現できるだろう、どこまで再現する？という話になり、以下2点に要点として諸々やることを決めていきます。

• プロダクト部の探索頻度が高くないため、探索のための柔軟性は捨てる。SQL書けてデータのドメイン知識ある開発メンバーがBigQueryでSQL書けばどうにかなったりする
• データ利活用が事業成長に繋がっているビジネス部門が、優先度高の業務を問題なく遂行出来きるよう、型になっているものを移行する

勿論全てを移行したい気持ちがあるものの、工数感と今後の保守運用観点から、一番最初に取捨選択と優先順位付けを決められたのは良かったです。特に「データ探索のための柔軟性を捨て、型になっているものの再現を最優先」でシャープになりました。

スケジュールと作業洗い出し

作業内容の洗い出し、工数、優先度を整理していき、現段階では解像度粗々ですが以下3種類の業務に分類出来そうだなと。

• ①データ基盤→LookerStudioのテーブル再設計
  • LookerのExplore相当のものを、LookerStudioではなくBQで再実装した方が良さそうと判断
  • 自分はLooker実装したことなく判断材料ないため、完全に信じます
• ②ダッシュボード再構築
  • 残すダッシュボードの精査、移行の優先順位と工数感
  • 移行作業しながら、LookerStudioの習熟度上がればいいなと
• ③LookerStudio切り替え付随業務
  • SalesForceに埋め込んでいるLookerダッシュボードの置き換え
  • Lookerからslackへのスケジュール配信の置き換え
  • 情シスが気にするデータ周りの監査ログなどセキュリティ面
  • googleアカウント発行とアカウント管理フロー体制
  • 社内周知全般

基本①が終わらないと②に進めないが、③は単発で進められるものもあれば②が完遂するまで着手できないものもあり結構複雑です。不安要素は早めに潰したいため「①→②を最速でやり切り、スケジュール遅れ要素を早めに出し切る」「監査ログなど自分で判断つかないものを別途単発で先にやる」という2点意識して進めていきました。概ねこの進め方で良かったですが、③の解像度がまだまだ粗く、利用ユーザ想定Q&Aや、ビジネス部門データスチュワート方面へのインプット等まだまだやることたくさんありました。

解像度が低い状態の超雑タスクリストです笑。プロジェクト初期時点では全作業を網羅するのは無理なので、あくまでも「プロジェクト遅延要因や不安要素を早めに解消する」が大事かなと！

LookerStudioの全般設計

Looker導入当初はLookerで一部集計ロジック持っている部分もあったのですが、責務分離やクエリコスト量削減観点から2年前にデータ基盤に全て集計ロジックを移植させました。なのでLookerのExploreでは汎用的なテーブルや集計結果をjoinさせてるだけだったので、これをデータ基盤に寄せることにしました。

LookerStudioのデータソース設計で考えたことは「カスタムクエリは保守運用コスト観点から極力使いたくない」「権限設計周り」「データ処理量などのクエリコスト観点」の3つです。
先ほどのLookerのExploreをLookerStudioで再現しようとするとカスタムクエリ祭りでしか再現出来無さそうでした。カスタムクエリは便利だし、混合データソースも使い方がわかれば、かなり武器になりそうでしたが、保守運用観点でかなり厳しいと判断。Lookerはgitでソースコード管理できますが、LookerStudio関連はソースコード管理一切できないんですよね〜。

Exploreの移行は、特定の部署しか使ってないものはBQ直接参照してもらうで良くね？みたいな考えもあり、利用部署と工数セットで移行対象決めてましたね。

権限周りについては、データソースをいじる人=データ基盤開発保守運用チームに閉じるで良さそうと判断。ゆくゆくはビジネス部のデータスチュワートにSQL周りをinputすれば出来なくはないが、絶対今ではないなと。
最終的には以下の権限設計でいきました

• データソースの作成はデータ基盤チームがやる
• データソースの閲覧権限はデータ基盤チーム + レポート作成する各部のデータスチュワートのみ
• LookerStudio利用者がBQなど好き勝手接続してレポート作成することはなく、必要最低限のメンバーのみがデータソース経由でレポートを作成できる

大まかな設計と保守運用ラインはこういうイメージで、各部のデータスチュワート的ポジションの方とすり合わせました。データソースは我々が作る。カスタムクエリ由来のものはなるべく作らない(赤線)。レポート作成者は、データソースのことは気にせず必要なレポートを必要な方に必要な権限で付与するのみ！

※saturnはデータ基盤、saturn_lookerはlookerのExplore相当を基盤で再実装したデータセットです

データソース周りで固めた方針はこんな感じかな

• looker用に作成したテーブルからデータソースを作る(基本)
• pii情報など特定のデータをjoinさせなければならない時だけ、カスタムクエリでデータソースを作る
• データの認証情報はSAを利用、データの更新頻度は12時間をデフォルトとする

ダッシュボード移行

これがホンマに一番地獄でした笑。

まずやったことは各方面に、業務上頻度高く見ているダッシュボード(優先度高)は何か？洗い出してもらい、移行対象をガッツリ選別しました。難しそうなダッシュボードから、LookerStudioのレポート作成で実際に再現してみて、使い勝手を知り、ある程度「型」がわかってきたら後は延々と全部移行作業していくのみ。。。

見た目は一旦最低限の再現に留めます。スタイル周りの微調整はかなりいろいろ出来ます。棒グラフや折れ線だけじゃなく、表現力結構高いです。

BQ側の参照元テーブルに実装足りないものあればデータ基盤側を修正したり、再現出来ないやつはLookerの実装を見たり、Lookerが吐くクエリ(bundeljsみたいなやつ)から推測していったり、、。それでもキツイものがあれば、仕様変更の打診などで要件を落としたりして対処。正直量が多かったですが、Looker利用ユーザーの皆さんが普段から不要なダッシュボードを消したり、カスタマイズ性が強いものは作らずテンプレぽいものを作ってくれたおかげで、かなり助かりました。

レポート関連で固めた方針はこんな感じです

• Lookerと違いフォルダという概念がないためレポートの「命名規則」を大事にする
• 企業IDや部署階層など、必須条件やデータ量が莫大するものに関してはパラメータで制限
• コントロールは利用者に設定させたいもの、フィルターは利用者に設定させたくない条件などにする

切り替え付随業務周り

このあたりはざっくり解説する程度で。

• 監査ログ周り
  • 情シスとSREチームに相談。情シスが何を知りたいのかを聞き出し、その情報をまとめる
  • 現Looker/移行後LookerStudioでのデータ可視範囲設計、監査ログについてまとめ、差分無いですよね？大丈夫ですよね？の確認をする
  • 監査ログ周りはLooker Studio のログイベントに全部書いてあったので助かりました
  • 「誰が」「何を」「何した」まで細かくログ取れてることも確認。直近の俺の動きが全部見えてる！笑
• アカウント発行周り
  • 各部門長にアカウント発行対象をヒアリングし、リストを元に情シスに打診
  • 今後の部署異動などによるアカウント発行/削除周りの管理運用フローも依頼して託す
  • 発行依頼！頼みます！おしまい！
  • 20名発行したとしても年間20万いかないぐらいですもんね。やっす！！！
• SalesForceへの埋め込みダッシュボード
  • Lookerの埋め込みURLをSalesForceに貼り付け、ビジネス部門がよく見るダッシュボードを連携してます。SalesForceとLooker両方のアカウント所有者が見れます
  • URLにパラメータ設定できるため、SalesForceの顧客ページから顧客IDをURLにわたすことで、各顧客ごとの集計済ダッシュボードを表示させてました
  • LookerStudioではこのパラメータ周りが無理だと思ったので、当初はSalesForceに「LookerStudioのレポートURLを記載する」で行く予定でした
  • 後輩がこの記事を見つけてくれてLookerStudioでも実現出来ることが発覚！マジで神、感謝
• Slackへのスケジュール配信
  • 各顧客チャンネルへのダッシュボード連携だけでなく、各部門が見ている数値類、全社展開しているものなど信じられないぐらい配信してることを知る。移行超ヤバそう
  • LookerStudioはメール配信しかないため「slackへの定期配信」は諦めます
  • その代わりslackのリマインダー機能を使って、定期で「見せたいLookerStudioのレポートURL」を投稿させます
  • 移行対象をめちゃめちゃ精査し「このタイミングで廃止」「置き換え対応する」「置き換えはしないがLooker解約まで通知し続ける」の3パターンに分類
  • 強い意志を持ち9割廃止しました。「あったら嬉しい」系は全部抹消です。
  • 有るor無いの二択なら有る選ぶに決まってる。本当に定期的に見せたいの？それ何人ぐらい見てる？見て無くね？
  • 本当にそれ全社に見せたいなら、見せたい人が意思を持ってやってくれ！という想いで
  • 配信スケジュールも時間帯バラバラだったので、昼過ぎに統一させる。これで管理コストめちゃめちゃ軽減しました、ヨカッタ！

slack通知は200種類ぐらいあり絶望でしたが各部門に意思を示せたゆえに9割削減できてヨカッタ...。こんなに丁寧にまとめたのにほぼ移行対象外というｗ

周知フェーズ

7月前半に全社周知されたものの、細かい移行スケジュールなどは伝えてない状況です。大事なのは「不安にさせないこと。機能は殆ど変わらないため、業務で困らないよ」

周知でどこまで話す？移行スケジュールどうする？などは、ビジネス部で一番Looker使ってるデータスチュワートの方にまず打診し問題無さそうと判断貰い、次にビジネス部門長にレビューいただき、全般齟齬なく方針も良さそうだという事がわかり、ようやく利用ユーザへの全体周知という流れで進めました。
やはり様々な業務フローに組み込まれている以上、伝え方や段取りをミスると社内混乱や反発が起きかねないので、(極端な表現ですけど)現場メンバーから部門長までの根回しした結果、方針なども問題ないことがわかって自分も安心して進められました。ヨカッタ。

資料は移行期間、変わらない点(重要)、変わる点(サクッと)、具体の画面を実際に操作しながら当日Q&Aしていく感じで共有しました。

所感

• 愛したLookerを卒業するのは辛かったですが、LookerStudioが想像以上にデキるヤツでした笑
• とはいえ諸々コード管理出来ない部分は辛いです。「DWHに全て持たせてデータソースに極力持たせない」「レポート作成権限を一部の方に閉じる」で何とかしていくしかないかな〜
• データ処理やクエリコストの兼ね合いから、Lookerが持っていた集計ロジックを全てDWHに移したんですよね、2年前に。あれMVPだわ
• 今までLooker開発保守運用してくれたメンバーのおかげで、殆ど単純移行作業だけで済みました。きれいに実装してくれてありがとう！
• 各部門、全てのユーザーの多大なるご協力により、1ヶ月で移行しきれた！本当に感謝
• BIツールはあくまでも手段であり「解決したいものは何？」が大事。このタイミングで「解決したいもの」の取捨選択出来て良かった。不要になったもの全部消せたぜ
• LookerStudioデータソース周りの設計実装は全然改善の余地ありです。もっと詳しくならねば

以上です。ありがとうございます！少しでもLookerStudioへの移行作の参考になれば