公開日
優秀なチームでも生産性は安定しない？データが示すサイクルタイムの変動性
チームの生産性をどうすれば向上できるのか。これは多くのエンジニアリングマネージャーやリーダーが抱える永遠の課題かもしれません。「サイクルタイムを短縮すれば、アウトプットは増えるはずだ」と考え、その数値を追いかけることは、一見すると正しいアプローチに思えます。しかし、その常識は本当に正しいのでしょうか。
本記事では、Pluralsight社の研究者らが発表した論文「NO SILVER BULLETS: WHY UNDERSTANDING SOFTWARE CYCLE TIME IS MESSY, NOT MAGIC」(2025年)に基づき、その答えを探ります。216組織、1万1千人以上のエンジニアから得られた5万5千件以上の膨大なデータを分析したこの研究は、私たちが信じてきた「生産性向上の常識」を覆す、衝撃的な結論を提示しています。
なぜ私たちは「サイクルタイム」に惹かれるのか？
そもそも定義が難しいソフトウェアの「生産性」
ソフトウェア開発における「生産性」は、工場の製造ラインのように「時間あたりの生産個数」で測れるものではありません。コードの行数、機能の実装数、コミット数など、様々な指標が提案されてきましたが、どれも一長一短で、品質やビジネスへの貢献度といった重要な側面を見過ごしがちです。開発者とマネージャーで「生産性」の定義が異なっている、ということも珍しくありません。
客観的指標として注目されるサイクルタイム
こうした背景の中、チケットが作成されてからクローズされるまでの時間を示す「サイクルタイム」は、比較的客観的で計測しやすいため、チームの健康状態や開発プロセスの効率を示す指標として広く使われています。実際に、ある業界レポートでは、サイクルタイムはエンジニアが最も信頼する生産性指標の一つとして挙げられています。多くのチームがサイクルタイムの短縮を目指すのは、こうした背景があるのです。
216組織、1万人以上のデータで解き明かすサイクルタイムの実態
では、サイクルタイムは実際に何によって左右されるのでしょうか。この疑問に答えるため、本研究では極めて大規模な実世界のデータが分析されました。
調査の概要：Pluralsight社による大規模分析
この研究は、216の組織に所属する11,398人のコントリビューターから、1年間にわたって収集された55,619件の観測データ（Gitとチケット情報）を分析したものです。特定の要因がサイクルタイムに与える影響をより正確に測るため、「ベイジアン階層モデリング」という統計手法を用いて、組織・個人・個人の月々の活動といった異なるレベルを分離して分析しているのが特徴です。
サイクルタイムを「短縮」させる4つの要因
分析の結果、一般的に「良いプラクティス」とされる行動が、実際にサイクルタイムを短縮させる傾向にあることがデータで裏付けられました。
- 週あたりのコーディング日数が多い： コーディングに集中できる日が多いほど、サイクルタイムは短くなります。
- マージされるPR（プルリクエスト）の数が多い： 作業を小さな単位に分割し、より多くのPRをマージする方が、サイクルタイムは短縮されます。
- 他の開発者との協業が多い： 多くの開発者が関わるPRに貢献している（ネットワーク分析における次数中心性が高い）人ほど、サイクルタイムは短い傾向にありました。「三人寄れば文殊の知恵」ということわざがあるように、共同作業は問題解決を早めるようです。
- （月単位で見ると）バグ修正チケットの割合が高い： これは少し意外な結果かもしれません。ある特定の月にバグ修正チケットの割合が増えた人は、その月のサイクルタイムが短くなる傾向にありました。これは、大規模な機能開発よりも、小規模なバグ修正の方が早く完了するためだと推測されます。
週あたりのコーディング日数とサイクルタイムの関係
コーディング日数が多いほど、サイクルタイムが短くなる傾向が見られます。
サイクルタイムを「長期化」させる要因
一方で、サイクルタイムを長期化させる要因も明らかになりました。
- PRあたりのコメント数が多い： これは、コラボレーションのもう一つの側面を示しています。一つのPRに対して多くのコメントがつく場合、それはタスクが複雑で、多くの議論や手戻りが必要であることを示唆している可能性があります。結果として、サイクルタイムは長くなる傾向にありました。
- （年単位で見ると）バグ修正チケットの割合が高い： 先ほどとは逆の結果です。年間を通じてバグ修正チケットの割合が高い人は、サイクルタイムが長くなる傾向にありました。これは、バグ修正に追われて本来のタスクに集中できない、あるいは、より困難なバグ修正を任される役割である、といった可能性が考えられます。
PRあたりのコメント数とサイクルタイムの関係
コメント数が増えるほど、サイクルタイムは長期化する傾向にあります。
単純ではない「バグ修正チケット」との複雑な関係
特に「バグ修正チケットの割合」が示す結果は重要です。月単位の短期的な視点ではサイクルタイムを「短縮」させ、年単位の長期的な視点では「長期化」させるという、一見矛盾した結果は、「サイクルタイムという指標は、見る角度によって全く異なる顔を見せる」という事実を浮き彫りにしています。
個別の要因よりも影響が大きい「サイクルタイムの変動性」
ここまで見てきたように、サイクルタイムに影響を与える要因は確かに存在します。しかし、この論文が示す最も重要な発見は、「これらの要因による影響は限定的で、それ以上に説明のつかない巨大な『変動』が存在する」という衝撃の事実です。
各要因がサイクルタイムに与える影響（50パーセンタイルから90パーセンタイルへの変化）
寒色がサイクルタイムの減少、暖色が増加を示します。同じ要因でも組織や時期によって影響が大きく異なることが分かります。
この図が示すように、例えば「コーディング日数を増やす」という施策の効果（青色の濃さ）は、組織や時期によって全く異なります。つまり、あるチームでうまくいった施策が、別のチームでうまくいくとは限らないのです。
ある月の好成績は”たまたま”？ 個人の中でもサイクルタイムは激しく変動する
この「変動」は、組織間や個人間だけでなく、一人のエンジニアの中でも存在します。下の図は、ランダムに抽出した個人のサイクルタイムが、1年間でどのように変動したかを示したものです。先月はサイクルタイムが非常に短かったエンジニアが、今月は非常に長くなる、といったことが頻繁に起こっているのが見て取れます。
たった一度の、あるいは一ヶ月のサイクルタイムの数値を見て、「Aさんは生産性が高い」「Bさんは低い」と判断することが、いかに危険であるかが分かります。
個人のサイクルタイム（月次中央値）の年間を通じた変動
個人のサイクルタイムが月によって大きく変動していることが分かります。
「10xエンジニア」という考え方の限界
このような巨大な変動性は、「10xエンジニア（＝10倍のパフォーマンスを出すエンジニア）」のような、個人の突出した能力に生産性の源泉を求める考え方にも疑問を投げかけます。たとえ非常に優秀なエンジニアがいたとしても、その人のパフォーマンスは常に一定ではありません。取り組むタスクの難易度、チームの状況、プライベートな要因など、無数の変数が絡み合い、アウトプットは常に揺れ動きます。個人のパフォーマンスだけに注目することは、この複雑な現実から目を背けることになりかねません。
結論：「銀の弾丸」探しはやめよう。生産性向上で本当にすべきこと
この大規模データ分析が私たちに突きつけるのは、「生産性向上に、たった一つの答え（銀の弾丸）はない」という、ある意味で不都合な真実です。では、私たちはこの現実とどう向き合えばよいのでしょうか。
個別の指標に一喜一憂しない
まず、サイクルタイムのような単一の指標の数値に一喜一憂することをやめるべきです。データが示すように、その数値は無数の要因と巨大な変動性の上に成り立つ、非常に「ノイズの多い」シグナルに過ぎません。短期的な数値を個人の評価に直結させたり、拙速な判断を下したりすることは、チームに混乱をもたらすだけです。重要なのは、長期的な視点で傾向を捉え、その背後にある文脈を理解しようと努めることです。
重要なのは「システム思考」：開発プロセス全体を俯瞰する
本論文が最終的に提言するのは、 個人に焦点を当てるのではなく、開発プロセス全体を一つの「システム」として捉える「システム思考」 の重要性です。
サイクルタイムは、様々な要因が複雑に絡み合った結果として現れる「アウトプット」です。その数値を改善したいのであれば、個別の要因に介入するだけでなく、「なぜコーディング時間が確保できないのか？」「なぜPRでの議論が長引くのか？」「なぜバグ修正チケットが特定の時期に増えるのか？」といった、システム全体の構造に目を向ける必要があります。
マネージャーやリーダーに求められるのは、魔法のような特効薬を探すことではありません。チームとの対話を通じて、自分たちの開発プロセスという名の「システム」を正しく理解し、どこにボトルネックがあるのか、どのレバーを引けば効果が生まれそうか、仮説を立て、実験し、辛抱強く改善を続けていくことなのです。データが示すこの厄介で魔法のない現実こそが、私たちのチームを本当に成長させるための、唯一の出発点と言えるでしょう。
開発生産性やチームビルディングにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: