はじめに
この記事は フリュー Advent Calendar 2022 の19日目の記事となります。
概要
Looker導入の経緯とその普及活動について、実体験をもとにつらつらと。
前提知識
BigQuery
Looker
業界の専門知識
データ分析環境の古さ
弊社におけるプリントシール機情報の分析は極めて後進的でした。
例えば1ヶ月前にどういった人がプレイしてその人が次プレイしたのはいつか、その人はプリのリピーターか、などを取得するためには毎回データエンジニアがガリガリSQLを書いて抽出する作業をしていました。
当然時間もかかりますし人によって抽出方法（条件）が微妙に違っていたりしたので数字にズレも発生していました。
そこで気付きました。
あまりに非効率だ！
と。
データエンジニアにとってもデータ利用者にとっても、より良い環境を用意していかなければいけません。
Looker導入
そこでついにLookerの正式導入ということに至りました。Lookerについて、私が特に良いと感じた点は「簡単なデータであれば利用者が抽出可能」ということ。依頼があるたびにSQLを叩いてレビューしてグラフに成形して提出する、という手間とコストの掛かる作業から解放されるときがきたのです。
データ自体はすでにBigQueryに入っているため、今回データエンジニアがやるべきはLooker環境の構築のみです。
LookMLでサクッと書いちゃいましょう。
はい、書きました。（全然お見せできず申し訳ありません。。）
実際にはLookML初見から1人で3ヶ月ほどかけて使える状態まで持っていき、今現在も少しずつ改善を繰り返している感じです。
元々SQLでガリガリ抽出する作業を行っていたため、どういったデータ構造か、どうすれば効率よく抽出できるかがわかっていたので、Looker環境の構築自体は非常に簡単でした。新規部署で一から環境構築となるともう少し手こずる気がします。
チームでの稼働に向けて
多くのチームや企業であると思うのですが、BIツールを用意したから使ってもらうというフェーズに入ったときに、いまいちみんな使ってくれないということがあるかと思います。
ここで大事なのはテクニカルスキルではなくヒューマンスキルです。（カッツ理論）
数字を扱うものは基本的にエンジニアのほうが食いつきが良いため、そのあたりの人から丁寧に説明して利用頻度を上げていきます。エンジニア以外の人に対してはエンジニアが率先してLookerを使用してデータを用意してあげましょう。SSOT（Single Source Of Truth）が担保されているため安心してデータ提供ができ、SQLを書く手間がないため非常に時短で提供ができます。なによりもLookerでデータを見ることができるという事実を広めていくことが重要なのです。
（こんな感じの見るだけで一通りのことがわかるダッシュボードを用意してあげることも有効ですね。）
ある程度広めたら関係者以外にも情報発信をしましょう。外堀を埋めていく感じです。
ここまでしてようやくデータエンジニアの役割を達成できた状態です。
今後の目標
現状、プリントシール機の情報をリアルタイムで分析することができていません。
解決策としてデータ通信の抜本的な改善が必要で、例えばPub/Subでデータを送受信しFunctionsで加工しBigQueryに投入する、といったフローを構築していこうかと検討中。。
まとめ
全然技術的なことが書けていませんね。。
ただ今回書きたかったことは書けました。
データエンジニアの業務は多岐にわたります。
個人的な感覚ですが、データエンジニアに必要なスキルは技術力だけではなく、問題を認識・理解し、解決に導く最適な手段を用意できる力も必要だと考えています。最適な手段がExcelでの提示なのであればそれでも良く、あくまでも利用者の視点に立って検討することが重要です。