📈
プロセス細分化で実現する開発生産性向上メソッド

Mimori Fujino
2024/10/31に公開
開発生産性
idea
 はじめにourlyでは開発生産性の向上について取り組んでおり、Four Keysや開発生産性の可視化ツールとしてFindy Team+を導入しています。
今回プロダクトチームの2Q（2024年7〜9月）リードタイム目標として設定した「commitからmergeまで平均50時間」を達成することができました🎉


※画像は2024/10/31時点のものとなります。
この記事では、目標達成のために行った取り組みについて2つ紹介します。

 取り組み
 1. 目標設計今まではcommitからmergeまで平均XX時間を目指すという目標だったのに対し、今回からは目標値を細かく、commitからmergeにかかる各プロセスごとに設定することにしました。
プロセスはFindy Team+のサイクルタイム分析に合わせて
commit~open
open~review
review~approve
approve~merge
の4つに分けています。

 現状把握まずは現状の時間をFindy Team+のサイクルタイム分析画面から確認、分解します。

 目標値の分解次に目標の Total: 50h に対して、各プロセスごとにどのくらい数値を減らせば目標達成ができるのかを設定しました。



Total
commit~open
open~review
review~approve
approve~merge


現状
63h
20h
10h
25h
8h

目標
50h
20h
4h
20h
6h

差分
-13h
0h
-6h
-5h
-2h


 シミュレーションとはいえすべてのプルリクエストを50時間以内にmerge厳守することは難しく、プルリクエストの性質上どうしてもリードタイムが伸びてしまうこともあります。（通常の機能開発ではなくDevOps改善やCI/CDに関わるものなど）
そこで、実際のデータと実感値に基づいてプルリクエストの所要時間をシミュレーションしてみたところ、プルリクエストは以下の3つに分類できることが分かりました
easy (34時間): 小さな不具合修正など、比較的簡単な変更
normal (50時間): 通常の機能開発
difficult (73時間): DevOps改善やCI/CD関連など、複雑で時間のかかる変更
上記の図が示すようにプルリクエストの所要時間は正規分布に従っており、difficult（73時間）のプルリクエストがある一方で、同じ割合でeasy（34時間）のプルリクエストも存在することが分かりました。
この分布から、easyとdifficultのプルリクエストが相殺し合うためnormalの50時間を目標値として開発を進めれば、全体の平均リードタイムも50時間に収まることが分かりました。

 2. 振り返りの見直しスプリントイベントに合わせてリードタイムが長いプルリクエストを抽出し、なぜリードタイムが伸びたかチームで振り返りを実施していましたが、改善のサイクルがうまく回っていなかったため、振り返りの方法を見直しました。

 見直し前
現状だとどのプロセスに問題があるのか、何が問題かが分かりにくいため、限られた振り返り時間の中で解決策を出すことができないことが多々ありました。
また、ノウハウが蓄積しないため同じ問題について繰り返し議論が発生することもあり、メンバーが集まる貴重な時間を効率的に使うことができていませんでした。

 見直し後
各プロセスの目標値を設定し、フォーマットを見直したことでどのプロセスに問題があり、何が問題かがメンバー全員の中で明確になりました。
また、問題や解決方法をメンバーで認識を揃えて抽象化することで、繰り返し発生している問題に対してはすでにある解決策を当てはめ、本当に議論が必要な問題にフォーカスできるようになりました。
この見直しにより、メンバー全員が同じ問題について議論できるようになりました。
また、問題を抽象化することで個別の経験を普遍的な学びへと発展させることができました。
その結果、振り返りの効率が向上し、限られた時間内でもすべての問題に対して適切な対策を立てられるようになりました。

 目標の達成に振り返りの見直しがどう作用した？問題を改善するサイクルが早まり、目標値とのギャップに対して都度アクションを打てた結果、ギャップがなくなりました。
ポイントは問題に対して毎度正しい改善ができたことではなく、細かく改善を試みることができたことです。サイクルが早まったことにより、さまざまな改善を都度行うことができたのが良かったと思います。

 目標達成したことによる変化commitからmergeまで平均50時間は達成。リードタイムは改善され、定量的な変化は確認できました。一方で、定性的な変化も確認するためアンケートを実施しました。
開発生産性の中にはリードタイムのような定量的な側面と、開発者体験（DevEx）と呼ばれる定性的な側面が存在しており、前者だけに着目してしまうと数値をハックすることになりかねないため、バランスよく両者を計測することが大切だと考えています。

 アンケート個人とチームの2軸で以下の質問に回答いただきました。
リードタイム改善により、日々の（個人｜チーム）の業務はどのように変化しましたか？
リードタイム改善により、（個人｜チーム）が新たに得たスキルや成長を感じた部分はなんですか？
回答を要約すると、全体的にコミュニケーションのハードルが下がった、意識統一やチームの一体感が生まれたという意見が多くありました。
目標値に対する進捗が細かく追えるようになったことで、全員が同じ問題にフォーカスできるようになり、全員で問題解決を目指すという一体感が生まれました。
また、問題に対してのコンテキストを揃えるコストも減り、開発者体験の向上をメンバーが実感できていることが分かりました。

 まとめこれまでの説明を踏まえ、目標達成のための重要なポイントは以下の2点です。

問題の細分化
プロセスや問題に含まれる要素を細かく分析する
解決が困難な問題や複数の問題は、より小さな問題に分ける


基準の統一化
各プロセスに具体的な目標値を設定する
チーム全体で基準を共有し、合意を得る
定期的な振り返りを通じて、問題点と対策の認識を全員で揃える

これらの取り組みを実施することで、開発者体験の向上という副次的な効果があることも分かりました。
また、この開発生産性向上の取り組みはプロダクトチームのメンバーが主導するボトムアップ型のアプローチで実施されました。
この事例が示すように、開発生産性の向上は必ずしもトップダウンの指示だけでなく、メンバーが主導するボトムアップな取り組みでも達成できます。わたしたちの経験が、同じように開発生産性の向上に取り組む他のチームの参考になれば幸いです。

 Findy Team+ Award 2024 を受賞しましたこの度、ourly株式会社は開発組織全体で自己組織化が促進されている組織として選出いただきました！
https://award.findy-team.io/2024
https://note.com/ourly/n/n3169802c8160
数値の改善に関してはまだまだ伸びしろがあるため、引き続き改善活動に取り組みたいと思います！