アウトプットフローを作る

ゲーム制作はアウトプットの連鎖で仕事が進み、最後にプロダクトに至ります。「アウトプット」は例えば仕様書、3Dモデリング用の三面図、ソースコードなど各メンバーの成果物。「連鎖」はある人のアウトプットをインプットとして別の人がアウトプットを出すという流れを指しています。

この記事ではゲーム画面のUIを実装する場合を例に、この「アウトプットの連鎖」を細かい粒度で可視化してメンバー全員が認識するのが大事、という話を書いていきます。

最も単純なフロー

ごく単純に考えると、UIデザイナーが書いたUI仕様書というものがあり、画面を実装するプログラマーはそれを受け取って実装すれば良いという事になりそうです。流れはこのような感じで、カッコ[]はアウトプットを示しています。

=> [UI仕様書]
　　=> プログラマー => [ソースコード]

では制作開始時にゲームプランナーが画面イメージをUIデザイナーに何かしら伝えた後、UIデザイナーが色々想像で補ってUI仕様書を書いてプラグラマーに渡せば、プログラマーはそれを読んであるべき画面を実装できるでしょうか？

もちろんできません。UI仕様書が実装に十分な内容とは限らないからです。UI仕様書というからには画面のレイアウトやインタラクションなどが書かれていそうですが、例えば武器リストが画面内にあったとして、1つも持っていない場合の表示の仕方について書かれているでしょうか？逆に1000個持っていた場合は？
これは書いてあるかもしれないし、書いてないかもしれないです。何故ならUIデザイナーが仕様書を書く際に「リストを実装する場合は1個も無い場合と多数持っている場合の表示の仕様が必要」という事を知らなければ書けないからです。

アウトプットの内容をリクエストするアウトプット

つまりUI仕様書を作る際には、「実装するためにUI仕様書に書いて欲しい内容リスト」のようなものがあった方が良いという事になります。UI仕様書というアウトプットを出すための、UIデザイナーへのインプットです。これはプログラマーが書いてUIデザイナーに渡す事になるでしょう。

　プログラマー => [仕様書に書いて欲しい内容リスト]
　　　=> UIデザイナー => [UI仕様書]
　　　　=>プログラマー => [ソースコード]

アウトプットの形式

さらにその画面で武器を確定した場合、良い感じに回るアニメーションをしながらその武器が画面の中央に出てくるとします。今回はアニメーションを実装するのもプログラマーだとして、そういったアニメーションの指示はUI仕様書の文や画像で説明するのは厳しそうです。おそらくUIデザイナーが何らかのツールでアニメーションを作り、それをプログラマーに渡す事になるでしょう。

　プログラマー => [仕様書に書いて欲しい内容一覧]
　　　=>UIデザイナー => [UI仕様書] , [UIアニメーション]
　　　　=>プログラマー => [ソースコード]

ここで[UIアニメーション]と書きましたが、この実体はいくつかパターンがあり得ます。プログラマーが使っているツールをUIデザイナーも使ってアニメーションまで作ってから渡すパターンもあるし、別のツールで動画を作って渡してプログラマーが目コピする場合もあります。いずれにしろ、この想定がお互いズレたまま進むと、どこかで想定外作業が発生してスケジュールが遅延するでしょう。それを防ぐためには具体的な形式を予め決めておく必要があります。

　プログラマー => [仕様書に書いて欲しい内容一覧]
　　　=>UIデザイナー => [UI仕様書] , [UIアニメーション（動画）]
　　　　=>プログラマー => [ソースコード]

必要な内容の網羅

さてこの画面に「武器強化ボタンが初めて使えるようになった場合、ボタンの解放演出が表示される」という仕様があったとします（モバイルゲームでよく見かける仕様です）。演出の内容はUIデザイナーの指示があるとして、この「初めて使えるようになった」かどうかの情報は端末とサーバのどちらで持つべきでしょうか？端末で持つ場合は別端末でプレイするとまた解放演出が表示されてしまいます。一方サーバで持つ場合はデータ管理が少し煩雑になります。

これは見た目ではなくプレイヤー体験と実装コストのトレードオフの判断なので、プランナー（企画メンバー）に判断してもらうのが良いかもしれません。こういったものは他にもいくつかありそうなので、他のゲームを参考にしてまずそういったものを洗い出して、予め企画メンバーに決めてもらう事にします。

(1)プログラマー => [実装コストとの見合いで決めて欲しい内容リスト]
　　=> プランナー => [上記リストの回答]
(2)プログラマー => [仕様書に書いて欲しい内容一覧]
　　=>UIデザイナー => [UI仕様書] , [UIアニメーション（動画）]

　　　(1),(2)両方 =>プログラマー => [ソースコード]

この解放演出の例は実装を進めていく中で決める必要が生じてから確認でも問題無さそうですが、「予め分かっていればこう実装したのに」という手戻りができるだけ起こらないようにするには、このようにできるだけインプット（実装するにあたって必要な情報）を揃えておく方が良いでしょう。

アウトプットフローを書く

上記の例で見てきたように、最もシンプルに考えると「UIデザイナーが仕様書を作ったらプログラマーが受け取って実装していきましょう」くらいの認識になるところを、「アウトプットとそれに必要なインプットの連鎖」という観点で具体的にアウトプットフローを書くと、色々な担当者の要件や決め事の連なりが見えてきます。

これが見えれば、そこからタスクやスケジュールの分解や見積もり、早めに検討依頼を投げるなどが可能になります。それによって情報不足による追加作業、認識ずれによる手戻り、都度返答を待つ事による遅延、予定外の作業による過負荷、などをある程度防ぐあるいは予想する事ができるでしょう。

またアウトプットフローを書く事の副次効果として、各作業をする際に「何のためのアウトプットなのか」「誰のインプットになるのか」を意識できるようになるので、必要以上に凝りすぎたり誰も必要としないドキュメントを作ったりも減らす事ができます。

最後に

プロジェクトでワークフローを決めるというのはごく当たり前の事ですが、その内容を「誰が何の作業をするかの流れ」で考えてしまうと、上記のような必要な内容の網羅や形式の認識合わせが難しくなってしまいます。

呼び方としてはワークフローでも開発プロセスでも何でも良いのですが、開発全体をアウトプットの連鎖と捉えた上で、「何をインプットとして何をアウトプットするか」を明確にすると良い事が多いので、プロジェクトやチーム作業をする上でぜひ考えてみてください。