Unityだからできる「ベータ版の前倒し」

　しかし、どんなにがんばってプロジェクトマネジメントをやっていても、誤算や遅延は発生する。気分でものを言う発注者が仕様を変更して炎上するほか、実際の使いやすさの問題、機能上の問題、拡張性の問題。さらに、発注担当者の女性にマネージャーが恋をしてしまう、プログラマが突然来なくなるといった場合もあるという。

　こうした予期せぬ事態を収拾するための対策として山本氏は、制作期間の前半にゲームとしてある程度完成させておくこと、「ベータ版の前倒し」が非常に重要だと言う。制作技法が洗練され、扱う素材が多くなればなるほど、まずゲームとしての面白さや、何を訴求するのかという仕様定義の部分に時間をかけて、しっかりしたものを最初につくっておく必要があるからだ。

　このやり方は、レガシーなゲーム産業で仕事をしていた人からは「ナンセンスだ」と批判されることもあるが、山本氏は「最初にゲームを作っておくことの重要性は、Unityのような汎用的なツールが出てきてから、圧倒的に必要になってきたことのひとつ。せっかく新しいツールが出てきたのだから、工程のあとのほうに重要な作業を押し込もうとせずに、考え方をあらためたほうがいい」と指摘する。

　また、「機能分析を行って工期の前半のほうにRC版までもっていって、ベータでかなり遊べるようにしておくというのは、炎上を防ぐ一番いい方法のひとつだと我々は信じている。これができなくて止まってしまったプロジェクトはけっこうあるが、これをやったがためにダメだったプロジェクトは、我々は1件もない」と断言する。

便利さゆえの落とし穴

　Unityの利点はまだある。大規模なプロジェクトになると、「コーディング規約」をつくることになるが、このコーディング規約が少なくて済むのがUnityの良いところ。「Unityを使うことによってコーディング規約の分量は4割以下になると思っていい」と山本氏は言う。

　また、試作段階におけるゲーム性の検証も容易である。しかし、便利であるがゆえの落とし穴もある。「Unityだから安いんでしょ」「Unityだから早いんでしょ」「Unityだから試作つくるの簡単でしょ」と思われてしまう。しかし、Unityを使おうが使うまいが、面白いゲームをつくるのは大変なんだということに気付かない発注者も多いという。

　そのために起きるトラブルも多いことから、「Unityに頼る部分」と「運用で吸収する部分」を分ける必要がある。Unityの良さとは別に、大規模開発には大規模開発のノウハウがある。要求条件（要求仕様）と優先順位をしっかり最初に把握する。炎上しているコンポーネントを早期発見し、報告する。伝言ゲームを減らす、指揮系統を一本化するといったポイントを挙げた。