「デスマーチ」を編集中 (節単位)

== 定義 ==
「デスマーチ」という言葉を広めたのは、[[エドワード・ヨードン]]であると言われている。ヨードンは、その著書『デスマーチ：なぜソフトウエア・プロジェクトは混乱するのか』で、デスマーチの定義を「プロジェクトのパラメータが正常値を50%以上超過したもの」<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.2</ref>もしくは「公正かつ客観的にプロジェクトのリスク分析（技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む）をした場合、失敗する確率が50%を超えるもの」<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.4</ref>としており、具体的には以下のいずれかに該当するものと定めている。
# 与えられた期間が、常識的な期間の半分以下である 
# エンジニアが通常必要な人数の半分以下である 
# 予算やその他のリソースが必要分に対して半分である 
# 機能や性能などの要求が倍以上である

また、ヨードンは『デスマーチ第2版』においてデスマーチを「成功する可能性」と「プロジェクトメンバーの満足度」の高低を軸に4種類に分類している<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.55</ref>。
=== 自滅型 (suicide) ===
:満足度も、成功する可能性も低い。
:プロジェクトマネージャーもプロジェクト要員も、プロジェクトの失敗を予感しているが、抜け出すことはできない状態。
=== カミカゼ型 (kamikaze) ===
:満足度は高いが、成功する可能性は低い。
:自滅型と異なり、プロジェクトマネージャーもプロジェクト要員も[[士気]]は高い。プロジェクトそのものは失敗しても、そこから何らかの教訓を得たり、メンバーは満足感を得る。
=== スパイ大作戦型 (mission impossible) ===
:満足度も、成功する可能性も高い。
:デスマーチの中でも成功する確率は高い。プロジェクト要員の「卓抜した技術と勤勉さ」<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.56</ref>とプロジェクトチームの結束によって、プロジェクトは成功するかもしれない。ただし、テレビドラマや映画と違って、犠牲者は生じるかもしれない。
=== モーレツ型 (ugly) ===
:満足度は低いが、成功する可能性は高い。
:軍隊式のスパルタ・プロジェクトであり、ヨードンは以下の特徴を挙げている。
:*プロジェクトマネージャーはプロジェクトを成功させるつもりである。
:*プロジェクトマネージャーはプロジェクトを成功させて利益を得ようとしており、企業内競争に勝ち抜くつもりである。
:*プロジェクトマネージャーはプロジェクトの成功のためならプロジェクト要員の健康や幸せが犠牲になることを厭わない<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.57</ref>。

ヨードンは、またデスマーチを回避する方法として「[[トリアージ]]」を強調している<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.128</ref>。

顧客の求めている全ての機能を盛り込むのではなく、優先順位を判断し、必須機能のみを開発しリリースする。その後に、追加機能の開発、リリースを段階的に行う。これを顧客との合意する上での政治力が、デスマーチの回避方法として重要であるとヨードンは述べている。