つぶやく
 |
 |
「プラグマタ」（PRAGMATA）はカプコンの完全新作タイトルで，試作から数えて約6年の開発期間を要した作品だ。松中氏はその本開発フェーズからメインのプロジェクトマネージャーとして参加している。
試作段階から持ち越された課題をどう把握し，どう手を打っていったのか。現場での事例から，ゲーム開発に共通する話が紹介された。
松中氏は2015年にカプコンへ中途入社。前職はゲームとは関係のない映像制作会社で，カプコン入社後はほぼ「バイオハザード」シリーズの開発に携わってきた。
「プラグマタ」でフルタイトルのメインマネージャーを初めて務めることになった。
 |
試作に約3年。課題を抱えたまま本開発へ
「プラグマタ」は，独自の爽快感と戦略性を持った新感覚SFアクションアドベンチャーとして開発されたタイトルだ。
TPSにパズル要素を組み合わせた新しい体験を目指しつつ，カプコンがこれまで培ってきた手応えのあるゲーム性は失わない。そうした狙いのもとで作られている。
 |
 |
 |
開発フローは大きく，「試作開発」「本開発」「デバッグ」「リリース」という流れになる。このうち試作開発に約3年，本開発にも約3年がかかった。
開始が2020年頃なので，トータルでおよそ6年である（発売は
2026年4月17日）。
 |
試作段階ですでに3年を使っている一方で，手応えは得られている。松中氏が合流したのは，本開発に進む段階。このまま本開発を終わらせてリリースしなければならない，「これ以上は遅れられない」という緊張感のある状況でのチーム合流だったと振り返った。
スケジュールは課題に大きく影響される。課題が何もなければ，敵を3か月で作りましょうと言えば3か月でできあがる。
しかし，メンバーが数人抜けた，パソコンが壊れました，といった小さな出来事でも計画は破綻する。
課題が残ったままなら，どれだけ計画を立てても壊れていく。松中氏が参加した時点では試作段階で出てきた課題がそのまま山積みになっており，チームが円滑に動き，スケジュールが計画どおりに進むには，まずそれらを潰す必要があった。
講演で取り上げられた課題は，「新規IP開発」「コミュニケーション」「ゴールが見えない」「経験不足」の4つ。
新規IPゆえに曖昧で，共通のイメージがない。ゴールが見えないので進む方向が分からない。目的の不明な会議と曖昧な作業指示がある。
ディレクターもリーダーも初経験で，開発経験そのものが不足している。
 |
これらに対して「ゴールに向かう意思決定」「コミュニケーションマネジメント」「経験をカバーするチーム運営」という3つの切り口から，何を行い何を感じたのかが語られた。
１．ゴールに向かう意思決定
 |
1つめのテーマは，開発ゴールの不明瞭さだ。たとえばA，B，C，Dの4人がいるとする。
 |
- SFだから世界観設定が大事だ。
- シューティングである以上，爽快感を作らないと遊んでもらえない
- 新しい要素として入れるのだからパズルをきちんと作らなければ
- ディアナをかわいく見せなければ
といった4つの方向が生まれる。どれも間違ってはいないし，全部正解でもある。しかし，それらはゴール設定ではない。
ゲームはこれらが合わさって1つのゴールになるものだが，各自が思い描く優先事項は少しずつ違っている。
伝言ゲームのように少しずつずれが積み重なり，最終的にまったく違うものが出てくるパターンは珍しくない，と松中氏は言う。
ずれは評価基準にも表れる。1つのものを作るにはレビューを何度か繰り返すが，最初にゴール設定がないと，レビュー1ではアクション重視，2ではストーリー重視，3では初心者重視といった具合に基準が動く。
目指しているものは同じはずなのに，優先するものが少しずつ違うため，できあがったものが自分の想定と違う。
結果として何週間，何か月とかけたものに対して，想像と違うのでやり直そう，という判断が下される。
 |
結局のところ，何を作りたいのかを誰も分かっていなかったのではないか，と松中氏は振り返った。方向性だけを基に進めても，最初に見えていたはずのゴールへは向かえない。
そして開発は長引き，試作に時間を費やすことになった。
解決策として松中氏がまず行ったのが，開発ビジョンの明文化と周知である。
資料の最上位にあるコンセプトは，開発当初から存在していなかったわけではない。メンバーの頭の中にはあり，語られてもいた。ただ，それを明示したうえで作っていたかというと怪しかったのだ。
そこで，きちんと資料として全員が見えるようにしようと考えた。100人規模がばらばらに作業する規模では，コアメンバーが分かっていても全員にまで浸透させるのは難しい。
目に見えて分かるものがあるかないかで，まったく違ってくるからだ。
コンセプトとして掲げたのは，圧倒的なSF世界観と新しいゲーム体験。ただしコンセプトはあくまでイメージなので，その下に3本の柱を置き，どういうゲームなのかを具体的に文字にした。
1本目の柱はゲームアクションで，TPS×ハッキングアクション。パズルとシューターを組み合わせたゲームである以上，ハッキングアクションがなくなることはありえない，という必ず守る要素として設定されている。
2本目の柱はゲームシステムで，自発的なモチベーションにつながる手応えとゲームサイクル。オープンワールドではなく，一本道をクリアするだけのものでもない。武器を強化して少しずつ強くなっていく，拠点とステージを往復するといったサイクルで遊ぶゲームだと定義した。
3本目の柱が世界観とビジュアルで，AIが支配する人気のない月面世界で奮闘する体験を掲げている。
これら3本をユーザー体験のレベルまで詳細化し，1枚の資料としてまとめた。そのうえで周知を徹底する。
毎週の定例会議や月1回の進捗全体会議では，必ずこの資料を会議の冒頭に持ってきて，改めて共有するようにした。
100人規模のチームには入れ替わりがあり，新しいメンバーはこのゲームがどんなゲームなのかを知らない。誰が入ってきてもすぐ分かるようゴールを資料化しておく，というのが最初に手を付けたことだった。
 |
もう1つが，議論の集中管理である。ゴールが定まっても，最初から全部を作れるわけではない。ここで松中氏がフォーカスしたのは，やることよりも「やらないこと」のほうだ。
開発の初期から中期にかけて，最もできあがっていたのがステージ1だった。最初に遊べる，敵と戦えるステージで，早い段階から形になっていた。
すると，みんなが触りたがる。もう少しクオリティを上げたい，ボスをもっと強くしたい……。形が見えているところに手を入れたくなるものだが，今やるべきはまだできていないところを作ることだ。
ステージ2も3もできていないのに1を作り続けても進まない。そこで，8割できているところは触らないでください，とやらないことを先に決定した。
やらないことを決めたうえで，優先してやることを決める。今やるべきことはステージ1の戦闘からゲームサイクルの仮実装まで，やらないことはステージ1の本実装やステージ2，やり込み要素といった具合に切り分けた。
こうすることで，ここで難易度を下げるべきではないか，いやまだ難易度の話をする段階ではない，といった議論を集中して管理できるようになる。
 |
ゴールが見えているかどうかで制作の内容はまったく変わってくる，というのが松中氏の実感だ。
 |
２．コミュニケーションマネジメント
 |
2つめのテーマはコミュニケーションだ。チームが100人規模になると重要性も難しさも飛躍的に大きくなる。数人のプロジェクトなら直接話しに行けば解決する問題が，聞いていないという事態を生む。
実際に起きていたのが，会議の増加と目的の曖昧さだった。人数が多いと話すべきことも増え，会議が開かれる。
しかし何の話をしているのか分からないまま解散し，結論が出ないのでまた会議を開く。重要な話だからとりあえず毎週の定例にしよう，となれば定例待ちが発生し，その定例も形骸化して，とりあえずあるから出ておこうという場になる。
定例が増えれば，チームの繁忙期には主要メンバーがほとんど会議で埋まる。出席はしても作業は進まず，議論も散って解決しない。目的のない会議が増えていた，というのが本開発合流時の状況だった。
 |
もう1つが口頭指示の問題だ。会議で決まったことが上から下へ下りてくる際，たとえば，ボス戦をもっと熱い感じにしてほしい，といった指示が出る。
受け取った側は，難易度を上げることだと解釈する人もいれば，エフェクトを派手にすることだ，BGMで盛り上げることだ，カットシーンを追加することだ，と解釈が分かれる。
レビューでの認識のずれとまったく同じ構図で，指示したつもりでも違うものができあがる。こうした口頭指示と会議の増加が開発の進捗を圧迫していた。
 |
対策の1つめは，指示系統の整理である。
やりたいことがあるからといって直接作業者に指示を出すと，別の人からも指示が飛んできて，何を先に作ればいいのか分からなくなる。
そこで，ディレクターを中心とした主要メンバーと，主に企画メンバーからなるゲーム方針決定陣との間で，まずゲーム方針のイテレーションを回す形にした。
主要メンバーが方向性を示し，企画メンバーが仕様を考案する。企画会議などで，「ああでもない」「こうでもない」と繰り返し，最終的に仕様として決定してから制作ラインへ落とす。
制作ラインに渡す時点では企画メンバーが内容を仕様化しているため，変なところから指示が飛ばない。
小さな組織のようなもので，誰が何を考え，どこで仕様を決定し，どこから指示を出すのかを明確にした形だ。
 |
2つめが，文書化された作成指示である。企画とコアメンバーがイテレーションを重ねて仕様を作っていれば，ある程度は文書化される。
「熱い感じにしてほしい」といった口頭指示ではなく，どういうことが必要なのかを仕様として書き，作業メンバーに渡す。
先の例であれば，危機的状況からの逆転を演出する，ディアナの見せ場を作る，後半戦でテンションを上げる，といった具体的な要件に落とし込まれる。
文字だけでなく，敵の攻撃がどう振りかぶるのかを図で示した指示書もあるという。
松中氏が参加した当初は，仕様書がないまま作っているという話がよくあった。簡単なものならそれでもいいのかもしれないが，蔓延すれば認識の齟齬で違うものが出てきたり，時間がかかったりする。
仕様書を作り，必要な要件を書いて指示することは重要だ，と松中氏は続けた。
 |
3つめが，会議の目的とゴールの明確化だ。会議を開くなら，その目的は何か，何が決定すればゴールなのかを明確にすることを徹底した。
Outlookで会議を設定して参加者を招待する際，何を話すのか，何が決まればゴールなのかを必ず記載する。
さらに，話す内容の資料も事前に貼り付けて参加メンバーに共有した。
招待だけ送ると，話す内容を把握していないまま集まることになる。それでは，話したいことの中身が逃げ，ゴールにたどり着けずまた会議を開くことになる。
会議の質を上げて回数と時間を減らす狙いで事前準備を徹底した結果，会議は早く終わるようになったという。
 |
コミュニケーションを円滑に回すことで無駄を省き，作業スピードを上げて作業時間を減らす。100%できていたかというと怪しいが，多くの作業者が関わるプロジェクトでは，こうしたことを意識するだけでも円滑に進められるのではないか，と松中氏は付け加えた。
 |
３．経験をカバーするチーム運営
 |
3つめのテーマは，若手中心のチーム運営だ。「プラグマタ」は非常に若いメンバーで構成されたチームだった。若いこと自体は悪いことではないが，経験は少ない。
経験していないことなので，思わぬところに落とし穴がある。
加えて新規IPであるため，そもそも誰も経験していない部分がある。シリーズ作であれば，このシリーズならこうだ，このキャラクターにこういうことはさせない，といったお決まりが共有されているが，新規IPにはそれがない。
 |
自由である一方で，まったく違うものができてしまうこともある。経験不足も新規IPも悪いことではないが，課題は課題であり，それをどう解決するかに注目した，と松中氏は言う。
そこで松中氏がまず行ったのが，短期目標の設定である。
開発期間は3年，トータルでは6年と，非常に長い。3年後のゴールに向けて作業を進めようとしても，いつ何を作ればいいのか分からなくなる。
そこで2か月に1回，場合によっては3か月に1回のマイルストーンを設定し，それぞれで何をゴールにするのかをあらかじめ決めた。
最終的にはマイルストーン15や16まであり，12から13あたりで全要素が入って通しでプレイできるアルファ版に到達し，最後で完成する。
この全体像をロードマップとして最初に敷いた。
 |
マイルストーン1のゴールは，ゲーム性が理解できるところまで作ること。全ステージをクリアしなくても，ステージ1から2を通しでプレイできれば大体どんなゲームかは分かる。
そう切り分けて，ステージ1から2の通しプレイと拠点サイクルをゴールに設定し，それ以外はやらないと決めた。マイルストーン2では，遊ばせポイントの理解，ステージ3から4の通しプレイ，ギミック攻略がゴールになる。
さらにマイルストーンの中を2週間程度のスプリントに分割し，スプリントごとのゴールとタスクを設定する。
焦点を絞って短期間のゴールをみんなで目指す形にしたわけだ。
 |
この仕組みは経験不足への対処としても機能する。経験値が少ないとトータルのボリューム感や作業量が分からないが，マイルストーンを1つずつクリアしていけば，1でこれだけできたから2でも同じくらい進むだろう，1と2でステージ1と2があまりできていないので3と4も厳しいのではないか，という見通しが立つ。
細かくイテレーションを回すことで，自分たちのスピード感を理解し，短期間で経験を積めるわけだ。
迅速なフィードバックも欠かせない。計画を立てて制作し，フィードバックを受けて，OKなら次のスプリントへ進む。
フィードバックは面白さ，デザイン，実装コストの観点から行われ，通らなかった場合は改善点を明確にしてから制作に戻る。
ここで重視されているのは，目標との乖離を確認して明文化すること。短いサイクルでレビューを回すことで，若手主体のチームであっても経験値と熟練度が上がり，この人はこういうことができるようになった，という形で開発を通じて成長していく。それも狙いのひとつだったという。
 |
また，体験共有も重要である。2か月に1度のマイルストーンの区切りでビルドを作成する際，全員でゲームプレイを必ず行うようにした。
そのうえで，社内で使用しているスケジュール管理ツールのバックログに，全員で意見を書き込む。
ここが面白かった，ここのディアナがかわいかったといった良い点も書いてもらうが，攻撃が強すぎる，この攻撃は面白くないといった指摘も出てくる。
それをリーダー以上のメンバーが見て，対応するもの，対応方法を検討するもの，意見としては受け取るが今回は見送るものと精査し，修正に反映していく。
ゲームを少しずつ良くしていく目的とは別に，ここで重要なのは，自分たちでプレイすることで今ゲームがどうなっているかを理解できる点だと松中氏は言う。
100人，何百人が関わる規模になると全体を把握するのは難しい。敵のこの部分だけを作っている人，イベントだけを作っている人がいて，全体像が分かっていないと自分が作っているものの解像度が非常に低くなる。
ここはこう作らなければいけなかったのか，と後から気づくことになる。何を作っているのか分からない状態は，ゲーム制作において致命的だという。
ゲームプレイには当然，時間がかかる。「プラグマタ」をクリアするには10数時間を要するため，全員がプレイすれば1日，2日，場合によっては3日は作業が止まる。
開発終盤になるほど要素が揃うので所要時間も伸びる。それでも必ずプレイしてもらっていた。
自分以外の人が作っているところを理解することで，自分が今何をしているのか，次の開発で何をしなければならないのかを意識できるようになるからだ。
 |
本当に面白くなっているのか，ゲームとして成立しているのか，自分が作っている要素がゲームの中でどういう役割を果たしているのかを，自分の目で確かめる。
意見を出すことも同様に重要だ。このゲームは難しい，といったことはプレイすれば分かる。
ただし，ずっとプレイしているとみんなが上手くなっていくため，ゲームはどんどん難しくなる。
新しく入ったメンバーにプレイしてもらうと，難しすぎると言われることが何度もあったという。途中途中でプレイし続けることに意味があるわけだ。
 |
まとめ
最後に，講演全体のまとめとして4点が挙げられた。
 |
1点目は明確なゴールの重要性。優秀な人材はたくさんいるが，曖昧な指示では活かせない。優秀なランナーがいても，ゴールがどこか分からなければたどり着けない。
ディレクターが方向性を示し，マネージャーがサポートすることで，明確なゴールに向かって走れる状態を作る。
2点目は，意図を明確にしたコミュニケーション設計。コミュニケーションは自然にうまくいくことはない。100人規模で集まるプロジェクトで，口頭であれをやってほしい，あれはいつまでなのか，とやっていても成立しない。
意図的に仕組みを作り，作業指示を明確にしてマネジメントする必要がある。
3点目は，経験不足の仕組みによる補完。若手メンバーの自由な発想を活かしつつ，短いサイクルで経験を積んでもらう。
小さなゴールを少しずつ達成して経験値を積み上げた結果，若手中心のチームでありながら自由な発想で面白いゲームができたのではないか，と松中氏は振り返る。
4点目は，見える化と資産化だ。3つのテーマを通じて松中氏が感じたのは，見える化の重要性だという。
ゴールはあったし仕様も決まっていた。しかし多くのメンバーが作業する中でそれが見えていないと，各自が頭の中で考えていることは意外なほど食い違っている。
必要なことは見える化して，みんなの力で成功を目指す。
今回の講演自体も，その延長線上にあると松中氏は語った。自分が頭の中で感じていたことを資料化すれば，それも1つの資料になるのではないかと考えて登壇を受けたのだという。
将来的に見返して，このときこんなことを言っていたと振り返れる形にしておきたい，と。ゲーム制作に限らず一般的な話なので，これができていなかった，当たり前のことなのにできていなかった，という気づきが少しでもあれば嬉しい，という言葉で講演は締めくくられた。
 |
