はじめに

　ゲームのプランナーとしてのお仕事、四捨五入するとたぶん40年くらいになると思います。
　そのノウハウを色々と書き記しておこうと考えています。
　この文書では「ゲームの仕様書に必要なコト」について書こうと。
　仕様書にまとめるゲームの内容なについては、ある程度考えがまとまっているとします。
　勿論、仕様としてまとめるうちに問題点や各要素の相互矛盾に気付き、訂正しるていくこともあるでしょう。
　私の場合も、そういう手順を踏んでいますから、ここで書かれている事は、身をもって実践した内容だと言えます。
　ゲームの仕様は多岐にわたりますから、仕様書の項目も多岐に渡ります。
　この文書では、特定の項目に依存しない形で書こうと考えています。できるだけ。
　この文書で記載するノウハウは、仕様書の1項目について記載しました。
　また、仕様書のサンプルも掲載しています。

記述すべき項目「何のために」

　まず初めにお伝えしたいのは「その仕様項目が達成しようとする目的」を記述する事です。
　いわゆる「手段と目的」の「目的」です。
　その目的を達成するために、書こうとしている仕様項目があります。
　仕様項目の目的ですから、割と具体的な内容になると思います。
　作ったプランツというゲームの操作性で言えば「プレイヤーの思考を邪魔しないタッチ操作」とかになるでしょうか。
　この目的の場合「プレイヤーの思考を邪魔しない」と「タッチ操作」を両立させるのが目的となります。プランツはパズルゲームですし、スマホのゲームですからこういった目的が定義された訳です。
　何故「目的を記載するか」というと、手段である仕様がその目的を達成しているかをチェックするために必要だからです。目標を達成していない仕様では意味が無いですから。
　また、ゲームの大目的とその仕様項目が整合しているかをチェックする際に効率的だからです。大目的と仕様項目の目的が合わない場合、そもそもその仕様項目は必要なのか？という所から検証する事になりますから。
　仕様の内容が目的を達成していれば、大目的と目的との整合を検証すれば、大体はうまくいきます。最も仕様レベルの不整合を完全には排除出来ませんから「ゲームを頭で動かす」事や実機でのテストで顕在化する事もあります。

検討すべき項目「導入するとどうなるか」

　ある仕様項目を書く場合、以前からある関連する項目との相互作用を考える必要があります。
　これは仕様を修正する際、特に重要です。
　新しく導入する仕様と以前からある仕様との相互作用をきちんと整理しないで導入すると、副作用（論理バグ、仕様の衝突など）が起こった場合、どうしてそうなったかを解明するのにとても難儀します。そして副作用が判明するのは、大抵、仕様がほとんど実装されてテストされてからなんです。もう、スケジュールは終わりに近づいてますし、おそらくスタッフの気も立っているでしょう。
「あ、ごめん、ここ間違ってたよ」（てへぺろ）
　まあ、大変な事になるでしょう。
　この「関連する項目との相互作用」というのは、ゲーム全体を把握していないと掴みきれないものです。巨大化したゲームの場合、何に作用するか理解するのはなかなか難しいかも知れません。
　そのためには、関連する要素事の関連付けをマップにしたり、関係するパラメータの依存関係をチャートにしたり、という仕様書とは別の書類を用意しておく方が良いかもしれません。
　マップの方は、円の中に仕様項目名を書いて、それらの依存関係を矢印で結ぶ、というものでしょうか。
　チャートの方は、例えばゲーム内通貨の場合、購入、消費、などの関係を網羅した相関図、というものになるのかと思います。
　もちろん頭に入っているに越した事は無いのですが、慣れるまではこれらのツールを用意する方が無難でしょう。
　幸い私は小規模の2Dパズルゲームなどを開発していますから、これらのツールのお世話にならずに済んでいます。

誰向けの仕様書なのか

　その仕様項目の対象読者は誰なのかを理解して記述する必要があります。
　プログラマ向けなのか、デザイナ向けなのか。
　それによっておそらく書く内容が多少変化するでしょう。
　もし、複数の担当の方に読まれる場合には、共通の記載をして、担当の方向けに注釈などで補強すると、仕様書の保守が楽になるかも知れません。

固定要素と変動要素を分離する

　主にこれは内部要素の場合かな、と思います。
　例えば剣のパラメータ設定を仕様に書く場合、特定の要素は剣の種類によらず同じ値になる場合もあるでしょうし、個々の剣の種類によって違う場合もあるでしょう。あるいは同じ剣の種類でも個体差があるパラメータもあるかも知れません。
　つまり、そのパラメータが変動する範囲を明確にしておく、という事です。
　まあ、この辺りを曖昧に書いておくと、プログラマさんによっては、質問してきます。そうでない場合には、プログラマ裁量で決めてくれます。この場合、後で変更をお願いするのは、ご想像の通りです。

書き方について

　この書き方は、あくまで私個人のスタイルのお話です。
　参考になれば幸いですってものです。

ファイル名規則と目次

　仕様書は、macのNumbersというExcelみたいなアプリで書いています。
　Excelと違うのは、シートに複数の表を置けるので、シート内に複数の表を置いても行列の干渉がありません。とても楽です。Wordのように図を貼り付けても改行でずれる、という事もありませんし。
　そして、仕様項目ひとつがひとつのファイルになります。
　そのファイルの一覧と何が書いてあるか、というものが目次です。
　ファイル名は、下のように記述しています。

TR010doc00_目次.numbers
TR010doc01_この資料について.numbers
TR010doc02_ゲーム概要.numbers
TR010doc03_ゲームの目標.numbers
TR010doc04_プレイの流れ.numbers
TR010doc05_妖精とブロック.numbers

　これは、プランツという2Dパズルゲームの仕様書のファイルです。
　TR010は行頭識別子です。プロジェクトコードを意味します。
　その後のdocが仕様書を意味します。
　その後の二桁の数字が仕様書番号を示しています。
　_以降がそのファイルのタイトルに相当します。
　番号を入れているのは、タイトル名だけだと他の人と情報共有する際、間違う可能性がある為です。またプロジェクトコードを入れているのは、同時に複数のプロジェクトを行う場合の混乱を避けるため、などの理由です。

各ファイル共通の項目

　各仕様書項目のファイルには、一番初めに「履歴」というシートがあり、そこに更新履歴の表を入れています。
　詳細な記述ではありませんが、日付、更新内容、という記載をしています。
　これを入れる理由は、あの項目っていつ入れたんだっけ？というような時の確認の他に、複数人で開発する際に更新箇所の確認を行う手がかりとして用意しています。gitなどできちんと管理している場合は、もしかすると不要かも知れません。

項目のヒエラルキー

　NumbersもExcelと同じように複数のシートを持てますから、シートが「大項目」となります。
　Numbersでは一つのシートに複数の表を入れる事ができますので、一つの表が「中項目」に相当します。
　表の左の列に要素名を書き、右側に内容、その右にメモ書きを入れる”note”、一番右に”history”で、ここが更新履歴と対応したメモ書きになります。
　要素名が「小項目」に相当します。
　つまり、ひとつのファイルが「仕様項目」、シートが「大項目」表が「中項目」、要素名が「小項目」という４階層構造になります。
　蛇足ですが、この階層構造で仕様書を記述する方法は、テーカン時代に上司である上田和敏さんに教わりました。

箇条書き

　要素の内容は、場合によっては箇条書きにしています。
なになに
なになに
　という書き方です。
　できるだけ、一つの内容を簡潔に書くようにします。
　これは、可読性を高めるためです。後から見直す時や他のスタッフが読みやすいようにするために行っています。
　また、書いていく際に仕様が具体化する、という効果もあります。

表

　実際のデータなどが入るものは、表として記載します。
　大抵は別シートにします。
　類似するデータは一つのシートに、異なるものは別のシートにというように分けて記載します。
　また、状態と種類などの要素で表にできそうなものも表にします。
　このような場合、表にする事で目の届いていない箇所が炙り出される効果もあります。

サンプルの仕様書

　Numbersを使って、サンプルの仕様書を書いてみました。
　２Dのスマホゲームの主人公の操作の仕様です。
　内容はサンプルなので、実際のゲームを想定しているものではありません。

おわりに

　ざっとですが、仕様書に必要なコトを書いてみました。
　私なりのやり方の説明となっています。
　皆さんと方法とは違っている箇所もあるかも知れません。
　もし、利用しようと思われましたら、手法の流用に止まらず、何故そうしているか、についても思いを馳せて頂ければ幸いです。