はじめに
この記事はBASE Advent Calendar 2022とLooker Advent Calender 2022 2日目の記事です。
こんにちは。BASE 株式会社 New Division BASE BANK Section にて、Engineering Program Manager (以下EPM)1をしている永野(@glassmonekey) です。
私達のBASE BANK Section チーム (以下 BANK チーム) はBASEの中でも、新規事業の金融系のプロダクトにフォーカスしたチームになります。特に新規事業なので、日々の不確実性にどう向き合って行くかをテーマに日々仕事をしています。
不確実性に向き合うためには、日々リリースしていくしかありません。そしてそれを観測するための分析基盤も日々のリリースに耐えうる、つまりはアジリティを保つ必要があります。
今回はどのようにアジリティを保ってデータ基盤を日々運用しているかをテーマに導入と活用の紹介をいたします。
データ基盤をこれから導入しようとしている方や、データ基盤を社内に普及させようと尽力されている方々の参考になれば幸いです。
ちなみに、今回の内容は7月に開催されたLookerユーザー会で発表した内容がベースになっているので、そちらももしよかったら御覧ください。
EPMの役割
最初に、私の役割であるEPMとはなにか？を簡単に説明させてください。
私は現在、YELL BANKというプロダクトのEPMをしています。 EPMの役割としてはざっくりですが、以下のようなことを日々やっています。 * 開発のリードや開発プロセスの改善 * 設定したリリーススケジュールへの責任 * プロダクトのクオリティの担保 * プロジェクト、プロダクトの技術的な阻害要因の排除 * ステークホルダーとの適切なコミュニケーション * 意思決定やエスカレーションの実施
特に私としては、早期リリースとリリース頻度には重きを置いていています。 最初の企画では3ヶ月かかる想定のものでも、スコープの調整をすると1ヶ月になりそうか? もしかしたら、工夫すればもっと早くリリースできないか？を考えていく感じです。
なぜなら、我々のつくっているプロダクトは不確実性だらけなので、わからないことばかりです。 それらの不確実性と向き合っていくには少しでも早くリリースして学習を重ねていくしかありません。
では、リリースした結果を学んでいくにはどうしたらいいでしょうか? 特にチームメンバーは全員がエンジニアというわけではありません。それぞれの立場で見る景色が違うため、KPIのような一定の定量的な指標を北極星にして目線をそろえていく必要があります。
そこで、目線をそろえるために定量的な指標を管理していくためにデータ基盤が登場します。
データ基盤とEPM
一般的にデータ基盤というと、Data Ware House(DWH)やらデータレイクといった言葉がでてくるのではないでしょうか。
我々としても、データ基盤のDWHにはBigQueryを使い、BIツールにはLookerを使っています。 もともとRedashを使っていましたが、クエリ管理の課題などから最近はLookerへの移行が進んできました。
Lookerへの推進はデータプラットフォームチームが全社的にリードし、我々BANK チーム としてはそれに則った形です。
しかし、この状況だと日々のリリース変更の度に、データプラットフォームチームへ都度依頼してデータの変更を共有しないといけないので若干非効率です。
そこである程度アジリティを保ちつつ、人的リソースも有限なので下のような体制での運用を始めました。
- 全社的なデータ基盤はデータプラットフォームチームが責任を持つ。
- BANKチームの細かな分析指標は、日々のリリースに責任を持つEPMが責任を持つ
ETLからELT
ではデータプラットフォームチームとEPMがどのように分業を進めていったを説明します。
一般的なデータ基盤において重要なプロセスに以下の3つのプロセスが挙げられます。 * Extract(抽出）... データをソースから抽出する。 * Transform(変換) ... データを必要に応じて加工する。 * Load(格納)... データ基盤に格納する。
一昔前では、Extract、Transform、Loadの順に行われたのでETLという略称で呼ばれていました。聞き馴染みのある方も多いのではないでしょうか。
この中で、一番変更可能性が高い箇所はTransformになります。分析したい点やプロダクトのリリースによるデータ変更による影響を受けやすいためです。
従来のETLプロセスでは、LoadがTtranformに依存している形だったので、Transformの変更の影響をLoadが受けやすいという構造でした。DWHを作るような規模のデータだとペタバイト級のデータを扱うことも珍しくなく、頻繁にLoad処理を変更することは現実的ではないでしょう。そのためTransformを変更することが難しいという状況を生んでしまい、アジリティを下げる要因だったのではないでしょうか。
一方で、最近ではETLの代わりにELTという流れが主流になってきました。つまりは以下ように変更可能性の高い、Transformの処理を最後に持ってくるわけです。
実際我々のチームでも、アプリケーションを変更した我々自身でデータ分析基盤の最終的な内容を変更するという体制を取りました。そのおかげで、リリースした内容の速報を翌日にはダッシュボードで作ったりといった柔軟な運用体制を敷くことができました。
つまり、Transformを我々EPMが責任を持ち、ExtractとTransformは全社的な部分はデータプラットフォームチームが、我々のチームが管理しているデータソースはEPMが整備するといった分業体制となりました。
特に、Lookerだと、派生テーブルによって気軽にELTが実現されている点で重宝しています。 クエリを書いてTransformを書く役割と、日々のKPIを管理してダッシュボードを作る役割を分けられた点は、他のBIツールには難しかった点かなと感じています。
とはいえRedashなどの他のBIツールでもクエリが書けるなら、同じような運用はできると思われます。
プロダクトライフサイクルに組み込む
現在、我々のチームが管理しているDatabaseやlog情報をそれぞれ日毎または日時でBigQueryに同期する形を取っています。 基本的にはembulkで一部Python のスクリプトをECSのタスクスケジューリングで実現しています。
基本的に同期するデータは、ほぼ生データをそのままBigQueryに入れるようにしています。 分析しやすいデータの整形といった処理はBIツールといった分析者の近いところで実現する方式をとっています。前述したELTです。
この方式を採用した理由としては、データのロード部分はデータ量の関係から頻繁な変更は難しいと考えた点が大きいです。分析観点という変化のしやすい内容をロード部分に組み込むと分析基盤としてのアジリティが下がってしまうことを懸念したためです。
最近は、PMMといった日々の施策に責任を持つメンバーも増えてきたので、ダッシュボード作りはPMMに任せつつダッシュボードに必要な情報はEPMが責任を持つといった分業体制で基盤周りの活動をしています。
もともと、BANKチームのエンジニア組織はフルサイクルエンジニアを掲げて全てのプロダクトライフサイクルに関わることを大事にしています。その中に分析基盤へのフィードバックも組み込んだ形を取るようになったといえます。
フルサイクルエンジニアに関しては同僚の松雪(@applepine1125)が、このあとblogを書いてくれるはずなのでこうご期待!!
書いてくれました。
devblog.thebase.in
あと、Lookerを活用して良かった点に日付の情報を以下のようにTimeframeとして定義しておくとシームレスに週次、月次、Quoaterといった形に拡張できる点は便利だなと感じています。
dimension_group: event_date {
type: time
time_frame: [
time,
date,
week,
month,
quarter,
year
]
}
具体的には、日々の振り返り用のデータをそのまま拡張して、役員会議の資料にも活用できる点です。このことにより、メンバーから経営層まで視点が合わせられるので、視座に関わらず同じ北極星を追いながら仕事ができていると感じます。
最後に
今後の展望として、データ基盤を作った体制ができたので、プロダクトへのフィードバックの仕組みづくりとそれを推進していくメンバーの採用を進めていきたいと考えています。 現在はembulkで雑にデータを転送していますが、今後プロダクトにフィードバックすることを考えるとGlueやSage Makerの活用も考えていけたらなと思っています。
そこで一緒にプロダクト作っていく仲間を絶賛募集中です。 もしちょっとでも興味あるとか、知見あるよという方ぜひ私までDMか、以下のフォームから応募お待ちしています!! 冷やかしでもいいよ!!
明日はダーツが得意な@ao_kikenさんによる、「チームメンバーの活動を知る工夫」です。楽しみですね!!
