「Pokémon Trading Card Game Pocket」開発の舞台裏。リモートワーク下で大規模チームを動かすDeNAの「イニシアチブ制」とは［CEDEC 2025］

　2025年7月22日〜24日に開催された開発者向けカンファレンス「CEDEC 2025」の初日となる22日，ディー・エヌ・エー（以下DeNA）の開発者によるセッション「リモートワーク下での大規模ゲームの開発手法 : Pokemon TCG Pocket の事例」が行われた。

「Pokémon Trading Card Game Pocket」公式サイト

「Pokémon Trading Card Game Pocket」ダウンロードページ

「Pokémon Trading Card Game Pocket」ダウンロードページ

　2024年10月に世界150の国と地域でサービスが開始され，2025年2月には累計10億ダウンロードを突破したトレーディングカードゲーム「Pokémon Trading Card Game Pocket」（以下「ポケポケ」）は，ポケモンとクリーチャーズ，そしてDeNAの3社協同プロジェクトで，DeNAはアプリ開発を行っている。
　セッションに登壇したのは，「ポケポケ」総合ディレクターを務める竹内 愛氏と，EPM兼エンジニアの今別府デニス幸生氏だ。

登壇した今別府デニス幸生氏（左）と，竹内 愛氏（右）

　DeNAはゲーム事業に特化した会社ではないため，ゲーム開発に関わる人材がすべてゲームに詳しいわけではなく，竹内氏もそれほどゲームが得意ではないことを最初に告白した。DeNAの社風として上下関係や役職に関わらず，個人が考えて発言できるという文化があり，その一方でトップダウンの開発がしづらい社風であるという点も前置きされた。


　こうした文化の中，しかもコロナ禍の最中で始まった本作の開発に際し，どのような問題が起き，それをどう解決したのだろうか。

コロナ禍に始まった完全リモート開発。その規模が大きくなるにつれ，課題が増えていく

　開発チームがコロナ禍中に編成されたことから，「ポケポケ」は，ほぼリモートで開発されたタイトルとなった。こうした事案は当然ながら，DeNAとして初めてのことだった。

　開発で最初に行ったのが，コンセプトとターゲット，UXの明確化だ。上記のとおりDeNAは開発者全員がゲームに詳しいわけではないため，メンバー全員が分かる言葉でコンセプトとターゲットを決めたうえで開発の方向性を共有し，一貫して開発できるようにした。リモートでコミュニケーションが取りづらい中でも，初期のコアメンバーは密接にミーティングを行い，ユーザーインタビューなども実施して，方向性を決定したという。


　コンセプトとターゲットを初期段階で明確にしたことは正解だったと，竹内氏は自己評価する。明確な指標があったことでズレに気付きやすく，チーム内だけでなく会社間のすり合わせもしやすかったのだ。

　開発は最初，30人に満たない小規模チームでスタートした。かつて竹内氏と開発を共にしたメンバーも多く集まり，リモートでありつつもコミュニケーションは円滑で，順調なスタートを切ることができたという。
　しかし，α版からβ版開発の段階で問題が顕在化してくる。PM（プロジェクトマネージャー）によるタスク管理も機能していて，メンバーの進行も遅れず問題ないように見えたものの，実際には「個々の機能はできているけど，どこからも動線がつながっていない」「演出のテンポが悪いのが，仮のものなのか本番相当のものなのか分からない」「互いの連携が必要なのに，どちらもタスクを持っていない」といった諸問題が多数発生し，機能がいつまでもできあがらない状況に陥ってしまう。

　タスクはPMが切ってメンバーに渡していたが，この方法ではメンバー個人がそのタスクに集中してしまうため，それが最初に決めたコンセプトとターゲット，UXの3つを意識して進行できていないという事態も発生した。
　タスクの見積もりミスや渡し漏らしといったトラブルも発生し，それらをリカバリーするのが難しく，全員がタスクを終えているにもかかわらず，実は完成に届いていないということがあった。


　こうしたことは，リモートワーク下での急激な組織のスケーリングで発生する「あるある」だと，今別府氏は振り返った。

　その1つが「リモートワークあるある」で，DeNAでは普段からチャットツール「Slack」を使って非同期のコミュニケーションを取っていて，これはリモートでもそのまま使えた。
　この方法は直接の会話よりも情報伝達の効率が下がり，リモート前のように「席に直接行って話す」といった柔軟なやりとりができず，リモート会議にもセッティングが必要という物理的な負荷がかかる。テキストでは細かい感情やニュアンスが伝わらず，ホワイトボードなど，会議に使うツールも実物ほど使いやすいものではなかった。
　また，非同期で大量の連絡が来ることも問題だった。いつでも連絡ができる手軽さから，忙しさに関係なく大人数から大量の連絡があり，1日で処理できる限界を超え，かえって連絡が滞ってしまう事態に発展したのだ。


　2つめは，「組織スケーリングあるある」だ。組織の人数が急激に増えたときに発生する事柄で，問題視されたのが「フラットすぎる組織」だ。上記のようにDeNAには上下関係や縦割りがなく，誰にでも話しやすい文化を持っている。人数が少ない状態なら決まることも早いし，全員がオーナーシップを発揮できる。

　ところが，プロジェクトが進んで人数が増えてくると，「誰が何を担当しているのか分からない」「次は誰が作業をするのか分からない」「全員を集めないと決められない」といった非効率な事態が発生した。
　メンバー間で責任が分散してしまうため，ハブとなるリーダーが必要になるのだが，そのためには明確な人事体制が必要になる。いきなりそのような体制にするのは難しいため，本来フラットで縦割りのない組織のはずが，かえって縦割りのような機能不全を起こすというジレンマに陥ってしまうのだそうだ。


　続いては「管理の一極集中」で，DeNAではプロジェクト管理にPMがアサインされ，面倒な管理業務を任せられるのでチームは開発に集中できる。プロジェクトの詳細な知識がPMになくても，組織が小さければ個別にコミュニケーションを取ることでカバーできるため，問題は起こらない。
　しかし組織が大きくなると，開発チームから上がってくるタスク報告が増大する一方，専門知識が不十分なPMはそれに対する有効な手を講じられず，スケジュールを伸ばす程度の対策しかできなくなる。開発チームのスケジュール管理はPM任せなので，スケジュールに対する責任感が薄れてしまうのだ。


　さらには，「会議少なすぎ問題」もあるという。少人数時は「Slack」での密なやりとりや，互いの信頼関係により，会議がなくても開発は進んでいくが，この状態でメンバーが一気に増えると，互いに会ったことがないという人が増え，仕様書や疑問点の共有が不十分になっていく。
　そこでいざ会議が必要となったときも，会議文化が根付いていないため，いったい誰を集めてどんなフローで行えばいいのかが分からず，互いに「何が分からないのか分からない」状態で開発が進んでいくことになる。

リモートとスケーリングの壁を打破する「イニシアチブ制」の導入

　こうした組織のスケーリングとリモートワークに適した文化の改変に導入されたのが「イニシアチブ制」となる。ここで言う「イニシアチブ」とは，タスク管理アプリ「Jira」の用語で，大きくなってしまった組織の文化を，現状の延長から少しずつ変化させていく取り組みを，チームに分かりやすく伝えることを意味する。


　改変前には総合ディレクターをトップに置いたピラミッド状になっていた組織を，「イニシアチブチーム」と呼ぶ30人程度の小さなチームを複数編成する形へ変更。各チームは「パック開封」「バトル」「ゲットチャレンジ」など，機能単位で分けられ，それぞれには機能を作るすべての職能が所属して，責任者としてはオーナー（主にプランナー）が置かれる。


　そのうえで，総合ディレクターの竹内氏がコンセプト，ターゲット，UX，具体の仕様などをオーナーに伝え，メンバーは仕様の実装だけでなくUXの実現までを期限内に達成することに責任を持ち，進め方やタスク管理はチームが洗い出していく。PMはそうした動きをフォローするサポート役にシフトし，オーナーはタスクの取捨選択や人的リソースの再配分など，ある程度自由な判断ができるようにした。


　全体の流れとしては，まず総合ディレクターが基本方針をチームに共有し，オーナーが詳細な仕様書を，そしてUI，UXデザイナーがそれをもとに画面遷移図を作成し，チーム全員が出社して読み合わせを行う「キックオフ」を実施する。
　また開発中は，実際に動いている画面を見ながらUXの精度を確認する「エピック確認会」を，また終盤には「プレイ会」を開催し，チーム全員でその内容を議論することで，フィードバックや調整などをすり合わせていった。

　「イニシアチブ制」を導入したことで見られた変化としては，チームのコミュニケーション不全が改善され，議論が活発になり，和気あいあいとした雰囲気に変わったこと。人数が少ないため，リモートでも意見が言いやすく，メンバーの距離が縮まったことなどが挙げられた。
　また，オーナーに権限を委譲したことで，チーム内で自主的な仕様提案が増加し，ディレクターが介入しなくても改善が迅速になった。さらに，チームメンバーが遅延を避けつつUXを実現するために取捨選択を行い，結果的にゲームのクオリティが向上した。


　イニシアチブ制の導入と並行し，いくつかの環境整備も行っている。その一例が，すべての会議を録画し，議事録を取ることによる透明性の確保だ。3社協同のプロジェクトなので，開発メンバーであれば，それらすべてを見られるようにし，議論の途中経過も共有して，決定に至るプロセスが分かるようにした。
　また，チーム間をまたぐ一部の開発者や，異動した開発者への引き継ぎを容易にするための仕様書のフォーマット化，最終成果物に関わるタスクをJiraのチケット化するチケット駆動開発，自動化によって開発効率を向上させるCI/CD整備などの施策も実施されている。


　リモートワークと急激な組織スケーリングによって生じた課題に対応するために導入した「イニシアチブ制」は開発メンバーにも好評で，これを導入したことでチーム内の絆がさらに深まったと竹内氏は評した。
　これは，完成形でも汎用的な手法でもないことを強調しつつ，プロジェクトにおける文化変革の例として何かしらの役に立てるかもしれないと今別府氏と竹内氏は述べて，セッションを終了した。

「CEDEC 2025」公式サイト

4Gamer「CEDEC 2025」関連記事一覧