プロジェクトはどのような理由で頓挫してしまうのでしょうか？

成功はよく似ているが、失敗はそれぞれ異なる。

ゲームの成功には、一連の必要条件に加え、少しの運も必要ですが、たった一つの落とし穴に足を踏み入れてしまえば、取り返しのつかない事態に陥る可能性があります。私たちは、一見華やかに見えるゲームが消え去っていくのを何度も目にしてきましたし、魅力的な要素を持ちながらも、うっかり深淵へと転落してしまったプロジェクトを見て、残念に思うこともありました。

あるプロデューサーが、プロジェクトを進める際の「薄氷を踏むような」緊張感について私に語ってくれたことがある。一定規模以上のゲーム制作は複雑なプロジェクトであり、その道のりには常に予期せぬ落とし穴が待ち受けているのだ。

確かに、多くの人は他人の経験から真に教訓を学ぶことは難しく、自ら失敗を経験して初めて、実際の体験を通じて学びを積み重ねることができる。しかし、他人が経験した失敗を多く見ることには、多かれ少なかれ、何らかの戒めとなる効果がある。

今回の「遊茶円卓会議」では、業界関係者たちと「プロジェクトはどのような理由で頓挫するのか？」というテーマについて語り合いました。

▍漕河涇の放浪者 大西王

私が経験したプロジェクトが頓挫した原因は、結局のところただ一つ――「独りよがりの開発」だった。

社長からプロデューサー、そして中間管理職に至るまで、全員が奇妙なほど傲慢で、外部からの経験は一切受け入れず、あらゆる意見や提案を避け、自分の考え通りに進めることしか考えていない。検証など必要なく、フィードバックも重要ではない。開発さえ完了すれば、すべてうまくいくと信じているのだ。

プロジェクトの開発過程では、小規模なプレイヤー体験会やインタビューもいくつか実施されたが、プレイヤーからのフィードバックアンケートは形だけのものだった。インタビューでは、プロデューサーが一人ひとりに直接反論するものの、その後はすぐに開発の世界へと戻り、プレイヤー市場の事情など全く理解していないようだった。

このような「閉ざされた環境での開発」をいつまでも続けることはできない。プレイヤーによるテストの規模がますます大きくなり、データの悪さがもはや見ないふりをすることさえできなくなった時点で、傲慢さはパニックへと変わり、必死になってプロジェクトの方向性を狂ったように調整して自救を図ろうとするが、最終的には積もり積もった問題とひどいデータのために、完全に破綻してしまう。

▍昨日、ゲーム業界を離れたミゲル

実のところ、ソロプロジェクトが頓挫する過程は、ごくありふれたものだ。まるでゆっくりと溺れていくように、一つひとつの問題は息を止めて乗り切れるように思えるが、最終的にはすべての問題が一度に押し寄せてくるのだ。

根本的な原因は、やはり私たちのアイデアと現実との乖離にあると私は考えています。何度かテストを行ったものの、プレイヤーからの反応は芳しくありませんでした。当時は頑固すぎて、プレイヤーにはそれを理解する忍耐力がないと思い込み、一からやり直すことをためらってしまいました。

そして、悪循環に陥ってしまうのです。外注の仕事を受けて生活費を稼ぐ → プロジェクトが停滞する → お金が尽きて、さらに外注の仕事を受ける。時には、外注の仕事ばかりに追われて、自分のプロジェクトには手も付けないことさえあります。ある意味、見ないふりをしているのかもしれません。

ある日、午前3時までエフェクトの修正をしていたところ、ふと「私たちは前進しているのではなく、ただその場で手直しをしているだけだ」と気づいた。その時点で、プロジェクトがすでに頓挫していることを認める方が、無理に続けようとするよりもむしろ気が楽だった。

▍3Aでプレーしたベテラン選手 XX

ほとんどのゲームは企画が立ち上がった翌日にはすでに死んでいるが、1年半、あるいはそれ以上経ってからようやく葬られることになる。

▍堅実な勝利を目指すカセットテープ

否定できないのは、購入型ゲームの大部分はライフサイクルが短く、リリース後1ヶ月、あるいはそれより短い期間でプロジェクトのROIを予測できるという点だ。つまり、購入型ゲームにおけるその後の運営への投資は、通常、GaaSよりもはるかに少なくて済むということである。したがって、購入型ゲームプロジェクトの「死」とは、一般的に開発段階で頓挫することを指す。

パブリッシャーや投資家の立場から言えば、プロジェクトへの投資を打ち切り、開発チームへの「資金供給」を停止することになります。では、どのような原因が信頼を完全に失わせ、プロジェクトの終焉を招くのでしょうか？

私の経験はインディーズゲームプロジェクトに限られていますが、提携やプロジェクトへの投資を決定する際には、多角的なリスク評価が必要です。具体的には、プレイ可能で将来性のあるデモ版、明確な市場ポジショニングと独自性、今後の開発計画や構想、そして「一見」信頼できそうなチームといった要素が挙げられます。

ゲームプロジェクトの将来性を評価することは、提携の前提となります。それ以外に、最も予測が難しいのはチームの安定性だと思います。インディーズゲームの開発は通常、個人や小規模なスタジオによって行われており、中核メンバーには成功したプロジェクトの経験や、成熟した確かな技術力を持つ者がほとんどいません。接触段階では、彼らのコミュニケーション能力や協調性、明確なプロジェクト計画、そして「規律ある情熱」を持っているかどうかを、限られた範囲でしか把握できませんが、それだけでは到底不十分です。

人的側面：中核人材の流出とチームの増員；人員規模とプロジェクトの野心とのバランス；技術力や人員不足に起因する開発効率の問題。

プロジェクト管理の観点：新しいアイデアや機能が次々と追加され、プロジェクトの範囲が拡大した結果、完了できなくなったり、当初のコアゲームプレイから逸脱したりすることになった。また、チームの能力不足による技術的負債の蓄積や、バグの頻発により、開発効率が指数関数的に低下した。

「つまらない」けれど完成されたゲームは、「面白い」けれど未完成のゲームよりも悪いと言われる。なぜなら、前者は少なくとも売れるからだ。

しかし、ゲームのアイデアの取捨選択や開発期間の長期化といった問題を乗り越えてプロジェクトがようやく実現したとしても、我々は最後の難関、すなわちゲーム市場のトレンドの変化に直面することになる。「例えば、その時点ではアクション系ローグライクが流行していたとしても、その後、AAA級のアクションゲームに人気を奪われ、その熱気が完全に冷めてしまう」といった具合だ。そのため、プロジェクトが危機に陥った際、投資家はプロジェクトの健全性評価を通じて、協力を継続するか、あるいは早期に損失を最小限に抑えるかを決定することが多く、これが買切り制のゲームプロジェクトの存亡を左右することになる。

上記のような様々な理由により、現在のインディーズ開発スタジオは、ゲームの開発進捗が70％以上に達して初めて、正式にパブリッシング提携を検討できるようになっています。さらに、ゲームのコアとなるゲームプレイの独創性が際立っていなければならないため、必然的にゲームの開発完成度には限界が生じることになり、これは国内のインディーズゲーム開発環境における悪循環とも言えるでしょう。

しかし、私は依然として楽観的な姿勢を崩していません。あらゆる問題は時間とともに解決できるものであり、より多くの有能な人材が現れたり、開発とパブリッシングが互いに高め合うような偶然の出会いが生まれたりして、徐々に中国の3iゲーム市場が築き上げられていくと信じています。

▍ある業界関係者 lll

製品がなぜ失敗するのかを論じる前に、まず、製品がなぜ生まれるのかについて議論する必要があります。

各製品のライフサイクルは、実は市場に登場したその瞬間からすでに決まっているものであり、そのライフサイクルを決定づける根本的な要素は、製品自体の品質である。

研究開発や運営の過程における、マーケティング、世論、インシデント、最適化といった要素は、実際にはすべて製品そのものを反映したものに過ぎません。本質的に、製品の衰退原因の90％は、その品質と密接に関連しています。

その根本的な原因は、各社におけるプロジェクト立ち上げの当初の意図にあると私は考えています。成功したプロジェクトであれ、失敗したプロジェクトであれ、それは変わりません。

私は、メインプランナーやプロデューサーの「好み」や「理想」だけを頼りに開発を進め、途中で自社製品がニッチすぎる、あるいは汎用性に欠ける（あるいは商業的な魅力が不足している）ことに気づき、その後ユーザーに迎合して調整を重ねた結果、最終的には「何とも言い難いもの」になってしまった例を数多く見てきました。

多くのチームが、上述のような理由から、時代や自社の技術、ユーザーのニーズにそぐわない、不自然な製品を作り出しています。その中には、卓越した品質と実力によって成功を収めるごく一部の製品もありますが、実際には、その大部分は失敗に終わっています。

つまり、あるプロジェクトがなぜ失敗するのかという点について、最も重要なのはそのプロジェクトの出発点が何であるかだと私は考えます。出発点こそが、プロジェクトの寿命や姿形を決定づけるのです。ある製品については、ドラマによくある台詞を借りて言えば、「この子はそもそも生まれてくるべきではなかった」と言えるでしょう。

▍マイルストーンの亡者 -D

プロジェクトは、無制限の残業によるラストスパートのせいで潰れてしまう（間違いない）――今まさに残業に追われている悲惨なプランナーより。

もちろん、これは冗談ですが、残業の有無やプロジェクト環境の良し悪し、さらには収益性が予想通りかどうか……といったことは、基本的にプロジェクトが頓挫するかどうかを決定づける決定的な要因とは言い難いでしょう。

プロジェクトを本当に頓挫させる直接的な原因はただ一つだけだ。それは、経営者や投資家自身が継続を望まなくなった場合である。隣のプロジェクトはリリースから1年が経ち、プレイヤーは減り続け、ほぼ常に赤字運営が続いており、開発スタッフも次々と辞めていった。しかし、経営者が「このジャンルにはまともな製品が一つは必要だ」と考えていたため、プロジェクトは頑強に持ちこたえてきた――もちろん、多くの場合、経営者の決定がもたらすのはプロジェクト解散という悪い知らせである。

リリース済みのプロジェクトには明確な「死の兆候」（収益がサーバーコストを下回る）があるものの、開発中のプロジェクトがリリースされるかどうか、あるいはどれほど長く持ちこたえられるかは、開発メンバーにとってほとんど予測不可能な問題であることが多い。つい数日前までは順風満帆で、福利厚生も充実し、皆で笑いながらチームビルディングを楽しんでいたかと思えば、週末を過ぎた途端にプロジェクトが突然消滅してしまうこともある。

あるいは、プロジェクト内部では不安が広がり、スケジュール目標は永遠に達成できず、誰もが品質に問題があると感じて改善を求めているものの、プロジェクトには常に新たな課題が生じ、新たなコストが投じられ、リリース日は遥か先のように思えるにもかかわらず、長年にわたる開発は依然として続いているのかもしれない。

以前、業界の知人がこう言っていた。「残業は生産目標を達成するためではなく、上司の不安を和らげるためだ」と。時には、残業を続けているうちに、本当に迷ってしまうこともある。長い開発期間の中で絶え間なく「ラストスパート」を繰り返しているのは、果たしてプロジェクトを完成させてリリースするためなのか、それとも単に上司の不安を和らげ、プロジェクトがまだ未知の「夜明け」の前に頓挫しないようにするためなのか？

▍トップ2社のプロデューサーによるプロジェクト中止ガイド

会議から予算まで、ゲーム開発を頓挫させる落とし穴：

会議室での空論、過剰な予算、方向性を失ったチーム――これらが、一つまた一つとゲームプロジェクトを静かに葬り去っている。「私たちは常に成功の教訓を総括するばかりで、失敗の経験を振り返ることはめったにない。傷口に塩を塗るようなものだからだ」とある業界関係者は、プロジェクトの失敗から得た教訓を総括する中でこう記している。ゲーム業界の華やかな成功物語の裏側には、さらに多くの、人知れず失敗に終わったプロジェクトがある。これらの失敗は偶然ではなく、会議、予算、勇気、そして重点の把握に至るまでの、体系的な崩壊によるものである。

会議は本来、問題を解決するための場であるはずですが、しばしばプロジェクトが頓挫する最初の現場となってしまいます。効果的な会議には、明確な目標の設定、実行可能な方法の決定、具体的な実行経路の策定という3つの重要なステップが必要です。多くのプロジェクト責任者はこの基本原則を軽視し、「話すことそのもの」に没頭して自己満足に陥っている。メインプランナーはただ話すために話し、チームリーダーは「ゲームにストーリーが必要か」といった抽象的な問題について議論を主導し、さらには専門的な問題を挙手による投票で解決しようとする。明確な議題や意思決定メカニズムを欠いたこのような会議は、チームの方向性の曖昧さや効率の低下を直接招く。チームメンバーが会議の結論について理解を一致させられず、それぞれが異なる方向に向かって努力し始めた時点で、プロジェクトはすでに破綻への道を歩み始めている。曖昧な目標は、チームメンバーを重複作業や方向性のずれという泥沼に陥らせ、貴重な開発リソースを浪費させる。

直感に反して、予算が過剰な場合、かえってプロジェクトの頓挫を早めてしまうことがあります。100万～300万の予算を持つ小規模なチームは、多くの場合、目標が明確で、業務負荷が均等であり、効率的に業務を遂行します。しかし、予算が2000万に膨れ上がり、チーム規模が拡大すると、「ある人は死ぬほど忙しく、ある人は死ぬほど暇」というリソース配分の不均衡が生じがちです。この不均衡は効率の低下を招くだけでなく、チーム内の対立も引き起こす。リソース配分が不適切になると、重要なタスクはリソース不足により延期される一方で、重要でないタスクに過剰なリソースが割かれてしまうことがある。混乱の中で、チーム内のコミュニケーションコストは急上昇し、問題を共に解決する姿勢の代わりに、内部での責任のなすり合いや言い争いが横行するようになる。

プロジェクトのテスト結果が芳しくなかったり、商用化の成果が予想を下回ったりした場合、チームは「安易に諦める」か「最後まで粘り通す」という二つの極端な対応に陥りがちです。多くのチームは、核心的な問題に深く切り込む勇気を欠いており、プロジェクトの根本的な欠陥と向き合うよりも、表面的な修正に終始してしまうのです。成功する調整には、チームに「生まれ変わる勇気」と「再構築するための忍耐力と細やかさ」が求められる。ゲームが期待通りの成果を上げられない場合、チームはゲームの内部に深く入り込み、すべてのフレームワーク、機能、関連性、数値、および相互作用の関係を整理すべきである。

修正作業において、よくある間違いは、すべての問題を同時に解決しようとしてしまうことです。「機能の追加」「コンテンツの補完」「最適化」をすべて一度にやろうとするのです。このようにあらゆる面を網羅しようとするアプローチは、往々にして逆効果となります。修正の重点には明確な優先順位を設けるべきです。最優先の課題は、プレイヤーのコアとなるフロー体験とポジティブなフィードバックを最適化し、プレイヤーを引き留めることです。その後に、体験に基づいて機能を開発し、遊び方を追加していきます。課金設計は、良好な定着率を基盤として構築されるべきです。

上記の中核的な問題に加え、ゲームプロジェクトには他にもさまざまな「失敗パターン」が存在します。例えば、技術的な欠陥はゲーム運営における「隠れたキラー」であり、リアルタイムのインタラクションに依存するゲームにとって、技術の安定性は極めて重要です。また、盲目的に流行を追うことや、イノベーションの欠如も同様に致命的です。権限の混乱、不合理な業務プロセス、そしてチームによるプロジェクトへの帰属意識の欠如も、プロジェクトが頓挫するよくある原因です。チームメンバーが「自分たち自身が、自分たちが手掛けているようなゲームをプレイしたくない」と感じてしまった時点で、そのプロジェクトはすでに魂を失っているのです。

ゲームは決して、企画、プログラミング、グラフィックが機械的に組み合わされたものではなく、生身の人間によって作り上げられる有機的な存在です。多くの管理者は、思いつきで決断を下したり、業界の重鎮の記事をを読んだり、業界関係者の大言壮語に耳を傾けたりするだけでチャンスを見出し、その後、企画書通りに「施工」すればゲーム開発は完了すると考えています。このような考え方の誤りは、「レシピを見れば自分は名シェフであり、豪華な料理を作れる」と錯覚するのと同じだ。ゲーム開発における「少々」「適量」「適宜」をどのように把握すべきか？火加減をどうコントロールすべきか？これらにはすべて経験と直感が必要となる。

最後にこれについては、言ってもいいのかどうか分かりませんが、私の見るところ、多くの企業の意思決定者は、情報過多のために、真に価値を生み出す「戦場」（つまりゲームそのもの）との間で、深刻な認識の乖離が生じているように思われます。

意思決定者は毎日、膨大な量の業界動向、市場データ、同業他社の見解、そして個人メディアによる分析に触れています。これらの情報自体は価値のあるものですが、危険なのは、それらが抽象的で「理想化された」仮想市場を容易に構築し、意思決定者をその抽象的なレベルでの「戦略シミュレーション」に没頭させてしまう点にあります。彼らが語るのは「二次元分野」「パーティーゲームのトレンド」「ユーザー獲得モデル」といったものだが、こうしたマクロな概念のすべては、最終的には具体的で楽しいゲーム製品を通じて具現化されなければならないという事実を見落としている。意思決定の根拠が、自社製品と密接に結びついた深い体験ではなく、主に外部の分析レポートや断片的な報告に依拠している場合、そのような意思決定は砂の上に建物を建てるようなものです。

「プロセスを最初から最後まで実際に体験してみる」ことこそが、まさにこうした認識のバブルを打ち破る最も効果的な方法である。一般プレイヤーとして、ダウンロード、チュートリアル、コアループから課金ポイントに至るまでの全プロセスを一度も体験したことのない経営者は、プレイヤーがどの段階で長いロード時間に苛立ち、どのクエストの節目で不合理な設計に足止めされ、またどの課金ポイントの手前で価値を感じられずにきっぱりと離れてしまうのか、到底理解できない。彼らが下す修正指示は、往々にして「私の感覚では」「データによると」「他社が成功した」といった抽象的な概念に基づいており、「私がその場面をプレイした時、確かに不快に感じた」という実際の体験に基づくものではない。その結果、製品の細部を熟知している実行チームと、マクロな情報の中で判断を下す意思決定層との間に、巨大な認識の隔たりが生じ、修正指示は当然ながら的を外した、あるいは全く逆効果なものとなってしまいます。

では、対処法はあるのでしょうか。ありますよ、皆さん。それは、意思決定者の注意を「天にも届くほどの富」という幻想や、膨大で雑多な情報の海から、ゲームの最も本質的な「第一原理」――「楽しいか？」――へと無理やり引き戻すことです。そのためには、意思決定者が自社の製品に対して最も厳しい、そして最も忠実なプレイヤーにならなければなりません。単にプレイするだけでなく、チームを率いて一緒にプレイし、「バグバッシュ（不具合探し大会）」を開催し、現場のスタッフ（特にカスタマーサポートやコミュニティ運営担当者）がユーザーから聞いた、最もリアルで耳の痛いフィードバックを匿名で収集すべきです。意思決定の基盤は、「業界レポートによると……」から、「昨夜、第3ステージをプレイしていた時に気づいたのですが……」へと転換されるべきなのです。

最後に、責任の大部分は確かにプロデューサー自身にある。というのも、これらの問題はすべて、私が実際に直面したことや、身をもって経験したことだからだ。私がこれまで見てきた中国のプロデューサーのうち、自分のゲームを実際にプレイしている人はほとんどおらず、大半はリリース時期になってから、見せかけだけプレイして、適当に指示を出すだけだ。