仕様書って、どう書いたらいいんだ……?【仕様書を書く前に】
今回は仕様書の書き方について。
この内容は、もはや就活用とかではなく、ゲーム業界入ったあとの段階の話だ。
とはいえ、実際にゲーム業界にはいってしまったら、仕様書というのは会社の書式とか、プロジェクトの書式があったりすると思うので、基本的にはそっちに合わせるべきことでもある。。
なので、ここまで書いて「このnoteは、書く意味あるんだろうか?」と、ちょっと思ってしまったが、ここまで来たからには書くぞ。
ぼかあ、有言実行と勢いの男なんすよ。
■仕様書とは?
仕様書。
今回においては「ゲーム開発の仕様書」ということになるけど、まずそれは何なのか? って大前提から話そう。
仕様書というのは、ゲームの設計書だ。
企画書段階では、ふんわりとした「こんな感じのゲーム」という内容だった。
仕様書では、それを具体的にどんな画面で、どんな機能で、どういう操作で――
ボタンを押したらどんなことが起こる?
効果音はどんなものが鳴る?
そういう細かいレベルで決めて、書いていくものになる。
大変そうだなって思うでしょ?
いや、実際大変なんだけどさ……。
出来るだけ多くの情報を正確にまとめようと思うと、とても時間がかかる。
しかし、残念ながら、仕様書を書くのにダラダラと時間をかけてはいられない。
なぜなら、仕様書が出来上がらないと、プログラマーもデザイナーも作り始めることができないからだ。
世の中の大きな会社では、
【先に仕様書を書くプランナーだけが稼働して、仕様書がまとまってからスタート】
なんてことをできる所もあるかもしれない。
でも中小開発会社ではそんなこと言ってられない。
クライアントから「この予算で、ここまで作ってくれ」と、発注があった所がスタートだ。
仕様書の完成が遅れても、締め切りが伸びるわけじゃない。
遅れたしわ寄せがどこに行くか?
それは、仕様書を見てから、作業をすることになるプログラマーやデザイナーだ。
とはいえ急いだ結果、仕様書の情報量が足りないとどうなるか?
プログラマーやデザイナーが作業をすることができなくなる。
どちらの場合においても、プログラマーやデザイナーの士気は下がる。
それは当然、開発するゲームのクオリティにも影響する。
なので仕様書作成というのは「完成速度と情報量のバランスが最も大事」というのが、僕の個人的な考えだ。
完成度8割でも、ゲームの全体像やおおよそのやりたい事や、機能の内容が書かれていれば、プログラマーやデザイナーの作業は開始できる。
出来る限り早期に……可能であればプロジェクト開始から3週間か1か月以内に、ここに到達しておきたい。
仕様書作成を複数のプランナーで分業するパターンもあるので、そういう時は仕様書の精度とスピードを上げることもできるだろう。
いずれにしても仕様書を書くプランナーは忘れてはいけない事がある。
「仕様書でつまずくと、チームがつまずく」ってこと……。
■仕様書はどのように作るのか?
ファミコン初期の仕様書は、A4用紙に手書きで書かれたりしていた。
しかし、令和の時代に、手書き仕様書というのは、なかなかお目にかからない。
さて、では何を使って仕様書を作るのか?
言っておくが、ここからはあれだ……。
宗教の話だ。
なぜなら、プランナーにはそれぞれに「仕様書は絶対これが書きやすい」というツールある。
ここについて、「絶対これ」とか言い出すと、そこから先は戦争じゃろうが! ということになる。
ちなみに僕は、マイクロソフト:エクセル派である。
いいね?
エクセルだ。
仕様書作成は、エクセルこそが至高。
広大な面積のある方眼紙であり、ゲームデータのシミュレーターにもなる。
シートを分けることで、ページを分けたり、ハイパーリンクでページ間の連結も用意。
エクセル以外を使う理由がどこにあろうというのか。
共有ができない? SVNかGITにアップしなさい。
同時編集がやりづらい? 作業分担ごとに仕様書のファイルを分けなさい。
パワポ? ワード? ページ制限がやりづらいんじゃ!
ワンノート? キャッシュがデカ過ぎ! あと表計算機能が使えん!
イラストレーター? 環境的汎用性が低いツール使うな! あと表計算が(ry
なんだ、おい? 戦争か? やろうってか?
……失礼。
つまり、僕の仕様書の説明は、エクセルを前提にして進めるってこと。
というわけで、次からいよいよ仕様書の書き方について、まとめていくぞ。
この記事が気に入ったらサポートをしてみませんか?