ゲーム開発・制作現場で勝ち続ける組織と人材

前提として、ゲームの面白さというのは、仕様書なり企画書なりに記述しきれないと考えます。例えば、スーパーマリオブラザーズのマリオのジャンプは、なぜ気持ちが良いのか？これは仕様書に無かったのではないのでしょうか（そもそも表現できないはず）。

では、どういうことが起こるかというと、自分たちでまずゲームを作ってみて、それをアウトプットした時点では十中八九がクソゲーということになります。とにかく、ゲームを作るとクソゲーができるんです。もちろん、仕事としてゲーム開発をしているので、クソゲーばかりでは困るのです。では、クソゲーではないゲームをどのように作るかというと、、物を変えていけるようにしています。プロダクトがリリースされる前であれば、そのプロダクトオーナーの意向によっていろいろ変えて行く、もしくはユーザーテストとかをやって変えて行くというふうになります。リリース以降であれば、直接的にユーザーの声を入れて行く、話題となっているものを見て変えていくということになります。そのときにゲーム開発当初の前提にこだわってしまうと、変えて行くことが困難となり、クソゲーで終わってしまいます。つまり、これはユーザーから学ばない、環境の変化に適応できないという状況ということです。

そのような状況・環境にならないように、チームが変化に対し、自分たちのプロダクトも含めてどんどん変化していく必要があります。その時に、自分はc++の人とか、自分はプログラマーとか固執するのではなく、例えば、グラフィックッカーのことを考える、モデル作っている人はこういうふうに考えるというようなことを理解し、自分のエンジニアリングの軸は1本あって、ほかのところ何となく分かりますといったようなスキルセットが求められているんだと思います。

クソゲー生産＝開発リスクを軽減するために、フィードバックを経てちゃんと適用して次の状態に行く、いかにサイクルを早くするか、いかに最初にちゃんと動くようになるまでのステップを短くするかといったリソース配分も大事です。とにかく１日に何回もリリースして、ユーザーの反応を見てどんどん変えるといったことをしていくので、それに付いて行けるエンジニア・サービスディレクターというのは、本当にそのことが好きじゃないとできないという面もあります。