エンジニアを揃えたのに、なぜゲーム開発は目標に届かないのか
初めてゲーム開発を依頼しようとするクライアントは、検討の際にとても自然な考えを持ちます。プログラムはエンジニアに、ビジュアルはアーティストに任せ、さらにプランナーに要件を整理してもらう。三人で分担すれば、ゲームはできあがるのでは？
エンジニアリングの論理で見れば問題はなさそうです。しかし私たちが長年案件を受けてきた中で、この方法で始めたものの、プロジェクトの途中で非常に多くの問題にぶつかり、長いあいだ停滞し、最終的にはプロジェクトを諦めるしかなかったケースを数多く見てきました。
全員が自分の仕事をしているのに、ゲームが完成しない
ゲーム開発は、一般的なソフトウェアプロジェクトとは少し違います。プログラム、アート、企画の三つの方向は、開発の過程で絶えずすり合わせる必要があります。アートのビジュアルスタイルはプログラムの技術的制約に合わなければならず、企画のゲームロジックはプログラムで実現できるものでなければならず、プログラムが作ったものはアートの設計意図を保たなければなりません。どれもコミュニケーションの問題に聞こえますが、GameNobilityの実務経験では、それだけでは到底済みません。
たとえば、アーティストが三人目のキャラクターまで描いたところで、一人目のキャラクターとスタイルの方向性が合っていないことに気づき、戻って描き直すことになります。プログラムの開発が半分まで進んだところで、企画書にロジックの抜けがあり、双方が同じ仕組みをまったく違う意味で理解していたことがわかり、改めて話し合うことになります。ここで問題が生じます。クライアントにとって初めてのゲーム開発なので、専門的なノウハウ、知識、技術が大きく不足しており、そのたびのやり取りが時間とコストの消耗になってしまうのです。
こうした状況を、私たちGameNobilityは何度も見てきました。最終的に私たちに引き継ぎを依頼してきたケースもあれば、もう続行できなくなったケースもあります。
専門的なノウハウを持つ人ほど、見落とされやすい
ゲーム開発の見積もりでは、クライアントは通常、なぜエンジニアに費用がかかるのか、なぜアーティストに費用がかかるのかを理解しやすいものです。こうした仕事にはプログラムコード、画像ファイル、アニメーションといった具体的な成果物があり、目で見て手で触れられます。
小規模なチームでは、実は全体の取りまとめがとても重要な役割で、たいていはプランナーが兼任します。もう少し大きな体制では、専任のプロデューサーやディレクターが担当します。呼び名が何であれ、この役割がしていることは同じです。プログラム、アート、企画の三つの方向が進む中でそれぞれ脱線しないようにし、衝突が起きたときに判断を下せる人がいて、取捨選択が必要なときに本当の優先順位をわかっている人がいる、ということです。
このノウハウこそ、ゲーム開発の中で最も数値化しにくく、初めての依頼の際に最も見落とされやすい部分です。
経験豊富なソフトウェア会社でさえ、ゲーム制作を過小評価することがある
この問題が初めてゲームを作るクライアントにだけ起きるのなら、まだ説明しやすいでしょう。
しかし私たちが見てきた限り、これは業界の背景、技術力、ソフトウェア開発の経験の有無とはあまり関係がありません。
GameNobilityは、自社に技術チームを持ち、社内にエンジニアやプロダクトマネージャーがいて、普段からソフトウェア開発をしている企業とも仕事をしてきましたが、そうした企業でもゲームプロジェクトを検討するときには、統合の複雑さを同じように過小評価します。開発がわかっていないからではなく、ゲーム開発の統合と一般的なソフトウェアプロジェクトの統合は、多くの点で考え方の論理が異なるからです。プレイヤー体験、フロー設計、アートとプログラムの相互依存といったものは、ほかの種類のプロジェクトでは必ずしも出会うものではありません。
ですから、ある業界の人が特にこの落とし穴にはまりやすい、とは言えません。ただ、これはとてもよくある現象で、たいていはプロジェクトに問題が起きてから、最初に何が欠けていたのかに気づくのです。
寄せ集めのチームが最後までやり切りにくい理由
寄せ集めのチームを選ぶ動機は、たいていコストを抑えたいからです。内装工事で一括請負業者を探したくなるのと同じで、それは十分に理解できます。個別に集めたエンジニア、アーティスト、プランナーは、一人ひとりの単価が統合型の制作会社より安いかもしれません。
問題はここにあります。統合に責任を持つ人がいないので、各自が自分の担当部分しか見られないのです。
プログラムは企画の仕様確定を待ち、企画はアートのビジュアル方針の確定を待ち、アートはプログラムの技術的制約の確定を待つ。このループは何周も回ることがあり、一周するたびにスケジュールは少しずつ後ろにずれ、コストも少しずつ膨らみます。かといって、寄せ集めのメンバーに各自で話し合ってもらい、その結果をクライアントに報告してもらうこともできません。結論が出ても実務経験による検証がないため、結局クライアントはうなずくしかないか、AIに実現できるかを尋ねるしかありません。しかしこの点でAIにわかるのは、全体の構成が論理的に成り立つかどうかであり、最終的にその方向性が本当に実行に移せるかを評価する専門家がいないのです。これは非常に重要なことです。
最終的な結果として、コストを抑えようとしたのに、かえって時間とお金がかかり、しかも望んだものができあがらないことがあります。プロジェクトの進行にとって、これは非常に頭の痛い問題です。
統合力のあるチームに任せると、実際に何が変わるのか
ここまでリスクばかり述べてきたので、もう一方の側面もはっきりお伝えします。
統合を本当に担う人がいると、開発の進み方はまったく違うものになります。
要件はプロジェクト開始前に一つずつ確認され、プログラム、アート、企画が同じ事柄を同じように理解しているので、開発の途中でそれぞれの認識が違っていたと気づくことはありません。技術的な制約や予算のプレッシャーにぶつかっても、すぐに判断できる人がいます。どの機能を簡略化できるか、どの工程は省けないか、今の条件の中で目標に最も近い結果をどう出すか、です。
リリース前のQAは形だけのものではありません。異なる端末、異なるネットワーク環境、異なる利用シーンを本当に見守る人がいて、プレイヤーが目にする前に問題を解決します。
最後に納品されるものは、単に「機能がそろっている」だけではなく、遊んでいてリズムがあり、手応えがあり、続けたいと思わせるものです。この差こそ、フロー設計が真剣に扱われたかどうかの差です。
私たちが手がけた案件では、ゲームのリリース後に、プレイヤーから自発的に「このゲームは思っていたより面白い」という声がクライアントに届いたことがあります。ありふれた一言に聞こえますが、マーケティングゲームでこの言葉を引き出せるということは、体験設計全体が成立している証拠です。
あなたのプロジェクトに何が足りないか知りたいですか？GameNobilityが評価します少し高い費用を払って買うのは、技術的な実行だけではありません。最初から最後までこのプロジェクトに責任を持つ人であり、そこには対応が必要だとあなたが気づいていなかった事柄も含まれます。
FAQ
Q1：統合力とは具体的に何を指しますか？
簡単に言えば、プログラム、アート、企画の三つの方向を同じプロジェクトの中で揃えられる力です。開発前に要件をどの方向の人も同じように理解できるまで明確にすること、開発中に衝突をどう解決するかを判断できる人がいること、テスト段階で問題がどの工程にあるかを見極められる人がいることが含まれます。この力は経歴書からは見えにくく、たいていは十分な数の案件をこなしてきた人だけが持っています。
Q2：寄せ集めのチームと統合型の制作会社、どちらが自分に合うかはどう判断すればいいですか？
この質問に絶対的な答えはなく、プロジェクトの規模と複雑さによります。機能が単純で仕様が明確な小規模ゲームを作るなら、寄せ集めのチームでもできる可能性はあります。しかし、プロジェクトが複数のシステムにまたがり、複数の開発方向を同時に進める必要があるなら、統合力が非常に重要になります。決める前に、もし途中で問題が起きたら、どこに問題があるかを自分で判断できるかを考えてみてください。
Q3：制作会社に本当の統合力があるかどうかは、どう確かめればいいですか？
提案の段階で、「過去にプログラムとアートの方向性が衝突したことはありますか？そのときどう対処しましたか？」と聞いてみてください。実際の経験があるチームなら、たいてい具体的な状況と判断の過程を説明できます。説明できないからといって経験がないとは限りませんが、もう少し確認する価値はあります。
Q4：初めてゲーム開発を依頼するとき、最も問題が起きやすいのはどの段階ですか？
私たちの経験では、最も問題が起きやすいのは開発の中盤です。要件は確定し、開発も始まっているものの、まだテストできる段階には達していない時期です。このときに方向のずれに気づくと、調整するコストはプロジェクト開始前よりずっと高くなっていますが、多くの問題はまだ、立ち止まって話し合う必要があると気づくほど目立っていません。この段階では誰かが継続的にチェックする必要があり、問題が大きくなるまで待っていてはいけません。
Q5：予算が限られている場合、統合は省けますか？
この質問には、私たちはたいてい逆に問い返します。開発の途中で問題が起きたとき、やり直すコストを受け入れられますか？統合の費用は省けても、統合の作業は誰かがやらなければなりません。専任の担当者がいなければ、たいていクライアント自身にのしかかります。異なる実行側の間を行き来して確認し、調整し、決定を下すことに時間を使うことになります。その時間のコストは、最初に節約した費用より高くつくことがよくあります。
