デスマーチ

デスマーチ (death march) とは、プロジェクトにおいて過酷な労働状況をいう。もとは、コンピュータプログラマである Andrew Koenig によって1995年に示されたコンピュータシステムのアンチパターンのうち、プロジェクトマネジメント上の問題点のひとつとして示した言葉である。

ソフトウェア産業に限らずコンピュータが関係する一般的なプロジェクト全般で使われるようになってきており、特に納期などが破綻寸前で関係者の負荷が膨大になったプロジェクトの状況を表現するのに使われる。死の行進、死の行軍等とも呼ばれる。

概要

デスマーチとは、長時間の残業や徹夜・休日出勤の常態化といったプロジェクトメンバーに極端な負荷を強い、通常の勤務状態では成功する可能性がとても低いプロジェクト、およびこれに参加させられている状況を主に指す。

プロジェクトが死に向かう過酷な状況でメンバーが行進する、という意味で「デスマーチ」と呼ばれる。メンバーは心身ともに極めて重い負担を強いられるため、急激な体調不良、離職、開発の破棄ともとれる中途半端な状態での強引な納品、場合によっては過労死や過労自殺に至る。その発生要因はプロジェクトに対するマネジメント（プロジェクトマネジメント）が不適切であることとされている。

「デスマーチ」という言葉を広めたのは、エドワード・ヨードンであると言われている。ヨードンは、その著書『デスマーチ：なぜソフトウエア・プロジェクトは混乱するのか』で、デスマーチの定義を「プロジェクトのパラメータが正常値を50%以上超過したもの」もしくは「公正かつ客観的にプロジェクトのリスク分析（技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む）をした場合、失敗する確率が50%を超えるもの」としており、具体的には以下のいずれかに該当するものと定めている。

1. 与えられた期間が、常識的な期間の半分以下である
2. エンジニアが通常必要な人数の半分以下である
3. 予算やその他のリソースが必要分に対して半分である
4. 機能や性能などの要求が倍以上である

デスマーチ状態の解消は困難を極める事が多い。予算や設定納期など、プロジェクト内部のメンバー以外の要因も多く絡むため、メンバーのみの努力での解消はほぼ不可能といえる。そのため、長時間残業が常態化することによってデスマーチを当たり前のように感じ、デスマーチに甘んじる負の循環が生まれる。さらに、極度な長時間労働それ自体がプロジェクトメンバーの「努力している」「労働している」という自負心を励起するため、あたかも奴隷が自分に繋がれた足かせの重りを自慢するかのように過酷な残業を自慢する傾向が見られる場合がある。

ソフトウェア産業におけるデスマーチは、「デスマ」という略語が存在し広く通じる程にある意味では普遍的なものであり、ソフトウエア産業全体がブラック企業の集まりに映る大きな要因になっている。プロジェクトがデスマーチの状況に陥ることを「デスマる」と称することもある。

デスマーチ状態に陥らないようにプロジェクトを始めるに当たっては、前述のように必要なリソースの正確な見積もりが極めて重要である。破たんが見えている状態（請負であれば契約内容）であればプロジェクトを開始しない判断も必要である。

火消し人

デスマーチ状態となっているプロジェクトを収束させるため、途中から参加するメンバーは「火消し人」などと呼ばれることがある。 途中参加であるゆえ、火消し人はプロジェクト全体や担当部分に関する知識を仕入れねばならない。火消し人は、既存のプロジェクトメンバーが自己の能力を超えて請け負った仕事の引き継ぎをすることになる。生き残った既存のメンバーの多くは担当範囲だけは熟知しているので「有能なメンバー」に見えるが、長期的な視点でプロジェクト全体の生産性を上げるには既存のメンバーからの情報収集と既存のメンバーの更迭が重要であり、「プロジェクトの事情」だけで居残っているメンバーの排除を促すことも火消し人の重要な役割である。

参考文献

• エドワード・ヨードン著 / 松原友夫・山浦恒央訳, デスマーチ―なぜソフトウエア・プロジェクトは混乱するのか, シイエム・シイ（2001） ISBN 4-901280-37-6
• エドワード・ヨードン著 / 松原友夫・山浦恒央訳, デスマーチ第2版ソフトウエア開発プロジェクトはなぜ混乱するのか,日経BP社 （2006） ISBN 4-8222-8271-6

関連項目

• ブラック企業
• プロジェクトマネジメント
• 人月の神話
• アンチパターン
• スパゲティプログラム