データ民主化の夢と幻想を追い続けて
はじめに
仕事でデータを扱うようになってから幾星霜。未だにこれだと思うようなツールにであっていません。
どのツールも良いところや悪いところがあるのですが、みんなで同じものを使わないと意味がないというデータツールの要求がいろいろややこしくさせているようにも思います。
ここでは私がデータ民主化に取り組んだ今までの足跡を書き留めておこうと思います。どういった課題に立ち向かい解決しようとしたのか、ある意味私の人生を切り取ったような記事になるかも知れません。
データとの出会い
業務でデータ分析をするようになったのは、私がNetyearで働いていた頃です。2005年くらいの頃の話です。もうすぐ20年経つと思うと恐ろしいですね。
当時から私はIAとしてHCDプロセスを運用していたので、新しく作ったUXの効果を測るために、PCサイトはSiteCatalyst、モバイルサイトはRTMetricsをつかって分析していました。
ただ当時のツールはどちらかというと外部流入別にユーザーセグメントを切って、コンバージョンしたかどうかを測るツールであり、UXが変わったことによるユーザーの態度変容を可視化するには機能が足りていませんでした。
また、クライアントワークということもあり、レポートを納品してタスクとしては終わってしまいます。当時はあまりデータ民主化のことについては考えていませんでした。
ガチ・データドリブンの世界
2011年にグリーに転職をし、初めてプロダクト運営に関わったのですが（そこから先はずっとプロダクト運営会社に在籍しています）、MediaWikiを魔改造したGREEWikiと言うものが当時あって、拡張タグを書くだけで、KPIモニタリング用のグラフが生成される環境になっておりびっくりしたことを覚えています。
今じゃ当たり前のMAUとかDAUなどのアクティブユーザー数指標であったり、継続率（コホート）のような指標についてもグリーで初めて知りました。あとKPIツリーの考え方やLTVについても。そういったデータが比較的簡単に可視化出来たのもすごかったし、A/Bテスト(有意差判定みたいな高度なことはしてませんでした)でのグロースハック検証みたいなこともしていました。
それらのデータはユーザー単位で集計されていたので、当時のSiteCatalystでは分からなかった特定の1ユーザー単位の行動を追うことができ、ユーザーの態度変容が分析できるかも？と思いました。
ただ、文系職メンバーは開発サーバへのアクセス権限がなかったので、あらかじめ定義された集計データを活用することしかできず、ショットの分析をする際はエンジニアに集計前データを抜いてもらう必要がありました。
その膨大なデータを分析する環境もなく、データ分析チームがたてたサーバに間借りしてたのを思い出します。
当時の私はRもPythonも書くことができなかったので、Excelで簡単な回帰分析を行うことくらいしかできませんでしたが…
グリーはある意味データの民主化には成功していたと思います。データガバナンスもしっかりしていましたし。ただ分析環境という意味では不足していました。私が2013年に退職するころに、まだリリースされたての頃のTresureDataをテスト運用していて、そのあたり変わろうとしていましたが私は使う前に辞めてしまいました。
新しい環境でデータ民主化の夢を見る
2013年にリクルートジョブズに転職した私は、前職での強烈なデータドリブン意思決定文化に慣れてしまっていたので、転職先でも同じような仕事がしたいなと思いました。
リクルートテクノロジーズにBigDataグループという組織が当時ありまして、そこのメンバーを紹介していただき、RJBのプロダクトのユーザーデータ集計によるモニタリング環境構築をしようとしました。
当初はIBM Cognosをつかっており、MAUやDAUなどのダッシュボードや1ユーザー単位の行動分析を行う環境など構築していただきました。
その成果物をソシオメディア様主催のイベントで登壇発表させていただいたりもしました。
その取り組みとは別に、RCAの方からDomoというBIツールを紹介していただき、自分が分析したい業務データをSQLを書かずに分析できるツールとしてこれは便利じゃないか？これこそがデータの民主化なのでは？と思い、Domoの普及に乗り出すことになります。Domoユーザー会で何度か登壇させていただくこともありました。
ただ今思うと、Domoはアカウント課金だったためアカウント数上限があり、ライトユーザーの取り込みに失敗したのと、閲覧だけの無料ユーザーもDomoChatに共有されたグラフだけ見れるという厳しい条件だったので、利便性が上がらず普及に失敗しました。
また、普段業務で見るツールはコンフルエンスとSlackだったので、そこから切りはなされたツールをわざわざ見に行くかといったら、それは厳しかったです。
他にもAccessの置き換えが困難だったことと現場でデータ抽出に使ってるSQLをDomoの処理にサクッと置き換えるのが難しかった点など、普及の障壁になったものは一杯ありました。
良かった点は、データモデリング（ETL）するパイプラインの処理をGUIとSQLと両方使い回せたことです。この機能があったので久々にSQLやろうかな、と思うきっかけになりました。
その後DomoはTableau勢力に負けてしまうことになります。ただTableauもDomoと同じ課題を解決していなかったので、同じ道をたどることになりますが。
アンラーニングでデータ分析スキルを養う
リクルートには当時STEP休暇という制度がありまして、最大4週間の有給休暇が取れつつさらに特別支給金がもらえるというすごい制度なんですよ。
こちらを活用してPythonで機械学習を教えてくれる社会人向けスクールに通うことにしました。
一カ月みっちりPython・Pandasを使った機械学習分析を学びつつ、空いた時間でSQLの書き方を復習していました。そのころ読んでいた本が「前処理大全」というほんでめっちゃオススメです。
この期間があったおかげで、スプレッドシートのデータを参照してColaboratoryで分析したり出来るようになりましたし、BigQuery上でSQLクエリを書いて自分でデータ分析出来るようになりました。
これらのスキルはPdM業務でもめっちゃ活きているのでやってて良かったなと思います。
データ基盤の運営を行う
2018年にリクルートマーケティングパートナーズへ移籍した後、いろいろあってデータ基盤を管理構築・データ利用推進する組織を立ち上げることになりました。
既存のデータ基盤はあったりなかったりで、あるものはその運用を引き継ぎ、ないものはゼロから立ち上げる、みたいな感じで走りながらルールを整えてつつ、利活用を推進するようなことをしていました。
当時、現場のメンバーはBQのデータをCSVでダウンロードしてGoogleDriveにアップしスプレッドシートでデータ分析をする、というかたが多く（今ならコネクテッドシートで一発で繋がりますが）、TableauなどのBIツールはあまり普及していませんでした。
また、Tableau CloudとBigQueryをつないでもライブでつなぐとめっちゃ重く、全然画面が表示されないという状況だったので（それは今もあまり変わってない気がする）、metabaseを検討している人たちもいたぐらいでした。ただし、metabaseはSQLが必須なので現場のメンバーでは使いこなせないという状況でした。
そこで、SQLを書かなくてもスプレッドシートのデータを整形して分析できるツールがあれば良いなと思い、nehanと言うツールを選定して普及に努めていました。
nehanはBQともスプレッドシートなど各種データソースと接続でき、ETLのパイプラインをGUIで構築でき、さらにデータセットの基礎集計機能もあるので、データの中身を可視化しながらパイプラインを構築できます。N:Nジョインしようとするとエラーで教えてくれたりもする優れものですし、クラスタリングや決定木などの機械学習処理もできます。
ただnehanは膨大なデータのパイプライン処理を一手に担うには荷が重く、既存のAirFlowやBQのスケジュールドクエリで構築されたELTフローについてはDataformやdbtに置き換えるような検討をしていました。
PdMとしてデータを扱う
2021年からPdMとして働いています。つまり、データ民主化を主導する側から利用者になったわけです。
利用者目線で行くと、一番しっくりきたBIツールは今の所ReDashかもしれません。metabaseとことなり、同一クエリ上で複数の読み込んだデータソースにアクセスすることができるからです。
ただそのReDashもSaaS版が2021年にサービス終了したりと雲行きが怪しいです。
それ以外で行くとLookerがいいかなと思います。高価なツールですけれども。
ちなみに現在会社でLookerを利用しています。ダッシュボード作成はTableauと同じ感覚で作れるのでラクです。
ただ、LookMLで定義されていないものが何で、定義されているものが何かをアタマに入れておかないと、ダッシュボードを作るのが急に難しくなります。
また、メジャーとディメンションの概念を理解する必要があります。こちらの記事を読んで大分理解が進みました。
正直SQLかける自分からすると取り回しが悪すぎるなと思います、Lookerの薄いBIというアプローチ自体は好きなんですけどね。
さいごにまとめ
結局自分はBigQuery→コネクテッドシートでスプレッドシート連携→スプシかLooker Studioで可視化がいちばんラクだなと思います。
BigQuery→Colaboratoryも最近よりシームレスになりましたし、最近知ったのですがColaboratory上のPandas Dataflameのデータとスプレッドシートを同期するInteractiveSheetの機能なんかもリリースされたりとどんどん便利になっています。
あとSalesForceのデータをスプシに取り込むコネクターがめっちゃ高性能でこれを無料で使っていいの？って思うほどです。（ただしデータ件数が多くなるとクラッシュしちゃいますが）その辺の記事はこちらでまとめているので、興味のある方は是非どうぞ。
ELTもスケジュールドクエリを駆使すれば小規模なら十分です。大規模なら、dbtかDataformをつかうべきでしょう。
DWHは今の所BQ一択です。なぜなら結局データ可視化のエンドポイントはみんなスプレッドシートだからです。であれば一番相性の良いDWHを選択するのが正しい道だと思います。
これが2024年現時点の私が出せる答えになります。もちろんこの環境でも課題は一杯あります。SQLがかけることが前提になっていますし。
素晴らしいツールが現れて、これらの課題を解決してくれる未来を夢見つつこの記事を終わりにしたいと思います。
こういう話もお酒も大好きなので、データの話しつつお酒のむ会とかあったら是非誘ってください〜