デスマーチとはプロジェクトが抱える責任を全てプログラマにおしつけるということ

ソフトウェア開発のデスマーチの惨状を聞くと、ほとんど例外なくプログラマが徹夜で頑張っている。逆に言うと、プログラマが徹夜で頑張るしかないプロジェクトほどデスマーチになる確率が高いと言えるだろう。

プログラムを書かなければソフトウェアが完成しないのはその通りだと思うが、遅れた原因はプログラマにだけあるとは思えないのに、なぜプログラマだけが苦行に耐えないといけないのだろうか。

従来の開発方法の場合、原因ははっきりしていて、前工程が遅れて、納期は変わらないから、プログラミングの工程に全てのしわ寄せが来るのである。

やっかいなのはプログラミングの工程自体はスケジュール通りに始まっているというケースである。仕様が確定していないのになぜか並行で工程が進んでしまう。こうなると関係者はスケジュールはやや遅れているが問題ない（平行で動いているので効率的とまで思ってしまう）という認識になりやすい。

クリティカルパス（※）ってなんでしたっけと小一時間問い詰めたい気分になるのだが、とにかく仕様が出来ていないのにプログラムが作れるはずもなく、どんどんと遅れだしていつものデスマーチが始まる。

デスマーチとはプロジェクトが抱える責任を全てプログラマにおしつけるということなのである。必要なのは最後にプログラマが踏ん張ってなんとかすることでなくて、やばそうな状態を回避できるように早めに手を尽くすことである。

自分の仕事ではないのは百も承知でも政治的なレイヤーに口を挟まないと被害だけを被ることになる。顧客側も開発側も、中間で遅れているスケジュールが最後に取り戻せると思っているのがそもそもおかしいのである。

そんなことやりたくないからプログラマやってるんです、と言われそうな気もするし、そういう気質の人は多いわけだが、プログラマの義務として言うべきタイミングで言うべきことを言わないといけないと思う。無言で頑張るだけがプログラマの仕事ではないはずだ。責任取れないのであれば回避の手段ぐらいは持たないといけないのだ。

※「クリティカルパス」　プロジェクトの完成を遅らせないためには絶対に遅らせてはならない工程の組み合わせのことです。言い換えると、前が終わらないと次に進めない工程の組において最も長くなる工程のことであり、クリティカル･パスの長さはプロジェクト全体の長さを意味します。
http://www.mitsue.co.jp/case/glossary/y_023.html 　より引用