この記事はZOZOアドベントカレンダー Series４ １４日目の記事です。
「LeanとDevOpsの科学」で紹介されているFourKeysを計測しているチームは多いと思います。
私のチームでもFindyTeamsを活用しながら計測を続けています。
FourKeysで計測する内容は以下のとおりですね。
- デプロイの頻度
- 変更のリードタイム
- 変更障害率
- サービス復元時間
これらはGithubのPullRequest（PR）などを活用し計測されますが、デプロイの頻度・変更のリードタイムについては、すべてのPRを計測するかどうかについては疑問に感じていました。
たとえば、
- リファクタリングのみのPR
- ライブラリのバージョンアップのみのPR
- テスト追加のみのPR
- 負荷テストに必要な変更のみのPR
- バグ修正のためのPR
これらは既存の機能に変更を及ぼすものではなく、顧客になにかインパクトを与えるためのものではないですよね。
そして、Scrumなどイテレーションを積み上げていくようなアジャイルのプラクティスを採用している場合、これらはスプリントバックログの完了の定義に含まれているべきものであって、単独でPRを立てているのは「未完了」の消化というものになります。
それらがデプロイの頻度・変更のリードタイムに含んでしまうと、チームのパフォーマンスを計測するだけであれば有効かもしれませんが、「未完了」の消化ばかりデプロイしていてもパフォーマンスが高くても何も顧客に提供していない、アウトカムがないということにもなりかねません。
よって、このような「未完了」の消化用のPRとアウトカムのためのPRをタグで分けてアウトカムのためのデプロイの頻度・変更のリードタイムのみを計測する。
そうすると、「未完了」の消化はできるだけスプリントで収めようとする動きも取れるでしょうし、アウトカムに値するPRが増えていけばビジネス上、競合に立ち向かえるだけのパフォーマンスを発揮することもできるでしょう。
ひとつだけ補足しておくと、チームによってはどうしても「未完了」の消化用のPRというのは必要になることもあると思います。ライブラリのバージョンアップはRenovateみたいな仕組みでやっていたり、大型のバージョンアップなどはやはりスプリントとは切り離してやっていかないといけないでしょう。なので全てのPRがアウトカムのためのPRというわけにはいかないのはその通りかと思います。そしてこれらのPRは「変更障害率」「サービス復元時間」の削減に寄与することも考慮しておくべき点でしょう。
これらの点に注意しながらアウトカムのための計測をしていけたらと考えています。