STORES のバックエンドエンジニアとして働いている app2641 です。
今回は Four Keys に則ったチームの開発パフォーマンス振り返りを毎月している、という話をします。
STORES Advent Calendar 2022の5日目です。

1年間開発パフォーマンスを計測した話

パフォーマンスの推移

一年間のパフォーマンスの推移は以下のようになっています。
グラフは STORES の開発を担っているある1チームの開発パフォーマンスです。
スプリントにおける「PRのマージ数」と「PRのリードタイム」の計測を行い、毎月グラフの変化からチームの状態を読み解いて次の一ヶ月でどんな Try をしていくかを決めています。
我々のチームでは1スプリント1週間のタイムボックスで開発をしています。

動機

このようなことを毎月行っているのには動機があります。
ウェブエンジニアとして何かしらの機能をリリースするとなったとき「開発速度」の話は常に持ち上がるものです。
開発速度が早いプロダクトはフィードバックを得て機能改善を回していくのに有利です。開発速度が早くてデメリットになることはないし、我々はチームの開発速度を向上するべく常に努力するのはとても重要なことです。

ただ、開発速度を上げるのは容易なことではありません。どうしたら開発速度を上げることが出来るのか、上げるためのきっかけとして何が出来るのかを模索したい、といった動機から毎月の開発パフォーマンスを計測していくに至りました。

計測を始めてから約1年ほど経ち、チームメンバーの日々の開発に対する意識は変わっていきました。リードタイムを短くするためにひとつのissueで行うことを出来る限り小さくしようとしたり、レビューが長引きそうになったら話す場を用意して問題解消に努めたり。

開発パフォーマンスの指標

パフォーマンスを計測するにあたり、まずは何をパフォーマンスの指標とするかを話し合いました。
意見交換を行ったのち最終的に DevOps の文脈による資料を参考にして Four Keys で挙げられている指標のうち「PR のマージ数」と「PR のリードタイム」をスプリント単位で計測していくことに決めました。
本来は Four Keys そのままの指標のほうが良いのでしょうが、STORES の開発体制と照らし合わせて前述の2つをまずは指標と置いています。
また、価値提供の PR でなくとも技術スパイクや main ブランチに向けていない PR なども計測を自動化するにあたって条件をシンプルにするために計測対象とするようにしています。

我々のチームではボードの管理に Zenhub というサービスを利用しています。
GitHub の issue をカンバンで管理できるようになる拡張機能のようなものです。
仕掛り中になった日時などは Zenhub API で取得できるので GitHub API で取得する issue 情報と共にこねくり回して計測をしています。Zenhub の API は現在は GraphQL 版が推奨されているようです。

振り返り会

月イチで先月のパフォーマンスから次月にどんな改善をするか決めています。

振り返りで出た案をいくつか紹介すると、

1日1コミットでも良いからプロジェクト外の対応もやってみる
PRはドラフト状態でもレビューはし始めても良いルールにする
気分転換できるissueをどんどん積む

など他にもありますが1年でたくさんの Try に取り組んできました。中にはチームに根付かなかったものもあります。
グラフを読み解くのは難しいですが、そこから見えてくるものは様々なチームの状態を表していて面白いです。例えば、マージ数が減っているのにリードタイムが短いときは開発に取り組める時間がなかったスプリントだと分かります。
開発に取り組めなかったのは何故なのかを突き詰めていくと改善に繋げられそうです。

そうこうしていた結果か、グラフでは1年を通してパフォーマンスが僅かながら向上したように見えます。本当はもっと劇的に改善することを望んでいましたが残念ながらそういった結果にはなりませんでした。
パフォーマンスが思ったより上がらなかったのは、そのスプリント固有の問題を再現性のある改善に落とし込めなかったことも大きかったと思っています。調査や法的対応など実装よりも入念な下準備が重要なプロジェクトが多かったために再現性を得られなかったというのが背景にあります。
また、いくつかのプロジェクトを経て、チームの特徴として調査系のタスクは見積もりを甘くしがちな傾向がグラフから分かってきました。
今後はこれらの反省を活かした1年にしていきたいです。