DREが考えるデータ基盤の生産性とfourkeysによる可視化

DREグループの石井です。

先日といってももうしばらく前ですが、Techmeeというイベントで生産性についてトイルの計測をしてそれを一定に抑える取り組みをしているという話をさせて頂きました。

https://timeedev.connpass.com/event/275750/

www.youtube.com

これはDREグループ内の生産性を維持する=一定以上のアウトプットが出せる状態を作り出すための取り組みでした。しかし、生産性といえば、古くはコード量で計測されていたような(最も、コード量は良い指標ではありませんが)ものや今で言えばfourkeysといったようなもので、どれだけアウトプットに繋がっているかが大切になります。

私の所属するDREグループでは、主に色々なデータソースからデータを抽出し、便利に分析しやすい状態にすることに責任を持つと同時に、データ基盤の運用も担当しています。

そのため、私達のグループはもとより、他の分析者の生産性を上げることに責任を持っていかないといけません。

今回はDREグループで始まったfourkeysによる生産性の計測と今後の展望について書かせていただこうと思います。

前提としてfourkeys

今回の計測に当たってはfourkeysをベースとして考えることにしました。これについては書籍や色々な発表資料などを漁り、グループ内で勉強会などを通してある程度共通理解を得て我々の計りたいものに対してまずはこれでいってみよう、という合意が得られたためです。我々が考える生産性については後述しますが、前提としてのfourkeysは以下の本や資料などを読んでいただけると理解が進むかと思います。

State of DevOps 2021

https://services.google.com/fh/files/misc/state-of-devops-2021.pdf

(2022もありますが、フォーム入力が必要なためパブリックに公開されているこちらを貼っています)　

エリート DevOps チームであることを Four Keys プロジェクトで確認する

https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

継続的デリバリーのソフトウェア工学

https://bookplus.nikkei.com/atcl/catalog/22/12/01/00531/

DREグループの考える生産性の定義

我々DREグループは社内向けのデータ基盤を提供するグループです。つまり、生産性計測の対象が1つのチームに閉じるとは限らず、何なら複数グループの活動が全て終わって1つの機能提供が完了するというケースも多くあります。

例えば、新規データをつなぎ込みモデリングした上でダッシュボードを提供しようとするケースでは、DREグループだけでなく、モデリングを担当するBIグループが絡んできます。このとき、DREグループが担当するステージング処理までが完了したとしても価値が提供できていると言えるでしょうか？そうではなく、データの取り込み、ステージング処理、モデリング、ダッシュボード化のすべてが完了して価値を提供できていると言えると考えています。

そのため、開発はもちろんですが、その2グループの連携がスムーズに流れることも重要な要素であり、その点も改善の対象となってくるはずです。例えば、もしドキュメントが足りなくてBIグループがモデリングに入れないのであればそれをスムーズに提供するべきだし、依頼内容が曖昧でヒアリングに時間がかかりすぎるならそこも改善対象かもしれません。

つまり、スループットとしては絵にすると以下の全体で計測・改善を行う必要があると考えています。

また、単に速度だけを追求してしまうと障害を起こしまくる仕組みになってしまいかねません。そのため、同時に安定性の指標として障害も計測する必要があるのですが、データ基盤の場合シンプルにデプロイによる失敗を計測すればよいかというとそういうことでもなく、どうしてもデータソース側の変更などにより「何もしてないのに壊れた」ということが発生することも多くあります。そのあたりを考慮して実装を考えていく必要があります。

実装

実装は以下の様になりました。

基本的にDORAが公開してくれている実装を使い、Github上の営みをBigQuery上に収集しています。

デプロイ周りについては、

ほとんどのリポジトリはmain merge時にデプロイ自動化されているので、マージをデプロイの代替指標として採用する
障害は現在Notion上のポストモーテムDBで管理できているのでそこから引っ張ってくる

ということにしています。

現時点では通常のfourkeysを取得できるようにしていますが、今後は上述した通りのリードタイムをNotion上にあるバックログなどと連携させて取得していく予定です。

考察と今後について

現時点ではほぼ素のfourkeysが取得できた状態です。最初に計りたかったものからするとやや乖離がある状態ですが、それでもいくつかの示唆を得ることができました。例えば、dbtのリポジトリでDREグループのリリース速度は十分早いのですが、データのモデリングを行うBIグループはかなりの時間がかかっておりなにか課題がありそうなことが特定できました。

これについてはヒアリングを行っており、実際にメンバー間でモデリングについての習熟度や前提条件の理解などの差があるために、レビューで大きな時間がかかっていることがわかりました。

また、当たり前ですがDREグループだとしても意図して大きいPRを出すとマージまでの時間が圧倒的に伸びていることがわかります。

どちらも担当ベースでは理解のあることと思いますが、具体的な数値として見えてくると議論の俎上にも上がりやすく、解決に向けて動きやすくなるのでシンプルなfour keysでも意味のある可視化なのではないかと思います。

ただ、やはりこれでは最初に書いたような課題は見えてこない部分はあるので、少しずつアップデートしていき、エンドツーエンドのfourkeysを測れるようにしてより生産性の高いデータ基盤を実現する礎にしていければと思っており、そのあたりはまたブログ等で発表できればと思っています。