「デスマーチ」を編集中

'''デスマーチ'''（[[英語]]：death march）とは、プロジェクトにおいて見積および管理の不手際により発生した過酷な労働状況をいう。

== 概要 ==
デスマーチは[[プログラマー]]である [[Andrew Koenig]] によって[[1995年]]に示されたコンピュータシステムの[[アンチパターン]]のうち、[[プロジェクトマネジメント]]上の問題点のひとつとして示した言葉である。
特に納期などが破綻寸前で関係者の負荷が膨大になった[[プロジェクト]]の状況を表現するのに使われる。「死の行進」、「死の行軍」などとも呼ばれる。

同様の問題は「[[人月の神話]]」などで古くから問題提起されてきたが、「デスマーチ」という万人が理解できる「言葉」としてのインパクトが非常に強かったためか、現在では[[ソフトウェア産業]]に限らず[[コンピューター]]が関係するあらゆる場面でも使われるようになってきている。

大規模なプロジェクトでは責任の所在が問題となるため「成功」の体裁を見繕うことが多いが、現実には破綻していることが多い。

== 主な原因 ==
デスマーチは営業能力に乏しい人物が失注を恐れ[[不当廉売]]に近い受注を行い、また管理能力に乏しい人物が人員の[[冗長化]]などを行わずプロジェクトを進行することによって発生するものであるとされる。

いわゆる[[ドカタ]]と呼ばれる土木建築業界などでは「[[設計]]」と「[[積算]]」が「[[見積]]」より前の段階で行われる。また、工事中の不慮の事故などによって欠員がでる前提で見積を作ることが一般的であり、過労死などによる死者が発生しても補える体制を整えていることが多い。

一方で[[ITドカタ]]の世界では「[[見積]]」のあとに「[[設計]]」を開始することが多く、始める前から予算の関係で手抜きをせざるを得ない状況となっていることも多い。
これはITドカタの世界には建築の世界でいう建築基準法のような最低限の品質を強制する法律がないため、手抜きが横行しやすいという特性によるところも大きい。建築の世界では手抜きを行えば耐震偽装問題などのように建築士法や電磁的公正証書原本不実記載、建設業法違反などで刑務所送りであるが、詐欺師が受注して[[ITドカタ]]に[[丸投げ]]しても罰する法律がなく、せいぜい民事訴訟の末に受注額の一部返金で済ますことが多い。

このため[[ITドカタ]]の世界ではたとえ「[[write once, run away]]」を行っても刑務所送りにならないどころか、返金すらせずに逃げ切る詐欺まがいの行為が横行しているのが実情である。

== 主な症状 ==
デスマーチに陥ると、長時間の[[残業]]や[[徹夜]]、[[休日出勤]]の常態化といったプロジェクトメンバーに極端な負荷を強いる。プロジェクト要員は心身ともに極めて重い負担を強いられるため、急激な体調不良、離職、開発の破棄ともとれる中途半端な状態での強引な納品、場合によっては[[過労死]]や[[過労自殺]]に至る。

欠員が出ること自体は適切に計画されていれば家庭の事情や不慮の事故などで想定されることであり、たとえ過労死であろうとプロジェクト自体への影響は抑制できるが、デスマーチと呼ばれるプロジェクトでは人員配置が無計画であるがために追加人員への説明に時間を要して本来の進行が止まるなどの被害を拡大させることが多い。これは[[人月の神話]]の時代から散々言われてきたことである。

また、デスマーチに限らず、極度の過労状態に陥るとアルコールよって泥酔した状態と非常に酷似した状態になることが医学的に明らかになっており、結果として残業などによって更なる品質の低下を招く。

== 定義 ==
「デスマーチ」という言葉を広めたのは、[[エドワード・ヨードン]]であると言われている。ヨードンは、その著書『デスマーチ：なぜソフトウエア・プロジェクトは混乱するのか』で、デスマーチの定義を「プロジェクトのパラメータが正常値を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>。

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

== 関連項目 ==
* [[ブラック企業]]
* [[プロジェクトマネジメント]]
* [[人月の神話]]
* [[アンチパターン]]
* [[制約条件の理論]]
* [[クリティカルチェーン・プロジェクトマネジメント]]
* [[葬儀]]

== 参考文献 ==
{{Reflist}}
#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

[[category: プログラミング]]