建前上、仕様書とは、どんな人間が読んでも同じものが出来上がる設計図だ。あー、知ってる知ってる。しかしながら実際に求められるのは、担当プログラマが知りたい情報だけ書かれた書類だ。
俺の考える良い仕様書とは、俺たちデザイナが作ってもらいたい内容と、プログラマが必要とする情報の最小公約数を記述したものだ。
作りたい内容をあますところなく記述できるわけない。記述したところで、そのうち、プログラマにとって重要な内容はいったいどれほどかわからない。つーか、プログラマによって同じ仕様でも、知りたい内容が違ったりする。
パラメータについて数値をひたすら記述しても、簡単に調節できるからそれほど重要じゃないかもしれない。実装について現実的な提案をしたつもりでも、プログラマにとってはすんげえ面倒臭くて、最初にこりゃダメだと諦めてた仕様のほうがベターだったりすることもある。
で、そんな最小公約数の書類をどうやって作るか。俺の場合は、「仕様の必然性*1」と「最終的に実現したいデザイン」を明確にした叩き台をもとに、プログラマ・アーティストと打ち合わせを行い、不明な点、はっきり数値化して欲しい点など、知りたい情報をインタビューする。その上で、それらを明記した仕様書を作る。
よくある話で（よくあっちゃ駄目だけど）、たとえ叩き台の仕様が破綻していても、その仕様が必要とされる理由が明白であれば、指摘されてすぐに修正することが可能だし、その場で代案を示すこともできる。それどころか、「そうしたいなら、こんなこともできるけど？」と仕様を発展させたアイデアをプログラマからもらえることすらある。
いかにも、ダメ企画っぽいが、仕様書とはそうやって作るのが一番早くてロスが少ないし、そうするしかないと俺は思っている*2。
というわけで、デザイナだからと気張って意地張って結局無駄になる「完璧な仕様」を考えがちな青春時代もいいけれど、とっととミーティングして相手の欲しい書類を作りましょうという話でした。
*1：前項(id:IDA-10:20060411#1)ではメタデザインと呼称
*2：もちろん、頭でシミュレートして書いた仕様書がパーフェクトというスーパーデザイナもいることはいるけど俺はムリ
