ノウハウ 2026.06.23

ゲーム開発のデスマーチはなぜ起きる？見積もり術を解説

ゲーム業界で長く働いていると、一度は「デスマーチ」という言葉を耳にするはずです。リリース直前の数週間、あるいは数カ月にわたって深夜残業や休日出勤が続き、スタッフが疲弊しきった状態でプロジェクトを完走する。そんな状況は決して珍しくありません。しかし、デスマーチは「やる気があれば乗り越えられるもの」でも、「ゲーム開発の宿命」でもありません。その根本には、構造的な問題と意思決定の積み重ねがあります。本記事では、デスマーチが発生するメカニズムを分解し、現場で使えるスケジュール管理の考え方、そしてクリエイターとして「ノー」と伝えるためのスキルについて解説します。

ゲーム開発でデスマーチが起きる理由

デスマーチが起きる背景には、単なる人手不足や予算不足以上の構造的な問題があります。よく見られる原因を3つに整理します。

仕様変更が連鎖する構造

ゲーム開発の現場では、企画段階から完成まで仕様が何度も変わることが珍しくありません。「もっと爽快感を出したい」「このシステムはやっぱり削ろう」といった判断が途中で生まれるのは、インタラクティブなメディアであるゲームの特性上ある程度避けられない部分もあります。

問題は、その変更が「軽微な修正」として扱われ、工数の再計算が行われないまま進んでしまうケースです。1つひとつの変更は小さくても、それが10回、20回と積み重なると、当初の設計とはまったく異なる作業量になっていることがあります。「ちょっと直すだけ」の積み重ねが、気づけばスケジュールを数週間単位で圧迫しているのです。

また、仕様変更が連鎖すると、先に完成していた部分の手戻りが発生します。グラフィックが確定してからUIを変えたり、バランス調整が終わったあとにシステムを追加したりすると、影響範囲が広がりデスマーチの入り口になります。

工数見積もりが甘くなる背景

「このタスク、どのくらいかかる？」という問いに対して、開発者が実態より短い数字を答えてしまうことがあります。これは怠慢ではなく、いくつかの心理的・構造的な要因から起きています。

ひとつは「楽観バイアス」です。人は物事を計画する際、うまくいく前提で考えがちです。バグが出ない、外部ツールが正常に動く、チームメンバーが予定通り稼働できるという前提で見積もると、必ず現実とズレが生まれます。

もうひとつは、「短く言わなければならない」というプレッシャーです。上司やプロデューサーが期待する回答が見えているとき、開発者は無意識に「言いやすい数字」を選びがちです。「3日ではなく1週間かかります」と伝えることへの心理的な抵抗が、見積もりを圧縮させます。

さらに、テストや調整、ドキュメント整備といった「目に見えにくい作業」が見積もりに含まれないことも多くあります。実装は終わっても、品質担保のための作業が残っているという状況は珍しくありません。

現場と経営の認識ズレ

デスマーチが起きるもうひとつの大きな原因は、開発現場と経営・プロデューサー層の間にある情報の非対称性です。

経営側は「あとどのくらいで終わるか」を把握したいのですが、現場の進捗は数字だけでは伝わりにくい。タスクが「80%完了」でも、残り20%に最も複雑な処理が詰まっていることがあります。逆に、「50%完了」でも後半は軽作業だけというケースもある。

進捗の「見え方」だけで判断が行われると、経営側は「あとひと押し」と感じて工数追加を躊躇し、現場は「伝えても分かってもらえない」と諦めてしまいます。このすれ違いが長引くと、現場だけが無理を背負う構造が固定化されます。

スケジュール崩壊を防ぐ見積もり術

デスマーチを防ぐためには、見積もりの精度を上げることが重要です。ただし「正確に見積もる」ことは現実的に難しいため、「ズレを織り込む」という発想が求められます。

バッファ設計の重要性

プロジェクト全体のスケジュールに、最初からバッファ（余裕）を設けておくことは基本中の基本です。しかし実際には、「ギリギリのスケジュールでいこう」という判断が下されることが多く、バッファが削られていきます。

バッファの設計には、タスク単位で設けるものとプロジェクト全体に設けるものの2種類があります。タスクレベルでは「この実装は3日と言うが、5日で計上する」という形で個別に積み上げる方法があります。一方、プロジェクト全体では最終リリース日の前に2〜4週間のバッファ期間を設けることが一般的です。

大切なのは、「バッファは余裕ではなくリスク対処のための枠」として、チーム全体で認識をそろえることです。バッファがあっても「余ったから機能を追加しよう」という動きになると意味を失います。

リスクを前提にした工数管理

見積もりを立てる際、「うまくいった場合」だけを想定するのではなく、「何が失敗しうるか」をあらかじめリストアップしておく方法があります。

たとえば「外部ライブラリの仕様変更」「新メンバーのオンボーディングコスト」「プラットフォーム審査での差し戻し」といったリスクを洗い出し、それぞれが発生した場合に何日の追加工数が必要かを事前に試算しておきます。このリスク一覧をプロジェクト開始時にステークホルダーと共有しておくことで、問題が起きたときに「想定外」ではなく「想定内」として処理しやすくなります。

リスクを前提にしたスケジューリングは、悲観的なものではなく、プロジェクトを現実的に前進させるための技術です。

優先順位整理の考え方

スケジュールが厳しくなってきたとき、「全部やろうとする」ことがデスマーチを深刻化させます。機能や要件を優先度で整理し、「必須」「あれば望ましい」「次回以降でもよい」の3段階に分けておくことが有効です。

この整理をリリース直前にではなく、プロジェクトの早い段階からやっておくことが重要です。後になるほど、どの機能も「重要に見えてくる」という心理が働くためです。優先順位が明確なら、スケジュールが圧迫されたときに「何を削るか」ではなく「何を残すか」で話し合えます。この視点の違いは、チームの合意形成に大きく影響します。

「働く場所」の選択肢を広げる。ゲーム・IT業界の多彩な求人を公開中

「ノーと言える」クリエイターが必要な理由

スケジュール管理やバッファ設計が整っていても、現場のクリエイターが無理な依頼を断れなければ意味がありません。「ノーと言える力」は、単なる自己主張ではなく、プロジェクトを守るスキルです。

無理な依頼を断る技術

「ノーと言う」というと反抗的に聞こえるかもしれませんが、適切な断り方は「できません」の一言ではありません。「この期日では対応が難しいですが、〇〇を削ればスケジュール内に収められます」という代替案の提示が基本です。

無理な依頼を受け続けると、クオリティが落ち、バグが増え、最終的にはプロジェクト全体が傷つきます。断ることは「楽をしたい」からではなく、「プロジェクトを正しく届けたい」という責任感からくるものだと伝えることが重要です。

また、「今の状況では対応できないことを早めに伝える」ことが、信頼を維持するうえで欠かせません。直前になって「やっぱり無理でした」と報告することのほうが、関係者への影響は大きくなります。

ロジカルに説明する力

感情ではなく、データと根拠で状況を説明できることが「ノーと言える」クリエイターの強みです。「大変です」「きついです」という言葉は印象を伝えますが、「現在の残タスクは〇時間で、残り稼働日は〇日です。このまま進むと〇件の未対応が発生します」という説明は意思決定を促します。

日ごろから自分のタスクを数値で把握しておく習慣が、いざというときの交渉力になります。タスク管理ツールを活用して稼働状況を可視化しておくと、説明のしやすさが格段に上がります。

「感覚で訴える」から「論理で伝える」への転換は、クリエイターとしての成長にもつながるスキルです。

信頼を失わないコミュニケーション

断り方ひとつで、相手との関係性は大きく変わります。断る際に意識したいのは「相手の立場を理解している」というメッセージを同時に伝えることです。

「おっしゃりたいことはわかります。ただ、現状では品質を担保したままでの対応が難しく、リリース後の評価に影響する可能性があります」というように、相手のゴールと自分の判断をつなげて話すことで、対立ではなく協力の姿勢を示せます。

断ることが続いても、このコミュニケーションを積み重ねることで「この人に相談すると正直に言ってもらえる」という信頼が生まれます。それが、長期的なキャリアにおける最大の資産になります。

健全な開発体制を作るために

デスマーチを防ぐには、個人の努力だけでは限界があります。組織とチームの仕組み全体を変えていく視点が必要です。

マネジメント側に必要な視点

プロジェクトマネージャーやプロデューサーが持つべき最も重要な視点は、「現場の声を正しく解釈する力」です。「遅れています」という報告を受けたとき、その背景にある要因を理解せずにプレッシャーをかけるだけでは状況は悪化します。

マネジメント側が「何が詰まっているか」「どこに支援が必要か」を問える環境をつくることが、チームの健全性を保ちます。また、スケジュールが崩れたときに「誰のせいか」を問うのではなく、「何を変えるか」を問う文化を持つことが重要です。

チーム全体で共有すべきルール

デスマーチを防ぐには、個人の裁量だけでなく、チームで合意したルールが必要です。「仕様変更は〇日前までに」「追加要件は必ず工数再計算を行う」「週次で進捗と懸念点を共有する」といったルールを明文化しておくことで、問題が可視化しやすくなります。

こうしたルールは、プロジェクト開始時のキックオフで合意しておくのが理想です。途中からルールを変えようとすると、余計な摩擦が生まれることがあります。

長期的に成果を出す組織文化

デスマーチを繰り返す組織には、「きつくても最後は何とかなる」という前例が積み重なっていることが多いです。問題は、それが「成功体験」として誤って記憶されてしまうことです。

長期的に良いものを作り続ける組織をつくるためには、「無理をしなかったプロジェクト」を評価する文化が必要です。計画通りに終わったプロジェクトは地味に見えますが、それこそが再現性のある開発力の証明です。

スタッフのコンディションを維持し、学びを次のプロジェクトに活かせる体制こそが、最終的なプロダクトのクオリティにつながります。

スケジュール危機を未然に防ぐ「本質を見抜く力」

デスマーチという最大のリスクを回避し、現場の状況を経営陣やマネジメント層にロジカルに説明するためには、目の前のトラブルの「根本原因」を正しく特定するスキルが欠かせません。以下の記事では、ゲーム開発の複雑な問題を分解し、チームを巻き込んでロジカルに解決へ導くための具体的な思考フレームワークを詳しく解説しています。

あわせて読みたい：ゲーム開発プロジェクトの「課題解決力」を高める思考法