ディレクション辞書

目次 ／ 制作・開発ディレクション ／ プロジェクトマネジメント

デスマーチの構造（失敗事例）

項目番号 153 ／ 最終更新 2026-09-20

10秒でわかる！要点まとめ

1. 概要

デスマーチとは、無理な条件のまま走り出したプロジェクトが、長時間労働と手戻りを繰り返しながら終わらなくなる状態を指します。

ここでは、実際に起きたモバイルCMS開発の失敗事例を取り上げます。

「要件はほとんどできてるから、納品を経験してください。」という一言で参加したプロジェクトは、3ヶ月後には月350時間超の労働、シャワーを浴びに帰るだけの自宅、深夜3時の呼び出しという状態になっていました。

プロジェクトの条件
項目 実態
依頼内容 「モバイルCMSをアジャイルで、FeliCaポイント機能つきで、アプリ版管理画面も」
予算・期間 500万円・3ヶ月（固定）
ドキュメント 「不要」と言われる
クライアント側 好きに要求を出す担当が5名以上。複数の部署から別々に要求が届く
元請け 会議にもメールにも一切出てこない
自社の体制 エンジニア中心のチームで、ディレクターは1名。折衝・進捗管理・ドキュメント・デバッグ・予算管理・見積もりになかったマニュアル作成まで、担当の決まっていないタスクはすべてディレクターに集まった

2. なぜ重要なのか

デスマーチは、振り返ると予測できる失敗です。 この事例で起きた出来事は、どれも着手前の設計ミスに対応しています。

起きたこと 根にある設計ミス
「検収不可.pdf」が届く 検収基準が最初から合意されていなかった。 完成の定義がないまま走っていた
現場の不満を書いたメールが、宛先違いでクライアントに届く 疲れたチームで情報管理が崩れ、社内向けと社外向けの境目がなくなった
深夜3時に元請けの検証現場へ何度も呼び出される 断れる関係ができていなかった。 断らないことが当たり前になっていた
2度目の納品直前に、テストデータがすべて消える 環境の分離が不十分なまま、本番に近い作業が進んでいた
完成したCMSは使われずにお蔵入り ビジネスの目的が合意されないまま、開発だけが最後まで進んだ

現場は「インターンのエンジニアが他案件の指示も受けながら手を動かし、隣では元請けが10分おきに進捗を確認する。ディレクターはその間に挟まる」という状態でした。

個人がどれだけ頑張っても、この構造の中では取り返せません。だからこそ、構造を着手前に見抜けるかどうかがディレクターの仕事になります。

3. 実務のポイント

事例から引き出せる教訓は10個あります。

着手前に決めること
  1. 「完成の定義」を文書にする。 検収条件が合意されていないプロジェクトに「完了」は来ません。契約前に検収基準を書面で固めます
  2. 要件の窓口を1つにまとめる。 課長・役員・メンバーがそれぞれ別の要件を言う構造は、必ず矛盾を生みます。クライアント側の窓口を1名にすることを、条件として交渉します
  3. 「ドキュメント不要」は受け入れない。 ドキュメントを省くと、ディレクターの記憶が仕様書の代わりになります。記憶で走るプロジェクトは崩れます
  4. ビジネスの目的を確認する。 「これが完成したら、誰が何を得るのか」を関係者が言えないプロジェクトは、お蔵入りの危険が高くなります
体制とルールで守ること
  1. アジャイルとスコープ固定を同時に受けない。 「アジャイルで」と言いながら予算と期日が固定されているなら、それはアジャイルではありません
  2. 断れない関係を作らない。 深夜の呼び出しに応じ続けると、それが標準になります。最初の1回に応じた時点でルールが決まると考えます
  3. ディレクター1人に全責任を集めない。 折衝・進捗管理・デバッグ・予算管理を1人で同時に担う体制は、それ自体が設計ミスです
  4. インフラにかけるお金を削らない。 データ消失は、弱いインフラの当然の結果でした。環境の分離とバックアップは最初に確保します
走りながら見ること
  1. 「もうすぐ終わる」を信じない。 「ほとんどできてる」は進捗ではありません。残っている課題を数で確認してから、続けるかを判断します
  2. やめる条件を最初から持っておく。 デスマーチは、止める判断が遅れるほど被害が広がります。撤退・縮小を選択肢として最初から置いておきます

4. スキルアップのヒント

関連