「Findy Team+」を活用して、リードタイムを半分に改善した話 – TalentX Tech Blog

MyReferチームの政家です！
TalentXではFindy Team+を活用して、開発生産性の改善を行っています。

https://jp.findy-team.io/

TalentXでは開発生産性の改善にFindy Team+を活用しており、その結果リードタイムを約半分に短縮することができました。

本記事では、Findy Team+を活用して、チームのリードタイムを短くするために、工夫した内容を紹介します。

MyReferチームでは、Findy Team+を活用前は下記のように、Four keysを管理し、
週次のレトロスペクティブにて、振り返りを行っていました。

従来の運用方法

デプロイ頻度、リードタイム

• タイミング：週次のレトロスペクティブ
• 集計方法：GitHubのAPIを使ったスクリプトで、スプリント内の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

カジュアル面談も行っておりますので、ぜひご応募ください！

i-myrefer.jp