他社様案件だが、どうにも唸ってしまうことがあるので、ボヤボヤにぼかしつつちょっと書く。

　難儀な話で、日本のゲーム業界は、一度ガラケーソーシャルとかを経由した所為で、ゲームを簡単に作れると思っている人が居るようだ。
　自社で仕様を切って、社外デザイナーにリソースを発注し、開発会社にゲームを作らせる。みたいな案件があるという。
　一瞬どうにかなりそうな気もするし、規模によっては成功しない事もないと思うのだが。
　実際ソシャゲだとギリギリどうにかなったりもした。
　だが。
　最近のスマホ規模やら、かつてのコンシュマ規模ならば絶対それは成立しない。

　どうにかなったら神様に感謝しろ


　という話で。普通はどうにもならない。
　２０ガバス賭けてもいい。

　何故か。

　　　　　　　　　アイデア　　　　　　　　　　　　　　　　　　　プログラム
　　　　　　　　　大枠の企画　　　　　　　　　　　　　　　　　データ、結合
　　　　　　　　　↓　　　　　　　　　　　　　　　　　　　　　　　　　↓
企画を思いつく⇒⇒⇒→→→→→→→→→→→→→⇒⇒⇒ゲームが完成する
　　　　　　　　　　　　　　　　　　　　　　　↑
　　　　　　　　　　　　　　　　　この間にある、「→」の線、
　　　　　　　　　　　　　　　　　企画を仕様に落とし込み、
　　　　　　　　　　　　　　　　　　ゲーム性を調整し、
　　　　　　　　　　　　　　　　デバッグをするという工程の
　　　　　　　　　　　　　　　　果てしなさを理解していない。
　　　　　　　　　　　　　　　企画屋の仕事はこの「→」であって、
　　　　　　　　　　　　　　　　「⇒」だけではないのだ。
　　　　　　　　　　　　　　「→」をブラックボックスだと思ってる奴は
　　　　　　　　　　　ゲームを作った事があると本人が思っていても
　　　　　　　　　　　　　　　　実際に作ったのとは違う。

　例えとしては、「城を作ったのは城主だが城主に城は作れない」というアレだ。
　じゃあ「城主が大工に指示を出せばつくれるか？」というと、大工の気が利けば作れるが、普通は無理だ。
　設計者が必要なのだ。城主が「こういう城がいい」つったところで細部を決め込まねばちゃんとした城は出来ない。

「いやいや設計図かけるよ俺」

　って城主が居たとする。
　本当に書ける人も居るけどね。書けないけど書けると思ってる人も居る。

「攻撃が当たったら２０ダメージ」

　ぐらいしか書かなくて、イケると思ってる人ね。
　そう仕様書に書いてあったら、無反応にHPから２０減算して終わりだ。普通はそうなのだ。
　ちょっとまてよ、攻撃当たったらエフェクトだしてダメージモーションかましてHPゲージがスムーズに２０減って、０になったら死んでくれよ。とか言うならそこまで紙に書く必要がある。
　勿論言わなくてもやってくれる開発会社やプログラマも居るが、それはサービスだ。
　そこまでやって当然ではない。
　また、実は、ダメージモーションとか要らなくて死ぬ時だけでいい、みたいな事もある。FPSとかね。サービスしてくれた仕事を、そこはオミットしてくれって言うと次からは、サービスしなくなる。無駄仕事だからね。

　ほぼ出来たゲームみてごちゃごちゃ追加要望をコスト追加なしで言えばどれぐらい無駄仕事を生んでいるかは理解した方がいい。

　そういう無駄仕事を減らすために、とにかく仕様書はちゃんと書かなきゃいけない。
　だいたい仕様書ってのは紙の上である程度以上の矛盾をつぶせるし、書き出す事で脳内のゲームをある程度リアルに実感できる。自分が作るものをリアルに創造できなくてどーする。またリアルに伝えられなくてどーする。
　プログラムを直すのは滅茶苦茶手間だが、仕様書直すのはすぐできるんだから。
　適当に作らせといて「イメージと違う」とか言う奴は多分地獄に落ちていい。クモの糸はたらさぬ。

　だが仕様書を書いたらそれでいいかと言えば良い訳が無い。
　文字列から全てを理解できるわけが無い。文字列でゲームを表現しきれるわけも無い。だから企画浸透会議とかが必要だし、浮かんだ疑問を即共有、即回答するために、企画者は開発現場に必要だ。
　そもそもが、仕様書だけでゲームをどうこうする事は無理なので、さっきの例ならダメージやそれを受けた時の表現とかを外部データに吐き出せるように仕様を切っておいてあとで調整できるようにする、ってとこまで考えるべきだ。

　その上でそれが正解とも限らないので（正解はプログラマの数だけある）、

「こういう事がしたいので、こういう手法でやろうとおもったけど、何かオススメの手ある？」

　というのをPGに聞けば一番いい手にとっとと辿り着ける。
　もう一度書くが、最適解は相手によって違うのだ。プログラマもデザイナも人によって能力が違う。

　こういうのは企画と開発が机並べてないと調整出来ない（当たり前）。
　ブラウザソーシャルゲーム全盛期、「既存ゲームの類似品で全部の遷移を書けば何とかなる（場合が無きにしも非ず）」っていう世にも稀な状態がちょびっとだけあったのだが、コンシュマや最近のスマホゲーはそうは行かない。

　なんでこんな当たり前の事を書いてるのだろうと思う人が多いだろうが、オレもこれが当たり前だと思うんだが、開発をオフショアって、ゲームでもやれると思っちゃう人は居るのだ。
　もちろん全く出来ないわけじゃないんだけど、可能なジャンルと、やり方ってのがある。

　そういうのは知ってる奴は知ってるし、知らない奴は全く知らない。知らなくていいと思ってる。
　でもそれはブラックボックスにして良い場所じゃない。問題は全部ソコで発生してるんだから。

　プロジェクトを山に例えると、誰一人自力で山を登ったことがないくせに、関係者が俺だったら登れると思ってるような状況ってのがある。
　マグレで登れる場合もあるので、一概に全否定できない。
　だが基本的には一人ぐらい山登りできる奴を混ぜるべきだ。シェルパを頼め。　

　仕様書投げて納品日に希望に希望通りのプログラムがミミをそろえて納品されると思っている人が居るらしい。
　それは絶対無い。
　どうやってミミをそろえて納品されるように持ってくかというのが手練手管。
　だから開発とは連絡を蜜にしてやらないとダメに決まってる。仕様書から完全な完成品を汲み取るのは絶対無理だから。キャッチボールしながら落しどころを探らないといけない。
　作ってみたら予想外の障害があった、作ってみたらクソつまらなかった、そういう事態は日々発生する。納品日までボヘーと指を咥えてて良い訳が無い。
　開発現場に机置いて常に質疑応答しつつ、ちょっと画面見てヘンな方向に苦労してそうだったらインタラプトして仕様を見直す必要だって出る。

　それが出来ないような開発座組みはダメ。当たり前だ。ほんと当たり前だ。
　ゲームは普通に作ったらクソゲーになるんだから、せめて良作になるように出来うる手は全部打たなきゃイカン。

　もちろん何事にも例外があるし、既存ゲームのクローンや素材変更ぐらいのもの、移植、規模が小さい等なら、遠隔でも開発できる場合がある。どれぐらいまでのゲームなら遠隔開発が可能で、どっからはムリか等も経験から導き出せる。
　だから理解して、もしくは理解してる人に聞いて、座組みとそのまわし方を考えないとゲーム製作はハッピーエンドを迎えない。

　もう一度書くが。
　何でこんな当たり前のことを書いてるかというと、当たり前じゃなかったらしいから。

　この辺は常識化して欲しいと思っている。