デジタルゲームの仕様書の書き方

はじめに

あくまでも僕自身の考える方法として、仕様書を作成する初学者向けにザックリと仕様書の書き方というか仕様書を書くための考え方や大まかな手順をまとめてみた。
立ち上げディレクターを何回か経験するたびに仕様書の書き方を試行錯誤し、今に至る。テキストばかりで読みにくいかもしれないが、何かの足しになれば幸い。気が向いたら挿絵をいれるかもしれない。

心構え

仕様書作成者の心構えとして、自分はただ書面をまとめる人である。と言う意識で望むと良い。
企画書の段階で大枠の面白さは決まっている。それを最大限活かすのがプランナーの仕事。
自分は殺し、その仕様に求められていることを愚直に実現するための方法を関係各所とコンセンサスを取り、最終的に書面にまとめることが大事。
そうすれば、面白さは自ずと付いてくる。

ここで説明する仕様書の種類とまとめ方

ここでは、どのデジタルゲームにも必要な機能仕様と画面仕様について説明する。
こういった仕様書を機能毎(レベルアップ仕様、合成仕様…)に一緒に書く文化もあるが、画面にならない仕様もあったり複数の仕様が一つの画面にあったりと、一緒に書くとキレイに整理できない事が多いので、僕は仕様の種類毎（機能仕様、画面仕様、マスタデータ仕様、サウンド仕様…）にまとめている。

まず最初に機能仕様を書く。その後に画面仕様やマスターデータ仕様を書く。ゲームにもよるがサウンドやエフェクトなどの仕様はある程度全体像が見えてからまとめてリストをつくるのがよい。そのほうがサウンドやエフェクトをつくる人が作りやすい。プログラマ的にも仮データが揃ってからまとめて入れたほうが手戻りが少なくていいはず。

仕様書を書いてみると、画面仕様を書かずに機能仕様だけを考えるのは動きを想像しにくく難しいかもしれない。そんなの時はざっくりした画面仕様も作りながら書いても良い。後で分離すれば良い。
とはいいつつ、これを教えるのは結構大変なので、無理せず機能仕様と画面仕様を一緒に書いても良いかも。でも、分けてかけるようになると頭の中も整理されるのでオススメではある。
マスターデータの仕様とか、サウンドの仕様などの他の種類の仕様についてはここでは割愛する。

機能仕様の書き方

機能仕様は、それぞれの機能毎にまとめた仕様書。
項目ごとに目的と要件、概要を書き、その後に詳細を書く。小さな仕様であれば、概要だけですむこともある。
目的、要件、概要は上司(ディレクタや、リードプランナー)が書いてくれる事が多いが、なければ自分で書こう。

概要まで書いたら一度上司とプログラマ、アーティストなど関係者に相談する。やりたいことが伝わればいろんなアイデアをくれるだろう。
他の仕様との整合性や全体像が想像できれば良いがそこは上司が補完してくれるはず。

関係各所と話して方針が固まったら詳細を書く。
書いていると矛盾や疑問点が出てくるので、できれば自分が思う最良の仕様を考えて都度関係各所とすりあわせる。
この時、開発者に忖度すると良くない。ゲームにとってもっとも良いと思う仕様を考える。
無理そうなら関係者から提案が来るのでそのときに落とし所を考える。
この時、目的と要件がハッキリしてると話がしやすい。与えられたものでも、自分なりにしっかり咀嚼しておくこと。
他の仕様で吸収できることもあるので、他の仕様もできるだけあたまに入れておく。難しければ上司に頼る。関係各所とコンセンサスが取れたら一段落。
いざ実装してみると問題がでるので、都度対応策を考え、上司や関係者と相談し、都度決定事項を仕様書に反映する。

画面仕様書き方

画面仕様は、実際に画面に映し出されるUIの設計書。
まず、機能仕様を元に画面リストとフロー図をつくる。このとき完成度は80%ぐらいで良い。どうせ後で変わる。

次に画面リストを元に画面毎に表示するべき要素のリストと、その要素を自分なりに画面に配置した画像をつくる。レイアウトもある程度は考慮しよう。想定した要素を全部画面にいれることが難しいことがある。
それぞれの要素について画像内に番号をふり、番号毎に標示物、標示物にテキストが含まれるならそのテキストキー、動作を書く。
テキストキーは後で翻訳対応するときに別でテキストをまとめる場合に必要。動作は、何らかの要因で変化する要素を記述する(タップしたらなにが起こるかとか)。機能使用と合わせて考えて書く。コントローラ操作があるなら別途操作方法も書く。

画面仕様を書いていくと数々の矛盾と戦い、画面リストとフローと画面仕様を行ったり来たりしながら作ることになるだろう。大きな仕様になると頭がこんがらがるが根気よく焦らず丁寧に書いていこう。複数の機能が含まれる画面ならなおさらだ。紙に書いて整理したり、考え方を考えよう。混乱しそうなら早めに上司や関係者に助けを請おう。

画面仕様は、書く前にざっくりプログラマやUIアーティストと相談するとよい。
どんな画面にするかざっくり方針を固めておくと仕様が書きやすくなる。
詳細な画面仕様を書き始めると矛盾が出てくるが、できれば自分で解決して一度仕様を書ききった方が良い。もしくは、プログラマやUIアーティストを交えて仕様策定→書面に起こす。をめっちゃ繰り返すかどちらか。
前者のやり方でも何回かやりとりが発生すると思うが、後者よりはマシ。とはいえ、前者は難度が高いので無理せず。
機能仕様と同様に問題発生したら都度対応策を考え、都度仕様書に反映する。

最後に

このように、仕様書を書くには関係各所とのコミュニケーションが欠かせない。決定事項は些細な物でも仕様書にメモでも良いので残しておくこと。
決定に至った議事録やslackのスレがあればそれを貼るのも有効。何故それに決まったのか経緯はすぐに忘れてしまうので。でも、書きすぎると仕様書が読みにくくなるので塩梅を身に着けよう。

だがしかし、この記事は上司や関係者ができる人でかつ話がわかる人であることを前提で書いてある。現実はそうではないことがある。そこをどれだけ自分で補間できるかがあなたの腕の見せ所だ。

仕様書に完成はない。だが、今後変わるかもしれないことでも、今のところのベターな方法が決まっていて書面化されていることが大事。どっちつかずの状態が一番良くない。ダメな決定のほうが、決めないことより100倍良い。どうしても決められない場合もあるが、なにができたら決まるかを決めておこう。プログラマに「もう仕様変わりませんよね？」などと言われることがよくあるが、そんなこと自分でもわからないのでうまくお茶を濁そう。

仕様書に書くのは基本的に決定事項だけにしよう。
仕様書の作成途中にメモ書きを残すのは良いが、早めにコンセンサスをとり、決定して明文化しよう。

改善点や、仕様バグが見つかったらその都度相談し修正しよう。仕様書を保守するのは面倒だが、それだけのメリットはある。その後のデバッグにも役立つ。仕様書作成で最も大事なのは丁寧さと根気である。

どの仕様書もしっかりかけるようになるには熟練を要するので、端っこ仕様から少しずつ書かせてもらってなじんでいこう。