開発速度を上げるために「ストレッチゴール」や「パーキンソンの法則」のことを考えたくなったら
納期の短縮を目指したのに、長期的にはむしろ開発に時間がかかってしまうようになることがありそう。
開発速度は当然早い方が良い。ストレッチゴールを設定してチームの成長を図る、あるいはパーキンソンの法則の対策するために、やや厳しい納期を設定することがあるかもしれない。
しかし、このようなアプローチは、長期的には開発速度の低下を招く可能性がある。
品質が落ちるかもしれない
開発速度と品質というと以下の発表が思い浮かぶ。
この発表によれば、質とスピードはトレードオフではない、つまり質を下げてスピードを得ることは長期的には成立しない。一方で、短期的には可能性があるとも考えられている（諸説あり、と書かれている）。
実際のところ、コードの共通化やテスト、「落ち穂」のタスクを後回しにしてリリースを優先することもあると思う。
品質を下げることでスピードを得てストレッチゴールを達成した場合、表面的にはチームが成長したように見えるかもしれないが、実際にはプロダクトの内部品質が低下している。将来の速度を落とすことで今の速度を得ているだけなので、成長も改善もしていない。
「余裕がない」のはいいことか
パーキンソンの法則があるからといって、締め切りに余裕があるとタイピングの速度が半分になる、なんてことは起きない（空いた時間で youtube を見たり SNS 触ったりするかもしれないが……）。
余裕があるからこそ、プロダクトや開発環境を良くしたり技術を深めたりといった行動をが取れたりもするので、必ずしも作業時間の短縮が成果につながるとは限らない。
要はバランス
1ヶ月かかる機能を2週間で作ろうとしても品質の高いものはできないし、1年かけたとしても、1ヶ月で開発した場合の12倍の品質になるわけではない。
結局のところ、費用対効果の高い部分を選択することが良い選択になる。与えられた期限で十分な品質の機能を持続的に開発できているかどうかが重要である。
速度と品質を両方計る
開発チームを評価する方法が速度だけだと間違った最適化をするかもしれないので、品質も計って改善しなければならない。
Four Keys でリリース頻度だけではなく平均修復時間や変更障害率も測るように、速度と品質の両方を高めていくことを考えなければならない。