こんにちは22卒でゲームプランナーとして就職予定の天の声です。

一通り就職活動を終えたので、残された学生生活で何か残せるものはないかと考えたので、
ゲームプランナーを目指す学生へ何か残すことはできないかと思い記事を執筆しようと考えました。

今回のテーマは
学生生活におけるゲーム開発のフレームワーク
について書いてみようと思います！

目次

はじめに
企画立案フェーズ
メンバー全員で企画をする場合
プランナーが頑張る場合
制作フェーズ
タスクの洗い出し
タスクの評価
まとめ

はじめに

学生生活でチーム制作をする機会、特にゲーム系の専門学校へ通っていると多くあると思います。その中でプランナーは中心的存在として役割を果たすことになりますが、まず覚えておいてほしいのは
プランナーは原則プログラマーやデザイナーよりも劣っている
ということです。

そんな中で、プランナーが果たすべき役割は何なのか。
自分の考えるプランナーの役割は、
ゲームを完成させる道筋をつけること。

ゲームというのは非常に完成させることが難しいエンターテイメントです。
これは、ディライトワークスのクリエイティブオフィサーを務めている塩川洋介さんの著書
ゲームデザインプロフェッショナルー誰もが成果を生み出せる、『FGO』クリエイターの仕事術
の中でも触れられています。

**ゲームには完全に完成させるための手法が存在しません。**その理由は、一作ごとに何を完成とするかの正解が、まったく異なるからです。　— ゲームデザインプロフェッショナルー誰もが成果を生み出せる、『FGO』クリエイターの仕事術より

塩川さんについては、ネットでも様々な批評がされていますが、ゲームデザインプロフェッショナルで触れられているこの言葉は非常に的を得た意見だと思います。この本では、ゲームデザインをマニュアル化して誰でも80点のクオリティで製作できるフレームワークのようなものが紹介されています。今回、自分が提唱するフレームワークはゲームをデザインするフレームワークではなく、チームをマネジメントすることを重視したフレームワークの紹介になります。

企画立案フェーズ

企画を考えるって結構大変です。
学生が取り組むコンテスト制作で大きなものといえば
日本ゲーム大賞のアマチュア部門
ではないでしょうか。
「自分の作りたいゲームを作るぜ！」っていうチームにはこのフェーズは関係ないので飛ばしてください。

テーマが決められているチーム制作で企画立案をする際、考えられる手法は2つです。（ほかにもあれば教えてください！）

メンバー全員でブレインストーミング
プランナーが頑張る

どちらがいい、悪いという優劣は一概にはつけられないと思います。
チームメンバーの意向や所属する組織（学校等の方針）もあるので、状況に合わせて選択してください。

パターン①　メンバー全員で協力する

今回は、日本ゲーム大賞アマチュア部門に挑戦する想定でいきます。

与えられたテーマからテーマ解釈を行い解釈した結果をひたすら案出し

チームメンバー全員でブレストを行うイメージです。
例えば、2021年日本ゲーム大賞のテーマ「メビウスの輪」。
（もう少しまともなテーマをだせんのかと企画中は腹が立ったものです。）

案出しをするとこんな感じですかね

これは、チームで行ったブレストではなく、個人で行ったブレストですがこれくらいやればこの中からゲームを作る種は1つくらい生まれるんじゃないですかね。（個人差ありますが）

解釈した種から良さげなものを企画にしてみる

チームでブレストした結果をチームメンバー各々が企画を作ってみるという段階になります。ここはプログラマー、デザイナー関係なくできるといいですが、やはりプランナーの見せどころです。陸上競技で行ったら100m走の決勝みたいなものです。歯食いしばっていい企画を立てましょう。
僕のチームの場合は、今回のゲーム大賞では「ループ」に着目して、企画立案してみました。（ゲーム紹介できる機会があればいいとは思っています）

以上、チーム全体で協力して企画立案をするパターンでした。目からうろこのやり方ではなく、オーソドックスな手法ですが、このやり方で結果を出したチームがあります。実績の出したチームを~~パクる~~参考にすることは悪いことではないので参考にしてみてください。

パターン②　プランナーが頑張る

メンバー全員で協力をした先ほどのパターンとは異なり、プランナーが主体となって企画立案を進めるパターンです。
日本ゲーム大賞アマチュア部門2021チーム制作ではこちらのパターンを自分のチームでは選択しました。
やるべきことは、パターン①を個人で行うだけです。

プランナー自身で企画を考える

その過程において自身でブレストを行うのもいいし、ぽっと出のアイディアを企画にするのもいい。なんにせよ企画を1人で作り上げることです。

チームメンバーにプレゼン

プログラマー、デザイナーも交えたミーティングで、自分の考えた企画のどこが面白いかをプレゼンをします。面白さがメンバーに伝わらないということは、コンテストの審査員や、大局的にみると、自分の作ったゲームを遊んでくれるユーザーにも届きません。ここはしっかりチーム内で面白さの共有ができるようにしてください。

プランナーが2人以上いた場合にはコンペ

プランナーが2人以上いて、企画案が2案以上出ている場合には、コンペをして多数決を取り1案に絞ります。痺れますね。
コンペで通った企画もメンバーからの疑問点があれば解決する姿勢は忘れてはいけません。

少し長くなってしまいましたが、こんな感じです。
ゲーム制作を経験した人ならばわかるとは思いますが、テーマがある「企画立案フェーズ」って一番面白いところでもありつらいところでもあります。「このテーマだからこの発想ができた！」と前向きにとらえ、「テーマ」というものさしをうまく活用しましょう！

制作フェーズ

企画が決まったらいよいよ制作フェーズに入ります。
でも、ちょっと待ってください。

「じゃあ平沢さんはタイトルシーン作ってください！、秋山さんはメインのシステムを作ってください！琴吹さんはリザルトシーン作ってください！.....」

これでは、失敗します。

ゲーム制作は原則
ゴールから逆算して考える必要があります。
そこでタスクの洗い出しを先んじて行います。
所謂仕様決定ですね。
仕様とは

仕様（しよう、英: specification スペシフィケーション）とは、材料・製品・サービスなどが明確に満たさなければならない要求事項の集まりである Wikipedia「仕様」より

つまり、やらなければいけないことを明確化することが仕様作成の意図になります。
自分は仕様を細かく砕いたものをタスクと呼んでいます。

タスクの洗い出し

考えられるすべてのタスクの洗い出しを行います。
今の実力で実現可能かどうかは別問題。とにかく、
やりたいことや自分たちのゲームを構成するうえで必要なものをとにかくすべて列挙します。

いきなり、キャラクターの歩き方とか、当たり判定とか細かなタスクを洗い出しても散漫になるだけなので、一定のルールのもとにタスクの洗い出しを行っていきます。

STEP1　「大きな粒度」でタスクを出す

キャラクターの歩き方とか、当たり判定とか細かなタスク

このような「細かなタスク」を出す前に必要なことは、「細かなタスク」を包含する大きなタスクをまず洗い出すことからです。

所謂、ゲームループで必要な要素になるのではないでしょうか。この「大きな粒度」のタスクが発見できないということはほとんどないと思います。ここはあまり時間をかけずに次のステップへ行きます。

STEP2　　「大きな粒度」から少し細かくした粒度でタスクを出す。

次に、STEP1で出したタスクを少しだけ細かくします。

このくらいの感じでタスクを分割します。
あくまでも少し分割しただけなので、歩き方とかほこりをどうたてるか等はまだ先の話です。

STEP3　　さらに細かくする。

STEP2で細かくしたタスクをまたさらに細かくします。

ここでようやくモーション、当たり判定等のタスクが登場しました。

このままSTEP4　またさらに細かくするステップを踏んでもいいですが、ここで注意があります。それは、
タスクは細かくしすぎると管理がしきれなくなる
という点です。

タスクをどこまで細かくするかは、チームの規模やリーダーの資質によります。
タスクの管理を補助するツールとしてWBS（Work Breakdown Structure）やガントチャートを使います。
（ここで、プロジェクトマネジメントを勉強している人なら今までやってきたSTEPはWBSの定義に即して分解していることに気づいたのではないでしょうか。何ならWBSを作っているのと変わりはありません。）

タスクを評価する

「評価する」というと小難しく聞こえますが、やることは単純です。重要度をつける。ただそれだけです。
評価する指標として、よくやりがちなのは、「S,A,B,C」みたいにランク付けをするパターンです。
一概に悪いとは言えませんが、各ランクにきちんとした意味を持たせられていますか？ゲームみたいなランクをつけて満足しているだけじゃないですか？

こういった、やった気になることを防ぐために、僕が考えたMSWCの法則というものを紹介したいと思います。（造語です。）

MSWCの法則

MUST（やらなくてはいけないこと）
SHOULD（やったほうがいいこと）
WANT（やりたいこと）

タスクの洗い出しで洗い出した各タスクに上記３点の観点から評価をします。評価をし終わった後に

CAN（できる）

できるかどうかですべて再評価します。（ここはプランナーだけでなく、プログラマーやデザイナーも参加したほうがいい）

評価が終われば制作の開始です！
MUST→SHOULD→WANTの順で製作を進めていきます。MUSTタスクでCANがついていないものは知識不足なので、勉強をするかタスクの再検討をする必要があります。

ここで気づいてほしいのはWANTは一番最後だということです。
企画段階では大風呂敷を広げて夢を語るものですが、実際のところ、WANTすべてをやりきるというのはすごく難しいです。
SHOULDをすべてこなしたら、１００点。WANTをすべてこなしたら２００点くらいの感覚でいるといいと思います。

気を付けるべき勘違い

よくある勘違いとして

WANT（やりたいこと）をMUST（やらなくてはいけないこと）と勘違いをする。
WANT（やりたいこと）をSHOULD（やったほうがいいこと）と勘違いをする。
MUST（やらなくてはいけないこと）はCAN（できる）と勘違いをする。

１，２はきちんと評価ができていません。ゲームにとって必要かどうかを冷静に判断してむやみやたらとMUSTやSHOULDにしないようにしましょう。

３に関しては、MUSTだからと言って必ずCAN（できる）とは限りません。チームメンバー次第では基本の実装ですら怪しい人もいるかもしれません。プログラマー、デザイナーの能力と相談しながら丁寧な評価をしましょう。

まとめ

ここまで基本の流れを紹介しました。
「なんだ、当たり前じゃん！」
と思った人はそれで大丈夫です。

実際のところ、学生のチーム制作ではこのような観点で進めているチームは非常に少ないと感じました。
結果を出す、出さない以前にやみくもに制作に取り掛かったところで先の見えない作業ほど地獄なものはありません。

ここで紹介したフレームワークは絶対的なものではなく、フレームワークをベースにチームや個人の実情に合わせて製作は進めるべきだと思いますので、１つの例として参考にしてみてください。

次回は、タスクの管理のコツやこのフレームワークを使った例（マイルストーンの引き方）等を書ければと思います。

よければLGTMやストックお願いします！

（コメントも大歓迎です。ここがおかしいとかのご意見も待ってます！）