Zaim の分析チームの濱口です。
分析チームでは各々が書いた SQL をドキュメントにまとめて GitHub リポジトリに貯めて共有しています。この試みを始めてから 1 年ほど経過したので、運用してみて感じたことや気づいたことを紹介しようと思います。
背景
SQL を GitHub リポジトリに貯め始めたのは、以下のような二つの問題意識があったからでした。
1. レビューの枠組みがなかった
SQL を複数人でレビューする確固たる枠組みがなく、タスク管理ツール上で雑にチェックしていたり、そもそもレビューを実施していなかったりしていました。このような状態が続いてしまうと、SQL のミスやデータの誤りにつながってしまい、データの信頼性が損なわれてしまいます。
2. 書いた SQL が集約されていなかった
分析チームのメンバーそれぞれが書いた SQL が、どこにあるのかが分かりづらい状態でした。他の人がやったことがある分析の SQL を参考にしたり再利用したりするのにも一苦労で、とても非効率です。
GitHub リポジトリに貯めるまでの流れ
リポジトリへの蓄積方法は、一般的なコードのレビューと同じく
という手順になります。
1. プルリクエストを作成する
マークダウン形式のファイルに作成した SQL の概要、実際に書いた SQL などを記載したプルリクエストを作成します。ディスクリプションには、データ抽出の目的と SQL を実行して抽出したデータを記載し、データの数値についても確認できるようにしています。
2. レビューをもらう
チームメンバーからレビューをもらい、SQL やデータに誤りがないかチェックします。
ディスクリプションにレビューのチェック項目を設けており、その項目に沿ってレビューすることで漏れが出ないように対策しています。最低でも一人からは Approve もらい、問題なさそうであればマージします。
運用してみた感想・まだ残る課題
といったように、当初、抱えていた問題は解消できました。しかし、運用する上で、また以下のような別の課題が出てきました。
1. 参考にしたいファイルが見つからない
最初のうちは良かったのですが、ファイルがどんどん増えていくうちに参考にしたいファイルを見つけるのが困難になってきました。
解決策として、すべてのファイルを同じ一つのフォルダに貯めていたのを、会社外と会社内の案件別で分割した上で、さらにデータマートごとにクエリを分けるようにしました。
2. レビューが滞る
データの抽出内容によってはかなり長い SQL になることもあり、とにかくレビューが大変でした。
レビューが大変だと後回しにされがちで、レビューが滞るという問題が出てきました。この問題に関しては
SQL のコーディングスタイルを定める
再利用できる箇所は切り出して共通化する
などを実施しており、現在も改善を続けています。その一部は、別の記事にまとめています。
まとめ
運用していて出てきた新たな課題についても、さらに改善していきたいと思います。
最後に
他のチームと協力しながら働ける Zaim では、一緒に働けるエンジニアを募集しています!
仕事を通じて色々なスキルを得たいという方は、ぜひ一度カジュアルにオンラインでお話しましょう。ご連絡、お待ちしてます。
0 件のコメント:
コメントを投稿