◆ 要求仕様と設計

　企画が通れば、いよいよ仕様の段階です。そしてこれ以降が、「ディレクター的な仕事」では真価の問われるところです。
　 企画段階が終わったところで、実際のゲーム開発の作業量ではとても半分などといえるものではなく、せいぜい最初の５～10％に過ぎません。上層部に認めてもらったゲームのプランがきちんと現実の製品になって登場できるかどうかは、ここから先のプロセスにかかっているのです。

仕様というのは、簡単にいえば「ソフトの設計図」です。どのようなものを作るのかを、詳細＆具体的に記述していくものです。なかなか実感がつかめないと思いますが、ここは一歩ずつ考えてみてください。
　 まず、完成像＝動いているゲームソフトをイメージしてみましょう。自分自身がプレイヤーとしてそのソフトに取り組んでいるところを想像するのです。
　 このとき、イメージの中心には、外観・制御・振る舞いの３要素があるはずです。
　 外観は、画面の見え方です。どこにどのような要素があり、ユーザーにどんなインフォメーションを与えるのか、さらにどう遷移していくのかというということです。
　 制御は、キーボードやマウスなど。どう動かすことで何が起きるのか、メニューがどうなっていてどう働くのかということです。
　 振る舞いは、プログラムの主な機能となります。ユーザーのアクションに対してどう応答するのかということです。
　 この３つの視点から、作ろうとしているゲームをしっかりイメージし、人に説明できるようにはっきりさせていきましょう。
　 さらに継続してプレイしている状態もイメージしてください。おもしろいゲームだと、プレイヤーは食事も睡眠もそっちのけで集中して取り組んだりするわけですが、そこでは何を観て何を感じているのでしょうか。突き詰めて考えれば、マップやステージの配置ということにもなりますし、マイキャラ（あるいはプレイヤー）がどう成長していくか＆どう成長させていくかのプランも含んだものになるでしょう。

こうして出てきた全体を、ソフトウェアとしてどういう形になるのかという視点でまとめます。その結果できあがる文書を、仕様書と呼びます。
　 仕様書では特定の書式を考える必要はなく、十分な内容がわかりやすく書かれていればOKです。逆に言えば、内容が不十分だったりわかりにくかったりしたら、どんなに立派な体裁でも不合格です。文章だけで書こうとしても、たいていは伝わりません。図や絵、数字・数式なども活用していくことになります。そして、相当な分量になってしまうため、全体の構成も使いやすいように工夫していく必要があります。

こうしてまとまった仕様は、正しくは「要求仕様」といいます。企画屋からプログラマに対して行う、要求（＝こういうソフトを作って欲しい）だからです。プロジェクト全体としては、その次に「どのような技術方法で実装するのか」という問題があり、この部分を「設計」といいます。また、この結果作られた文書を「実装仕様書」と言う場合があります。
　 ただ、ここは既にエンジニアたちの聖域です。メインプログラマが誇りと責任を持って取り組むべき課題で、ゲームデザイナーがちょっかいをかけていい場所ではありません。

要求仕様と設計の関係は、一応前者から後者へという流れになります。
　 ただ、実際には、逆転することもあります。要求が、技術的にできなかったり、あるいはもっと合理的な他のやり方で目的を達成できたり、あるいは技術的に可能なことがあってそれを組み込むことで要求にはなかったおもしろさが出せそうな場合など、プログラマの側からあれこれとボールが帰ってくることがあるのです。
　 そして、ゲームにおける仕様段階は物語性の部分や美術面なども含むため、グラフィッカーやシナリオライターなどとも、同じようなボールのやりとりをすることがあります。
　 そのため、仕様の決定は、適宜フィードバックループを描きながら、具体化していくことになります。