変更コスト曲線

理由は、ひとつの決定の上にどれだけの作業が積み上がっているかにあります。要件が構想書にあるだけなら、変更は 1 つの文書に影響するだけです。設計に反映されていれば、設計とそこから派生したすべてに影響します。実装され検収まで終わっていれば、手戻り、再検証、ドキュメント、関係者への連絡が加わります。そのため曲線は直線的ではなく、ほぼ指数関数的に上昇します。

この数値は バリー・ベーム に由来します。ベームは 1981 年の著書「Software Engineering Economics」で、プロジェクトのデータからこれを導きました。実行フェーズの費用が大きい従来型のプロジェクト、たとえば建設、プラント建設、イベントなどでは、この関係は現在も変わりません。現場で変更されたものは、計画段階で変更していれば済んだ費用の何倍もかかります。

ソフトウェア開発では、この曲線はかなり平坦になりました。自動テスト、継続的インテグレーション、小さなリリースが、遅い変更のコストを大きく下げています。ケント・ベック はここから逆の主張を立てています。曲線が平坦であれば早期に決めてしまう利点はなくなり、もっとも情報が揃った時点で判断できるようになります。

したがって曲線の形は、手法ではなく対象となる案件によって決まります。実行が高価で成果が積み上がっていく領域、たとえば建設や移行案件では急峻になります。修正が安価で自動的に検証できる領域では平坦なままです。この傾きが、プロジェクトライフサイクル のどのフェーズで決定に価値があるかを決めます。