乱暴で建設的な話をしてみる：ゲーム制作編(非連載)

某知り合いから振られたネタを膨らませてみる。「素人で集まってゲームを創りたい」という発想だ。成功するためにはどうすればいいかなんてことが分かっていたらみんなそうするので、分からないということを前提に「こうするよりはこうしたほうがよさそうだ」というbetter論で行く。「これはダメ」という指摘と受け取ってもらっても構わない。

1.まず何がしたいのか見極める

×：「ゲームを創りたい」という漠然とした願望だけでは「ゲーム作成の困難さ」に負けて終わるのが関の山。
○：「このゲームによって何かを伝えたい」「こんなシステムのゲームってどうよ？」といった「そのゲームによって達成される具体的な何か」をチームの中で明確化し、全員の合意を得る。これが出来ない場合製作段階でチームが解散する可能性大。
◎：「こんなゲームってどうよ？」の後に「それって受けるか？」という自問自答をチームで行う。創ることが目的だったり「別にンなこと拘らない」価値観の集団なら要らない作業。あくまで商業的見地。ただしこれをあらかじめやっておくと、何らかのトラブルでチーム解散になりかけたとき「完成したってどーせ受けないし」という愚痴を叩くことができる（ぇ

2.初期段階で欲を出さない

×：最終完成系を先に描いてしまうと、開発途中での困難や方向修正でいつのまにか目的を見失い、モチベーション低下で崩壊する。
○：とりあえず「ゲームシステムとして最低限動く」というαバージョンの完成を第一目標に形を整える目標で全員の合意を取る。絵に色はいらない(ぶっちゃけラフで良い)、音楽はメインだけで効果音は後回し、システムはファイルインターフェースと表示、最低限の操作ができればよし、シナリオはイメージの一部抜粋程度。「こんな風になるんだ」というイメージ確認が全員で出来ればよし。ACTやRPG、SLGはシステムが非常に割を食うが、そこは耐えるしかない。というかノベルゲーム、テーブルゲーム、STG以外でシステムを独りで組むのは半ば自殺行為。それが出来るならある意味神。まったくの新ジャンルなら臨機応変に判断。
◎：αバージョン完成→βバージョン→完成までのプロセスにおいて加えたい要素のステップをツリー状に描く。次バージョンの実現のために前バージョンで「まず最低限何が必要なのか」を見出す。これはシステムに限った話ではなく、各担当者が「ここは熱意と時間入れたい」という部分と「ここはとりあえず形だけでもいいや」という場所の比重分けにも適用できる。

3.各人の役割と責任を明確化する。そのために完成までのプロセスと計画を立てる。

×：「足りない部分はおいおい」では延々その役を買う奴が出ない。しかもゲーム製作には、初期段階では分からない「足りない部分」が後々に続発するため、収拾しきれず破綻する。
○：αバージョン完成までの全体計画と、制作進行プロセスを線引きする。その上で各人の担当を明確化し、各人の計画を線引きする。順序を逆にすると悪戯に期間が延びるため、各担当者が自分の仕事に対して「どうあがいてもこんだけかかる」線を引く必要がある。
◎：お互いの仕事ペースを肌で知っておく。「こいつは放っておいても出来上がる」奴と「こいつはある程度の時点で進み具合を確かめて、ケツ叩かないと動かない」奴を同じ扱いにしていてはダメ。お互い冗談を交えつつ、マジになるところではマジになろう。全員で作っているんだという意識を常に！

4.優先度を決める

×：「これってよくない？」というアイデアは山ほどあるが、現実性、他の作業との兼ね合い等を考えずにアイデア先行で取り組むと何も出来上がらずに時間だけ経っているということになる。アイデアの大半は「やってみたらダメだった」で終わるため。
○：何かを優先すると何かがダメになる場合は「どういう理由でどちらの方が大事だからこうしよう」という根拠を以って全員を納得させる。イベント等の時間的理由がある場合は「これだけはないとヤバい」というものを、可能な限り「数少なく」定めてそれだけを完成させる。とにかく欲張らないこと！
◎：各担当者の拘りを全員で納得しておく。シナリオ担当、絵担当、音楽担当、システム担当、および広報担当等、それぞれの役割が「これだけは絶対譲れん！」という部分と「できればこうしたいんだけどなー」という部分を晒しておく。特に「譲れない範囲」に関しては、お互いが理解した上で制作を進めると、いざモメごとが起こったときにチーム崩壊する確率が劇的に減る。

5.モメたら初心を思い出そう

×：意見が分かれたとき、多数決は絶対禁物。採用されなかった側に不満が溜まり、チームが崩壊する。素人集団は面子の取替えが効かない。取替えが効くようならそもそもそいつは要らない。
○：「俺たちはこういう理由でゲーム作り出したんじゃなかったのか」という原点を見直す。それ自体が間違っていたなら、どうすればいいのか見直す。場合によっては一部(あるいは全部)やり直しにもなるが、それ自体にも意味があったと思うしかない。某シナリオ担当のようにジャンケンで割り切れるならそれでいいが……全員がそうだと楽だな。人生之ネタ也。そして負ける。
◎：「何が譲れない部分なのか」を明確化し、それを満たす方法を全員で考える。全員にひとつ「他の面子に作業を増やさせてでも実現したいワガママ」を許す権利を与え、お互いがそのために努力するという約束をつくるとやりやすい。特にないという奴はとりあえず「第一段階」が完成するまでは何も言わず付き合う。それ以後「ここはこうしたいんだけどー」と言えばいい。ワガママを言うことはお互いを調停する手段であって損得ではない、という発想があると理想だが…。

6.計画は見直す

×：計画に縛られてそれが守れなかったらダメ、という発想で物事を進めるといざそうなったときに喧嘩になる。
○：定期的にお互いの進捗を確かめて、遅れている部分は「何に思ったよりも時間がかかっているのか」をはっきりさせる。「ではどのくらい伸びそうか」を再度見直し、各人のスケジュールに反映する。ただしこの際、遅れていない担当者の〆切まで延ばす必要はない。「とりあえず出来上がってない担当者の分は抜きにしても組み上げる」くらいの意気込みで。急がず、だらけず。特に作業の遅れが他の面子に影響を及ぼす範囲は重点的に取り組む。主にシステム、シナリオ。
◎：テストを兼ねて「出来上がった部分とりあえずくっつけてみようぜ」という発想でお互いの作業確認をする。それによって計画段階で見えなかった意外な点(問題や予想以上の効果など)が見出せる。路線修正も少しずつなら破綻しない。目的は見失わないようにしたいが、目的を意固地に守ることだけが目的ではない。ゲーム制作を愉しむというのは、きっと無意識的に大事な目的だ。

7.テストは全員で

×：テスト担当を特定の誰かにすると、いざ一般公開したときにバグが発覚したとき、責任を一方的に押し付ける構図が出来上がる。これを都合がいいと思うような奴がいるようだとチームとしてヤバい。
○：全員でテストをやる。問題点(バグ)一覧を書き出すフォーマットをあらかじめ決めておき(Excel表など)、各人が発見した問題を平等に扱う。
◎：「明らかに動作不良・直さないとヤバイ」「可能な限り修正したい」「欲を言えば変えたい」の区別をし、修正計画を立てて作業をする。逆にいえば、とにかく「絶対直す」部分が直らない限り次に行かない。どうしても直らない場合は「直らないことを前提にした対応策」を考え、実行する。

……とまぁ、理想的な概念論だけぶち上げてみた。基本的にどのジャンルのゲームでも通じる共通事項で話を進めたが、「このジャンルのゲームに特化した指標をよこしやがれコラ！」という要望があれば書いてみたい。すでに日記の長さじゃねーな。

え、らっきょネタ連載？　棚上げ。痛覚残留が書けなかった時点で負け。