ゲーム開発における「見積もり」の難しさと、現場で効いていた一つの工夫
Photo by Mario Scheibl on Unsplash
目次
- ゲーム開発の見積もりが年々難しくなっている
- あえて「削る前提の仕様」を見積もりに入れる
- 仕様変更を「横にずらす」ための仕込み
- 「そんなに必要ですか?」と聞かれる前提で説明する
- それでも、計画通りにはいかない
- おわりに
ゲーム開発の見積もりが年々難しくなっている
ゲーム開発の見積もりは、ここ数年でさらに難易度が上がったと感じています。技術的に複雑になった、という話だけではありません。開発の途中で、市場環境や競合タイトルの動きを踏まえて仕様が変わることが、もはや特別な出来事ではなくなりました。
実際の現場では、
- リリース時期が前後する
- 競合の成功・失敗を見て方向性を微調整する
- 運営を見据えて仕様を入れ替える
といった判断が、開発中に何度も入ります。
こうした状況で「仕様変更分の工数バッファを、最初から精度高く積む」
というのは、正直かなり難しいです。私自身もいろいろ試しましたが、数字として綺麗に積めた試しはほとんどありません。
あえて「削る前提の仕様」を見積もりに入れる
その中で、現実的に機能していたと感じているのが、少し回りくどい見積もりの仕方です。
それは、初期見積もりの段階で、意図的にオミット候補の仕様を盛り込んでおくという方法です。
たとえば、
- 最終的に最低限 n体 のプレイアブルキャラクターが必要な場合
→ 見積もりでは (n+4)体 として計上する - 雑魚敵のバリエーションやエフェクト量を、少し多めに見積もる
といった具合です。
ここで重要なのは、「削ってもゲーム体験を致命的に損なわない要素」を選ぶことです。
エフェクト、雑魚敵、バリエーション要素などは、比較的スケールしやすく、調整弁として使いやすいです。逆に、コア体験に直結する部分をこの枠に入れると、あとで身動きが取れなくなります。
仕様変更を「横にずらす」ための仕込み
このやり方の一番のメリットは、開発途中で大きな仕様変更が入ったときにあります。
たとえば、
「新たに××の対応が必要になりました。
その代わり、優先度の低い●●を削る形で調整できます」
という話ができるようになります。
予算や期間そのものを動かす調整は、プロデューサーやディレクターにとっても負担が大きく、ステークホルダーとの合意形成も一気に難しくなります。
一方で、同じ枠の中でスコープを入れ替える話であれば、意思決定は比較的スムーズです。
結果として、
- 調整の説明コストが下がる
- 開発ラインを止めにくくなる
- 現場の混乱を最小限に抑えられる
といった効果がありました。
「そんなに必要ですか?」と聞かれる前提で説明する
この手法を取ると、特に開発経験のあるステークホルダーから、
「キャラクター数、そんなに必要ですか?」
「このエフェクト、本当に全部要りますか?」
と突っ込まれることがあります。
ここは、正直に言えば一番説明に苦労するところです。
ただ、この段階で丁寧に説明し、「なぜこの構成にしているのか」を共有しておくと、後々の進めやすさが大きく変わります。あとから削る前提であること、調整余地として持っていることを理解してもらえると、仕様変更時の話が驚くほど早くなります。
それでも、計画通りにはいかない
もちろん、このやり方を使っても、開発が計画通りに進むわけではありません。開発ラインは毎週変わる「生もの」ですし、人員や優先度の都合で、思ったように削れないこともあります。
それでも、あらかじめ余白を構造として組み込んでおくことで、
現場の心理的な負担は確実に軽くなります。
最終的に私がしっくりきているのは、
予算や期間はなるべく動かさず、スコープの組み替えで前に進む
という考え方です。
完璧な見積もりを目指すより、壊れにくい計画を作る。
ゲーム開発では、その方が現実的だと感じています。
おわりに
X(旧Twitter)を中心に日々発信しております。
ご興味をお持ちいただけましたら、ぜひ弊社Webサイトや私のXもご覧いただけますと幸甚でございます。
https://www.tatsu-mi-systemsolution.jp/
https://bsky.app/profile/itchie-tatsumi.bsky.social
https://x.com/itchie_tatsumi