ゲーム企画書、仕様書の書き方、フォーマットをご紹介
今回は一例として、私が開発チームへ説明する企画書の作成事例、そしてそこから仕様書作成のサンプルをご紹介いたします。
最新サンプルはこちらに掲載しました。
https://x.com/ukyoP_san/status/1708468824172060689?s=20
大まかな流れはこんな感じで構成していきます。
今回は企画書と資料3までについて触れます。
資料1|企画概要書
・どういうことを実現したいのか?
・どういう遊びをしたいのか?
・コアコンセプト
についてのドキュメントです。
企画書は、誰に対してどんな目的で作るのかによって内容を変えますが、このページではゲームを作るという前提で話を進めていきます。
この場合、資料1ではある程度実現したいことを書いているようなイメージです。参考資料としてはこのサクセスさんで公開されているような企画書レベルのものですね。
まぁここまで詳しくは書かないですけども、最低限エッセンスを盛り込みます。
参考までにむちゃくちゃラフな企画書を添付します。
1−1|企画書P1、表紙、タイトル
タイトルは最初に考えてもいいけど、最後に修正しなおすことも多いです。ただ、知的財産権を取り扱う場合はほぼ変えられないです。
・タイトル表記
広告などではテキストデータでよく使いますので、できる限りそれで分かるほうが理想的です。スマホ向けの場合、ストアに表示される文字量などにも制限があるので8~12文字ぐらいがセオリーなのかな。
・メインビジュアル
世界観を表すためのワンパンチです。色、キャラの雰囲気などもここで表現できると理想的です。
1−2|企画書P2、コンセプト、概要、要約
これはこうなんだよっていう部分。
本作のテーマ的なものや、遊び、表現する軸です。
参考タイトルに掲げながら、こんな遊びという表記をすることも多いですが、どこが他と違うのか?という視点を意識しておくこと。
ただし今のご時世、差別化やこれなんだよっていうのが完結に表示できないことも多いので、できる限り知恵を絞って書き出す感じで書面化します。
ここですごく悩むようであれば、それぐらい競争率が高いということでもあり、PRや広告で苦労することが目に見えてしまう。
ゲームの難しさはこれがある。
あとRPGのように全体的な作品力で魅力を打ち出す場合も、特徴を絞り出すことが難しい。
だからオリジナルはマーケがクソ大変ということにも直結するわけですが、物量勝負やクオリティ勝負になると正直大手には勝てないのでできれば避けたい戦いです。ランチェスターの戦い(弱小なりの戦略)を意識して、工夫していきましょう。
1−3|企画書P3|詳細
この辺は要素に合わせて自由にページ構成や枚数を変えていくイメージ。
できれば仕様に落とし込む前の概要レベルぐらいは欲しい。この時点でコアな部分の方針ぐらいは詰めておきたい。もちろん、作りながら変更は前提という意味で。
1−4|企画書P4、ゲームサイクル
全体のフローやゲームサイクルを表記。どこまで書き込むのかについてはお好みで。
1−5|企画書P5、スペック
必要であれば書く。ただ、規模間ぐらいは想定しておかないと手を出しづらいので、最低限の規模間は共有して取り掛かりたい。必要であればリクルートもやるので。
資料2|仕様書の作成
仕様書は実際にゲームを作るために必要な設計書です。
企画書が紹介文書のようなものだとしたら、仕様書は実際に組み立てるための説明書や設計図のようなものです。
作り方は企画書に沿って、コンテンツを細分化。具体的にプレイヤーベースで体験するための機能に分けて、書類を作っていくことになります。
種類としては、大きくこの辺を作ります。ストーリー、キャラクターデザイン、サーバー構成などは仕様書ではなくて別資料で作ることがあります。
といった感じで作っていき、さらに細分化して仕様を落とし込んでいきます。
実際ゲームで使うためのパラメータや数値、参照元のデータは別途資料4のマスターデータというドキュメントを制作しますが、企画仕様には基礎となる計算式や、根幹の部分のみを書いておきます。
【注意事項と補足 】
仕様書を作り込む前に、コアとなる部分だけのモックを作って動作テストを行なって、そこが面白いのかどうかのチェックをひたすらやりましょう。
モックレベルで面白くならない、面白くなる兆しが見えないと判断したら、作らないという選択肢を取るからです。
この辺りは欄外にある記事でも記載しています。
仕様書のサンプル
▼サンプル1
▼サンプル2
▼サンプル3
資料3|技術要件定義書
私は基本的には資料2の中に知りうる技術的な要件の概要を記入します。
シーケンス図やユースケース図は書くとしてもレイアウトベースで書いてしまうことが多いので、資料2の中で終わらせてしまうこともありますが、技術者が求める場合は用意するといった感じです。
その後、開発者やデザイナーとMTGをして、この技術要件は盛り込んでおいて欲しいので追記しましょう、デザイン用件を入れておきましょうというような感じで要素を盛り込みますが、より技術的な部分はプログラマ同士で共有するドキュメント側で管理することが多いです。
まとめ
企画書や仕様書の書き方は会社やプロジェクト単位でも異なりますので、あったやり方をやっていきます。
ドキュメント作成は大変ですが、引継ぎ資料にも使いやすいですし、仕様把握、QA(デバッグ)時のテストケース作成などでも役立ちますので、できる限り丁寧に設計はしていきたいところです。
ただ作りながら常に古い資料を更新することはかなり大変なので、その部分も計算しておくといいかもしれないです。
具体的にお見せできる資料がなくて恐縮ですが、少しでも参考になれば幸いです。
詳しくはこちらもみてね!
企画の建て方、コンセプトの見つけ方
ゲーム制作の全体の流れ
この記事が参加している募集
いただいたサポート費は還元できるように使わせていただきます! 引き続き読んでいただけるような記事を書いていきたいと思います。