開発現場ごとに、風土がある。
目標や計画の立て方、仕事の分担のし方、指示の出し方、そういった物事が、
現場の辿ってきた歴史に基づき、築かれている。

ドキュメントの扱い方もそう。
金融系やお役所関係の業務を扱う現場ならば、仕様書や設計書の書き方に
厳しいルールを定め、正確な内容を記載する事に努められている。

片やゲーム開発の現場ならば、作成されるドキュメントの量やルールは大幅に減る。
仕様書は、プランナーが自身のアイデアをプログラマーに伝えるために描いた簡易図と、
幾つかの箇条書きで構成されたペラ紙一枚という事が多々ある。
あとはプランナーとプログラマーで意識のすり合わせをしてからプログラムの製造が
始まる。

どちらの風土も間違っているわけではない。
ドキュメントが整っていれば、技術者はそれを見ることで保守作業を効率良く
実施することが出来る。

機能追加の際には、過去のドキュメントを元に規模感を把握して、見積もりを
立てることもできる。

ゲーム開発では、ドキュメントの作成数が少ない代わりに、
プログラムのビルド＆スクラップを多く繰り返す。
出来るだけ早くプランナーの頭の中身をプログラマーが形あるものにし、
作り上げたゲームのプロトタイプを元にアイデアが練られる。

どうすればよりゲームを面白くできるか？
操作をしていて不便を感じるところは無いか。爽快感のある操作にするには？
よりプレイヤーの心をひきつける演出方法は？

改善すべき点は即ゲームに盛り込む。
作り直した物を元に再びアイデアが練ってブラッシュアップ。
繰り返していく結果として、初めにプランナーが作成した仕様書と、出来上がった物が
かけ離れていることが多々ある。
ドキュメントの正しさよりも、遊びの楽しさが重視するというスタイルで突き進めていく。

このように、開発現場毎に風土が全く異なっている。
現場に入った時はまず、現場のルールや作法を確認しなくてはならない。

その現場に入るまでは当たり前だと思っていた観点とは正反対に扱われる物がある。
そういう事を心に留めておいて損は無いかと思います。

しん