2018年9月の完全運用移行を経て現在に至るものの、山邉氏は「一般ユーザー向けのUI/UX（ユーザーインターフェース／ユーザー体験）が熟成度が低い。ドラッグ＆ドロップなどUI的な機能面はもちろん、日本語フォントへの追従や色味といった不満点は確かに残る」と指摘した。
だが、「数字の信頼性が向上し、社内コミュニケーションの基点になった」「想定以上に非エンジニアでもLookMLを使った開発が可能」「BI側にデータを取り込む必要がないため、システム連携に伴う障害が減った」「比較的コストを気にせずに、希望者にアカウント発行ができる」といった利点も並べた。
同社は今後、他のSaaS連携によるシステム強化や可視化対象のスコープ拡張、ログインしない受動的なユーザーにはSlackからの通知による認知や活用の向上を目指しつつ、より最適化したシステムの構築とビジネスの拡大を目指すことも明らかにした。
言葉の定義の違いをどう埋めるか
次に登壇したリクルートライフスタイル データエンジニアリングユニット データソリューショングループ data planner 近藤慧氏は、LookML導入がこの4月であるため、導入までの課題を中心に語った。同社は「じゃらん」「ホットペーパー」が有名だが、近藤氏の部署は「Airレジ」「Airシフト」「Airペイ」などの実店舗業務支援を中心とした「Air」事業を展開している。
日々の売買業務や商品管理、収益といったリアルデータとともに、ウェブやアプリケーションから生成されるデータの融合に課題を感じた同社は、データ加工やテキスト化を経て、Google Cloud Platform（GCP）が提供するDWHサービス「BigQuery」に投げ込んでいた。その結果を「Tableau」などのBIツールで可視化に取り組んできたが、今回新たに加わったのがLookerである。
リクルートライフスタイル データエンジニアリングユニット データソリューショングループ data planner 近藤慧氏
Lookerの導入背景について近藤氏は「データの民主化がある。誰でも使いたいときに使えるDWHとBIツールが必要だ」と、データ界隈では著名なThomas H. Davenport氏の言葉を引用しながら、社内システムの改革と素早い意思決定を目指した。
だが、導入数カ月というタイミングでは、大きな課題が改めて明確になったという。それは営業部門やウェブマーケティング部門における「店舗」という言葉の定義の違いだ。データ抽出のフラグがチームによって異なるため、店舗という言葉の意味の違いがコミュニケーションコストにつながるようになったとしている。
この課題はLooker側で吸収することで改善したが、BIツールも使う人もいれば、以前から社内で稼働していた“野良BI”、場合によってはBigQueryからSQLで通知を引き出す人もいれば、アプリケーションに搭載されるBI機能を持ち出すケースもあったという。
この混沌とした状態を改善するためにリクルートライフスタイルが提示したのは「抽象的なハブレイヤーの構築」である。事業の中心となる部分にハブとしてLookerを実装し、データセットのモデリングや既存DWHとのフィット化は、モデリングと定義をコードしして管理するか、GitHubによる履歴管理などを用いたツールで補完。前述した言葉の定義についても可視化したデータはすべてLookのダッシュボードなどを通じて発信するようになると、多くの課題が解決したと語る。
リクルートライフスタイルは可視化とデータラベルなど利用者の意思統一を図るためLookerを実装
それでも近藤氏は「ツールだけでは銀の弾丸にならない」と説明。「Lookerは優れたツールだが、それだけではなく、ツール導入以前の課題は組織や人間に付随している。導入時は事業全体に関わるビジネスチームや製品チーム、データチームなど各部門からメンバーを招集し、組織的アクションに至った」（近藤氏）と“推進センター（Center of Excellence：CoE）”的アプローチが有用な一例であると示した。
