失敗するゲーム、開発時の兆候、その対策
1｜まずはじめに
本記事は事実を元にした記事です。具体的な詳細は明らかにしませんが、過去100タイトル以上のリリースに関わった経験、開発現場で体験したことを元に書いています（スーパーブラック企業ゆえに本数はすごい）。
ただ本記事は私が経験した事例であり、すべての開発ケースがこれに当てはまるのか？というとそうではないことをご了承ください。もしもこの記事を参考にして、失敗を回避できる確率が高まるのならば、それにこしたことはありません。
失敗する確率をなるべく減らす為の一助になれば幸いです。
2｜対象となる機種
家庭用ゲームソフト、PCダウンロードソフト、オンラインPC、ガラケー向けアプリ、スマートフォン向けアプリとなります。
3｜参考の組織体
組織人数は10～100名規模を参考にしており、QA（品質管理）やCS（カスタマーチーム）、バックオフィス等は含まない人数とします。
4｜失敗の定義
この記事内での「失敗の定義」ですが、開発規模は2000万円以上のプロジェクトで、結果として【大きな赤字を残してしまったもの】とします。
具体的にお話をすると、法人開発がメインであり、リリースにこぎつけない（未完成）状態。リリースしても成果を出せずに１年以内にサービス終了した運営タイトル。販売しても1000本以下などで終わるゲームといった感じです。逆を言うと、仮に売り上げ100本でも黒字になっていれば成功としています。
5｜一番の失敗原因はどこか？
開発とはとても繊細であり何が失敗なのかを具体的に表現することは難しいと思います、とはいえ、一番しくじってしまうケースの共通項、ここを失敗していると立て直すことが極めて難しかった例を１つだけ選べ！と言われたら、間違いなくこう伝えます。
プロトタイプ制作時、ゲームのコアサイクルが作り切れないこと
少し言い換えると、
プロトタイプ制作後までに、本作の根幹となる主要なゲームサイクルが作り切れなかったこと
だと振り返っても言えます。
６｜あの成功作も同じ轍を踏んだ？
上記の記事でも書いていたけど、ゲームサイクルが序盤からできていないままに進めてしまい、後で大変になった様相が書いている。ゲームだから最初のコアとなる部分のゲームサイクルができていないと当然ながら腑に落ちない状態が永遠に続く
結論としては、コアとなるゲームメカニクスやルールがあやふやなままに制作が進んでしまうことによって、完成に近づけば近づくほどに理想と完成品質のギャップが生まれてしまう。
想定外のものが出来上がってしまう。そもそもいつまで経っても完成に近づかないという逆の手ごたえの方が大きくなっていき、赤字が膨れ上がって身動きできないという状況が起こってしまいます。
プロトタイプ版のレビューを適切にできないままに、本開発へ進んだ場合、開発が進みにつれていろいろな点で開発内部で亀裂が生じ、結果的にリリースできたとしてもリカバリーや立て直しができずに失策する例が圧倒的に多かったと、自ら体験したことからも多かったなと思います。
７｜ゲームのコアサイクルとは何か？
この記事内では、ゲームのコアサイクルとは、「繰り返しプレイするための構成を成している、最も重要なメカニクスとゲームルール」を指します。
ちょっと例題を出して紐解いてみます。
2Dタイプの横スクロール型の敵を倒すアクションゲームの場合における、
コアサイクル（メカニクスとゲームルール）の例を書いてみます。
＜メカニクス例＞
キャラクターの行動
プレイヤーが操作するキャラクターが攻撃や防御などの動作を行うことができる敵の行動
敵がプレイヤーに対して攻撃を行うダメージシステム
キャラクターや敵が受けるダメージを計算する仕組みHP
キャラクターや敵が持つ体力値アイテム
キャラクターが使用できるアイテムスコアやレベルシステム
ゲームをクリアするために必要なスコアやレベル管理
＜ゲームルール例＞
ゲームの進行
ステージをクリアして次のステージに進むことができる。ゲームオーバー
HPがなくなった場合ゲームが終了する。クリア条件
最終ステージでボスを倒すことでゲームクリア。
などです。上の項目だけでも一部ですし、キャラクターの行動と敵の行動、アイテムについてはもっと深堀する必要がありますが、上ではざっくりと書いています。（しかも上にはステージ構成、障害物なども書いていない）
この2つが組みあわせり、最低限のゲームのコアサイクルを作っていきます。そこにSEやエフェクト、アニメーション、敵の行動ロジックや攻撃パターンなどを追加していき、「気持ちよさ」「成長実感」などがより感じやすくなる、ゲーム製品版に向けたゲームサイクルに仕上げていくイメージです。
つまりはプロトタイプの時点、雪だるまを創るための「核」の基盤を固める点がこの工程にあたり、周辺から進めれば進めるほどに手直しの手間、やりづらさが大きくなることは想像しやすいかと思います。
８｜まとめ
大失敗する多くの例は、プロトタイプ版、または初期段階で、ゲームのコアサイクルが確定しないままに制作を進行するケースが圧倒的に多い。
なので、コアサイクルが確定するまでは、周辺情報や大規模開発に手を出す前に、全力で見直しをする、またはチーム内でここまでは確定しようよと促すやり方がいいのではないか？と思えます。
９｜防ぐ方法はあるのか？
ここからはいくつか大失敗を防ぐため、特に序盤の失敗を防ぐためにできることを書いてみます。ちなみに、コアサイクルができたと言えども、失敗するケースもあるんです。
ゲーム企画として最良かを検証する
世の中にはゲームに適しない題材があります。それを無理してゲーム化すると高確率で失敗します。少なくとも着手する前にはチーム全体でどういうゲームなのか？を明文化しどこがウリなのか、完成像はどうなのかをコアメンバーには共有しておく必要があります。技術的に実現可能な範囲かを検証する
ある程度紙面上や製作前に、どういう技術を用いるのか、それを具体的に再現できそうなのか？を予測と、そのリカバリー案を検討しておくことが必要です。ゲームでやる価値があるのかを検証する
たまにデジタルゲームにする理由がないものをゲームしようとすることがあります。その場合もかなり失敗確率が上がります。できても売れないです。アート部門が実現可能な範囲かを検証する
技術的な部分に共通するところはありますが、アート部門でも再現できるものなのかを事前に検討しておく必要があります。ゲームデザインが実現可能かを検証する
たまに、全く新しいものを生み出そうとするプロジェクトがありますが、この場合はプロトタイプの完成までにものすごく時間がかかることを想定しておいた方がいいです。少なくともやりたいこと、再現したいことがある程度できそうだなという確信をもった状態で、着手できることが望ましいです。
作りながら考えていくという場合も悪くはありませんが、この場合はものすごいスピード感とチームの一体感が必要です。プロジェクト進行がスムーズにいくかを検証する
たまに大物がこぞって参加するプロジェクトがあります。この場合、同館が手も確認やだれかのエゴが入りまくって遅延しまくるケースがあります。日本の場合は開発費は固定費が多いので、進まなければキャッシュアウトが爆発的に増えます。プロジェクト進行が決定的に遅い場合は、それだけでリスク要因になります。大金がない限りはあまりオススメしない案件です。決裁者、責任者のやる気があるか
もはや説明不要。言わずもがなです。上記項目をキャッシュがある範囲内で実現できるのかを検証する
この部分を度外視するクリエイターってめちゃくちゃ多い。お金がなくなればプロジェクトは閉鎖ですから、本当に気を配りたい。
P.S1｜企画が良くなかったから失敗した？
上で紹介した9.1、9.2のケース以外において、「企画書がいけてない状態で開発したから失敗した」というケースは実はあまりみてないです。
なぜなら、企画書がなくても開発は進むことがありますし、企画書がなくても特定の人のアイディアがゲームとして再現され、それがおもしろくなる場合があるからです。（企画書は後付けで必要な時にしょうがなく作るケース、なんてこともあるぐらいなんで）
だから、プロトタイプの時点である程度「これいけそうじゃん！」っていう確信が持てないアイディアは、むしろいきなり風呂敷広げて進めない方がいいぐらいです。
時間をかけてでもやり切るか、あえてそのアイディアは一旦捨てて、違うものを考え直すぐらいが理想的です。
小さいプロジェクトでコストも小さい場合であれば、さくさくっととりあえず完成まで作り切ることもありです。ただ、法人クラスで数十人などが関わってしまう場合は、まずはプロトタイプで確信が持てるまで妥協しないことはめちゃくちゃ大事です。
なぜならば、プロトタイプが良くできたからといってもうまくいく可能性はないので、であればプロトタイプを仕上げるというのは今後の作品運命を大きく揺さぶり、失敗要素を少しでもこの時点で排除できるのでやっておきたいところです。
P.S2｜作り出すと引き返せない心理に負けてはいけない
さて、人間、失敗を恐れますが、ゲーム開発とは完成しない限りは「失敗」と認めたがらない傾向も強くあります。
ゲームデザインが固まらないのに開発が進むケース、この場合、開発を進めれば進めるほどに、本来のゲーム性とは不必要な要素が積み重なってしまいます。お家で例えると基礎（土台）が固まっていないままに、ビルを作っていってしまうようなものです。
しかし、ストップとか、撤退だ！とは言えないところまで来てしまうと、誰もが「なんか傾いてる」と気づきながらも創り進めてしまいます。
この時苦しんでいるのは実はディレクターだったりプロデューサーだったりもしています。
で、あるときにちゃぶ台返しが起こります。そう決裁者へのプレゼンです。だから必要な第三者レビューは定期的に、かつ早期にやることが重要です。
なぜなら、プロジェクトリーダーはある程度ごまかせる力と権限を持っているからです。良くないものは良くないんだなと受け入れられる度量は年を重ねるほどにハードルが高くはなりますが、常に謙虚であれることは成長に繋がります。謙虚さを失えば人は成長をしないと誰かが言ってました。
この引き返せないジレンマについては、定期的に密なコミュニケーションを行うと同時に、定期的に第三者のチェックを行う仕組みを事前に決めておくといいかと思います。それでも防げないことはありますが、事前に決めることで、ルールだからと押し通しやすくもなります。
P.S3|つまらない要素をごまかすために不要な開発をしてしまう罠
嘘を隠す為に嘘をつき続けなくなることと同じように、ゲーム開発でも、おもしろくない要素を活かす為に、無理やりおもしろくするための不要な開発をしてしまいます。
開発は一度進んでしまうと、組織体は「既にたくさん作ってしまったものを、今更壊そうとは思わない、思えない」という心理に陥ってしまいます。
ここで、うーん、やっぱやりなおしじゃー！って英断ができるリーダーや組織体であればいいわけですが、多くは良くない要素を直そうと、失敗した要素を上手く活かそうとする工夫をしようとするわけです。
別にこのアプローチは悪い話ではありません。
ただ、中には、「面白くない産物」を過剰に面白くしようとするために超絶無駄な開発コストを支払おうという人も出てくるわけです。
この対応で上手くいけばいいですが、この時は根っこのコア要素が既につまらない場合が多いんです。あとは不要だったりする。
なので、見直すべきは根幹の部分であり、上塗りではないということに早く気づけることが大切です。仮に修正をする場合でも、最低限のゲームサイクルが体験できるモックをその場でも創り、すぐに検証と効果を測る必要があります。
一番最悪なケースは、基本のゲームサイクルが出来上がっていないにも関わらず、周辺情報（キャラクターやシナリオ、BGM）等をどんどん制作していくケース。でも肝心のゲームサイクルがない。だから永遠に完成できない。
そういう事例もめちゃくちゃあります。
この場合においても第三者のレビューを入れて、正直な感想を透明性ある環境（誰かのバイアスを入れない、検閲しない形）で出してもらった方がいいです。
それ以外ではどうするのか・・・？
という記事を続けて書きたいのですが、PSが長くなりすぎたので次回に回します。
気になる箇所、コメントがあればぜひお願いします。
株式会社スタジオデルタ
ゲームプロデューサー兼マーケター うきょう
ゲーム作ったりマーケしたりしています。
▼ゲーム開発の全体像などの資料が無料DLできます
https://www.studiodelta.co.jp/gamepr/
▼お問い合わせはコチラまで
info@studiodelta.co.jp
いただいたサポート費は還元できるように使わせていただきます！ 引き続き読んでいただけるような記事を書いていきたいと思います。