ゲーム開発の仕事の１つに「仕様作成」があります。

──そもそもコレ、何のために作るんでしょう。

組織の仕事って「やるからやる」とか
「資料作成のための資料作成」みたいなのが山ほどあるので、
それと同じに見られることもままあります。

ゲームの規模が大きくなければ、仕様書なくてもゲーム作ることはできます。
でも個人的には、仕様書はあったほうがいいと考えてます。
理由は３つです。

①実装前に全体を（それなりの粒度で）見渡すことができる

実装に掛かる時間、必要なスキルが予想できます。
作りながらだと、この部分が行き当たりばったりになりやすくて
結果壁にぶつかったときに手の打ちようがなくなったりします。

②自分以外の実装メンバーに、作るモノを伝えるコストが下がる

ゲームの内容を全部覚えて、
チームメンバーひとりひとりに口頭で説明するのは時間が掛かります。
仕様書という形になっていれば「読んどいて」で終わります。

③デバッグに必要

テストプレイで違和感があったとき
「普通こうならないよね、こうなるよね」では
終わらないことが増えてきました。
このゲームにおいてはこの動作が正常、仕様通り、というのを
書いておかないと、仕様作成者しかデバッグができなくなります。
（そもそも仕様書無しではデバッグ会社さんが受けてくれない……）

ただこれらって、
実際にそれなりの規模のゲームを作ってみないと
実感できないことでもあります。

作ってみて「調整」
（この言葉非常に危険だけども、それも作ってみないと実感できない）
すればいいんだ、と言われると
「まぁそうなんだけど（ごにょごにょ）」となりますし。

僕は相当ゲーム好きで、
作りたくて仕方ないほうだったので
「ゲームには仕様書が必要です！」って言われたら
「そうなんですね！じゃあ書き方学んできます！」
だったのだけども
そうじゃない向きもいるわけで。

そういうときにどう伝えるのか、というのが
学校や後輩に話していて感じることでもあります。

これって仕様に限らずで──

仕事のどのフェイズも同じで、

・その仕事が何のために存在するのか
・その仕事の前後にはどんな仕事が存在するのか
・どんなアウトプットが求められているのか

を伝えるほうがいい、と思うようになりました。
それがないと仕事が作業になって、
時間が無限に溶けていくと思うのです。
（仕様書って完成しないから）

……といういろんな大前提があって、
さて「仕様書の書き方」を話しましょう、になります。遠い。