※ Retty Advent Calendar 15日目の記事です
おしながき
はじめに
Rettyでは施策の実行や目標設定といった様々な場面で
データを積極的に活用しながら日々の業務を回しています。
"データ活用" という言葉は今でこそよく聞く言葉ですが
その実現のためには行うべきことがたくさんあるため苦労しています。
今回は、ベンチャーとしてのデータ基盤の取り組みの一例として
その活動をご紹介できればと思います。
お送りするのはソフトウェアエンジニアをやっています @takegue です。
ベンチャー企業とデータ活用
データ活用は、昨今の企業では当たり前に言われているようなことで
今さらなぜ苦労するの？とか思いの方もおられるかもしれません。
まずはそのあたりからつらづらと述べておきたいと思います。
完璧さよりも早さを重視する
"Done is better than perfect" という言葉が尊ばれるように
とりわけベンチャー企業では「完璧さ」よりも「変化の速さ」を求める傾向にあります。これは
「考えて考えて考え抜いて結論を出す」 よりも
「一旦出して反応をうかがってみよう。ダメだったら次に行こう」ということです。
データ活用の主たる用途の一つである分析という行為は、専ら前者に属する行為です。 「1ヶ月分析に時間をかけて現場にとっては当たり前の事実しかわからなかった。」ということは我々にとっては致命的で、ともすれば "分析自体は価値である" だとわかりつつも 単純に"分析という行為"に時間をかけつづけてしまうことは 避けたいコストになります。 そのため一種の矛盾を抱えてしまいやすくなります。
ベンチャー企業におけるデータ活用の難題の一つは、こういった環境のもと より短期間でより効果的な分析を行える環境を整えていくことにあります。
Rettyにおける現状
短期間で効果的な分析を行なっていくための環境としては、データの集約的な場である データウェアハウス (以下DWH)をはじめとしたデータ基盤を構築できることで活用の速度がより進むことになります。 しかしながら、この基盤開発は企業ごとのフェーズやデータ活用に対する温度感によって課題も実体も千差万別になります。
規模が小さい企業ほどデータでわからないことの方が多くDWHのROIに懐疑的になるでしょうし、成熟した企業ほど完成されたセクショナリズムが活用の大きな壁になることが必至です。
Rettyの現状は、ちょうどこのこの中間の状態で スタートアップというほど小さくないためデータもありますが、 大企業というほど障害となるセクショナリズムは確立されていない状態にあります。 だからこそですが、DWHの方向性や有用度を決める大事なフェーズで 様々なことを実験しつつ利用価値を最大化していくべきえ大切なタイミングと考えています。
DWHの開発で大切にしていること
RettyのDWH開発で大事にしているのは端的に言えば
基盤 としての側面よりも プロダクト としての側面を重視していくことです。
プロダクトとしてのUXを大事に
もっとも大事にすべきは "使われるDWH" であることです。使えないデータをため続けるDWHはゴミ集積場となんら変わりありません。そのためにDWHを一つのプロダクトとしてUXを改善していくことが必要であると考えています。
- よく行う分析ほど手早く実行できる状態になっているか？
- データを見る側がデータを使う効果を実感できているか？
- 使いたい思えるデータをDWHが取りそろえられているか？
こういった観点をふまえながら、プロダクトとしての改善を行なっていきます。
DWHのUXを考えていく上で最も難しい点は、作る側/使う側にも少なくない技能を求める点にあります。 データがあれば何ができるのか、 何が分かるのか？意図したとおりの分析をするためには、どのようなデータがあれば良いのか？信頼足りうるデータを整備していくにはどのようにシステムを作れば良いのか？といったことにある程度の下地が必要となります。
データは味方にできれば強力な武器で、それこそ使う人が使えば生産性を数十倍にするほどの武器です。ですが使い手によって効果が全然変わる代物でもあります。 時には、これらを伝えるためDWHを作り運用していく側が啓蒙し活用を進めていくことも大事になります。 利用者の立場になってみて、はじめて気づく改善点も多々あります。
プロダクトとしての変化を大事に
データ活用のニーズを柔軟に捉え、変化していくためには DWHというプロダクトも変化できるという下地が必要です。
ユーザ規模の変化、プロダクトの方向性の変化、社内のニーズの変化などなど これらの変化に耐えうるように設計/開発を行なっていきます。その変化を許容するために早すぎる最適化をさけることも大切と考えています。
開発者として横断的な動きを大事に
DWHは様々なサービスでのパイプライン処理になることが多いですが
DWHのUXを追求をしていくことが大事とはいえ
ベンチャー企業のような人数規模が大きくない会社では
常に人手不足というリソースの問題がつきまといます
以前の記事 Webサービスを支えるユーザログ基盤開発＠Retty において、開発中のRettyのログ基盤についてご紹介する機会がありました。 技術スタックとしてはフロントエンドに属する話でしたが この開発はDWHというプロダクト開発の一環として行っています。
DWHの開発では各工程で分担し、開発効率化を図ることの方が多いと思いますが 全体として開発を通してできるようにすることで サイロ化を防ぐことができます。
このような動きをするためには、開発者としてのフットワークの軽さだけではなく 同時に要素技術を絞るといった動きも必要になります。
RettyにおけるDWHの開発プラクティス
ここでは具体的に我々がどのようにこれらを実現しているか、 どのようなツールを使っているか紹介していきます。
DWHそのものだけではなく、DWHの利用を推進する周辺の道具は 生産性を高めるために必要な道具になります。 これらを紹介していければと思います。
BigQueryを中心としたデータ基盤
RettyにおけるDWHは現在BigQueryを中心に構築をされています。 そのため分析者の観点では、BigQueryをさわる(=SQLを書く)ことができれば あらゆる分析ができる状態になります。
BigQueryの良い点は、分析者が使うときの関心事がとても少ないことだと考えています。 SQLでスキャンするデータ量さえ気にしていれば基本的に問題はありません。 ストレージや分散ノード、それに伴うコスト計算などなど 本来であればこれらの要素を考える必要があるのですが、 BigQueryではこれらがうまくブラックボックス化されており、驚くほど簡単に使えます。
このような素晴らしいサービスであるBigQueryを中心に据えたことで 少人数でも驚くほど利用価値の高いDWHの構築/運用を行うことができます
アウトプットを最大化するためのダッシュボードツール
ダッシュボードツールは、分析に携わるものとして大きな悩みの一つです。
- 頑張っては作ったものはいいものの、結局誰もみなかった
- 簡素すぎると資料としての価値が低く作った人にしか理解できない
といった問題がよく起こります。
スプレッドシートによるお手軽ダッシュボード
BigQueryではスプレッドシート出力の連携を簡単に行うことができるため 単純なデータ出しや探索的調査ではスプレッドシートが活躍します。 複数の調査結果をまとめたり、小回りが効きやすいため9割ぐらいの用途で スプレッドシートで十分なことが多いです。
ただ、分析をこなしていくうちに チームごとに定期的に見たい指標だったり 集計作業を単純化するため定期的に自動実行したいことが増えてきます。
Rettyではこれを実現するために、 自由に使える簡単なSpreadsheetのバッチ処理のランナを用意しています。 中心的な機能は、「定時にBigQueryのクエリを実行してスプレッドシートに反映する」だけです。
ユーザは、定期的に実行したい行を追加してSQLを貼り付けるだけで 簡単に定期実行するSQLを追加することができます。 またスプレッドシートに貼られたグラフを特定のSlackチャンネルに 貼り付ける機能もあるので、例えば移動中などの間にグラフデータを確認するなどの利便性もあります。
redashなどでも同様のことは実現できますが
- サーバなどのメンテナンスコスト
- グラフなどのデータ処理能力/表現能力
- ダッシュボードの利用度の監視 とその運用
といった面でデメリットと
全てのダッシュボードツールでいえることなのですが、 ダッシュボードツールに合わせたSQLの書き方、みたいなものが必要になります。
スプレッドシートとピボットテーブルを使った手軽さがまさりつつあります。
データポータル (Datastudio)
先ほどいったようにダッシュボードはその運用がされづらい、という問題をはらみます
運用されなくなったダッシュボードは正確さ等にかけ 間違った判断をもたらすことになるため、「運用されなるぐらいなら作らない」 というのは一つの解ではあると思います。
一方で、
- 浅い分析の回数を減らすために優れたダッシュボードを一つ用意する
も一つの解になりえます。
どちらもできる手段を用意しておくことが、大事であると考えています。
そんな時の手段として, データポータル(旧: データスタジオ)を利用したりします
データポータルが素晴らしい点は
- パワーポイントの様なグラフィック面での柔軟さ
- データを深掘りするインタラクティブな操作
を簡単に実現できることです。
具体的な数値等は伏せますが、 例えば以下のようなダッシュボードを簡単に構築することができます。
弊社のデザイナさんと共同して作ったものですが、上記の1ページで
- 経路別での遷移率の確認
- デバイス別の遷移率の確認
- 任意の期間での集計および前期間との変化の比較
といった操作ができるようになっています。
データソースのUX/DX
どのように情報を提供するか？ 改善するか？
データソースの集約化
「SQLを覚えればあらゆる分析が行える」状態を実現するために サービスに関するあらゆる情報をDWHに集約化していく必要があります。
ユーザイベントのログ、DBのマスターデータといった点はもちろんのこと サービスのパフォーマンスメトリクス情報やシステムログ等もDWHに集約していきます。
さらに一歩踏み込んでサービスに追従する開発者のアクティビティの情報も RettyではDWHに集約しています。
例えば Githubの通知データです。
- いつissueが作成されたか？それが解決されるまでの時間は？
- Pull Reuqestのレビューまでの時間
- 個人に関するOrgnizationにおけるコミット量
これらの情報が現在のRettyのDWHには集約されており 必要とあれば個人の開発に関するパフォーマンス情報の集計することも可能です。
コストに関するデータをDWHに入れてしまえば、ROIも確認できますし どこがコストのボトルネックを占めているかも一目瞭然となります。
個人的には、DWHに入れるデータソースは 必要とされる前に入れておく、ことが大事だと思います。 これはデータを必要な形に加工する時間よりも有益なデータがたまるまでの時間の方が長いからです。
なぜなら、データはいれはじめてから貯まるまでに時間がかかるためです。 多少使う頻度が少なくても、あるとよそうだなとおもったものは 雑でも良いので先にDWHにいれるようにしています。
本格的につかうようになったタイミングで、安定的に稼働かつ 使いやすい形に加工します。
As-is ではなく As-was
データベースなどのテーブルの転送を行うときには その時の最新の状態ではなく、当時の状態が再現できるようにしましょう。 アプリケーションのロジック等によるデータの加工もふまえて データの投入が行えるとより良いでしょう。
分析者も巻きこみDWHの品質改善を行っていく
より効果的なDWHを作るためには、使う側の観点を持ちながら整備していくことが大事です。 そのために心がけていることは、「分析者でも」品質改善を行えるように 全体像の開示および開発の余地を広く保つことだと考えています。
技術スタックはSQLを中心とする
分析者と協調的に開発するために、おおよその部分がSQLだけで 開発等が行えるようにします。
このための動きとして
動きを行う必要があります。
仮想テーブル (View) <-> 実テーブル による スキーマのPoC
DWHにおけるテーブルは スター型スキーマ と呼ばれる
正規化された状態ではなく様々なテーブルが結合された非正規化の状態が好ましいとされています。
これには
- 分析者が必要とするテーブル構造の負荷を下げるため
- カラムナ型DBではインデックスや外部制約などの制約が課せないため非正規化しておく必要がある
といった理由からです。
非正規化された状態というのは意外と取り扱いが難しく
という問題が発生します。
このために「現場のニーズに合わせた迅速な変化が可能な」スター型スキーマを用意する必要があります。
ここで活躍するのは BigQueryのview機能です。 viewはデータベースにおける仮想テーブルで、利用者にとっては実テーブルののように振る舞いますが、実体は実テーブルに対するただのSQLです。
これをどう利用するかというと、弊社ではview機能を用いて
「分析者が使いやすいテーブル 分析者 がつくります」
このために原則viewと実テーブルの区別をつけないようにSQLを書くようにします。 そしてこのview自体は分析者らが中心に洗練していき、あるタイミングにおいて実テーブルに差し替えます。
BigQueryのビュー機能を活用することで、UXにたったテーブル開発ができます。 またその開発はBigQueryで全て閉じるため敷居が低くなります。 なおかつ分析者でもDWHの機能開発を行うことができるようになります。
実テーブルに差し替えるタイミングで、バッチ処理を記述することになりますが それはviewのSQLを実行するだけなので、バッチ処理への組み込むのも簡単です。
SQLによるView/データソースのユニットテスト
SQLを中心とした開発の最大の難点は
他人が書いたSQLは読めない ことが挙げられます
コード規約や WITH句をはじめとした CTEを使うことで
ある程度見やすいようにSQLを書くことはできますが
- 入力(元テーブル)のデータに関する知識が不足していて入力想定しているかわからない
- 出力における制約 (どのカラムでユニークを想定しているのか ) も記述した本人しかわからない
といった、SQL自体が非常にコンテキストが高いものになりやすい性質があります。 これらがSQLが属人化するだけでなく分析の質を担保しづらいものにする最大の原因で チーム開発を妨げる最大の障壁と考えています。
そこで弊社では
「SQLでテスト駆動開発ができる仕組み」 を提供し 分析者がSQL自体のテストを記述できるよう にしています。
BigQueryのViewは利用されないviewを含むこともできるので、
特定のprefix (図中では __check ) を テストケースとして認識して
CI等でテストを稼働させるようにしています。
この機能自体は、実テーブルでもViewでも同様に利用できるため様々な検証を SQLで完結することができるようになります。
例えば、以下のような確認項目をSQLで確認することができるようになります
- ユニーク制約の確認用途: 安心して group by / joinができる
- カーディナリチェック: 意図しない属性が増えていないか確認できる
- 異常値: データソースの問題かSQLの問題かの切り分けに有用
- ありえない組み合わせの確認 → データソースに対する制約の記述
- データskewの確認: (-> Performanceに直接がでる)
おわりに
これまでの取り組みを色々振り返って整理しているうちに、思わぬ大作になってしまいました。 ここまでお付き合いいただきありがとうございした。
最後にお決まりになりますが、
Rettyではサービスのデータ基盤開発を担う人材を絶賛募集しております。
データ活用の方向性や利便性を高めてつつ、自らデータ活用していくような
カオスですが面白いフェーズにあります。
この面白い世界で一緒にやりませんか？ ぜひお待ちしております。
