このページの本文へ

前へ 1 2 3 4 次へ

“DeNAの開発チーム流アジャイル”が突破口に【CEDEC2025レポート】

「ポケポケ」開発チームが直面した“いつまでも完成しない問題” リモート×大規模な組織づくりの難しさ

2025年08月04日 10時00分更新

文● 福澤陽介/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 昨年(2024年)10月にリリースされ、若年層を中心に人気を集めるスマートフォンアプリ「Pokémon Trading Card Game Pocket」(以下、ポケポケ)。その開発はコロナ禍の最中にスタートしたが、開発チーム内では、開発を進めても「いつまでも出来上がらない問題」が発生していた――。

 2025年7月22日から24日、ゲーム開発者向けのカンファレンス「CEDEC2025」が開催。ディー・エヌ・エー(DeNA)のセッションでは、ポケポケ開発チームが、リモートワークかつ大規模な開発チームで生じる“あるある”課題を解決した、組織づくりにおけるさまざまな工夫を披露した。

 登壇したのは、DeNAでポケポケの総合ディレクターを務めた竹内愛氏と、EPM(Engineering Project Manager)兼エンジニアを務めた今別府デニス幸生氏だ。

「リモートワーク下での大規模ゲームの開発手法 : Pokémon TCG Pocket の事例」と題したセッションをレポートする

累計1億ダウンロードを突破した「ポケポケ」開発の裏側

 ポケポケは、世界中で楽しまれているポケモンカードを手軽にコレクションできるアプリだ。2024年10月30日に、150の国と地域で正式サービスをスタート。今年2月には、累計ダウンロード数が1億回を突破している。

Pokemon Trading Card Game Pocket

 同アプリでは、The Pokémon Company(ポケモン)がパブリッシュ・全体プロデュースを、Creatures(クリーチャーズ)がカードゲーム開発とアプリ企画協力を、そしてDeNAがアプリ開発を担当している。

ディー・エヌ・エー ゲームサービス事業本部 開発運営統括部 副統括部長 竹内愛氏

 話の前提として、竹内氏はまず、DeNAのゲーム開発体制について説明した。DeNAは、ゲーム事業だけを展開する企業ではないため、開発に携わる全員が必ずしも「ゲームに詳しい」「ゲームが大好き」というわけではない。竹内氏自身も「ゲームは下手」だとこぼす。また、上下関係や役職を意識せずに発言して、目標や課題に向けて一人ひとりが考える、「“こと”に向かう」社風があるという。

顕在化する「いつまでも出来上がらない問題」

 ポケポケの開発は、コロナ禍の最中にスタートすることになった。そのため、DeNAとしては初めて、スタート時からリモートワーク主体で開発・制作が進むタイトルとなった。

 開発に先立って、まずは「コンセプト/ターゲット/UX(ユーザー体験)」の明確化を図った。これは、個々人が主体的に考えるというDeNAの組織文化と、全員がゲームに詳しいわけではないという事情も考え、開発チームの方向性に一貫性を持たせるためだ。

 具体的には、まずは「コンセプト」「ターゲット」を定め、それを基に「各機能のUX」を設計。そのUXを実現する「具体な仕様」を考え、実装するという流れだ。

 例えば、「ポケモンカードらしさを大切する」というコンセプトから、カードを手に入れた際のUXは「開封のワクワクを体験できるようにする」と決め、「拡張パック(カードが入ったパッケージ)をスワイプで開ける」仕様に落とし込んだ。

 竹内氏は、「結論としてこの明確化は、最後までプラスに働いた。(先に決めたコンセプトやUXという)指標があるためズレに気づきやすく、会社間やメンバー間でもスムーズにすり合わせができた」と語る。

コンセプト/ターゲット/UXの明確化

 こうして、30名ほどの体制で取り組んだ初期段階は、順調に開発が進んだ。かつて同じタイトルに携わったメンバーが中心だったこともあり、リモートワークでも密にコミュニケーションが取れていた。

 しかし、開発の段階が進み、α開発の後半からβ開発にかけて、「いつまでも出来上がらない問題」が表面化する。具体的には、個々の機能はできているものの導線がなかったり、演出が仮のものか本番のものかが不透明だったり、連携が必要な機能同士で“お見合い”をしていたり、といった具合だった。

 この当時は、PM(Project Manager)がタスクを切ってメンバーに渡すというタスク管理方法をとっており、一見、遅延なく進行しているように見えた。しかし、タスクの処理が進んでも、機能はいっこうに完成しない。

 竹内氏は、「こうした管理方法では、メンバーがタスク処理だけに集中してしまい、その機能がUXに合致しているかを意識できなかった。また、“タスクの見積りミス”や“渡し漏らし”もリカバリーできず、その結果、完成に届いていなかった」と振り返る。

いつまでも出来上がらない問題

 開発初期には問題がなかったのに、なぜ、タスクの遅れや漏れに対処できなくなったのか。それは、プロジェクトが進み、開発に携わるメンバーが「数百人規模」にまで膨れ上がっていたからだ。

前へ 1 2 3 4 次へ

カテゴリートップへ

  • 角川アスキー総合研究所