製作振り返り【Bordered】2018/03/28

こんにちは。 SATです。
早いものですっかりＯＢ２年目になろうとしています。
気づいたらリアルガチな職業プログラマーになっていました。

この度、2016年度全体製作「Bordered」が完成し、リリースされました。

このプロジェクトの振り返りを兼ねて現役部員とこれから入ってくる新入部員の皆さんへ教訓を残そうと思います。

ちなみに、私はもうOBの老害になりかけてますが、ひっそりと活動を続けていく所存です。

プロジェクトが失敗する原因

そもそもの話から始めると、このプロジェクト、発足当初から私が卒業するまでの間は一切ノータッチでした。

しかし、相当な苦労を経てシナリオが完成したにも関わらず、そこから半年以上もエディター班が機能せず放置された状況もあり、やむなくOBになった私が手を入れることになったわけです。

もちろん、大学卒業以前から横で見ていたのでこうなることは薄々見えていたわけですが。。。

ではなぜこの作品が１年以上も放置され続けたのか？
それは、主に以下のような原因があったとSATは考えます。

規模感を把握できないままに企画が始まり、目標が見えないまま進んでしまった

• 初めてゲームを作る人が圧倒的多数で、ボリューム感が掴めていなかった
• 思い描くシナリオをそのまま形にすると、間違いなく収拾がつかなくなる（＝削る作業が必要になる）

タスクを洗い出さないまま部門分けして、縦割り化してしまった

• 部門同士で話し合うべきことがたくさんあったのに、「上手いことやって」と適当に流していた
• 普通、双方でイメージや見解が違うはずなのですり合わせが必要になる

担当割りに期限が付けられていなかった

• 「ゆるくやろう」というのが当初のウリだったというのもあるが…
• それだと己のタスクに責任感がなくなり、途中で投げ出す人も出てくる
  （実際、途中で幽霊化した人が半分くらいいたはず。体感レベルで）

情報共有がおろそかだった

• どの部門でどこまで進んでいるのか、誰が何をやっているのか？
  これを把握するのは週一回の部会しかなかった
• 部会に参加しない週が続くと、帰属感が薄れていく
• そして幽霊化

責任を持ってプロジェクトを牽引する人間がいなかった

• 当初の部長は引退して戦力外へ
• シナリオ班が実質的な牽引役となったが、その責任感を持つ者はおらず
• エディター班はシナリオが完成した時点で既に統率がとれていなかった
• 結果、プロジェクト自体が忘れ去られていく

裏事情的な

ぶっちゃけ、プロジェクトを諦めるのも重要で、もし諦めるならばそれは早い段階でその判断を下す必要があります。
後になればなるほど成果物が増えていき、引けなくなっていきます。
そしてその判断を下すのは他でもなくリーダーです。

今回のBorderedでは、放置されるまでにシナリオが既に完成している状態
＋グラフィックがある程度のボリュームで仕上がっている状態だったため、
あとはエディターで実際に編集するだけで完成できる
＝短期間で完成できると私が判断、私が主導権を握ることで製作再開へと至りました。

そもそもOBが主導権を握っている状況もどうなんだよ、というツッコミもありそうですが、
現役生はもう別のプロジェクトで捗っている状況だったため深入りできなかった…という事情もありました。

これがもし、シナリオもグラフィックも中途半端な仕上がり…
みたいな状況であればプロジェクト自体を明示的に解体する、という発想もアリだったと思います。

とはいえ、シナリオやグラフィックだけができていても、
それでもエディター側で必要になる実際のタスク量は膨大で、結局大変な思いをする羽目になったわけです。。。

チームでゲームを作るための教訓

前置きが長くなりましたが、今回のプロジェクトで得られた経験をまとめると以下のようになります。
もちろんここに載せきれないこともたくさんありますが、気になる方はぜひ私に直接聞いてほしいと思います。

何事も期限を設けるべし

• 期限を決めてもそれ通りにいかないのだから、決めなかったらいつまで経っても終わらない。
• 「趣味だからいいや」ではなくてあくまでも完成することに主眼を置かないと経験にならない。

直接集まって作業 or 時間拘束して作業すべし

• 自宅で一人で作業ができるならそれが理想だが、自分を律せられる人はそう多くはない。
• 学内にいるなら昼休みなどの時間に集まることはできるはずだし、
  できない場合でもSkypeなどで同期的に作業することもできる。
• 自分だけでモチベーションを保ち続けるのは難しい。
  他の人から刺激を受けるのはモチベーションに繋がる良い機会になる。

終わったら反省すべし

• 自分の経験だけで完結させないで、サークル内でもっと知見を共有してほしい。
• これをやらないとまた同じ失敗を繰り返すだけ。
• 自分だけ認識していても、周りがその失敗に気付いていない場合は何の意味もない。

プロジェクトをマネジメントすべし

• 「各人が好きなようにやった結果、一つのゲームが出来上がる」というのはまさに幻想でしかない。
• 実際には各人を取りまとめる立場がいないと、
  バラバラのものが出来上がってとてもじゃないけどゲームと呼べるような代物にはならない。
• そして残念なことにマネジメントしたくて創作活動部に入ってくるような変態部員は九分九厘いない。
• こればかりは「誰かがやらなきゃいけない」と割り切って誰かが買って出るしかない。

ウディタってチーム製作するツールじゃねーからッ！ いやまじで。

• チーム開発って競合が付き物なんですよね。
  • うっかり同じファイルを編集してしまったりとか。
    • 物語の中心となるマップがあったりしたらもう大変！
• ちゃんとファイルの差分が取れて管理できるならいいが、
  あいにくウディタはバイナリばっかりなので差分の取りようがない。
  • 今回は途中から頑張ってGitを導入したが、その敷居の高さからかえって混乱してしまった。
• いずれにせよ複数人でウディタは触らないのが得策だろう。
• 「じゃあ、どうすりゃいいんだよ」って？あえて消極的な意見を言えば、RPGを諦めた方が早いです。
  • Unityなど自作プログラムで作る場合、
    RPGは相当な経験を積んだプログラマーじゃないと作るのが大変なのです。
    実装するべき機能が多すぎるんです。
  • シナリオ中心ならノベルゲー、システム中心ならRPG以外の自作プログラムを書いた方がよっぽど自由度が上がりますよ。
  • RPGのシステムってもはや飽和状態（完全オリジナルを出し辛い状況）と言ってもいいはずなので、
    そこに固執するぐらいならその枠から外れちゃってもいいのでは？と個人的には思います。

運用ルールを決めよう

• ウディタなどの編集ツールを複数人で使う場合、
  ファイル管理やID管理、素材の管理は運用ルールとしてまとめておかないと確実にてんやわんやになります。
  • ファイル管理 -> ファイル名の命名規則
  • ID管理 -> 千の位は装備種別、百の位は装備対象者、みたいな
  • 素材管理 -> どこからどのファイルを取ってきた？利用規約は？

飲み会お食事会をやろう

• いわゆる昭和的な飲みニケーションを肯定するつもりはありませんが、
  ご飯やお酒を共にしながらサークルの部員と話す機会はとても重要です。
• 普段の部会や作業だけでは部員同士で込み入った話ができず、
  相手の考えを知ることもできなければ自分の意見を伝えることも難しいでしょう。
• そういったモヤモヤ、お食事会を通じて少しでも解消できないでしょうか？
• 元々上下の関係はそんなにない（後輩の方が先輩よりも経験あるケースもザラにある）ので
  ガンガン言っちゃっていいと個人的には思います。
• 幹事役をやるのは気が進まない…という方も多いでしょうが、
  行動力を磨くという意味でやってみる価値は大いにあると思います。
  誰かがやらないといつまで経っても開催されないので。