gametips

ゲーム作りに関するあれこれ

ゲーム作りにおいてのフラッシュアイデアの扱い方を考える

今回はゲーム作りにおいてフラッシュアイデアが湧いたときにどのように扱えばよいかを考える

フラッシュアイデア

その場で思いついた案のこと。ジャストアイデアとも言う。素晴らしい閃きのことを表すこともあるが今回はただ頭に思いついた案として扱う。

フラッシュアイデアが湧く時

自分達が開発しているゲームをプレイしているときやぼーっとしている時にフラッシュアイデアが湧くときがある。この部分をこうしたらもっと良くなるじゃないか、という具合である。パッと思いついたその案はとても良いものに見え、今すぐにでもデザイナーやエンジニアに仕様変更をお願いしたい気持ちである。

フラッシュアイデアが持つ危険性

フラッシュアイデアを思いついたその勢いに任せて採用しようとするのは危険である。なぜなら思いついたその案は基本的に使えないものであるからだ。アイデア出しをすればわかるが思いつきで並べたそれは9割以上使えないものだ。そのフラッシュアイデアも使えない可能性が高い。

また、フラッシュアイデアを採用する上で開発現場を混乱させるリスクがある。そのアイデアが現在の仕様に対しての変更である限り、改修を行うためのコストが発生する。プランナーがふと思いついたその仕様を適用するためにはデザイナー、エンジニア換算でその何十倍もの工数がかかることがあるのだ。

例えばコマンド選択式の戦闘があるゲームで、相手の行動を一回スキップするスキルがあったら良いと思ったとしよう。そうすれば強いボスに対して新しい戦い方の戦略が生まれると考えたからだ。

ではその改修にどのくらいの時間がかかるだろうか、これはプログラムの組み方によるが、仮に必ず全員が行動する前提でプログラムを組んでいた場合、それなりの工数が必要になるだろう。スキップの仕様を組み込んだ上で保守管理性を損なわないように改修するには戦闘システムそのものに対する大幅な変更が必要になるかもしれない、仮にパッチを当てるような形で改修ができたとしてもそれはツギハギの対応となり、今後の戦闘システムの改善工数や不具合の含有率に悪い影響を与えるだろう。もちろん戦闘システムの変更に対してテストコードを書き直したり、テスターの方々にテストをしてもらう工数もある。

デザインに関してもそうだ。プランナーがUIや3Dモデルに対してのちょっとした変更だと思っていても案外影響がある場所は多い。

フラッシュアイデアを思いついて伝えるときにそのアイデアに付随する影響ををあまり評価せずに作業者にまかせてしまう人はいるだろう。

フラッシュアイデアは悪か

フラッシュアイデアそのものを批判しているわけではない、ゲーム作りにおいてアイデア出しは必須であるし、ブレストなどではどんなくだらない思いつきでも場に出すことが推奨される。問題はそのアイデアを思いつきの勢いに任せて採用しようとすることだ。

フラッシュアイデアの扱い方

ではフラッシュアイデアはどのように扱ったら良いだろうか。まずその時の開発のフェーズを確認する。それがブレストなどのアイデア出しの段階であればどんどん出してしまおう。躊躇することはない。

しかし、それがある程度開発が進んで成果物ができてきた段階であれば一旦自分の中で留める。そしてお手洗いに行くなりご飯を食べて一旦心を落ち着かせてから再度確認する、なぜこのアイデアが良いのか、このアイデアはこのゲームがプレイヤーにしてほしい体験を適切に提供できるのか、チームのメンバーに差し込みで作業をお願いしても良いほどのアイデアなのか、などである。そうすると殆どのアイデアは落ちるだろう。

イデアがその確認をパスした時、もしくはどうしても判断がつかず周りの意見を聞いてみたいと思った時に、初めてチームに共有すると良いだろう。

イデアの伝え方

イデアの伝え方にも工夫が必要だ。

作業者が一番困るのは "このアイデアは良いと思いませんか?" とただ投げてくる場合である。これに答えるのはなかなか難しい、まずそのアイデアがどういう理由で良いのかがわからない。そして、そのアイデアの良し悪しを考えるのにも時間が必要だろう。さらに適当に "良いですね" と答えようものなら "じゃ、お願いします" といわれ、作業者の負担が増える、変更が軽いものなら良いが、重いものなら作業者に対する負荷になるとともに成果物にも影響がでるかもしれない。作業者の方で工数を算出するにも時間がかかるし、アイデアに対していきなり "これくらいの追加工数をいただきますが良いですか?" などと聞いたら角が立つかもしれない。ままならないものである。

そこでまず伝える側の工夫として以下の点を事前に考えておくとよいだろう

  • なぜこのアイデアを導入したいのか
  • このアイデアの重要度はどれくらいか(ある程度追加工数をとっても導入するべき、追加工数が比較的少ないのであれば導入したい、導入の前に一度みんなの意見を聞きたい)

この2つがわかるだけでも議論を進めやすいだろう。

もう一つ大事なことは工数追加や影響範囲に関して理解があるということを示しておく、ということだ。アイデアの共有の後に、このアイデアの採用にあたってどれだけの工数が必要で影響範囲がどれぐらいか、もしくはそれを調べるのにどの程度工数が必要なのかを聞いておくことが大事である(仮に追加工数を取りたくないと思っていても)。

これは作業者に対してのフォローになる、追加工数を取る準備ができているとわかっていればアイデアそのものを素直に評価できるようになるし、相手が自分のことを気にかけてくれているとわかっていれば、多少は工数内で頑張ってくれるかもしれない(返報性という)。

イデアの受け方

出てきたアイデアを受け取る方にも気をつける点はある。

まずわからないところを明らかにする。なぜそのアイデアが良いのかわからないときはアイデアの意図を聞き、そのアイデアの採用にあたっての追加工数が取れるかどうかがわからなければそれを聞くのである。

そして不明点をなくした上で自分の考えを伝えるのだ。そのときはアイデアそのものと作業の都合を分けて伝えるとよいだろう。"アイデアとその意図は良いと思いますが、その改修を行うためには8時間ほど時間が必要です"という塩梅である。

フラッシュアイデアに強いチームとは

イデアの伝え方として方針を考えてみたが、このような方針を使わずどんどんチームにアイデアを共有してもうまく回るチームもあるだろう。そのチームの特徴はお互いに信頼と尊重があるチームだ。そのようなチームだと発言はどんどんされるし、仮に未熟な状態でアイデアが上がってきてもそれぞれの視点からきちんと主張を行い、適切にアイデアを扱うことができるだろう。

まとめ

フラッシュアイデアを採用するためには考えるべきことが案外多い。

重要なのは以下の3つである

  • その時の気分に流されず一度アイデアを吟味する
  • チームに共有するときはきちんと説明する
  • 作業をお願いする相手の都合を鑑みる

せっかく思いついたアイデアだ、説明不足やメンバー同士の変な確執で棒に振らないようにしたい。