[4ヶ月後]Findy Team +の数値爆改善した（実データ公開します）
導入
2024年1月から、Findy Team+を導入いたしました！
導入の経緯などは、以下をぜひ御覧ください。
導入してから、4ヶ月地点でどのように変化があったのかを記載させていただきます。
実データも公開するので、ぜひ見てください！
目的
Findy Team + の導入目的は、上記のnoteで詳細に説明していますが、開発者体験が良くなることを第一目的として、スピーディーに開発ができて、心地よい状況を目指しています。また、定量的にミチビクの開発チームがイケているよね！ってことを示す指標としても使いたいという意図もあります。
目標
目標スコアは、Award表彰されるために、かなり高めに設定しています。スプレッドシートで管理していて、月1で月初に更新をしています。過去28日間の絞り込みのフィルターをつかっています。
月1で改善のアクションを設定してPDCAを回しました。まずは、リードタイムスコアが一番低かったので、そこから着手しました。そのあとに、アウトプットスコアの着手をしたという順番です。
改善結果
たった4ヶ月で以下の改善を実施することができたので、各セクションに分けて説明していきます。
リードタイムの削減
コミットからオープンまでの平均時間
レビューからアプルーブまでの平均時間
アウトプットスコアの上昇
デプロイ頻度
レビューワーの分散
コミットからオープンまでの平均時間の削減
目標は、48hだったのですが、5月月初時点では、11.3hなので、大幅に削減できました。
理由は、プルリクエストサイズを小さくすることを意識したからです。可能な限り小さな粒度（300-500行）にしようと意識をした結果だと思います。
最初は上手くいかなかったのですが、劇的に効果がでたのは、「1日2PR」ルールの設定です。小さくしようということをメンバーに伝えても、やっぱりPRを大きくなってしまいました。という振り返りが多くありました。
バイセルさんのテックブログで「1日1人あたり2PR以上作成する」という記載があったので、参考にさせていただきました。
1日1人あたり2PR以上作成する
具体的にどのくらい PR 数が増加すれば生産性が良い状態であるのかを明確にしたいという意見があったため、 1 日あたり各メンバーが提出する PR 数の目標を定めることになりました。 2PR以上という数字は、生産性が高いと言われている他社や他チームの事例を参考にして設定しました。
そこで、もう設計の時点で1つのタスクの最大工数を0.5人月に設定しようという取り組みをしました。これが効果てきめんでした！！！！！
ミチビクの開発プロセスでは、設計が完了したらすべてのタスクに対して、工数の2点見積もりをしてもらっています。最速工数と最遅工数の2つを各タスクについてしてもらって、その2つの見積もりの間であれば、OKという管理をしています。
このプロセスにおいて、最速工数を0.5以上にしないというルールを決めました。今振り返ってみると、当たり前で見積もり時点で、1になっているものは、1日2PRできないのは明白です。この気づきそうで気づかなかったことに、エンジニアのメンバーが気づいてくださり、1日2PRが実現できました。
レビューからアプルーブまでの平均時間
目標が、24hでしたが、5月月初時点では、18.7hまで削減できました。
上述の「1日2PR」がここでも効きました。やはり大きなPRはレビュー負荷が高いので、小さなPRでしたらサクッとレビューできるので、感覚的にもレビュー難易度が非常に小さくなりました。
また、PRでレビュー時に指摘が多いと、レビューからアプルーブのスコアが下がってしまいます。この課題は特のオフショア側に顕著であり、オフショアのレビューでの戻りが多かったので、改善しました。
この点に関しては、バイネームレベルのPRレベルで分析をかけました。個人が特定できてしまうので、情報をお出しすることはできないのですが、PRに対して、レビューからアプルーブまでの時間が長かった順にソートして、上位10件くらいをPickupして、なぜこのPRは時間がかかったかを1つ1つ分析してもらいました。そこで検知できた課題に対してPDCAを回したことによって、改善の結果がでてきました。コード規約やレビュー体制の運用見直し、静的解析の修正などが対策例です。
デプロイ頻度
目標は1日2デプロイでしたが、5月月初時点では4.3デプロイなので、計測当初の1月は0.3デプロイだったので、14倍になりました！！！！
これはリードタイム改善の複合要因でもありますが、上述の「1日2PR」が一番効果でた施策だと思います。
レビューワーの分散
これが導入した当時の過去1年でのCTOである金杉のレビュー件数で、1345件という完全な一極集中をしていたというカオスな状況です。。。
改善後は、下記の過去28日間の数値になります。
見てもらうとわかると思うのですが、分散が進みつつあります。以前として、金杉は、88件と多いですが、PRが小さくなっているので、負荷はそこまで感じてない状況です。
今度は品質の面もつきまとうので、CTOやテックリードがレビューしなくても、どうやって、品質を担保しながら高速に開発できるか？という課題に今対応しています。レビューワーの育成であったり、開発者テストをどう設計するか？自動テストをどこまでいれるか？になります。
まとめ
実際にFindy Team +を導入して、4ヶ月が立ちましたが、定量的な成果が如実にでていて嬉しいです。今まで気づけていなかった開発生産性の課題に気づくことができましたし、その課題の解決に向けてPDCAを回すことができ、着実に成果を出すことができました。
ただし、目標は非常に高いところにセットしているので、本来の目的やアウトカムといったところは見失わずに、引き続きPDCAを回していきたいです。
