読者です 読者をやめる 読者になる 読者になる

ゲーム開発者が偉ぶるブログ

ゲーム開発のビジネスやマネジメントについて日々思うことをあれこれ偉ぶって書き綴ったもの。

グラフィックデザイナーの罪

ゲーム開発 マネジメント

ゲーム開発において、プランナーからの指示や要望が非常に抽象的で曖昧なことが多く、アセットを実際に制作したりゲームに実装されてから「あ、なんか思ってたのと違った」「こういう時に困るのでここはこうして欲しい」みたいに修正変更が後から後から加わって突貫工事のようになっていく‥そしてグラフィックデザイナーやプログラマがそんな状況に対して憤るのが日常風景になっている。
データを制作して実装する前から「いや、これそのままやってもダメでしょ」のように問題のある場所を先に指摘しても「とりあえず作ってよ」で失敗を実際に体験しないと納得しないというのもまた日常。ゲームに出してみるとアレコレと問題が浮き彫りになるが、デザイナーやプログラマからは「こうなるって企画段階で分かるでしょ」「想像力が無さ過ぎじゃないか」みたいな意見も飛び出す。

だがしかし、そんなグラフィックデザイナー自身はどうなのかというと、プログラマに対して非常に曖昧な機能要望を出しては「思ってたのと違う‥」「あ、この機能が足りない」「問題があるからこれせっかく作ってもらったけど使えない」みたいなことが多発するのもまた日常風景だ。これは傍から見ればどっちもどっちに思える。

そんな日常風景を見てきて思うのは、例えばツールに対しての機能要望なら、どんなGUIで・何を押したらどうなって・Aのような条件下では結果がこうなって、Bの条件下では結果がこうなって欲しい‥といった感じでかなり要望を詰めて、なんなら仕様書をちゃんと用意するくらいが最もスマートなように思う。
「仕様書を用意するなんて時間がかかる」と言われるかも知れないが、実装しては問題が発覚して修正要望・追加要望を重ねていって結局満足なものができるのに時間がかかりプログラマもどんどん機嫌が悪くなっていくのを考えれば問題を洗い出して仕様書をちゃんと用意する方が断然良いのではないか。

ちなみに冒頭に挙げたようなプランナーの事例をなんとかしたいと思っているのであれば、仕様書に必要な要素が足りなくて実装後に問題が起こる中でよくあるパターンをリストアップしておき、それをチェックリスト化し、仕様書を作成する段階でチェックリストに沿って確認してもらう‥という形を実施した方が建設的とは思う。
それもまた面倒がられる可能性はもちろんある。