Kyashに1人目のデータエンジニアとして入社してから3ヶ月半程でやったこと
この記事はKyash Advent Calendar 2020 18日目の記事です。
Kyashでデータエンジニアをしているmomotaです。
1人目のデータエンジニアとして2020年9月1日に入社してから今までの3ヶ月半程でやってきたことを、年の瀬ということで振り返りつつ筆を執ってみました。
課題の整理
Kyashでは四半期毎に全社に加えてチーム毎でもOKRを設定し、達成に向けて動くというカルチャーがあります。
自分が所属するデータチームでは以下の項目をOKRとして決めて、達成に向けて動いていました。
Objective1. データガバナンスの整理
Objective2. Kyashに数字を見る文化を植え付ける
Objective3. データ基盤強化
Objective4. 採用
上記のOKRを設定した当時、課題感としては以下のような内容がありました。
データガバナンスの観点における課題
- 消していいのかどうか分からないテーブルがある
- 誰が作ったのか分からないテーブルがある
- 一部の抽出データや中間テーブルが信頼性担保にかけている
- データの意味が一見で分からない(WHERE hoge_type=1 とあるが hoge_typeのそれぞれの意味はソースコードをみないと分からない状態、等)
Kyashのデータドリブンな文化の観点における課題
- 後述するアンケートの実施によって浮き彫りになったいくつかの課題
データ基盤における課題
- データレイクと、その先の中間テーブル作成が密に絡まっていて分離されていない
- データ基盤として使用していたGCP projectが一つしかなく、本番環境のデータをメインとして扱いつつもETLの実装検証用に開発環境のデータも入れる形として存在していた。
課題をグルーピングして整理していく内に以上の大枠に集約されOKRとしての設定に至っています。
チーム開発運用の方針決め
OKRの達成に向けて動いていくのと同時に進捗を可視化して円滑に運営する必要があると考え、まずは運用の方針を決めることにしました。
自分が入社した時にはETLのGitHubリポジトリがある状態だったのと基本的に一人での実務になる想定だったので、ツールが集約されている方が楽そうだと思い、運用はGitHubに集約させ、GitHubプロジェクトの機能を利用してカンバンでタスクの進捗を可視化させる事にしました。
(尚、PdMと連携して開発をしている他のチームはJiraを使っています)
四半期毎にOKRを刷新していく運用なので、プロジェクトも四半期毎に作成する形としています。
また、OKRの達成率はGitHubのマイルストーン機能を使って可視化する事にしました。
これにより、GitHubでイシューを作成したりイシューの消化をする際にどのOKRに関わる内容なのかが分かり、OKRドリブンな進行ができたかなと思っています。
また、GitHub上で可視化させたタスクの消化具合やOKRの進捗具合が上司へのレポートラインそのものになるので、円滑なコミュニケーションにも一役買えたのではないかと思っています。
(ただし、GitHubを全てのベースにしているので上司にEngineering経験があるのが前提になるかもしれません。)
データガバナンスの整備
データガバナンスの観点で感じていた上記の課題に対して大きく取り組んだのは、中間テーブルを作成するSQLをGitで管理してレビューフローの体制を構築することでした。
弊社ではデータ基盤としてBigQueryを利用しており、かつ中間テーブルをviewテーブルとしてデータセット内に定義していたこともあり定義のSQLは画面上で確認ができていたので以下の精査を行い、クリアしたテーブルをGitで管理するという体制に移行しました。
- テーブルが不要かどうかを精査
- SQLが正しいかどうかを精査
この様に一つ一つのテーブルにチェックボックスを付けて対応していきました。(まあまあ骨が折れました)
また、SQLは以下の構文を使う事により実行するだけでviewテーブルが作成できるようにし、これをAirflowのBigQuery Operatorに組み込んで定期実行する様にしています。
CREATE OR REPLACE VIEW {{ params.dataset_name }}.{{ params.table_name }}
OPTIONS (description="これはこんなテーブルですよ!", labels=[("git", "true")]) AS
-- 以下にviewテーブルのSQLを記述
中間テーブルを作成するSQLに中間テーブルを利用しているというパターンもあったため、中間テーブル作成に依存関係が必要だと認識した結果使い慣れているAirflowの導入機運となりました。
また、一番最初に「中間テーブルが集約されているデータセットを再作成する」タスクを導入する事でレビューフローを通さず作成されたテーブルは消えるようになっているので、データガバナンスの面でも一役買っています。
Kyashに数字を見る文化を植え付ける
入社したての頃、Kyashではプロダクト開発が盛んで機能開発が同時並行でどんどん進んでいるという印象を受けつつもデータチームとしてはそもそも今まで存在してなかったこともあり、データがプロダクトの意思決定や改善にどれだけ寄与できているのかを疑問に感じていました。
そこで、OKRを設定する前のタイミングでKyashのメンバーがデータに対してどういう認識でいるのか現状を調査し、その結果を元に課題感を洗い出して施策を考えるという計画で進めました。
実際に実施したアンケートがこちらです。
具体的な結果の数字は伏せさせて頂きますが、「どうしたらもっとredashにある数字を見るようになると思いますか?」の回答を集約した結果以下の課題感が浮き彫りになりました。
- 目標数字と現状との乖離がすぐ分かる状態
- 重要なKPIが大台に乗った時に全員で喜ぶ機会
- プロダクトの本当に重要な指標が一つにまとまっていること
この結果を元に、全員が同じ場所の数字を把握しその数字を見る習慣をより一層付けていく必要があると判断し、
- 重要な数字を1つのダッシュボードに集約、啓蒙活動
- slackでのredashクエリ通知内容の定期的な更新
- KPIが大台に乗った際に、All hands(全社会議)でCEOに発表してもらう様に依頼
などの施策を実施してきました。
特にダッシュボードなどは作って終わりだと全く意味がなく、作ってからが勝負だと思っているので
- オンボーディングフローにredashのダッシュボードの存在認知と閲覧出来る状態までを組み込む
- エンジニア全員が集まる週次のミーティングにおいて、グラフの追加や数字の報告などの発表を通じて啓蒙活動をする
- redashの数字がslackに通知されてきた際やデータ分析の結果何か新しい知見があった際に、Slackのチャンネル上でコメントをして、データに対するコミュニケーションの促す
- 数字の変化に対してその要因を調べてレポーティング&啓蒙活動
などの工夫を行ってきました。
これに関しては終わりがないというか、やり続けることが重要だと思っているので引き続き施策の内容を含めてアップデートし、より数字を見る文化の促進、その先の数字を分析する文化の促進までつなげていきたいと考えています。
データ基盤強化
基盤強化としては、OKR設定前にETLの改善による高速化を行っていたいのですがその過程でデータレイクとそれ以降の中間テーブル作成がごちゃ混ぜになっている現状をまず課題として認識し改善に向けて取り組みました。
ETLではembulkを用いてAWS RDSからBigQueryへの転送を行っているのですが、一部がこのタイミングで複数のテーブルを結合して新しい名前としてBigQueryに転送していたので、この部分をviewテーブル作成のフェーズに移動し、ETLにはデータをそのまま、なんの加工もせずに転送することだけを責務とさせました。
現在のデータ基盤概要図
また、私が入社したタイミングではGCPのプロジェクトは1つしかなく、そこに本番環境のデータ+αで開発環境のデータが入っている状態でしたので、新たに開発用と本番用のプロジェクトを作成して分離させることで基盤の土台を強化していきました。
(移行に関しては事前準備を入念に行いました)
結果として、現在は基盤の土台が固まってきたかなと言える状態になっています。
採用
このOKRだけ期中に追加したものとなるのですが、2021年以降の課題感を考えた時に最低もう一人欲しいよねという話を上司とした結果採用活動を行うことにしました。
そこで募集要項のアップデートや使用してる採用ツールのセットアップを行い、あとはひたすらスカウトです。
この手の仕事は継続が大事だと思っているのですが、スカウトに限らず継続のコツとして「熱くなり過ぎず、また距離を取り過ぎず行う」のが自分の中でしっくりきていたので「毎朝15minだけ」の予定を入れて淡々とスカウトをしていってます。
まとめ
ここでは書ききれない(or 書けない)内容もたくさんありますが、入社してあっというまの3ヶ月半でした。
まだまだ課題の多い状況ではありますが、2021年も引き続き解決していきたいと思います。
Kyash Advent Calendar 2020の他の記事もぜひ読んでみてください。
Discussion