デスマーチ
デスマーチ (death march) とは、プロジェクトにおいて過酷な労働状況をいう。本来は、コンピュータプログラマのアンドリュー・ケーニッヒによって1995年に示された、コンピュータシステムのアンチパターンのうち、プロジェクトマネジメント上の問題点の1つとして示した言葉である。日本語では、しばしば「デスマ」と略される。
ソフトウェア産業に限らず、コンピュータが関係する一般的なプロジェクト全般で使われるようになってきており、特に納期などが破綻寸前で、関係者の負荷が膨大になったプロジェクトの状況を表現するのに使われる。「死の行進」「死の行軍」等とも呼ばれる。
概要
デスマーチとは、長時間の残業や徹夜・休日出勤の常態化といった、プロジェクトメンバーに極端な負荷・過重労働を強い、通常の勤務状態では成功する可能性がとても低いプロジェクト、およびこれに参加させられている状況を主に指す。
プロジェクトが死に向かう過酷な状況でプロジェクト要員が行進するという意味から、「デスマーチ」と呼ばれる。プロジェクト要員は、心身ともに極めて重い負担を強いられるため、急激な体調不良、離職、開発の破棄ともとれる中途半端な状態での強引な納品、場合によっては過労死や過労自殺に至る。その発生要因は、プロジェクトに対するマネジメント（プロジェクトマネジメント）が不適切であることとされている。
「デスマーチ」という言葉を広めたのは、エドワード・ヨードンであると言われている。ヨードンは、その著書『デスマーチ：なぜソフトウエア・プロジェクトは混乱するのか』で、デスマーチの定義を「プロジェクトのパラメータが正常値を50 %以上超過したもの」[1]もしくは「公正かつ客観的にプロジェクトのリスク分析（技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む）をした場合、失敗する確率が50 %を超えるもの」[2]としており、具体的には以下のいずれかに該当するものと定めている。
- 与えられた期間が、常識的な期間の半分以下である
- エンジニアが通常必要な人数の半分以下である
- 予算やその他のリソースが必要分に対して半分である
- 機能や性能などの要求が倍以上である
また、ヨードンは『デスマーチ第2版』において、デスマーチを「成功する可能性」と「プロジェクトメンバーの満足度」の高低を軸として、4種類に分類している[3]。
- 自滅型 (suicide)
- 満足度も、成功する可能性も低い。
- プロジェクトマネージャーもプロジェクト要員も、プロジェクトの失敗を予感しているが、抜け出すことはできない状態。
- カミカゼ型 (kamikaze)
- 満足度は高いが、成功する可能性は低い。
- 自滅型と異なり、プロジェクトマネージャーもプロジェクト要員も士気は高い。プロジェクトそのものは失敗しても、そこから何らかの教訓を得たり、メンバーは満足感を得る。
- スパイ大作戦型 (mission impossible)
- 満足度も、成功する可能性も高い。
- デスマーチの中でも成功する確率は高い。プロジェクト要員の「卓抜した技術と勤勉さ」[4]とプロジェクトチームの結束によって、プロジェクトは成功するかもしれない。ただし、テレビドラマや映画と違って、犠牲者は生じるかもしれない。
- モーレツ型 ("ugly")
- 満足度は低いが、成功する可能性は高い。
- 軍隊式のスパルタ・プロジェクトであり、ヨードンは以下の特徴を挙げている。
- プロジェクトマネージャーはプロジェクトを成功させるつもりである。
- プロジェクトマネージャーはプロジェクトを成功させて利益を得ようとしており、企業内競争に勝ち抜くつもりである。
- プロジェクトマネージャーはプロジェクトの成功のためならプロジェクト要員の健康や幸せが犠牲になることを厭わない[5]。
ヨードンはデスマーチを回避する方法として、「トリアージ」(en)を強調している[6]。
顧客の求めている全ての機能を盛り込むのではなく、優先順位を判断して必須機能のみを開発し、リリースする。その後、追加機能の開発やリリースを段階的に行う。これを顧客との合意するうえでの政治力がデスマーチの回避方法として重要であると、ヨードンは述べている。
出典
参考文献
- Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects、1997年、NCID BA63231533
- エドワード・ヨードン著 / 松原友夫・山浦恒央訳, デスマーチ―なぜソフトウエア・プロジェクトは混乱するのか, シイエム・シイ（2001） ISBN 4-901280-37-6
- エドワード・ヨードン著 / 松原友夫・山浦恒央訳, デスマーチ第2版ソフトウエア開発プロジェクトはなぜ混乱するのか,日経BP社 （2006） ISBN 4-8222-8271-6