理由はいくつか挙げられるが、次の3点にしぼって説明しよう。(1)デスマーチになっても作業中止に至らないから。(2)受託側も発注側も"本来あるべきだった仕様"を示せないから。(3)デスマーチ案件は完成後に受託側にとっての経営資源となるから。これらを説明したうえで、悲惨なデスマーチを防ぐための方策を示そう。
まずは、「(1)デスマーチになっても作業中止に至らないから」。建築では建築資材が空間を占拠しているため、倒壊すれば作業を中止せざるを得ない。ところが、ソフトウエア開発では物理的な資材を伴わないため、パッチを当てながら作業を継続できてしまう。ゆえに社会的な耳目を惹かない。こうして膨大な無駄と苦役を投入した果てに、システムは曲がりなりにも「完成」してしまう。ゆえに「あわや失敗かと思われたが、なんとか完成した」と認識される。原因としてせいぜい「プロジェク管理の不徹底」くらいは挙げられるだろうが、技術的な問題に関して蒸し返されることはない。
これには「(2)受託側も発注側も"本来あるべきだった仕様"を示せないから」も関係している。最終的に適切な仕様として完成したかどうかは、発注側も受託側もわからない。有り体に言えば「的外れな仕様のシステムが非常識なコストをかけて完成した」といったところなのだが、お互いに「では適切な仕様はどのようなものだったのか」を示せないので、この問題はうやむやにされる。ゆえに明らかな失敗とはみなされない。
発注側としては失敗を認めたくないという事情もある。当初の倍以上の開発コストをかけて、稼働が数年遅れになったとしても、「我が社のシステムは無事刷新された」と表明するだろう。とくに上場企業であれば責任追及が怖いので、システム刷新に失敗したとはなかなか公言できない。それでもあまりにも出来が悪いようであれば訴訟に至るが、互いに痛手が大きいのでその確率は低い。
続いて「(3)デスマーチ案件は完成後に受託側にとっての経営資源となるから」はどうだろう。保守性や可読性の劣悪さはデスマーチ化の一因となるが、それゆえに「他の業者では保守できない神経系」が出来上がる。いったん完成してしまえば受託側にとってそのシステムは「こっちのもの」で、顧客はもう逃げられない。下請けの技術者を送り込んで保守や二次開発のマージンを稼げば、一次開発での持ち出しは遅かれ早かれ回収できる。鬱になって去った技術者の代替はいくらでもいる。ようするに受託側にとってデスマーチは、彼らの大好きな多重下請体制の中で対応できる「想定内の日常」であり、異常で反省されるべき状況とはみなされない。