ゲーム制作でＧデザインをやっていますが、どうにも疑問に・・・＞の続きですが、（　http://www.hatena.ne.jp/1129173775　←参照して頂けると有難いです）　以下の2つの案の意見を求めます。　①「仕様書（もどき）を作る」　暫定的な仕様でもすべて記録し、変更された場合も、いつ、何回変更されたか一目瞭然な記録。　②「仕様、ゲームデザインに民主主義を取り入れる」　会議などで決定されたゲーム内容に関する事項を（うちでは、幹部かプロデューサー本人のみ行っている)、全スタッフにメール等で報告し、投げかける。興味のあるスタッフ（一部でも）から寄せられた反対、賛成の票を集め、もし9割など極端な反対の票が集まれば、それを以ってプロデューサーに掛け合う。（それでも曲げないのであれば、それはそれ相当の理由があるとして諦める）　また、スタッフの意見もディレクターが建設的にまとめ、掛け合う。（当然皆バラバラではあるが、聞くだけムダとは言い切れない）　次のプロジェクトで実際に実行しようと思っています。長くなりましたが以上です。

①「仕様書（もどき）を作る」

現状で仕様と呼べるようなものもなく、皆の頭の中にあるイメージで開発が進められているのですよね？そうでしたら、モドキでも作るとイメージの統一ができていいと思います。

②「仕様、ゲームデザインに民主主義を取り入れる」

これも皆が参加できるという意味でいいと思います。

前にいたところではアイデア専用などいくつかのメーリングリストを用意して、思いついた人が投げて開発に反映させるようなことをしていました。

．．．．どちらもいいと思います。しかしこれらをしても現在開発が進んでいるプロジェクトの進行が円滑になるかというと…あまりその効果はないと思います。

２番を取り入れると、多くの人から意見が集まるため、よりよいアイデアなどが生まれていいと思います。しかしよりよいアイデアが生まれるとなると、これまで以上にプロジェクトへの変更が増え、開発が滞る可能性が考えられます。

１番を取り入れると一目瞭然でわかりますが、作るだけでは”あぁ変更されたんだな”という記録にしかならない可能性もでてきます。作り方を間違えると、始めの部分の差分、さらに差分、そして差分、またまた差分…で、一目瞭然の状態から”いっぱい変更があるけど結局今はどうなっているの？！”という感じになり兼ねません。

このような流れは私が前にいたところでの仕様書っぽいものを作ろうとしていたときに辿った道でした。

現在開発が動いているものを円滑に進めるためには、開発完了まで絶対に変更しない！という仕様を少しずつ決めていくことだと私は思います。後になって”いいアイデアが出たから”なんて思い変更を許すと結局進むものも進まなくなってしまいますから。

http://www.hatena.ne.jp/ダミー:detail]

こんにちは。

また回答します。

これは自分の意見なのでURLはダミーで失礼します。

プロジェクト全体を通して大切なことは製作者全員の意識やイメージの一致だと思います。

以前、ぷよぷよやバロックを製作した米光一成さんとお話する機会があったので聞いたのですが

仕様書を作成しても誰も読まないので、製作の最初スタッフに

今回のイメージはどういう感じであると映画を何本かみせたそうです。

そういったことで作成中にデザイナーからも意見が出てきたり

半分丸投げの状態になったときも上手く言ったそうです。

これは私の経験談なのですが、以前ほとんど仕様書がない状況で仕事をしたことがありますが

その際たまたまディレクターと同じゲームをやっていて

ディレクターのいっていることがあまり指示が飛んでこなくてもなんなくわかったという経緯があります。

必要なのは相手がどう思っていてそれをいかに伝えるかということなので

そういう点では仕様書という文章もよりもイメージボードなどが分かりやすいのではないでしょうか。

だた、設定は状況によって変わってゆくので

どのように変更されたかという仕様書が書類としてキチンと残されているというのは分かりやすくて助かります。

それに、前の質問のコメントでおっしゃっていたカップルの痴話げんかのようなことは避けられますよね。

その仕様書が更新されたときにプロジェクトに関わる人全員に伝わらなければいけませんので

更新された情報を定期的に全員に発送するメーリングリストや会議が必要だとおもいます。

（以前、仕事で企画さんがグラフィックのモーション班にだけ情報を伝えて

プログラマーが何も知らないという現象が起きていました。

ここが更新されているよ、そんな話知らない！という責任の擦り付け合いが…）

そのためにも定期的な業務報告が必要になってくるのではないでしょうか。

②は潤滑にプロジェクトを進めるというよりはモチベーションアップに効果的だと思います。

一部の人にしか連絡されない＆自分の意見を言うことができないというのは

そのプロジェクトに参加する意欲がどんどん薄れていき、生産性の低下に繋がります。

アイデアがどんどん出て収集がつかないという危険性はありますけれど

「いつでも自分の意見が言える」という環境を作り出し、

プロジェクトに積極的に参加する意思を一人一人がもつことが大切なのではないでしょうか。

それにメーリングリストもよいと思いますが

週に一回のペースでミーティングをするとか（大人数だと無理かもしれませんが…）

直接話し合えるような雰囲気をつくるのもいいかなと思います。

（その場合は議事録をとるのが不可欠になりますが）

あと、下っぱの意見なんですけれども

変更や修正がかかる場合にその理由を明確にしてほしいと思います。

最終的には作業をすることになるのですが

やはり機械ではないのでこちらの気持ちを考慮して

「なぜこの作業が必要なのか」ということを納得させてもらいたいです。

こう考えるとどれもコミュニケーションなんですよね。

情報を潤滑に伝えるということを意識して

さらにそれを組織化することで状況は改善されると思います。

それに現状の悪いところを改善しようとしている動きが見えるだけで救いになると思います。

いろいろ試行錯誤をしてゆけば良いプロジェクト、

ひいては良いゲーム作りに繋がるのではないかと思います。

どうか頑張ってください。

ＵＲＬはダミーです。

長考してみたんですが、あまり建設的な意見が思い浮かびませんでした。

（自分の場合、最後の現場がとてつもなく劣悪な状況であった、というのがありますが。）

以下、そんな実体験を交えても愚痴やらなにやらです。

１．責任の所在を明確にしたがらない上司。

　正確には、とにかく自分が席に緒を負わないようにする上司、です。

　自分の思いつきを現場に伝える。大概は口頭で。現場が具体的な意見を求めると、現場の判断に任せる、と言う。そのくせ、現場が提出したデータには、ＯＫを出したがらない。なんかグダグダとしたまま期日が近づく。どちらも納得できないまま作業終了。

　こういう上司の場合、まずしっかりとした企画書は作りたがりません。現場サイドが作るのも嫌がります。たとえ現場サイドで企画書を作ったとしても、それを見たがりません。ましたや、それを認めるなんてあり得ません。なぜなら、それをするとなんらかの問題が発生したときに、自分の責任となってしまうからです。

２．民主主義方式の問題点。

　この場合、自分の意見が取り上げられなかったときに、かなり臍を曲げる人がいます。

　また、自分を巻き込まないでくれよ、という人や。

　スパイみたいな人もいたりします。

　そして、信じられないことですが、損得に関係なく、ただチーム内に疑心暗鬼をばらまくような人も存在します。

　ひとつのゲームを完成させる、という方向で共同作業をしているはずなのに、一致団結というのはなかなか難しかったりします。

　個人的には、１のすべての記録を残す、というのはいいことだと思います。

　これを認めてくれる、あるいは黙認してくれる上司なら、光明も見えるのではないでしょうか。

　逆に、反対したり、文句を言ったり、妨害したりする上司だと・・・

　まずは、チーム内の人たちとプライベートで個別に話をし、意識を確認してみるのがいいんじゃないでしょうか。

　後は、チーム内の人間関係も把握しておく必要があります。表層ではわからない、意外な好き嫌いもあったりします。

　ただ、自分が一番快適にゲームを作れていたときは、そういう悩みを抱えたことってないんですよね。それこそ阿吽の呼吸で意思の疎通ができたと・・・

　なによりも、そういう仲間がいるかどうかが重要かもしれませんね。