- 納期・人員・予算が圧倒的に足りないまま突き進む、破綻寸前のプロジェクトのこと！
- 残業や徹夜が常態化し、メンバーの心身が限界を超える過酷な労働環境を生む
- 見積もりの精度向上と優先順位の合意形成を徹底すれば、未然に防げるケースが多い
4コマ漫画では登山ツアーをメタファーに使っていますが、これはIT現場で実際に頻発するケースそのものです。本来3か月かかるシステム開発を1か月で納品すると営業が約束してしまう。これがデスマーチの典型的な発火点であり、見積もりと実態の乖離がすべての根源にあたります。
漫画2コマ目の道具不足・食料不足は、人員や予算が確保されないままプロジェクトが走り出す状況と重なるでしょう。エドワード・ヨードン氏の定義では、必要リソースの半分以下で始まったプロジェクトはデスマーチに該当します。足りないリソースを残業で埋めようとすれば、メンバーの疲弊が品質低下を招き、品質低下がさらなる手戻りを生むという悪循環に陥りかねません。
注目すべきは3コマ目のガイドの判断です。頂上を一気に目指すのではなく、5合目をまず目標に切り替えました。実務においてはこれをスコープの再定義とトリアージと呼びます。全機能を一括納品する計画から、優先度の高い機能だけを先にリリースする段階的アプローチへ転換する行為にほかなりません。この判断が早ければ早いほど、チームの体力と信頼を温存できるのです。
一方で、計画の見直しを怠った場合のリスクは深刻でしょう。労働基準法上、月80時間を超える時間外労働は過労死ラインとされており、デスマーチの放置は法的責任や損害賠償に直結する経営リスクでもあります。人が倒れてからでは遅いという教訓を、この4コマは登山という身近なシーンで端的に示しています。
【深掘り】これだけ知ってればOK！
デスマーチという言葉は、エドワード・ヨードン氏が1997年の著書で広めたIT業界の用語です。直訳すると死の行軍。もともとは戦時中の捕虜が過酷な行軍を強いられた状況を指す言葉でしたが、IT業界ではシステム開発プロジェクトの現場が同じように追い詰められる状態を表現するために使われるようになりました。
ヨードン氏はデスマーチの具体的な定義として、与えられた期間が通常の半分以下、必要な人員が半分以下、予算が半分以下、要求される機能が通常の倍以上のいずれかに該当するプロジェクトを挙げています。つまり、冷静に判断すれば失敗する確率が50%を超えるにもかかわらず、走り始めてしまったプロジェクトがデスマーチの正体です。
では、なぜこのような状況が生まれるのでしょうか。主な原因は大きく3つに分けられます。1つ目は見積もりの甘さです。営業部門が技術的な難易度を正しく把握しないまま案件を受注してしまうケースが典型的でしょう。2つ目は途中での仕様変更。顧客からの追加要望をそのまま受け入れてしまい、スケジュールだけが据え置きになる状況を招きます。
3つ目はプロジェクト管理の不備です。進捗の遅れに気づいても対策を打たず、根性論で乗り越えようとする組織文化が、デスマーチを加速させてしまいます。リソースの不足を残業で補い、疲弊したメンバーの効率がさらに下がるという悪循環に陥るのが特徴です。
会話での使われ方
このままだと完全にデスマーチに突入するから、今のうちにスコープを絞って顧客と再調整しよう。
プロジェクトマネージャーが開発チームとの定例会議で、スケジュール遅延の兆候を察知して方針転換を提案している場面です。
前回の案件がデスマーチ化した原因を振り返って、次は見積もり段階からバッファを確保しましょう。
開発部の部長がプロジェクト完了後のふりかえり会議で、次の案件に向けた改善策をチームに共有している場面です。
隣のチームがデスマってるらしいけど、人員の追加要請は出してるのかな。
先輩エンジニアが後輩に対して、他チームの状況について雑談している場面です。日常会話ではデスマーチを略してデスマと呼ぶことも多くあります。
【まとめ】3つのポイント
- ゴールの見えない強制行軍：デスマーチとは、リソースが圧倒的に不足したまま走り続ける破綻寸前のプロジェクト
- 見積もりと合意形成が命綱：要件定義の段階で責任範囲と優先順位を顧客と握ることで、過重労働の芽を摘める
- 放置すれば人が壊れる：対策を打たなければ離職や体調不良が連鎖し、プロジェクトだけでなく組織そのものが崩壊するリスクがある
よくある質問
-
Qデスマーチが発生する主な原因は何ですか？
-
A
主な原因は、見積もりの甘さによる納期・人員・予算の不足、途中での仕様変更、そしてプロジェクト管理の不備です。特に営業が技術的な難易度を把握しないまま受注するケースや、顧客の追加要望を断れずスケジュールだけが据え置きになる状況が代表的な引き金となります。
-
Qデスマーチを未然に防ぐにはどうすればよいですか？
-
A
最も有効なのは、要件定義の段階で顧客と責任範囲・優先順位を文書で合意しておくことです。エドワード・ヨードン氏もトリアージ（機能の優先順位付け）の重要性を強調しています。全ての要望を受け入れるのではなく、必須機能に絞って段階的にリリースする計画を立てることが予防の鍵になります。
-
Qデスマーチに巻き込まれたらどう対処すべきですか？
-
A
まず、何が原因で炎上しているのかを冷静に分析しましょう。やるべきタスクと未決定事項を洗い出し、優先順位をチームで共有することが第一歩です。闇雲に作業を続けるのではなく、顧客への再交渉や人員追加の要請など、根本的な対策を上長に提案することが重要になります。
-
Qデスマーチと炎上プロジェクトとの違いは何ですか？
-
A
炎上プロジェクトは、予算・納期・品質のいずれかが大幅に計画を逸脱してしまったプロジェクト全般を指す言葉です。一方デスマーチは、その炎上状態の中で特にメンバーが長時間残業や徹夜・休日出勤を強いられ、心身の限界を超えるほどの過酷な労働環境に置かれている状況を強調した表現です。炎上がプロジェクトの状態を表すのに対し、デスマーチは現場の人間にかかる負荷に焦点を当てた言葉といえます。
【出典】参考URL
https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B9%E3%83%9E%E3%83%BC%E3%83%81 ：デスマーチの定義・エドワード・ヨードンによる分類・発生要因の根拠
https://e-words.jp/w/%E3%83%87%E3%82%B9%E3%83%9E%E3%83%BC%E3%83%81.html ：IT用語としてのデスマーチの定義・語源の根拠
https://www.kokuyo-furniture.co.jp/contents/dic-deathmarch.html ：デスマーチの原因一覧と予防策の根拠
https://e-words.jp/w/%E7%82%8E%E4%B8%8A%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88.html ：炎上プロジェクトとデスマーチの関係性の根拠
https://assign-navi.jp/magazine/engineer/death-march/e54.html ：ヒアリング不足によるデスマーチ事例と対策の根拠
コメント