デスマーチ（Death March）

デスマーチ（Death March）とは、無理な納期や人手不足のまま進められ、長時間労働が続いて、関わる人が疲れ果ててしまうような開発プロジェクトのことです。直訳すると「死の行進」で、IT業界では、破綻しかけたプロジェクトを指す言葉として広く使われています。

現実世界に例えると、デスマーチは到底たどり着けない距離を、食料も休みも足りないまま、期日までに歩き切れと命じられた行軍のようなものです。誰もが無理だと感じながら、引き返すこともできずに進み続けてしまいます。

デスマーチ図解

※画像をクリックすると拡大表示します。

言葉の広まり

言葉の出どころです。この言葉は、米国のソフトウェア技術者エドワード・ヨードン氏が1997年に出版した書籍の題名で広く知られるようになりました。同書は、成功の見込みが低いと分かっていながら進められるプロジェクトを「デスマーチ」と呼び、その実態や生き延び方を論じています。日本でも、開発現場の厳しさを表す言葉として定着しました。

デスマーチの兆候

気づくための目安です。プロジェクトがデスマーチに向かうときには、いくつかの共通した兆候が見られます。早めに気づけば、立て直す余地も残ります。

なぜ起きるのか

主な原因です。受注を取るために無理な納期や金額で契約してしまう、作業量を少なく見積もる、開発の途中で要望が次々と追加される、といったことが重なって起こります。発注する側と受ける側のどちらか一方だけでなく、双方の判断の積み重ねが原因になることが多く、構造的な問題ともいわれます。

人を増やしても解決しない

よくある誤った対応です。遅れを取り戻そうと途中で人を増やすと、新しく加わった人への説明や調整に時間が取られ、かえって遅れが広がることがあります。「遅れているソフトウェアの開発に人を追加すると、さらに遅れる」という経験則は、ブルックスの法則として古くから知られています。人数だけで解決しようとするのは危険です。

もたらす影響

被害の大きさです。長時間労働が続くと、確認の漏れが増えて品質が下がり、完成後も不具合の対応に追われることになります。何より、関わる人の心身の健康が損なわれ、退職者が出て、さらに人手が足りなくなる悪循環に陥ります。プロジェクトが終わっても、組織に深い傷が残ることがあります。

防ぐための工夫

予防の考え方です。根拠のある見積もりを示し、期間・費用・作るものの範囲のどれかを調整できるよう、早い段階で発注側と話し合うことが大切です。要望の追加は、影響を見積もったうえで受け入れるかを決める手順を設けます。遅れが見えたら、隠さずに早めに報告し、範囲を減らすなどの判断を仰ぐことが、傷を浅くする近道です。

働き方の見直しとの関係

近年の変化です。日本では働き方改革の一環として、時間外労働に罰則付きの上限が設けられ、際限のない残業で遅れを取り戻すやり方は、法律の面でも通用しなくなりました。短い期間で区切って作っては確かめるアジャイル開発の広がりもあり、無理を前提にしない計画づくりが、これまで以上に求められています。

巻き込まれたときは

個人としての身の守り方です。心身の不調を感じたら、無理を続けずに上司や社内の相談窓口、医師に早めに相談することが何より大切です。自分の作業量や残業の記録を残しておくと、状況を伝えるときの助けになります。プロジェクトの成否よりも、自分の健康を守ることを優先してください。

あわせて知っておきたい用語

• 炎上プロジェクト：
  遅れや問題が重なり、収拾がつかなくなったプロジェクトです。
• 見積もり：
  作業や製品にかかる費用や期間を、事前に計算して示したものです。
• アジャイル開発：
  短い期間で開発と確認を繰り返し、変化に柔軟に対応する進め方です。
• 技術的負債：
  その場しのぎの作りが、将来の開発の負担として積み重なることです。