こんにちは！広告事業本部でリードアプリケーションエンジニアをしている高木です。
私が所属するチームでFindy Team+を導入し、サイクルタイムの改善に取り組みましたので、その内容を紹介いたします。
Findy Team+は、GitHubやJiraなどの開発ツールと連携し、開発生産性の可視化・向上を支援するツールです。
サイクルタイムとは最初のコミットからマージされるまでの時間のことで、開発効率を測る指標の1つです。
Findy Team+では、サイクルタイムの平均時間に加えて以下の各プロセスのリードタイムも確認できます。
- コミットからオープンまでの平均時間
- オープンからレビューまでの平均時間
- レビューからアプルーブまでの平均時間
- アプルーブからマージまでの平均時間
背景
弊チームでは、レビューに時間がかかっていることが長年の課題でした。
Pull Request（以下、PR）をオープンしてからマージするまでに2〜3営業日掛かっている印象がありました。
このプロセスの遅延は、リリースのタイミングに影響を及ぼし、開発の効率を低下させる要因となっていました。
そこで、チームの開発効率を上げるための方法を模索していたところ、会社の施策としてFindy Team+の導入が決まったため、Findy Team+を使ったサイクルタイム改善に着手することにしました。
結果
まず初めに、結果からお伝えします。
サイクルタイム平均値（2024/01/01~2024/01/31）
Findy Team+を導入した2024年1月時点の、サイクルタイムの平均時間は64.4時間でした。
時間が掛かっていると感じていたオープンからマージまでの時間も実際に平均で50時間以上掛かっていることがわかりました。
サイクルタイム平均値（2024/12/01~2024/12/31）
さまざまな施策を実施した結果、2024年12月時点のサイクルタイムの平均時間は、13.1時間にまで短縮できました。
オープンからマージまでの平均時間も約10時間になり、約1/5になりました。
サイクルタイム推移（2024/01/01~2024/12/31）
推移からもサイクルタイムが着実に短縮されていることがわかります。
やったこと
前提
弊チームでは、レビュワーが2人自動でアサインされ、両方のレビューが完了するとマージ（リリース）するというフローを採用しています。
このプロセスを改善するために、以下のアクションを実施しました。
アクション
振り返りの実施
週1のスプリント会議でFindy Team+のスコアを確認し、PR単位で時間が掛かっているものがないかをチェックしました。
時間が掛かっているPRがあれば、その原因を分析し、改善施策を考え実施していきました。
レビューの速度に関連する指標の「オープンからレビュー」と「レビューからアプルーブ」を重点的に見ていました。
2つの指標はそれぞれ以下の時間です。
- オープンからレビュー： PRをオープンした時点から1人目のレビュアーが最初のレビューをした時点(アプルーブではなくコメントも含む)までの時間
- レビューからアプルーブ： 1人目の最初のレビューから2人ともがアプルーブするまでの時間
上記の指標について、おおよそ8時間を超えているPRがあれば原因の分析をしていました。
レビューを1日以内に返せていない可能性があり、何か問題が起きているかもしれないからです。
PRの粒度を小さくする
時折、丸ごと新規画面が完成した状態に近いPRが提出されることがありました。
PRの粒度が大きいと、レビューに時間がかかる原因となります。
そこで、PRの粒度を小さくすることで、レビューを容易にし、レビュワーの負担を軽減することを目指しました。
PRの適切な粒度については、Findyさんのスライドが参考になりました。
このアクションは「コミットからオープンまでの時間」、「オープンからレビューまでの時間」、「レビューからアプルーブまでの時間」の短縮に対して効果がありました。
リマインドの強化
既にチームのSlackチャンネルに通知をする仕組みがありましたが、1日2回の通知では、その間にオープンされたPRのリマインドが届かないという問題がありました。
そこで通知回数を増やす提案をしましたが、「頻度が多すぎるのは避けたい」という意見があったため、各自で好きな時間に個人宛に通知を受け取る設定をしてもらうことにしました。
また、会議のタイミングなどでレビューが遅くならないように声がけを実施しました。
私の場合は、元々あった10時30分と17時30分の通知に加えて、お昼休憩後と退勤前に通知を受け取るように設定しました。
この変更により、業務の流れに合わせてPRを確認できるようになり、対応の遅れを減らすことができました。
このアクションは「オープンからレビューまでの時間」、「レビューからアプルーブまでの時間」の短縮に対して効果がありました。
レビュワーの付け替え
マネジメント業務を兼任しているメンバーもいるので、レビューをする時間が取れないことがありました。
そのため、レビューが難しい場合は、レビュワーを自由に付け替えていいようにしました。
このアクションは「オープンからレビューまでの時間」、「レビューからアプルーブまでの時間」の短縮に対して効果がありました。
意識の施策
弊チームではレビューを最優先にしているわけでなかったので、レビュー依頼が飛んできてもすぐには確認していない印象がありました。
PRの内容によってはすぐにレビューが終わるものもあるので、レビュー依頼が飛んできたらすぐに内容だけでも確認するように意識を向けるようにしました。
このアクションは「オープンからレビューまでの時間」、「レビューからアプルーブまでの時間」の短縮に対して効果がありました。
レビュー済みのPRのラベル付けと通知
アプルーブからマージまでの時間が長い原因の1つとして、レビューが完了したことに気づかないことがありました。
そこで、レビューが完了したPRには「レビュー済み」ラベルを付け、PR一覧ページで視認しやすいようにしました。
また、レビューが完了したPRをSlackに通知するようにしました。
このアクションは「アプルーブからマージまでの時間」の短縮に対して効果がありました。
今後の課題
アプルーブからマージまでの時間が依然として長いため、さらなる改善を目指していきます。
また、チームサーベイの結果から「開発手順や技術仕様のドキュメントが整備されており、すぐに参照できる。」の項目が他の項目と比べて著しく低いことがわかりました。
この課題を解決するために、ドキュメントの整備と参照しやすい環境の構築に取り組みたいです。
