--- title: "デスマーチとは：システム開発で起きる原因と、発注者・受託側の回避策" url: "https://www.issoh.co.jp/column/details/19804/" published: 2026-11-15 updated: 2026-11-15 categories: ["DX"] publisher: "株式会社一創" --- # デスマーチとは：システム開発で起きる原因と、発注者・受託側の回避策 デスマーチとは、期間・人員・予算のどれかが正常な見積から大きく外れたまま進み、計画の時点で失敗する見込みのほうが高いシステム開発プロジェクトを指す言葉です。現場では、終わりの見えない残業と休日出勤が続く状態として現れます。この記事では、エドワード・ヨードンが示した定義を判定基準として使う方法、見積不足・スコープ膨張・体制不足という3つの原因が重なる仕組み、時間外労働の上限規制や取適法との接点を整理する記事です。そのうえで、受託側と発注者がそれぞれ契約前に打てる回避策と、引き受けを見送るべき条件を示します。 ## まとめ：デスマーチは契約前の見積・範囲・決める人の3点で防ぐ デスマーチの多くは、開発が始まる前に決まっています。根拠のない納期から逆算した工数、予備のない見積、同じ予算と納期のまま積み増される仕様変更、仕様を決める人の不在。どれも契約前か契約直後に手を打てる事柄で、走り出してから残業で埋めようとすると現場が持ちません。 受託側は、見積の前提条件と予備を書面で示し、変更要求を必ず費用と日程に換算して返します。発注者は、業務上の期限と必須機能を分けて伝え、意思決定者と回答期限を最初に決めることが予防策です。再見積で必要期間の半分しか取れないと分かった案件は、引き受けないか、範囲を削ってから契約します。 すでに炎上して計画の作り直しが必要な段階に入った案件は、予防ではなく立て直しの手順で扱います。 ## デスマーチとは：ヨードンの定義と炎上プロジェクト・長時間労働との違い ### ヨードンの定義：期間・人員・予算が正常値から50%以上外れた計画 デスマーチ（death march）はもともと、捕虜や兵士を極限まで歩かせる「死の行進」を指す英語です。ソフトウェア開発の用語として広めたのは、米国のソフトウェア工学者エドワード・ヨードンが1997年に出版した『Death March』（邦訳『デスマーチ』2001年、第2版2006年）でした。 ヨードンは、プロジェクトのパラメータが正常値を50%以上超過したものをデスマーチと呼びました。具体的には次のいずれかに当てはまる計画です。 - 与えられた期間が、同規模の案件で一般的な期間の半分に満たない - 投入できる技術者が、必要な人数の半分以下しかいない - 予算やその他のリソースが、必要な量の半分しかない - 求められる機能・性能が、通常の2倍以上に膨らんでいる この定義の要点は、残業時間ではなく計画値で判定する点です。言い換えると、要件定義が終わって見積が出た時点で、その案件がデスマーチかどうかはほぼ判定できます。後半の回避策は、この判定を契約前に行うことを前提に組み立てています。 ### 炎上プロジェクトとの違い：デスマーチは計画時点で無理を抱えた状態 似た言葉の「炎上プロジェクト」は、遅延・予算超過・品質の崩れが重なり、今の計画では約束を守れなくなったプロジェクト全体の状態を指します。主語はプロジェクトで、判定の時点は「問題が表に出た後」です。 デスマーチは、作業する人の側から見た呼び名です。最初から無理な計画で始まった案件は、表面上は順調に見える時期にも、現場では長時間労働で帳尻を合わせています。そこから品質が崩れ、遅延が隠せなくなった段階で、外からは炎上として見えるようになります。デスマーチは炎上の手前から始まっていることが多い、と整理しておくと対策の打ちどころを間違えません。 炎上が表に出た後に発注者が進める棚卸し・スコープ再定義・中止判断の手順は、[炎上プロジェクトとは：システム開発が炎上する兆候と原因、発注者側の立て直し手順](https://www.issoh.co.jp/column/details/19782/)で扱っています。本記事は、その手前で無理な計画を作らない方法に絞ります。 ## デスマーチの原因：見積不足・スコープ膨張・体制不足が重なる仕組み ### 厚生労働省が挙げるIT業界の残業理由：納期・顧客対応・仕様変更 原因を個人の努力不足や管理能力の問題に帰すことは、同じ事態が繰り返されるもとです。厚生労働省の[「IT業界の働き方・休み方の推進｜IT業界の現状と課題」](https://www.mhlw.go.jp/seisakunitsuite/bunya/koyou%5Froudou/roudoukijun/shigoto/it/state.html)は、ITエンジニアの業務で「厳しい納期」「顧客対応」「急な仕様変更」など、発注者からの要望に対応する業務が大きな比重を占めていると整理しています。所定外労働の理由にも「トラブル等の緊急対応」「顧客対応」「仕様変更」「納期・予算に無理がある」が並びます。 つまり、デスマーチの原因の多くは受発注の構造の中にあります。受託側だけ、発注者だけで直せるものではなく、見積・範囲・体制のそれぞれで双方が何を決めるかを分けて考える必要があります。 ### 見積不足：決まった納期から逆算した工数と予備ゼロで進める開発計画 最も多いのは、作る量から工数を積み上げるのではなく、先に決まった稼働日から逆算して工数を割り付けた見積です。たとえば必要な工数が12人月の案件を、6人の体制で3か月（18人月）と見積もれば余裕があるように見えます。ところが要件定義が終わっていない段階の見積は誤差が大きく、仕様が固まると工数が当初の1.5〜2倍に膨らむことは珍しくありません。 予備（バッファ）を積んでいない見積は、この誤差をすべて残業で吸収する前提になっています。受注競争で価格を下げるために予備を削った見積も同じです。見積の予実差の測り方と、段階ごとに積む予備の目安は[見積もり精度とは？予実差の測り方と段階別の目安・予備の決め方](https://www.issoh.co.jp/column/details/11003/)で詳しく扱っています。 ### スコープ膨張：同じ予算と納期のまま積み増される小さな仕様変更 2つ目は、開発途中で範囲が少しずつ広がる現象です。1件ずつは「画面に項目を1つ足す」「帳票の並び順を変える」程度の小さな依頼でも、追加のたびに費用と日程を見直さなければ、半年で数十件が積み重なります。ヨードンの定義でいう「機能が通常の2倍以上」は、契約時点ではなく、この積み増しの結果として到達することが多いのです。 発注者に悪意があるとは限りません。業務部門が開発中の画面を見て初めて要望に気付くのは自然なことで、問題は要望を受ける仕組みがないことにあります。要件追加を変更管理と追加見積で受ける契約の作り方は[スコープクリープとは：原因と防ぎ方、要件追加を変更管理と追加見積で扱う契約の要点](https://www.issoh.co.jp/column/details/19768/)で整理しています。 ### 体制不足：頭数は足りても仕様を決める人とレビューする人がいない 3つ目は体制です。開発者の人数が足りないケースに目が向きがちですが、実際に詰まるのは、仕様の採否を決める人と成果物をレビューする人が足りないケースです。発注者側の確認待ちで1〜2週間作業が止まり、その遅れを後工程の残業で取り返す。この繰り返しが、人数が揃っている案件でもデスマーチを生みます。 受託側でも、設計の中心人物が複数案件を兼務していると同じことが起きます。1人に質問が集中し、その人の残業時間が最初に上限へ近づきます。体制図に名前が載っていることと、その案件に必要な時間を割けることは別の話です。 ## デスマーチが法令に触れる点：時間外労働の上限規制と取適法の禁止行為 ### 時間外労働の上限規制：原則月45時間・年360時間、特別条項でも年720時間 長時間労働で納期を埋める計画は、法令の上限にぶつかります。厚生労働省の[「時間外労働の上限規制 わかりやすい解説」](https://www.mhlw.go.jp/hatarakikata/pdf/000463185.pdf)によると、労働基準法の上限は大企業で2019年4月、中小企業で2020年4月から適用されています。 | 項目 | 上限 | | ------------- | ------------- | | 原則（36協定） | 月45時間・年360時間 | | 特別条項の年間上限 | 年720時間以内 | | 時間外＋休日労働（単月） | 月100時間未満 | | 時間外＋休日労働（複数月） | 2〜6か月平均80時間以内 | | 月45時間を超えられる回数 | 年6か月まで | 違反には罰則があり、6か月以下の拘禁刑（2025年6月の刑法改正前は懲役）または30万円以下の罰金が科されるおそれがあります。月100時間未満と2〜6か月平均80時間の枠は、特別条項の有無にかかわらず常に適用されます。受託側のPMにとっては、デスマーチを残業で乗り切る選択肢そのものが、上限を超えた時点で法令違反になるということです。計画段階で、メンバーごとの月の残業見込みがこの表に収まるかを確かめてください。 ### 取適法の禁止行為：受託側に責任のない仕様変更と無償のやり直し要求 2026年1月1日、下請法は改正されて「中小受託取引適正化法（取適法）」になりました。ソフトウェアの開発委託は情報成果物の作成委託として対象に含まれ、資本金や従業員数の基準に当てはまる取引では、発注者は「委託事業者」として禁止行為の規制を受けます。 公正取引委員会の[「委託事業者の禁止行為」](https://www.jftc.go.jp/shitauke/shitaukegaiyo/oyakinsi.html)は11の行為を挙げており、その1つが「不当な給付内容の変更及び不当なやり直し」です。受託側に責任がないのに発注内容を変更し、または受領後にやり直しをさせて受託側の利益を不当に害すると違反になります。変更そのものが禁じられているわけではなく、変更で生じた費用を発注者が負担しないことが問題になります。 スコープ膨張を「サービスで対応してもらう」形で続けると、デスマーチの原因になるだけでなく、取引によってはこの規定に触れます。発注者にとっても、追加の費用を払って範囲を変える手続きを踏むことが自社を守る手段です。 ## 受託側の回避策：見積の根拠開示と変更管理で無理な計画を受けない ### 受注前に見積の前提条件と予備を書面で示し、納期の根拠を確かめる 受託側がまずやるべきことは、見積書に「何を前提にこの金額と期間になるか」を書くことです。対象の画面数・帳票数・外部連携の数、発注者側で用意するデータと回答期限、要件定義後に再見積する範囲を明記します。前提が崩れたときに見積を見直す根拠になり、価格だけで比べられる事態も防げます。 あわせて確かめるのは、発注者が示す稼働日の根拠です。法改正の施行日や既存システムの保守期限のように動かせない日付なのか、社内の目標として置いた日付なのかで、交渉の余地がまったく違います。動かせない日付であれば、範囲を削る提案を見積と同時に出します。 ### 変更要求はIPAモデル契約の変更管理書で費用と日程に換算して返す 開発中の変更要求は、口頭で受けた時点でデスマーチへの一歩になります。[IPAの情報システム・モデル取引・契約書（第二版）](https://www.ipa.go.jp/digital/model/model20201222.html)は、第37条で変更管理の手順を定めています。変更の提案を受けた側が「変更管理書」を作り、変更の理由・詳細・費用・スケジュール・契約条件への影響を書いて、連絡協議会で可否を協議する流れです。 実務では、小さな変更も含めて1件ずつ変更管理書の形で記録し、費用と日程への影響を数字で返してください。影響が小さければ「費用0円・日程影響なし」と書けばよく、その記録が積み重なると、どこで範囲が膨らんだかを双方が同じ表で確認できます。 ### 引き受けを見送る条件：再見積した必要期間の半分以下しか取れない案件 見積の前提を示し、範囲の削減も提案したうえで、なお次のどれかに当てはまる案件は引き受けません。 - 再見積した必要期間に対し、与えられた期間が半分以下 - 必要な技術を持つ要員を、開始時点で半数以上確保できない - 仕様の採否を決める人が発注者側で決まらず、回答期限も置けない - メンバーの残業見込みが、月45時間を超える月が7か月以上になる 最初の2つはヨードンの定義そのもの、4つ目は上限規制の「月45時間超は年6か月まで」に収まらない計画です。受注が欲しい場面ほど「なんとかなる」と考えがちですが、ここに当てはまる案件で利益が残ることはまずありません。断る場合も、どの条件が満たせないかを示せば、範囲や期間を見直した再依頼につながることがあります。 ## 発注者の回避策：納期の根拠・意思決定者・進捗の見方を先に固める ### 発注前に業務上の期限と必須機能を分け、納期の根拠を受託側に伝える 発注者が最初にできる予防は、「いつまでに、何が動けば業務が回るか」を分けて伝えることです。稼働日に必須の機能と、第2期以降でよい機能を発注前に分けておけば、見積が予算や期間を超えたときに範囲で調整できます。全部を同じ優先度で依頼すると、受託側は期間を削るか残業で埋めるかしか選べません。 納期と一緒に伝えるべき情報は、その日付を選んだ根拠です。法改正の施行日で動かせないのか、社内の決算期に合わせたいだけなのかが分かれば、受託側は現実的な段階リリースを提案できます。要件定義の段階で決めておく事項は[要件定義とは？決める内容・進め方・成果物と失敗を防ぐ発注者の役割](https://www.issoh.co.jp/column/details/12848/)、計画書への書き方は[プロジェクト計画書の書き方](https://www.issoh.co.jp/column/details/19762/)で示しています。 ### 発注者側の意思決定者と回答期限を決め、仕様の確認待ちで現場を止めない 体制不足の原因のうち、発注者が直せるのは「決める人」の部分です。仕様の採否を決める人、追加費用を承認する人、受入の合否を決める人を、部門名ではなく個人名で決めます。業務部門ごとに要望を出す人がいても、最後に採否を決める人がいなければ、受託側は全員の要望を受けるしかありません。 受託側からの確認事項には回答期限を付け、たとえば「3営業日以内に回答、間に合わない場合はその旨と見込み日を返す」と取り決めます。確認待ちで止まった日数を定例会で毎回数えるだけでも、発注者側が原因の遅れは目に見えて減ります。 ### 定例会で残作業の見積推移と残業時間を受け取り、兆候を早く掴む デスマーチは、進捗率よりも残作業の見積と残業時間に先に表れます。完了率が予定どおりに見えても、残作業の見積が毎週増えている、メンバーの残業時間が月45時間に近づいている、という2つが重なったら、計画に無理があるサインです。残作業の推移を1枚のグラフで追う方法は[バーンダウンチャートとは：見方と作り方、発注者が遅延を見抜く読み方](https://www.issoh.co.jp/column/details/19802/)で解説しています。 受託側の労働時間は受託側の管理事項ですが、「残業でカバーしている作業がどれだけあるか」を報告の項目に入れてもらうことは発注者にもできます。社内にこれらの数字を検証できる人がいない場合は、発注者側にPMOを置く方法があります。PMOの役割と外部に任せる判断は[PMOとは？役割・種類とPMとの違い](https://www.issoh.co.jp/column/details/19156/)で整理しました。一創では、発注前の要件定義と見積の妥当性確認から、開発中の進捗・変更管理の見張りまでを発注者側で支える[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)を提供しています。 ## デスマーチに入った後の判断：要員追加より先に開発範囲を削る理由 ### 要員追加が逆効果になるブルックスの法則と、範囲の削減を先に出す順序 すでにデスマーチ状態にある案件で、最初に出てくる案は要員の追加です。しかしフレデリック・ブルックスが1975年の『人月の神話』で示したとおり、遅れているソフトウェアプロジェクトに人を足すと、教育と連絡の負荷でさらに遅れる場面があります。追加した要員が戦力になるまでの数週間、既存メンバーの時間が削られるためです。 順序は、範囲を削る、期限を動かせるか確かめる、決定の遅い役割を補う、最後に作業者を足す、の順です。範囲の削減は発注者にしか決められないので、受託側は削減案を早く出し、発注者はその案に期限を付けて回答します。計画そのものを作り直す段階に入っている場合は、前述の炎上プロジェクトの立て直し手順に切り替えてください。 ## システム開発のデスマーチの原因・違法性・回避策に関するよくある質問 デスマーチについて、発注者と受託側の双方からよく出る質問をまとめました。 ### デスマーチの語源は何ですか？ 英語の death march（死の行進）で、捕虜などを過酷な条件で長距離歩かせる行為を指す言葉です。ソフトウェア開発の用語としては、エドワード・ヨードンが1997年の著書『Death March』で、期間・人員・予算などが正常値から50%以上外れたプロジェクトをこう呼んだことで広まりました。日本では2001年に邦訳が出ています。 ### デスマーチは違法ですか？ デスマーチという状態そのものを禁じる法律はありません。ただし、長時間労働で納期を埋めた結果、時間外労働が月45時間・年360時間の原則や、特別条項の年720時間、月100時間未満などの上限を超えれば労働基準法違反になります。また、受託側に責任のない仕様変更を費用負担なしで繰り返すと、取引によっては取適法の「不当な給付内容の変更」に当たることがあります。 ### アジャイル開発にすればデスマーチは防げますか？ 手法を変えるだけでは防げません。[アジャイル宣言の背後にある原則](https://agilemanifesto.org/iso/ja/principles.html)には、一定のペースを継続的に維持できるようにする「持続可能な開発」が含まれています。ただし、反復ごとに作る範囲を発注者と決め直す運用がなければ、短い期間ごとに無理な量を詰め込むだけの開発になるためです。範囲を優先順位で切る仕組みがあって初めて効果が出ます。 ### デスマーチになりやすいプロジェクトの特徴は何ですか？ 契約時点で見分けられる特徴が4つあります。稼働日が先に決まっていて見積がそこから逆算されている、見積に予備がない、要件定義が終わる前に固定価格で契約している、発注者側で仕様を決める人が決まっていない。2つ以上当てはまる案件は、開始前に範囲か期間を見直してください。 ### デスマーチの責任は発注者と受託側のどちらにありますか？ 一方だけの責任になることはまれです。無理な見積で受注した受託側にも、根拠のない納期を求めたり仕様の決定を遅らせたりした発注者にも、原因があることがほとんどです。IPAのモデル契約も、双方の分担と協力を前提に作られています。個別の案件で損害の負担を争う場合は、契約内容に基づいて弁護士に相談してください。 ## 関連記事 - [ベンダーコントロールとは？発注者が進捗・品質・変更を握る方法と偽装請負にならない線引き](https://www.issoh.co.jp/column/details/19770/)：発注者が平時に受託側の進捗と変更を管理する方法 - [リスク管理表の作り方：発生確率・影響度の項目と課題管理表との違い、更新の運用](https://www.issoh.co.jp/column/details/19780/)：見積不足や体制不足をリスクとして事前に登録して見張る表 - [プロジェクト進捗管理とは？遅延を防ぐ見える化の方法と会議運用の実務](https://www.issoh.co.jp/column/details/15672/)：定例会で遅延を早く見つけるための進捗の見せ方 - [準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説](https://www.issoh.co.jp/column/details/13187/)：要件が固まる前の工程を固定価格で請け負わないための契約形態 --- 出典: [デスマーチとは：システム開発で起きる原因と、発注者・受託側の回避策]()（株式会社一創）