設計の仕事

職種紹介
【 設計職の役割って? 】
膨大な要素を整理し、開発の筋道をたてる

ゲームは膨大な要素で成り立っており、開発するには、それらをいかに整理し、多くの人と分担・協働できるようにするかが重要です。特にゲーム開発の要であるプログラム開発は、工程が非常に複雑です。開発中は、仕様変更も多々発生しますし、役割分担をして業務を進めるため、後工程で矛盾や不足が出る恐れもあります。それを防ぎ、プログラマが正確に作業できるよう筋道をたてるのが設計職の仕事です。特に昨今のハイエンドゲーム開発ではゲーム開発の規模が桁違いに大きくなっているため、企画職とプログラマの架け橋となる設計職の仕事は、効率よくゲーム開発を進める上で欠かせない存在です。

【 どんな仕事なの? 】
アイデアを技術的に検証し、効率化された開発の為の仕様を作成する

企画職をはじめ、さまざまな職種から出てくるアイデアを実現するには、どういう仕様が必要かを論理的に整理し、コーディングしやすさや仕様変更などへの柔軟さを意識して設計し、それを他職種と共通するための仕様書に仕上げます。また、実際コーディングされたものが仕様を満たしているかをチェックすることも大事な役割です。
単に要求されたアイデアの仕様書化を行なうのではなく、企画的視点(やりたいことが本当に反映されているか)やプログラマ的視点(企画職の提示したアイデアに不整合は潜んでいないか)の両面から要求を分析し、実装や変更を行なったあとの運用や影響を考慮しながら、最終的な実装仕様に落とし込みます。

機能ではなく“おもしろさ”を設計する

面白さと同様に、企画要件を実現するシステムは一通りではなく、さまざまな手法があります。そこから適切なものを選択するのが設計職の仕事のため、設計過程では、常に「なぜそのシステムにするのか」という説明が求められます。また、単に要件を満たす「機能」を提案するのではなく、「アイデアをいかにユーザーが実感できる形で実現できるか」を考えるため、企画職とのコミュニケーションも重要です。そのため、要件定義のための論理的思考力はもちろん、相手が何をしたいのかを汲み取るヒアリング能力・理解力も求められます。

インタビュー

PROFILE
■職種:設計
■入社:2010年入社

【 多くのプロジェクトに関われるのが魅力 】

設計職の実際の仕事の流れとして、主にディレクターや企画職から、ゲーム上において実現したい様々なシステム、機能の要望が上がるので、まずはその内容を確認します。そして、その機能はゲームプログラム上に実装することが現実的に可能なのか、要望を出した人の意図が正しく実現できる仕様になっているか、ゲームのコンセプトからずれたものになっていないか等の確認を行い、必要であれば内容の調整やすり合わせをしたうえで、その結果を仕様書に起こします。こうしてプログラマがその仕様書を用いてゲームを作成できる状態に進めていく、といった流れになります。

弊社には設計職として20人弱在籍していて、各プロジェクトに配属されていますが、プロジェクトの大小や開発の進捗具合によってプロジェクト内の設計職の人数や作業内容は流動的に変動していきます。

ゲーム開発というのは膨大な要素の集合で成り立っているため、必ずこの部分から作成するというわけではありませんが、仮にまずはプレイヤーキャラクターのアクション要素の検討から始める場合があるとします。この段階では、他職種のスタッフの人数も少なく、検証や開発を進められる範囲も限定されているので、設計職についても最小限の人数だけがアサインされます。
しかし、アクションゲームとしての骨組みが固まった後、キャラやマップなどのデータ量産期前後になってくると、メニュー機能やゲーム中に発生するイベントを実現するためのシステム、ネットワークサービスの構築など、ゲームの完成に向けて多種多様なシステムが必要になります。この時点では設計職の人数も大きく増え、それぞれ本人の適性やそのとき優先される項目に応じてメニュー仕様作成、イベントシステムの検証など個別の作業を担当することになります。そしてある程度プロジェクトが落ち着き、他のプロジェクトで設計職が多く必要となった場合には、また順次新たなプロジェクトに移動し、異なる業務にあたることになります。このように社内の様々なプロジェクトに携われるだけでなく、タイトル内の広い範囲に関わることができるのは、設計職の魅力の一つだと思います。

【 内容を落とし込んでいくという考え方 】

次に私たち設計職の作成するプログラマに渡す仕様書作成のイメージについてお話します。
まず企画職の要望が書面にまとめて送られてきます。
例えばプレイヤーの攻撃アクションに関する要望であれば、剣で敵を斬るモーションがあり、それはこのボタンを押すことで発生し、もう一度押した場合には連続攻撃になる、などのゲームシステムを構成する各要素がリストアップされています。
状況によってはそのままプログラマがこのリストに沿って必要な機能を作成するというケースもありますが、設計職が携わることができるときは、より詳細な内容にまで落とし込んだ仕様書を作成します。「このボタンを押した場合、この攻撃が出るが、この行動の時には出ない」「この状況ならこちらの行動が優先される」というような網羅性の保証のほか、ゲームデータとしての形式まで整理します。これは、例えば異なる攻撃で同じアニメーションやダメージ値を再利用できるようにするか、連続攻撃をデータだけで自由に設定できるようにするかといったことで、その必要性と実装の複雑さ、運用のしやすさを天秤にかけて検討します。
いずれについても、実際のプログラムで検討漏れを含んだまま実装されてしまい後々苦労することがないように、見落とされている要素がないか注意しながら仕様書に落とし込んでいきます。

このように仕様書の作成を進めていくため、設計職は要望の出どころであるディレクターや企画職、実装を行うプログラマと主にやり取りをすることが多いです。
また、企画職の中でも、例えばAIのスクリプトを作成したり、このマップにはこのオブジェクトや敵を置く、などのデータ作成を担当される方がいますが、この方たちとのやり取りも比較的多くなります。例えば設計職から、この敵の配置はシステム上不具合に繋がるのではないかという指摘や、このシステムを実現するために、マップにとあるオブジェクトを置いてくださいなどの依頼を行う場合もあります。逆に企画職から、特殊な挙動の敵を配置したいので、それを実現するためのシステムやデータを設計してくださいという相談を受けたりすることもあります。 またグラフィック関係の方とも、メニュー画面の設計等において、こういったデザインのものをくださいと作成依頼をしたり、イメージやデザインのすり合わせを行うことがあります。

【 新しい分野への挑戦 】

私は『DARK SOULSⅡ』でメニューやネットワークサービス、マルチプレイ周りの設計を担当しました。
実はネットワーク関係については入社するまであまり詳しくなく、大学の授業で学べる程度の知識しかない状態でしたので、担当することが決まった時点で再度勉強を始めました。とても苦労しましたが、ベテランのプログラマや設計職の先輩に助けられつつ、最終的にどうにか作り上げられたことは自信につながりました。
実際にユーザーさんに触ってもらって狙い通り機能しているという部分もあれば、今だからこそもっと工夫ができたなと感じる部分もあります。当時の全力は尽くしましたが、得られた知見や反省点もたくさんありましたので、これらは今後のタイトルで活かしたいと思っています。

弊社は自由度が高い会社だと感じます。 設計職特有かもしれませんが、任される仕事のアプローチについてはトップダウンで指示されることはあまりなく、『こういうことをやりたいから、どうすればいいのかを考えてください』というかたちで個々人に任されることが多いように感じます。 自立性と責任感が問われるためプレッシャーに感じることもありますが、ゲームのシステムを考えることそれ自体が好きな人にとっては、これ以上ない職場だと思います。