小規模チームだからこそ大変なことは沢山あるんです
2016年3月14日～18日（現地時間）、アメリカ・サンフランシスコ モスコーニセンターにて、ゲームクリエイターの技術交流を目的とした世界最大規模のセッション、GDC（ゲーム・デベロッパーズ・カンファレンス）2016が開催。２日目の15日、『宇宙戦士ガラクZ』（英題：Galak-Z: The Dimensional）のセッションが行われた。
今回のスピーカーの採択について、ホスト曰く「Galak-z のこのセッションは、AAAでさまざまな問題を経験済みだったRajさんがなぜ再び同じ問題を繰り返してしまったのかについて話してくれるというのが面白いと思い、採択となりました」とのこと。
セッションのスピーカーを務めるRaj氏のキャリアは、『Tonyhawk's Pro Skater』のテスターとしてキャリアを始め、『Vigilante 8』、そして映画『South Park』に参加。そこでインタラクティブなメディアに興味があることを自覚し『メダル オブ オナー 』シリーズの開発に参加している。
『Lord of the Rings The battle for Middle Earth II 』(17 BitのJake氏とはここで出会った)、『Command & Conquer』でRTSや大規模チームプロジェクトのプロデューサー経験を積み、Double Helix GamesやCapcomでプロトタイプ作成に従事したもののプロジェクトが立て続けにキャンセルになったそうだ。
その後はバーを開いたりとゲーム業界から遠のいていたが、E3で17 BitのJake氏に再開。『宇宙戦士ガラクZ』のアイデアに興味を持ち、シアトルで再びゲーム開発に携わることになったそうだ。
17-BITのスペースシューティングゲーム『宇宙戦士ガラクZ』（英題：Galak-Z: The Dimensional）はPC版が現在配信中。海外ではすでにプレイステーション4向けに販売されており、日本での配信も予定されている。本作は、小規模スタジオにとってはとても野心的なプロジェクトだったそうで、ロシージャルなレベル構築システム、プロシーキャルミュージックや、ロボの変形システムなど、ほとんどのシステムは一から作られている。発売後はさまざまな賞を受賞し、Metacriticのスコアは82点と、文句ない結果であったが、さまざまな問題に衝突したと言う。
●大規模チームで経験を積んできた自分たちが、小規模チームで躓いたこと
まず、X-Levelと呼んでいた「ゲームの全体像を見せられるステージ」の作成で躓いたことについて。Raj氏がチームに入った時、X-Levelが完成すれば全体の見積もりが立てられるだろうと思っていた。しかし、ゲームデザインドキュメント (ゲーム構造や企画意図をまとめたドキュメント) がほぼ存在していなかったことが発覚。さらに、それまでの開発にかかっていた時間も不明だったため、今後の見積もりも立てられなかったそうだ。
結果として、人材間の作業依存性（訳注：Aさんが作ったものをBさんが組み込むetc）
が見えず、スケジュールが組めなかった。誰かが全体像を掴んでなければいけない、でも誰も全体像を掴まないまま細部を詰めていく状態になっていたのだ。
そんな時、唯一の足掛かりだったストーリーが（スタッフたちは、ストーリーに沿って作業を進めていた)保留になってしまったと言う。そしてプロトタイプ作成をくり返す事態になり、メンバーがいろんなシステムを組み立てているあいだにスケジュールをまとめようとしたが、情報が足りず断念したと語った。
●何が悪かったのか？
この原因として、業界のベストプラクティス(最善と考えられている手法)を採用しなかったからであるとRaj氏は言う。チームが小さいからとコミュニケーションについて心配していなかったが、スタッフとのコミュニケーションを少しでも怠ると状況把握ができず、結果混乱に陥り、自分が全体のどこを作っているのか見失ってしまうことがあるそうだ。そして過負荷（自分に仕事が溜まって隘路状態に）、そして疲労（疲労した状態ではミスが増えた）と、悪循環を招く結果に。そんなときJake氏が家庭の事情で日本に移住し、チームは時差の影響で毎日2～3時間ビデオミーティングをするとになってしまった。
●ではどうやって解決したのか?
まず、ゲームの核となるおもしろさをきちんと再認識した。ゲームプレイの核となる部分は面白かったので、「これを活かせばいい！」という結論に至った。そしてプロシージャル（自動生成）システムが出来上がると、効率的に開発が進められるようになったそうだ。
また、GDD（仕様書）を作って情報を共有し、エンジニアが誰かを質問攻めにしなくても実装を進められるように。これにより人材が能力を発揮できる環境になったとのこと。なおGDDは複数のスプレッドシートで進捗管理をしようとしたが、無理だったので色々試し、Asanaというシステムを採用したと述べた。
結果、作業時間と見積もりが立てられ、誰かの手が空いたら、浮いている作業のリストからすぐにカバーに入ることができたそうだ。また、毎日、進捗状況のデッドラインを設け、京都に移住したJake氏が進捗をチェック際に役立てたそうだ。
しかし開発には、実は予定の2倍の時間がかかったと言う。つまり、2倍の予算がかかっているということだ。
ではどうやったらうまくいけるか。Raj氏は、以下の項目を述べた。
◇規律をしっかり作り、守ること
スケジュールとは責任を担うことであるという意識を持つ。チームに押し付けるのではなく自分の仕事だという気持ちを生み出すような環境を生み出すことが大事だと述べ、仕組み・スケジュールをきっちり組むことで、逆に自由になる（時間に追われない）とのこと。
◇チーム全員がゲームをきちんと紹介できるようするべき
小さいチームは全員がゲームの売り込みができるくらいでないとだめだと言う。そして、たくさんのショーに出展してフィードバックを得るのは良いことではあるが、開発の進捗を犠牲にしすぎてはいけない。
◇営業職を置くことは非常に大事
リリース半年前などから仕込むことがベスト。PRはフルタイムの仕事が要求される。
◇よく寝て、集中できるようにすること
精神的なスタミナが残ってなければ、正しい判断はできない。よって、ゆっくり休むこと、見たい映画は見に行くことが大事。
◇品質に妥協しないこと
Raj氏「さっきはよく寝ろと言ったな、アレは嘘だ」(会場笑)。品質に妥協しないためには踏ん張ることが必要なときもある。
最後にまとめとして、「作り手が楽しんでないゲームは、ゲーマーも楽しめない」と述べ、セッションは締めくくられた。
