このように、一般に行われているようなソースコード上で該当箇所を見付け次第に変更してしまうやり方では、不適切な変更が行われたり、協同作業では大きな混乱が生じたりしますが、その他に、以下に挙げるような作業（行為）が増えて工数も失うことになります。
- 短納期の圧力が急がなければという気持ちをかき立て、理解不十分な状態であるにも関わらず見付け次第にソースコードを変更してしまう。
- 数日前に変更した箇所と変更が重なったとき、前に変更した箇所を読み返しながら、その時の状況を思い出そうとするのですが、ソースコードがすでに変更されていることもあって容易には思い出すことができません。結果として不適切な変更をする可能性が高くなります。
- またそのような中で、すでに変更した箇所が間違って変更したことが判明し、変更のし直しが生じます。この場合も、関連する箇所を漏らしてしまうことが少なくありません。
このような手戻り作業が後半になってどんどん増えていき、短納期でかけがえのない工数を失うだけでなくソースコードを思いつくままに変更することによる品質の低下も招くことになります。
XDDPでは、無駄のないプロセスと「変更３点セット」の成果物の効果などにより、こうした手戻り工数の多くが消えてしまいます。さらに変更箇所や変更内容について早い段階でレビューされることで思い込みや勘違いが事前に指摘され、間違った変更も大幅に減ります。その結果、kLOCあたりのバグ発生率は１／５から１／１０に減少しており、事前に獲得していた工数も平均で３割前後が余るという状態が起きています。中には５割の削減も珍しくありません。
XDDPの開発アプローチは２つの場面で活用できます。
- 派生開発の混乱時にこれを使って混乱を静める
- 混乱が鎮まったあとは混乱の種を元から消す
多くの組織では、不適切なプロセスで派生開発に対応しているためにデスマーチの状態に陥っていることが少なくありません。でもXDDPを適用することで状況によっては１回でデスマーチから脱却することもあります。
また、ひとたびデスマーチの状態が解消した後は、派生開発を組織に行き渡らせることでさらに効果を広げることができます。ソースコードの寿命を長持ちさせるためのリファクタリングに適用したり、SPL (Software Product Line)などの他の手法と接続したりしてさらに開発の効果を上げることもできます。さらに、XDDPの適用によって回収した時間を将来のために投入することもできます。そこにあるソースコードは長期にわたって不適切なプロセスによって痛んでいますので、早晩、新規に開発しなおす必要性が高くなっていると考えられます。新規開発の設計技術の一部（アーキテクチャ設計の部分）は派生開発の中では出てきませんので、別に学習する必要があります。
XDDPの導入によって回収した時間をこうした新しい技術を吸収するために使ったり、いろいろな勉強会に参加したりして将来に備えることができます。派生開発と並行して新規開発に着手することもできます。何よりも重要なことは、そこにいるソフトウェアエンジニアが疲弊しないで済むということです。
派生開発推進協議会 初代代表 清水 吉男