「予定では3か月で動いていたはずなのに、半年経っても画面が出ない」「ベンダーから連絡がなくなり、こちらから督促してようやく『遅れています』とだけ返ってくる」——中小企業経営者が直面するシステム開発のデスマーチには、発注側からは見えにくい火種の段階があります。本記事ではデスマーチに巻き込まれた経営者の典型的な体験談を3段階で整理し、火種の段階で気付くための4つの判断軸を解説します。
この記事の結論（3行）
- デスマーチは「要件の曖昧さ」「窓口の単線化」「進捗報告の質低下」の3つが揃った時点でほぼ確定する
- 発注側が止めるべきタイミングは、画面が出ない段階ではなく「議事録が来なくなった段階」
- 巻き戻しは「機能を3割捨てる・期日を後ろにずらす・体制を入れ替える」の3点セットで動かす
なぜシステム開発のデスマーチは発注側からも止められないのか
デスマーチとは、納期に間に合わない見込みが立っているのに、止まらずに走り続けてしまう状態を指します。技術書ではエンジニア側の労働問題として語られがちですが、発注した経営者の立場でも被害は深刻です。請求は止まらないのにシステムは出てこず、社内では「いつ動くのか」を問われ続けます。発注側からデスマーチを止められない理由は3つあります。
- 既に支払った費用がもったいないと感じてしまう
- ベンダーの「あと少しで動く」という言葉を信じてしまう
- 自社で巻き戻す体力がなく、走り続けるしかないと判断してしまう
この3つの心理が重なると、半年・1年と無駄なコストが積み上がっていきます。デスマーチは技術問題ではなく、発注側の意思決定の問題でもあります。
既に支払った費用がもったいないと感じる「サンクコストの罠」
着手金として300万円、中間金として300万円を既に支払った後で「このまま続けてもうまくいかない」と感じても、止める判断ができなくなります。経済学でいうサンクコスト効果です。支払い済みの費用は取り返せないにも関わらず、続ければ取り返せると錯覚してしまいます。冷静に見れば、止めて別ベンダーへ切り替えたほうがトータルで安く済むケースは少なくありません。
ベンダーの「あと少しで動く」を信じ続けてしまう
デスマーチに入ったベンダーは「あと2週間で動きます」と言い続けます。本人たちも本気でそう思っているケースが多く、嘘ではありません。ただし2週間後にまた「あと2週間」と言われ、これが半年続きます。発注側からは、本当にあと少しなのか、根本的に作り直しが必要なのかを判別できません。
自社で巻き戻す体力がない
社内にシステム担当者がいない中小企業では、ベンダーを切り替える判断自体が重荷です。「いまから別のベンダーを探して説明して契約してまた1からとなると、もう1年かかる」と考えてしまい、走り続ける選択をしてしまいます。
デスマーチに巻き込まれた経営者の体験談：3段階の火種
ここでは複数の経営者からヒアリングした体験談を、デスマーチが進行する3段階に整理します。
| 段階 | 期間 | 表面化する症状 | 発注側の対応の遅れ | |---|---|---|---| | 火種期 | 着手〜2か月 | 議事録の遅延・要件再確認の増加 | 「最初はこんなものだろう」と流す | | 拡大期 | 2〜5か月 | 進捗報告の質低下・窓口担当の交代 | 「もう少し待てば動く」と信じる | | 破綻期 | 5か月以降 | 画面が出ない・連絡が途絶える | 巻き戻しの体力がなく走り続ける |
3段階のうち、止められる可能性が高いのは火種期です。拡大期に入ると巻き戻しコストが急上昇し、破綻期に入ると別ベンダーへの切り替えしか選択肢が残りません。火種期で気付くために、自社の発注プロセスを業務改善・システム見積もりAI適正診断で点検しておくと、初期段階のリスクが見えやすくなります。
火種期（着手〜2か月）：議事録が遅れる・要件確認が増える
着手から2か月以内の段階で出る最初のサインは、議事録の遅延です。週次会議の議事録が翌日に出てこない、内容が薄くなる、決定事項の項目が抜けている——こうした変化が火種期の典型です。同時に「すみません、ここの要件をもう一度確認させてください」というベンダー側からの再確認が増え始めます。本来は要件定義で固まっていたはずの項目を改めて確認しているということは、設計段階で迷っている可能性が高い兆候です。火種期の特徴は、まだ表面上はプロジェクトが進行しているように見えることです。発注側が「最初はこんなものだろう」と流してしまうと、ここから症状が加速していきます。
拡大期（2〜5か月）：進捗報告の質が低下し窓口担当が交代する
2か月を過ぎると、進捗報告の中身が抽象化していきます。「設計を進めています」「実装中です」のような表現が増え、具体的な画面数や工数進捗が出てこなくなります。同時にベンダー側の窓口担当が交代するケースも増えます。「PMが変わりました」「担当エンジニアが体調不良で交代します」という連絡が来たら、ほぼ確実に内部が混乱しています。拡大期の特徴は、追加要員の投入や残業による「力技」での挽回が試みられていることです。一時的には進捗が回復したように見えますが、品質が大きく下がり、次の段階で破綻につながります。
破綻期（5か月以降）：画面が出ない・連絡が途絶える
5か月を過ぎても画面が出てこない、こちらから督促しないとベンダーから連絡が来ない、定例会議が「次回に持ち越し」を繰り返す——ここまで来ると破綻期です。この段階でベンダー側の社内では、撤退方針が議論されている可能性もあります。残念ながら、ここで止めても支払い済みの費用はほぼ戻ってきません。破綻期に入ってから動くのではなく、火種期のサインで動けるかどうかが、デスマーチを最小コストで終わらせる分かれ道です。
発注側がデスマーチを止める4つの判断軸
火種期で気付き、止める判断ができるかどうかは、発注側が持っている判断軸の数で決まります。経営者が押さえておくべき判断軸は4つです。
判断軸1：議事録の品質を毎週見る
最初の判断軸は議事録の品質です。会議の翌営業日中に届くか、決定事項・宿題事項・担当者・期日が明記されているか、前回の宿題が消し込まれているか——この3点を毎週確認してください。1つでも崩れた週が3回続いたら、火種期に入っていると判断してください。
判断軸2：要件再確認の頻度をカウントする
ベンダー側からの「要件をもう一度確認させてください」のメールが、月に何件届くかをカウントしてください。要件定義書が固まった後の月3件以上は、設計段階で混乱が起きている兆候です。再確認の項目が同じ機能に集中している場合は、その機能が設計上の難所になっている可能性が高いです。
判断軸3：窓口を二重化しておく
ベンダー側の窓口を1人に集中させると、その担当者が体調を崩したり退職したりした瞬間にプロジェクトが止まります。契約段階で「窓口は主担当と副担当の2名体制」を条件に入れておくと、火種期に副担当が状況を補足説明してくれる場合があります。窓口の単線化は、デスマーチを止められなくする最大の原因の1つです。
判断軸4：3か月単位での「続行・修正・撤退」レビュー
プロジェクト期間が6か月以上の案件では、3か月単位で「続行・修正・撤退」を判断するレビューを契約に組み込んでください。レビュー対象は「画面の動作確認」「残工数の合理性」「品質保証体制」の3項目です。レビューを契約に明文化していないと、「途中で止める権利」が事実上ない状態になります。発注前に契約条項を整理する場面で、診断する流れを使うと条項漏れを減らせます。
なおレビューを実効的なものにするには、レビュー時点で動作する画面が一定数あることを前提条件として契約に書き込むことが重要です。「3か月時点で5画面以上が動作確認可能」のような数値基準を入れておけば、ベンダー側も逆算してマイルストーンを設計します。数値基準が無い「進捗確認会」では、抽象的な議論で終わってしまい、撤退判断につながりません。
経営者目線で考える「デスマーチを許容してしまう組織の弱点」
ここからは経営の話です。デスマーチが発生する案件には、ベンダー側の問題以前に、発注側の組織にも弱点が潜んでいます。経営者が向き合うべき視点は3つです。
第一に、システム発注の意思決定が経営層と現場担当者の二段階構造になっている問題です。経営層は契約締結の段階で離れてしまい、現場担当者は「自分が選んだベンダーだから」と引っ込みがつかなくなります。第二に、社内に「システム発注の前任者」がいない問題です。前回の発注を経験した社員が退職していると、火種期のサインを誰も認識できません。第三に、デスマーチを止める意思決定そのものが「失敗報告」と受け取られる文化です。経営者が「止める決断こそ経営判断」というメッセージを出さない限り、現場は走り続けてしまいます。
この3つの弱点は、ベンダー選定の精度を上げても解消しません。発注プロセスそのものを設計し直す必要があります。デスマーチの再発を防ぐには、ベンダーの実績よりも、自社の発注プロセスを見直すほうが効果が高いケースが多くなります。具体的には、発注前の要件整理に外部の第三者を入れる、契約に「3か月レビューと撤退条項」を組み込む、社内に発注ノウハウを蓄積する文書を残す、この3つを並行で進めることで、次回の発注ではデスマーチに巻き込まれる確率を大きく下げられます。
加えて、経営層が「止める判断は経営判断」というメッセージを出し続けることも欠かせません。現場担当者が安心して撤退案を提案できる文化があるかどうかで、火種期での発見率は大きく変わります。「失敗報告を歓迎する組織」を作っておくことが、デスマーチに対する最大の予防策になります。
ぷらすわん実例：ある製造業A社の体験談から学ぶ巻き戻し
ぷらすわんが相談を受けたある製造業A社の事例をお伝えします。A社は受発注管理システムを別ベンダーに発注し、当初6か月・1,200万円の計画でした。着手から4か月経った時点で、画面はログイン1枚しか出ておらず、議事録は2週間遅れの状態でした。経営者からの相談時には既に支払い済みの費用が800万円に達していました。
この案件で取った巻き戻しの手順は3点セットです。第一に「機能を3割捨てる」。当初予定の45画面から、まずは20画面に絞り、残りはフェーズ2に回しました。第二に「期日を後ろにずらす」。残り2か月の予定を4か月に延長し、現実的なスケジュールに引き直しました。第三に「体制を入れ替える」。既存ベンダーは継続しつつ、ぷらすわん側で進捗管理と品質レビューを別契約で入れる構成に変えました。
結果として、追加コスト350万円で実用レベルまで持っていけました。完全な乗り換えだと別途1,000万円規模の追加が必要だった試算もあり、巻き戻しコストとしては許容範囲に収まったケースです。同じような状況の経営者は、まず現状を項目別に整理してから巻き戻しの選択肢を検討する流れをお勧めします。
まとめ
システム開発のデスマーチは、発注側からも止められない構造的な問題を抱えています。サンクコスト・「あと少し」の信頼・巻き戻し体力の不足という3つの心理が重なり、半年・1年と無駄なコストが積み上がります。止めるためには、議事録の品質・要件再確認の頻度・窓口の二重化・3か月単位のレビューという4つの判断軸を契約段階から持っておく必要があります。
巻き戻すときは「機能を3割捨てる・期日を後ろにずらす・体制を入れ替える」の3点セットで動かしてください。完全な乗り換えよりも、現契約を活かしながら範囲を絞る方法のほうが、トータルコストは抑えられる傾向があります。発注前にプロセスを見直したい経営者の方は、現状を比較を依頼する流れから入ると判断が早まります。