MyReferチームの政家です！
TalentXではFindy Team+を活用して、開発生産性の改善を行っています。
TalentXでは開発生産性の改善にFindy Team+を活用しており、その結果リードタイムを約半分に短縮することができました。
直近7月以降は10h~20hの間に落ち着いている
本記事では、Findy Team+を活用して、チームのリードタイムを短くするために、工夫した内容を紹介します。
MyReferチームでは、Findy Team+を活用前は下記のように、Four keysを管理し、
週次のレトロスペクティブにて、振り返りを行っていました。
従来の運用方法
デプロイ頻度、リードタイム
- タイミング：週次のレトロスペクティブ
- 集計方法：GitHubのAPIを使ったスクリプトで、スプリント内のPRをスプレッドシートに出力し、手動で集計。
PRのオープン・マージ時刻を元に、リードタイムを集計
変更障害率、平均修復時間
- タイミング：週次のレトロスペクティブのタイミング
- 集計方法：スプリント内の障害をチームで確認。障害数とリリース数を元に、変更障害率を手動で集計。障害報告書(※)を元に、障害発生時刻〜改修リリース時刻から平均修復時間を、手動で計算
※ 影響が大きかったバグに関して、原因や今後の改善策チームで振り返っている
運用上の課題
MyReferチームでは、Findy Team+導入前から、Four keysの運用は行っていたため、
各数値の意識はチームに根付いていました。
その一方で、下記の課題も発生していました。
- PRのオープンからマージまでのサイクルの中で、どこがボトルネックになっているのかの詳細が追いづらい
- 他チームとの集計ロジックが一部異なり、単純に数値の比較ができない
- リアルタイムに、数値が確認できない
- 手動集計作業や、報告用シートへの記載などの管理工数がかかる
Findy Team+を用いた改善
Findy Team+を活用して、下記を行いました。
- チーム間での計測方法の統一
- レトロスペクティブで、目標から逸脱しているPRの詳細を確認
計測方法の統一
Findy Team+導入前は、
- リードタイムにテスト時間を含めるか含めないか
- プロジェクトのようなmainにマージされる期間が長いものを含めるか含めないか
など、チームによって算出方法がバラバラでした。
チームの責任者間で計測方法を会話し、Findy Team+の計測方法を統一する事で、チーム間でのばらつきがなくなり、
他のチームとの比較ができるようになりました。
レトロスペクティブで、目標から逸脱しているPRの詳細を確認
スプレッドシート運用の際には難しかった、「PRのオープンからマージまでのサイクルのどこで時間がかかっているのか」が一目でわかるので、具体的な議論ができるようになりました。
課題が明確にわかる事で、下記のように具体的な改善策を取り組む事ができています。
- 「アプルーブからマージまでの時間が長いから、アプルーブ時に実装者にメンションつけよう」
- 「オープンからレビューまでの時間が長いから、PR作成者が責任を持ってリマインドしよう」
Findy Team+活用以外の改善取り組み
チームの課題が見えてきた事で、MyReferチームではFindy Team+活用以外の取り組みとして、下記の改善を行いました。
ファーストレビューまでの時間の目標を設定
これまでMyReferチームでは、「オープンから1日以内にはレビューしよう」という暗黙のルールがありましたが、
個人のタスクが忙しいとレビューが後回しになったり、レビューの偏りが発生する問題がありました。
チームで一度ディスカッションをした結果、レビューはある程度優先したほうが全体効率が良いという結論に至り、今では「4時間以内」を目安にファーストレビューを行うという目標でやっています！
Findy Team+の活用結果、活用前の課題、リードタイムを改善した方法を紹介しました。
Findy Team+を活用する事で、
- 目標から逸脱しているPRの詳細の振り返りが行える
- 他チームの数値を意識できる
- リアルタイムに数値を確認ができる
- 手動の集計作業がなくなり運用が楽になる
等ができました！
Four keysや開発効率の可視化や改善で困っているチームに、おすすめしたいと思います。
現在、TalentXでは一緒に働く仲間を募集しております。
talentx.brandmedia.i-myrefer.jp
カジュアル面談も行っておりますので、ぜひご応募ください！
コメント