【32】作業フローのクリティカル・パスに効く開発環境

後藤誠

　私が長年関わって来たイベントシーン開発では、DCC ツールからの出力データや、ゲームシナリオが書き込まれたスクリプトなど、多くの「アセット」がデザイナーやプランナーによって制作される。これをゲームに最適なデータへ加工し、組み込み、編集した箇所を確認できるようにする必要がある。このステップを如何に少なく、高速に回すことができるかがクオリティに関わってくる。仮に、結果を確認できるまでに 10 分かかっていたのを 5 分に短縮できれば 2 倍のクオリティ・チェックができるようになる。理想は、アセットの編集と同時に確認ができるライブ・エディット環境（待ち時間ゼロ）だ。「触ってなんぼ」のゲーム開発では、この時間がクオリティにダイレクトに影響を与える。

　これまでの経験を振り返ると、いくつかの共通する有効な方法が見えてきた。

それは、

「バッチファイルを実行」だけにする
サーバーで出来る事はサーバーでやる
各担当者間の作業フローを図にする
「うっかり」対策をする

である。

1.「バッチファイルを実行」だけにする

　デザイナーもプランナーも担当するアセット制作で手一杯である。「1 から 10 の手順で更新してください」なんてものを渡したら、何らかの問題が必ず発生する。「このバッチファイルをダブルクリックしてください」だけにしておけば、バッチ処理内で各担当者の違いを吸収できる。また、データの加工法に変更があった場合でも作業者に影響を与えることなく修正が可能である。

2.サーバーで出来る事はサーバーでやる

　他のデータと組み合わせてパッキングをする場合や、ムービーのようにデータ加工に時間かかる場合、更新の確認に時間がかかる。こういうときは、アセットがコミットされる度にサーバー側でその処理を行い、終了後にコミットしたユーザーへ自動で通知メールを送るようにする。こうすると、作業者はコミット後に続けて他の作業に取り掛かることができる。また、自分の制作担当範囲以外の部分をサーバー経由で参照できるので、全体としても無駄が減る。これの実現には、Jenkins などの CI ツールが便利だ。

3.各担当者間の作業フローを図にする

　ある程度以上の開発規模になると、個々がプロジェクトの作業フロー全体を把握するのが難しくなる。このような状況で、ワークフロー担当のプログラマーが気を付けなければならないのは、個々の担当者からの要望や報告の具体的な内容のみではなく、作業フロー全体がどのような状況なのかを理解することである。そのために、全体の作業フローを図化し、皆が見られる Wiki などで共有しておくことが望ましい。ポストモータム時の資料にも利用できるため、非常に便利である。

4.「うっかり」対策をする

　どんなに注意しても、「うっかり」は発生する。これは仕方がないことだ。しかし、手順や作業フローで、これを減らすことができる。以下は「うっかり」対策として私が心掛けているチェック事項である。

手動で移動やコピーをさせていないか？ → 眠いときやマスター間際のとき、これが原因で問題が発生する。バッチ処理で行うようにするべきである。
担当ごとのファイルやフォルダのアクセス権限は適切か？ → 影響範囲を最小限にすることができる。
手順を間違えたら警告が出るか？ → 間違いを早く気付いてもらうようにする。
あらゆるアセットがバージョン管理されているか？ → 事故発生時に巻き戻しができるようにする。

　その他、状況に合わせたチェック項目を更新し「うっかり」が起こらないようにするのが良い。

　ゲームクリエイターが考えた多くの素晴らしいアイデア。そのアイデアの実現力が成功のカギだ。そして、日々の開発サイクル改善により、実現力を上げることができる。