データが経営に欠かせない資産となる中で、データドリブンをどう推進していくかが重要になってきています。婚活サービス、恋活サービス、マッチングアプリなどを手がける株式会社Diverse（以下、Diverse）とデータプラットフォームを提供するLooker Data Science, Incによる講演内容から、BIツールの活用に関する課題と、それを踏まえて実現するデータドリブンな体制の推進方法を見ていきます。
従来の属人化しがちなBI運用を解消する
「すべての人へ出会いのプラットフォームを作る」をミッションに日本最大級の婚活サービス「youbride」や恋活サービス「YYC」、マッチングアプリ「Poiboy」などを展開するDiverse。同社は、データプラットフォーム「Looker」を活用しながら、データドリブン企業を目指している。
Lookerは2012年に設立されたベンチャー企業で、顧客数は1800社超。国内にもユーザーが多く、EC企業や通信、メディア、メーカーなど幅広い企業に採用されている。
Looker Data Science, Inc. Account Executiveの森永道氏はまず、Lookerが世界中で高く評価されている背景について、データ分析の現場で発生している属人化によるボトルネックや部署による指標の違いなどのデータカオスの課題を解決できる点と説明した。
データ分析の現場では、毎日同じようなSQLを書いたり、データそのものが属人化したりして混乱しがちです。従来のBIツールのアプローチはデータマートがサイロ型で管理が難しく、利用範囲も限られていました。そこでLookerは、データ定義を一元化し、エンドユーザーがさまざまなデータソースにアクセスしやすい環境を提供したのです。（森永氏）
森永氏によると、Lookerが従来のBIツールと決定的に異なるのは、今あるデータを分析することではなく、将来にわたって予測不可能に増えていくデータを、ガバナンスを保ちながら柔軟に分析することにフォーカスしている点だという。Lookerでは、Treasure Data CDPなどに蓄積されたデータをもとにデータモデリング層を提供するデータプラットフォームとなる。アナリストは「LookML」と呼ばれるSQLの抽象化言語でデータ定義を行い、クエリの結果を取得・表示する。ユーザーはWeb UIやWebへの組み込み、REST APIなどからデータを利用することになる。
「100%イン・データベースで、シンプルな定義モデル、SQLの再利用が可能、そして分析とビジュアライズもできる革新的なアーキテクチャを備えているのがLookerです」と森永氏は強調する。
分析担当者がいない中でLookerに注目
続いて、Diverseから、Lookerを採用した背景を説明した。マッチング事業を行うDiverseには、ユーザー同士がマッチングしたときのデータやユーザーがどういったプランを購入しているかなど、事業を展開するうえで不可欠な顧客データが膨大にある。それらを手軽に分析するためにLookerを採用した。
「Diverseでは3つのプロダクトすべてでTreasure Data CDPにイベントを送っています。ただ、SQLの知識の深い人は極めて少なく、データサイエンティストやデータアナリストなどの分析専任の担当者もいないという状態でした。また、当社のエンジニアはアプリケーションエンジニアが中心で、データ分析を専門で行っているわけではありませんでした」
そうした中で課題になったのは、データ分析や解析をどう行っていくかだった。かつてのデータ分析のフローは、（1）CDPでSQLを書く、（2）SQLの結果をスプレッドシートで管理しグラフ化する（スプレッドシート管理者が必要）、（3）出したグラフからこんなグラフも出してほしいと依頼が来る、というものだった。この（1）〜（3）を日々繰り返していたという。
このループの問題は、SQLの属人化とリソースの集中が起こってしまうことです。一部のプロダクトではツールを使って解消しようとしていましたが、そのツールを活用すること自体が属人化につながる面がありました。また、SQLの勉強会なども実施していましたが、間違ったクエリを間違ったまま使い回すということも起こっていました
可視化ではElasticsearchやKibanaを使っていたが、その運用についても設定した人しか使えず、後からどうなっているか確認したり修正したりすることが難しくなっていたという。
現場で発生していた「3つの課題」を解決
そこでDiverseが目指したのが「誰でも数字を出せる会社」だ。まず上記3つのステップのうち（1）Treasure Data CDPでSQLを書くところから見直しを始めた。
PrestoやHiveでクエリを書く必要があり、誰かが過去に書いたクエリのコピペが日常化していました。書いた人間以外は修正することが困難でした。Lookerでは、LookMLにYAML形式でdimensionやmeasureなどの集計項目を定義していきます。すると、セレクトボックスで簡単に項目を選択し、グラフを作成できるようになるのです
定義自体も手動で行う必要はなく、Treasure Data CDPのテーブルからLookerが「おおまかにいい感じに取り込んでくれる」という。こうした自動生成の際にはSQLのwhere句の、相当する部分の条件を手直しする必要があるが、一度定義して手直しすれば継続的に使えるため、メンテナンス効率は非常によく「SQL属人化から解放された」と評価する。
次に、（2）SQLの結果をスプレッドシートで整理しグラフ化するについては、これまではさまざまな数字を複数のスプレッドシートにまとめていた。また、計算するための中間シートやうまくスプレッドシートに書き出されないところに修正依頼をスプレッドシート管理に出すといった手間があった。
Lookerでは、日々追いたい数字は種別ごとにダッシュボードを作り管理しています。どういう条件で数字を出しているかは誰でも見られる状態です。Treasure Data CDPから直接データを持ってきているので、スプレッドシートの管理をする手間もなくなりました
最後の（3）出したグラフからこんなグラフも出してほしいと依頼が来るについては、「前のグラフに追加で条件を加えてほしい」「時間が経ってから依頼がくるので記憶がない」「SQLを再度書き直すため時間がかかる」といったことが課題だった。これに対してLookerでは、「条件の追加はFilterを操作するだけで誰でもできるので、少しの条件追加では依頼が来なくなりました」と熊埜御堂氏は説明する。
Lookerを導入することで得られた成果とは
こうして徐々に課題を解消し「データドリブンな会社」へ近づいているDiverseだったが、エンジニア目線で特に注意を払ったこともあったという。例えばLookMLの整備は、ある程度のSQLの前提知識が必要となった。
「SQLの知識のある人が手を入れていくことが必要です。また、テーブルによって遅いクエリが発生することがあり、その調査を行う必要がありました。もしクエリを速くしたいと思ったらTreasure Data CDPならTimeでしっかり絞るといった知識は必要になります」と熊埜御堂氏は話す。
このほか、Slackに日々の数字だけでなくグラフ化したものを投稿して社内に告知したり、Lookerの勉強会を実施したりするなどして普及を図っていったという。「Lookerはクリックすれば使えてしまうのですが、最初に触ってみないとそこまでいきません。数字を見るためにこんなツールがあるという、最初の働きかけを行うことが重要になってきます」と話す。
そのうえで、Looker導入の成果として、「Lookerを整備するうえで間違っていた数字を見つけ、正すことができたこと」「Lookerのダッシュボードを見ることでデータ分析に関心を持ってもらえるようになったこと」を挙げた。このほかにも、「さまざまな分析を行って簡単に結果を見ることができるようになったこと」「ユーザーの特定の行動にかける時間やAPIレスポンスなど、これまで見えていなかったものも見える化できたこと」など多数の効果を実感しているという。
