執筆者
R.T.
デスマーチ発生原因①
「デスマーチ」という言葉はIT業界で頻繁に使われますが、単なる"忙しい状態"を指しているわけではありません。
長時間労働、度重なる仕様変更、人員不足、精神的疲弊などが複合的に重なり、現場が正常な判断を失っていく危険な状態を意味します。
そして厄介なのは、
デスマーチは個人の努力不足ではなく、構造的な問題によって発生するケースが非常に多いという点です。
無理なスケジュール設定
これは、
デスマーチが発生する主な原因の一つでありなかなか改善できない（分かっていても適正にできない）ことが大きな問題となっていると思います。
例えば、
営業側が案件を取りたいあまり、現場の工数を十分確認せずに納期を確定してしまうケースは珍しくありません。
取りたい、取らなければならないの前には…という意思が働いてしまうと防ぐ・回避するが難しいことであります。
特にIT業界では、実際に作業を始めてみないと見えない問題も多く、最初の見積もりが甘いまま進行すると、後半で一気に破綻します。
本来3か月必要な作業を2か月で終わらせようとすれば、当然どこかで無理が発生します。
次に多いのが、「属人化」
特定のメンバーしか分からないシステムや手順が存在すると、その人に負荷が集中します。
さらに、
その担当者が休めなくなり、疲弊によってミスが増え、結果としてさらに工数が増えるという悪循環に陥ります。
特に中小企業や人員に余裕のない現場では、この問題が深刻化しやすい傾向があります。
デスマーチ発生原因②・回避策
「仕様変更の多さ」も大きな原因
開発途中で「あれも追加したい」「やっぱりこの仕様を変えたい」という要望が繰り返されると、スケジュールは簡単に崩壊します。
本来であれば追加費用や納期調整が必要ですが、日本企業では“とりあえず頑張る文化”が根強く、現場が吸収する前提で話が進んでしまうことも少なくありません。
そこにクライアント様に喜んでいただきたい、ご要望に応えたいという想いも確かにあるのですが…
人を増やせば解決する
この発想と行動が更に危険な問題を発生させていることもまた事実です。
炎上した案件に途中から大量の人員を投入しても、新しく入った人への説明コストが発生するため、むしろ現場が混乱する場合があります。
これはソフトウェア開発の世界で有名な「ブルックスの法則」として知られており、遅れているプロジェクトに人を追加すると、さらに遅れることがあると言われています。
加えて、
デスマーチ状態が長引くと、単純に残業が増えるだけでなく、離職率の上昇や品質低下にも直結します。
疲弊した状態では集中力が落ちるため、バグや設定ミスが増え、その修正対応でさらに工数が膨らむという負の連鎖が起きやすくなります。
どうすればデスマーチを回避できるのでしょうか。
まず重要なのは、何といっても「余裕を前提にしたスケジュール設計」の徹底ですね。
トラブルや仕様変更が一切起きない前提で計画を立てると、高確率で破綻します。
ある程度のバッファを確保し、“予定通りにいかないこと”を前提にする必要があります。
次に、
「情報共有の徹底」も重要です。
ドキュメント整備やレビュー文化を定着させ、特定の人しか分からない状態を減らすことで、属人化リスクを下げられます。
引き継ぎしやすい環境は、結果的にチーム全体の安定につながります。
加えて、
「仕様変更にルールを設ける」ことも効果的です。
変更自体を禁止するのではなく、変更時には納期やコストへの影響を明確化し、現場だけに負担を押し付けない仕組みが必要です。
もしあなたが現場の一員として働くなら、「無理が常態化している会社かどうか」を見極める視点も大切です。
慢性的な残業、頻繁な炎上、担当者頼みの運用が当たり前になっている企業は、構造的な問題を抱えている可能性があります。
短期的な根性論だけでは、デスマーチは解決できません。だからこそ、個人の頑張りではなく、“仕組み”を改善する視点が重要なのです。
