仕様書って、どう書いたらいいんだ……？【仕様書を書く前に】

　今回は仕様書の書き方について。
　この内容は、もはや就活用とかではなく、ゲーム業界入ったあとの段階の話だ。

　とはいえ、実際にゲーム業界にはいってしまったら、仕様書というのは会社の書式とか、プロジェクトの書式があったりすると思うので、基本的にはそっちに合わせるべきことでもある。。

　なので、ここまで書いて「このnoteは、書く意味あるんだろうか？」と、ちょっと思ってしまったが、ここまで来たからには書くぞ。
　ぼかあ、有言実行と勢いの男なんすよ。

■仕様書とは？

　仕様書。
　今回においては「ゲーム開発の仕様書」ということになるけど、まずそれは何なのか？　って大前提から話そう。
　
　仕様書というのは、ゲームの設計書だ。
　企画書段階では、ふんわりとした「こんな感じのゲーム」という内容だった。
　仕様書では、それを具体的にどんな画面で、どんな機能で、どういう操作で――
　ボタンを押したらどんなことが起こる？
　効果音はどんなものが鳴る？

　そういう細かいレベルで決めて、書いていくものになる。

　大変そうだなって思うでしょ？

　いや、実際大変なんだけどさ……。

　出来るだけ多くの情報を正確にまとめようと思うと、とても時間がかかる。
　しかし、残念ながら、仕様書を書くのにダラダラと時間をかけてはいられない。
　なぜなら、仕様書が出来上がらないと、プログラマーもデザイナーも作り始めることができないからだ。

　世の中の大きな会社では、
　【先に仕様書を書くプランナーだけが稼働して、仕様書がまとまってからスタート】
　なんてことをできる所もあるかもしれない。

　でも中小開発会社ではそんなこと言ってられない。
　クライアントから「この予算で、ここまで作ってくれ」と、発注があった所がスタートだ。
　仕様書の完成が遅れても、締め切りが伸びるわけじゃない。

　遅れたしわ寄せがどこに行くか？
　それは、仕様書を見てから、作業をすることになるプログラマーやデザイナーだ。

　とはいえ急いだ結果、仕様書の情報量が足りないとどうなるか？
　プログラマーやデザイナーが作業をすることができなくなる。

　どちらの場合においても、プログラマーやデザイナーの士気は下がる。
　それは当然、開発するゲームのクオリティにも影響する。

　なので仕様書作成というのは「完成速度と情報量のバランスが最も大事」というのが、僕の個人的な考えだ。
　完成度８割でも、ゲームの全体像やおおよそのやりたい事や、機能の内容が書かれていれば、プログラマーやデザイナーの作業は開始できる。
　出来る限り早期に……可能であればプロジェクト開始から３週間か１か月以内に、ここに到達しておきたい。

　仕様書作成を複数のプランナーで分業するパターンもあるので、そういう時は仕様書の精度とスピードを上げることもできるだろう。

　いずれにしても仕様書を書くプランナーは忘れてはいけない事がある。

　「仕様書でつまずくと、チームがつまずく」ってこと……。

■仕様書はどのように作るのか？

　ファミコン初期の仕様書は、Ａ４用紙に手書きで書かれたりしていた。
　しかし、令和の時代に、手書き仕様書というのは、なかなかお目にかからない。

　さて、では何を使って仕様書を作るのか？

　言っておくが、ここからはあれだ……。
　宗教の話だ。

　なぜなら、プランナーにはそれぞれに「仕様書は絶対これが書きやすい」というツールある。
　ここについて、「絶対これ」とか言い出すと、そこから先は戦争じゃろうが！　ということになる。

　ちなみに僕は、マイクロソフト：エクセル派である。

　いいね？
　エクセルだ。

　仕様書作成は、エクセルこそが至高。
　広大な面積のある方眼紙であり、ゲームデータのシミュレーターにもなる。
　シートを分けることで、ページを分けたり、ハイパーリンクでページ間の連結も用意。

　エクセル以外を使う理由がどこにあろうというのか。
　共有ができない？　SVNかGITにアップしなさい。
　同時編集がやりづらい？　作業分担ごとに仕様書のファイルを分けなさい。

　パワポ？　ワード？　ページ制限がやりづらいんじゃ！
　ワンノート？　キャッシュがデカ過ぎ！　あと表計算機能が使えん！
　イラストレーター？　環境的汎用性が低いツール使うな！　あと表計算が（ry

　なんだ、おい？　戦争か？　やろうってか？

　……失礼。

　つまり、僕の仕様書の説明は、エクセルを前提にして進めるってこと。

　というわけで、次からいよいよ仕様書の書き方について、まとめていくぞ。