|
|
1行目: |
1行目: |
− | {{Otheruses|[[ソフトウェア]]産業の[[プロジェクト]]|囚人・捕虜の行進|死の行進}}
| |
− | '''デスマーチ''' ({{lang|en|death march}}) とは、[[プロジェクト]]において過酷な[[労働]]状況をいう。本来は、[[コンピュータプログラマ]]の{{仮リンク|アンドリュー・ケーニッヒ (プログラマー)|en|Andrew Koenig (programmer)|label=アンドリュー・ケーニッヒ}}によって[[1995年]]に示された、[[コンピュータシステム]]の[[アンチパターン]]のうち、[[プロジェクトマネジメント]]上の問題点の1つとして示した言葉である。[[日本語]]では、しばしば「デスマ」と略される。
| |
| | | |
− | ソフトウェア産業に限らず、コンピュータが関係する一般的なプロジェクト全般で使われるようになってきており、特に納期などが破綻寸前で、関係者の負荷が膨大になった[[プロジェクト]]の状況を表現するのに使われる。「'''死の行進'''」「'''死の行軍'''」等とも呼ばれる。
| + | '''デスマーチ''' ({{lang|en|death march}}) |
| | | |
− | == 概要 ==
| + | 1 死の行進 |
− | '''デスマーチ'''とは、長時間の[[残業]]や[[徹夜]]・[[休日出勤]]の常態化といった、プロジェクトメンバーに極端な負荷・[[過重労働]]を強い、通常の勤務状態では成功する可能性がとても低いプロジェクト、およびこれに参加させられている状況を主に指す。
| |
| | | |
− | プロジェクトが[[死]]に向かう過酷な状況でプロジェクト要員が行進するという意味から、「デスマーチ」と呼ばれる。プロジェクト要員は、心身ともに極めて重い負担を強いられるため、急激な体調不良、[[離職]]、開発の破棄ともとれる中途半端な状態での強引な[[納品]]、場合によっては[[過労死]]や[[過労自殺]]に至る。その発生要因は、プロジェクトに対するマネジメント(プロジェクトマネジメント)が不適切であることとされている。
| + | 2 長時間の残業や徹夜の業務・休日出勤などを、連日強いられること。特にソフトウエア業界などで、膨大な作業の終わりが見えない状態を「死の行進」にたとえていう。ブラック企業 |
| | | |
− | 「デスマーチ」という言葉を広めたのは、[[エドワード・ヨードン]]であると言われている。ヨードンは、その著書『デスマーチ:なぜソフトウエア・プロジェクトは混乱するのか』で、デスマーチの定義を「プロジェクトの[[母数|パラメータ]]が正常値を50 %以上超過したもの」<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.2</ref>もしくは「公正かつ客観的にプロジェクトのリスク分析(技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む)をした場合、失敗する確率が50 %を超えるもの」<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.4</ref>としており、具体的には以下のいずれかに該当するものと定めている。
| |
| | | |
− | # 与えられた期間が、常識的な期間の半分以下である
| + | {{テンプレート:20180815sk}} |
− | # エンジニアが通常必要な人数の半分以下である
| |
− | # 予算やその他の[[経営資源|リソース]]が必要分に対して半分である
| |
− | # 機能や性能などの要求が倍以上である
| |
− | | |
− | また、ヨードンは『デスマーチ第2版』において、デスマーチを「成功する可能性」と「プロジェクトメンバーの満足度」の高低を軸として、4種類に分類している<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.55</ref>。
| |
− | | |
− | ; 自滅型 (suicide)
| |
− | : 満足度も、成功する可能性も低い。
| |
− | : [[プロジェクトマネージャー]]もプロジェクト要員も、プロジェクトの失敗を予感しているが、抜け出すことはできない状態。
| |
− | ; [[神風特別攻撃隊|カミカゼ]]型 (kamikaze)
| |
− | : 満足度は高いが、成功する可能性は低い。
| |
− | : 自滅型と異なり、プロジェクトマネージャーもプロジェクト要員も[[士気]]は高い。プロジェクトそのものは失敗しても、そこから何らかの教訓を得たり、メンバーは満足感を得る。
| |
− | ; [[スパイ大作戦]]型 (mission impossible)
| |
− | : 満足度も、成功する可能性も高い。
| |
− | : デスマーチの中でも成功する確率は高い。プロジェクト要員の「卓抜した技術と勤勉さ」<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.56</ref>とプロジェクトチームの結束によって、プロジェクトは成功するかもしれない。ただし、テレビドラマや映画と違って、犠牲者は生じるかもしれない。
| |
− | ; モーレツ型 ("ugly")
| |
− | : 満足度は低いが、成功する可能性は高い。
| |
− | : 軍隊式のスパルタ・プロジェクトであり、ヨードンは以下の特徴を挙げている。
| |
− | :* プロジェクトマネージャーはプロジェクトを成功させるつもりである。
| |
− | :* プロジェクトマネージャーはプロジェクトを成功させて利益を得ようとしており、企業内競争に勝ち抜くつもりである。
| |
− | :* プロジェクトマネージャーはプロジェクトの成功のためならプロジェクト要員の健康や幸せが犠牲になることを厭わない<ref>ヨードン著 松原・山浦訳 『デスマーチ第2版』 , p.57</ref>。
| |
− | | |
− | ヨードンはデスマーチを回避する方法として、「[[トリアージ]]」([[:en:Business triage|en]])を強調している<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
| |
− | | |
− | == 関連項目 ==
| |
− | * [[プロジェクトマネジメント]]
| |
− | * [[銀の弾などない]] - [[銀の弾丸]]
| |
− | ** [[人月]]
| |
− | ** [[人月の神話]]
| |
− | * [[アンチパターン]]
| |
− | * [[制約条件の理論]]
| |
− | ** [[クリティカルチェーン・プロジェクトマネジメント]]
| |
− | * [[ブラック企業]] - [[IT業界離れ]]
| |
− | * [[過労死]] - [[過労自殺]]
| |
− | | |
− | == 外部リンク ==
| |
− | * [http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/012600470/ 記者の目 - 「死の行進」から生還するための心得] - [[日経コンピュータ]]
| |
− | | |
− | {{就業}}
| |
| {{DEFAULTSORT:てすまあち}} | | {{DEFAULTSORT:てすまあち}} |
| [[Category:経営学]] | | [[Category:経営学]] |