ゲームプランナーとは？仕事内容を図解で丸わかり

ゲームプランナーを調べているあなたは、「結局どんな仕事？」「未経験でもなれる？」「年収や将来性は？」といった疑問を持っているはずです。
この記事では、ゲームプランナーの役割をディレクター等との違いから整理し、企画→開発→テスト→運用までの仕事の流れを“図解イメージ”でわかりやすく解説します。
さらに、必要スキル、きついと言われる理由、向き不向き、なり方（大学・専門・独学比較）、資格、年収、求人の探し方まで、検索上位でよく語られる論点を一つにまとめました。
読み終える頃には、自分が目指すべきプランナー像と、次にやるべき準備が具体的に見える状態を目指します。

ゲームプランナーとは？ゲーム開発における仕事と役割を解説【図解】

ゲームプランナーは、ゲームの「面白さ」を言語化し、仕様としてチームに伝え、形にしていく企画職です。
アイデアを出すだけでなく、ルール設計、報酬設計、レベルデザイン、イベント設計、数値調整、運用改善など、ゲーム体験の中身を作る仕事が中心になります。
立場としては、プロデューサーやディレクターの方針（売上目標、世界観、スケジュール）を受けて、実装可能な形に落とし込む“設計者”に近い存在です。
図解イメージで表すと「方針（上流）→設計（プランナー）→制作（各職種）→検証→改善」の真ん中を担い、企画と現場をつなぐハブになります。

ゲームクリエイターの中でのプランナー／ディレクターとの違い（職種・役割）

混同されやすいのが、プランナーとディレクター（場合によってはプロデューサー）の違いです。
ざっくり言うと、ディレクターは「何を作るか・どう作るかの最終判断をする責任者」、プランナーは「面白さを仕様にして実装へ落とす設計担当」です。
ただし会社によって呼び方が異なり、プランナーが進行管理まで担う現場もあります。
応募や配属のミスマッチを防ぐには、職種名よりも“担当範囲（仕様、レベル、運用、KPI、進行）”を確認するのが重要です。

企画職のタイプ：レベル・バトル・イベント・運用など特化領域

ゲームプランナーは「何でも屋」ではなく、現場では領域別に分かれることが多いです。
コンシューマではレベルデザインやバトル設計など“完成品の体験設計”が重視されやすく、スマホ（特に運用型）ではイベント設計やKPI改善など“継続運用の設計”が比重を増します。
自分が得意な方向性（物語・演出が好き、数値調整が好き、ユーザー行動分析が好き）を把握すると、志望職種の選び方が一気に具体的になります。

• レベルプランナー：ステージ構成、導線、難易度カーブ、チュートリアル設計
• バトルプランナー：スキル/敵AI/パラメータ、メタ設計、バランス調整
• イベント/クエストプランナー：期間施策、報酬設計、周回設計、演出の流れ
• 運用プランナー：KPI設計、施策立案、ABテスト、継続率/課金率改善
• シナリオ/演出寄り：会話、カットシーン、演出仕様、感情曲線の設計

日本のゲーム業界で求められる人材像と需要（上場企業・スマホ/コンシューマ）

日本のゲーム業界では、上場企業を中心に「運用で数字を伸ばせる人材」「チーム開発で仕様を回せる人材」の需要が安定してあります。
スマホはリリース後の改善が前提のため、KPI（継続率、ARPU、課金率など）を見て仮説検証できるプランナーが評価されやすい傾向です。
一方コンシューマは、体験の完成度が勝負になり、レベルデザインやバトル設計など“遊びの骨格”を作れる人が強みになります。
共通して求められるのは、アイデアの多さより「実装可能な形に落とす力」「他職種と合意形成する力」「改善を回し切る粘り強さ」です。

【図解】ゲームプランナーの仕事内容：企画立案→制作→リリース後運用の流れ

ゲームプランナーの仕事は、企画書を書いて終わりではありません。
企画フェーズで方向性を作り、開発フェーズで仕様を固め、テストで問題を潰し、リリース後はデータを見て改善を続けます。
図解イメージで表すと「企画（Why/What）→仕様（How）→制作（Build）→検証（Test）→改善（Improve）→運用（Operate）」のループです。
特に運用型では、リリース後が“本番”になり、イベントやアップデートを通じて体験を育てていきます。

企画フェーズ：アイデア発生から企画書・タイトル案作成、プレゼンテーションまで

企画フェーズでは、ユーザー課題や市場の空白を見つけ、「誰に、どんな体験を、なぜ今出すのか」を定義します。
ここで重要なのは、面白さの根拠を“言葉と図”で説明できることです。
企画書には、ターゲット、コア体験、差別化、マネタイズ（必要なら）、開発規模感、参考作品、リスクと対策などを整理し、社内の意思決定者に通る形でプレゼンします。
タイトル案や世界観の方向性もこの段階で叩き台を作り、以降の仕様作成の軸にします。

• ターゲット：誰が、どんな状況で遊ぶか（通勤、夜、友人と等）
• コア体験：一番気持ちいい瞬間は何か（勝つ、集める、解く、驚く等）
• 差別化：既存作と何が違うか（操作、ルール、テンポ、表現）
• 実現性：期間・人数・技術で作れるか（スコープ調整）
• 成功指標：何をもって成功とするか（評価、継続、売上等）

開発フェーズ：仕様書作成、社内レビュー、エンジニア/デザイナーとチーム開発

開発フェーズの中心は仕様書作成とレビューです。
仕様書は「画面」「操作」「ルール」「例外」「数値」「遷移」「文言」まで、実装者が迷わない粒度で書きます。
同時に、エンジニアとは実装コストや技術制約をすり合わせ、デザイナーとはUIの見やすさや演出の気持ちよさを詰めます。
プランナーは“決める人”ではなく“決まるように整える人”として、論点を整理し、選択肢と判断材料を用意するのが強い動き方です。

• 仕様書：Googleドキュメント/Confluence等で管理し、更新履歴を残す
• 画面遷移図：Figma等でプロトタイプを作り、認識ズレを減らす
• パラメータ表：スプレッドシートで一元管理し、調整しやすくする
• レビュー：目的→変更点→影響範囲→未決事項の順で短時間化する

テスト～改善：チェック・分析・問題対応（不具合/バグ）と数値での改善

テストでは、仕様通りに動くかだけでなく「遊んで気持ちいいか」「理解できるか」「理不尽ではないか」を確認します。
不具合（バグ）が出たら、再現手順、期待結果、実際の結果、発生条件、優先度を整理して報告し、修正後の再テストまで回します。
運用型やオンライン要素がある場合は、ログやKPIを見て、離脱ポイントや課金導線の詰まりを特定し、仮説→施策→検証のサイクルを回します。
ここでの強みは、感想ではなく“数値と観察”で改善を語れることです。

• 不具合対応：再現性の確認→優先度付け→修正確認→リグレッションチェック
• 体験改善：チュートリアル離脱、難易度の壁、報酬の弱さを特定
• 数値改善：KPIの変化を見て、施策の因果を検証（ABテスト等）

運用フェーズ：イベント設計、スケジュール管理、KPI/年間計画、アップデート方針

運用フェーズでは、イベントやガチャ（ある場合）、新機能追加、バランス調整などを計画し、ユーザーの熱量を維持します。
重要なのは、短期の売上だけでなく、中長期の体験価値（飽きにくさ、目標の提示、コミュニティの盛り上がり）を設計することです。
年間計画では、季節イベント、周年、コラボなどの山を作り、制作リソースと品質を両立させます。
また、KPIを見ながら「何を伸ばす月か（継続/復帰/課金/拡散）」を明確にし、施策の目的をぶらさないことが運用プランナーの腕の見せ所です。

ゲームプランナーに必要なスキル一覧（未経験OKと言われる理由も整理）

ゲームプランナーに必要なスキルは、専門ソフトの操作よりも「考えを形にして伝え、チームで前に進める力」です。
そのため、未経験OKの求人が一定数あるのは、ポテンシャル（論理性、文章力、調整力、学習力）を見て育成できる領域が多いからです。
一方で、未経験でも“何を作れるか”が見えないと採用されにくいため、企画書や改善提案などのアウトプットが重要になります。
ここでは、現場で評価されやすいスキルを分解して整理します。

企画力：ニーズ把握・トレンドに敏感・流行を読み、刺さる企画を立案する方法

企画力は「ひらめき」ではなく、観察と分解で再現性を上げられます。
具体的には、ヒット作を“要素分解”し、どのユーザー課題をどう解決しているか、どの瞬間に快感があるかを言語化します。
その上で、自分の企画ではターゲットを絞り、コア体験を1行で言える状態にし、差別化ポイントを2〜3個に限定すると通りやすくなります。
トレンドは追うだけでなく、「なぜ流行ったか」を構造で理解すると、次の企画に転用できます。

• 分析対象を決める：売れている理由ではなく“遊ばれている理由”を見る
• 体験を分解する：導入→学習→成長→達成→共有の流れで整理
• 企画を絞る：ターゲット/コア体験/差別化を短く強くする
• 検証する：小さなプロトタイプや紙でルールを試す

分析力：ユーザーデータと数値から仮説→施策→検証を回す（改善の型）

分析力は、運用型ゲームで特に強い武器になります。
大事なのは、数字を眺めることではなく「どこで何が起きているか」を仮説に落とし、施策で検証することです。
例えば継続率が落ちたなら、難易度、報酬、導線、ロード時間、マッチングなど原因候補を分解し、ログやユーザー行動から当たりを付けます。
施策は目的と成功条件（どのKPIがどれだけ動けば成功か）を先に決めると、改善がブレません。

• 現象：KPIの変化（例：Day1継続が低下）
• 仮説：原因候補を分解（例：チュートリアルが長い/報酬が弱い）
• 施策：変更案を作る（例：導線短縮、報酬増、演出短縮）
• 検証：ABテストや期間比較で効果確認
• 学習：再現性としてドキュメント化

コミュニケーション能力：社内調整・チーム連携・質問力でプロジェクトを前に進める

プランナーのコミュニケーションは、雑談力よりも“合意形成”の技術です。
仕様変更が起きたときに、影響範囲（工数、スケジュール、品質、他機能）を整理し、関係者が判断できる材料を揃えることが求められます。
また、エンジニアやデザイナーに相談するときは、目的と制約を先に共有し、相手の専門性を引き出す質問ができると強いです。
「伝える」だけでなく「誤解が起きない形にする」ことが、現場での信頼につながります。

• 目的→背景→結論→依頼の順で話す（情報の迷子を防ぐ）
• 未決事項を明確化し、決める人と期限をセットにする
• 相手の言葉で復唱し、認識ズレを早期に潰す
• 議事録で決定事項と宿題を残す

ドキュメント作成力：仕様書・企画書の書き方、レビューで通る要点

ドキュメント作成力は、プランナーの“実務力”が最も出る部分です。
レビューで通る仕様書は、読み手（実装者・QA・運用担当）が必要とする情報が揃っており、例外処理や数値の根拠が書かれています。
逆に落ちる仕様は、目的が曖昧、用語が統一されていない、画面遷移が追えない、例外が抜けている、更新履歴がない、などが典型です。
文章は上手さよりも、構造（見出し、表、箇条書き、図）で理解コストを下げることが重要になります。

• 最初に目的：この機能で何を達成するかを1〜2行で書く
• 用語統一：同じものを別名で呼ばない（混乱の元）
• 例外を書く：通信失敗、所持上限、途中離脱など
• 数値の根拠：なぜその報酬量/確率/難易度なのか
• 更新管理：版数、更新日、変更点を残す

管理・マネジメント：進行管理、工程理解、残業を増やさない段取り

プランナーは、タスクの交通整理役になることが多く、進行管理の素養があると強いです。
工程理解（仕様→実装→データ作成→QA→修正→リリース）を押さえ、どこがボトルネックになりやすいかを先回りして潰します。
残業が増える現場では、仕様の確定が遅い、レビューが長い、優先順位が曖昧、差し戻しが多い、が起点になりがちです。
段取りとしては、早めに叩き台を出し、関係者を巻き込んで小さく合意を積み上げるのが有効です。

• タスクを分解し、依存関係（先に必要なもの）を見える化する
• レビューは短く頻繁に（大きな差し戻しを防ぐ）
• 優先順位を明文化し、スコープ調整の基準を作る
• リリース前は“やらないこと”を決めて品質を守る

きつい？やめとけ？ゲームプランナーの現実（残業・プレッシャー・理由）

ゲームプランナーは華やかに見える一方で、「きつい」「やめとけ」と言われることもあります。
理由は、仕様変更が起きやすい、締切が動かない、関係者が多い、成果が見えにくい、といった構造的な難しさがあるからです。
ただし、働き方は会社・プロジェクト・フェーズで大きく変わります。
現実を理解した上で対策を持てば、消耗しにくく、やりがいを感じやすい職種でもあります。

「きつい」と感じる典型パターン：仕様変更発生、締切、調整コスト

きつさの代表例は、仕様変更の連鎖です。
「面白くないから変える」は正しい一方で、変更は実装・デザイン・QA・運用計画に波及し、調整コストが一気に増えます。
また、リリース日やイベント日程が固定されていると、遅れを取り戻すために残業が発生しやすくなります。
プランナーは“間に立つ”立場のため、各職種の要望を受け止めつつ、優先順位を整理して決め切る負荷がかかりやすい点も特徴です。

• 仕様が固まらないまま実装が進み、後から差し戻しが増える
• 関係者が多く、合意形成に時間がかかる
• イベント運用で締切が連続し、休みが取りづらい時期がある
• 「面白さ」の議論が主観的になり、決着がつきにくい

「やめとけ」と言われる理由：向き不向き、成果の見えづらさ、競争の激しさ

やめとけと言われる背景には、向き不向きがはっきり出る点があります。
曖昧な状態から仕様を作る、他人の意見を統合する、地道に改善を回す、といった作業が苦手だとストレスになりやすいです。
また、ヒットの要因はチーム成果であり、個人の貢献が外から見えにくいこともあります。
さらに人気職種のため応募者が多く、未経験枠は特に競争が激しいのも現実です。

• 成果が“売上や評価”に直結するまで時間がかかる
• 正解が一つではなく、判断の連続で消耗しやすい
• 未経験はポートフォリオがないと書類で落ちやすい
• 会社によって業務範囲が違い、入社後ギャップが起きる

それでもやりがいは大きい：ユーザーの反応、ヒット、エンタメを作る魅力

一方で、やりがいは非常に大きい職種です。
自分が設計したルールやイベントで、ユーザーが熱中したり、SNSで盛り上がったり、レビューで褒められたりする瞬間は、他職種では得にくい達成感があります。
また、改善が数字で返ってくる環境では、施策の手応えを定量的に感じられます。
「面白さを作る」という抽象的な仕事を、仕様とチームワークで現実に落とし込むプロセス自体が、ものづくり好きには強い魅力になります。

• ユーザーの反応が直接届く（感想、配信、SNS、レビュー）
• 改善で数字が動くと、再現性のある成長を実感できる
• チームで一つの作品を完成させる達成感がある
• 企画・分析・調整など、汎用スキルが身につく

失敗しない対策：期待値調整・スケジュール設計・社内合意の取り方

消耗しないための対策は、個人の根性より“設計”で解決するのが有効です。
まず期待値調整として、目的・優先順位・やらないことを明確にし、スコープを守ります。
次にスケジュール設計では、レビュー回数、バッファ、QA期間を最初から織り込み、後半にしわ寄せが来ないようにします。
社内合意は、関係者を早期に巻き込み、叩き台→小さな合意→確定の順で進めると、手戻りが減ります。

• 仕様は“完璧”より“早い叩き台”で認識合わせを優先する
• 優先順位を明文化し、変更時は影響範囲をセットで提示する
• 決裁者を特定し、決める期限を先に置く
• 議事録で決定事項を固定し、後戻りを防ぐ

ゲームプランナーに向いている人診断（適性・経験・プレイ習慣）

ゲームプランナーの適性は、「ゲームが好き」だけでは測れません。
好きは入口として強い一方で、仕事では“好きなゲームを作る”より“ユーザーに選ばれる体験を作る”視点が求められます。
そのため、論理的に分解できるか、他人に伝えられるか、改善を繰り返せるかが重要です。
ここでは向いている人・向いていない人の特徴と、学生・社会人それぞれが作れる実績の作り方を整理します。

向いている人：論理的に考え、相手に伝え、やり切れるタイプ

向いているのは、面白さを感覚で終わらせず、要素に分解して説明できる人です。
また、チーム開発では自分の正しさよりも、合意形成と前進が優先される場面が多いため、相手の立場を理解して伝え方を調整できる人が強いです。
さらに、リリースまでには地味な調整や修正が大量に発生するので、最後までやり切る粘り強さも重要になります。
ゲームを遊ぶときに「なぜこの導線？」「この報酬量の意図は？」と考える癖がある人は適性が出やすいです。

• 面白さを言語化できる（例：テンポ、学習曲線、報酬設計）
• 相手の専門性を尊重し、合意形成できる
• 改善の反復が苦にならない（仮説検証が好き）
• 締切や品質の責任を持ってやり切れる

向いていない人：曖昧が苦手、調整が嫌、改善の反復が苦痛なタイプ

向いていない可能性があるのは、曖昧な状態を許容できず、最初から正解を求めすぎるタイプです。
ゲーム開発は不確実性が高く、途中で方針が変わることも珍しくありません。
また、調整や交渉を避けたい人は、プランナー業務の中心である“間に立つ仕事”が負担になりやすいです。
さらに、数値調整やテストの反復を単調と感じる場合、運用やバランス系の業務は苦痛になりがちです。

• 仕様変更に強いストレスを感じやすい
• 人に説明するより一人で作業したい
• 細かい調整や検証が苦手
• 批判やフィードバックを受けるのがつらい

学生・社会人別：経験が少なくても作れる実績（作品・企画書）とアピール方法

未経験で最も効くのは、「考えられる」ではなく「作れる・書ける」を見せることです。
学生なら、チーム制作やゲームジャム、企画書、レベルデザイン案などで“完成させた経験”を作れます。
社会人なら、現職の経験をプランナー業務に翻訳し、要件定義、進行管理、データ分析、資料作成などの再現性を示すのが有効です。
共通して、企画書は1本の大作より、短い企画を複数用意し、狙いと差別化を説明できる方が評価されやすいです。

• 企画書：ターゲット/コア体験/差別化/画面案/収益（必要なら）
• 改善提案：既存ゲームの導線や報酬を分析し、施策案を提示
• プロトタイプ：紙/スプレッドシート/簡易ツールでルールを試作
• プレイ記録：気づきと仮説を継続的にまとめる（ブログ/Notion等）

なるには？大学・専門学校・独学のルート比較（入学/学費/コース）

ゲームプランナーになるルートは大きく「大学」「専門学校」「独学＋就職/転職」の3つです。
どれが正解というより、あなたの状況（学歴、年齢、資金、時間、作りたい領域）で最適解が変わります。
重要なのは、どのルートでも最終的に“ポートフォリオ（企画書・仕様・実績）”で勝負になる点です。
ここでは、各ルートのメリット・注意点を比較し、選び方の基準を作ります。

大学で学ぶメリット：専攻の選び方（情報/心理/経営など）と就職での活かし方

大学のメリットは、ゲームに限らない基礎力を積み上げられる点です。
情報系ならプログラミングやデータ分析の素養がつき、運用や仕様理解で強みになります。
心理学はユーザー行動や動機づけの理解に役立ち、経営・マーケは市場分析や収益設計の会話がしやすくなります。
ただし大学は制作実習が少ないことも多いため、サークル、ゲームジャム、個人制作で“アウトプット”を補うのが必須です。
就職では、専攻で得た強みを「プランナー業務にどう効くか」で翻訳して語れると評価されます。

• 情報：仕様理解、データ分析、エンジニアとの会話がスムーズ
• 心理：チュートリアル設計、継続動機、UXの説明に強い
• 経営/マーケ：市場・競合、KPI、施策設計の説得力が増す
• 補強：ゲームジャム参加、企画書作成、分析記事の発信

専門学校の強み：キャンパス環境、ゲーム開発コース、制作実習で実務に近づく

専門学校の強みは、制作実習とチーム開発の機会が多く、実務に近い経験を積みやすいことです。
プランナー志望でも、仕様書、レベル設計、イベント設計、プレゼンなどを授業で回し、ポートフォリオを作りやすい環境があります。
また、現役講師や企業連携がある学校では、レビューの観点が実務寄りになり、就職活動での武器になりやすいです。
一方で学校によって質の差が出るため、卒業制作のレベル、就職実績、カリキュラム（運用/分析の有無）を事前に確認するのが重要です。

• 制作実習：企画→仕様→実装→テストの流れを体験できる
• チーム開発：調整・合意形成の経験が積める
• 就職支援：ポートフォリオ添削、企業説明会、OB/OG情報
• 確認点：卒業制作の公開物、講師の経歴、就職先の内訳

独学でなる方法：企画書作成、ゲーム分析、プロトタイプ、プログラミングは必要？

独学は、最短距離でアウトプットに集中できるのが魅力です。
まずは企画書をテンプレ化して複数作り、次に既存ゲームの分析→改善提案をセットでまとめると、思考の再現性を示せます。
プロトタイプは、紙でもスプレッドシートでも構いません。
プログラミングは必須ではありませんが、簡単な実装ができると検証速度が上がり、エンジニアとの会話もスムーズになります。
独学の弱点はフィードバック不足なので、ゲームジャム、コミュニティ、SNS発信などで他者レビューを取りに行くのが成功の鍵です。

• 企画書：短い企画を量産し、狙いと差別化を説明できるようにする
• 分析：面白さ/離脱/課金導線を分解し、改善案まで書く
• 試作：紙・表計算・簡易ツールでルールを検証する
• 学習：Unity等は“必要になったら”でOK、目的は検証速度

未経験からの準備チェックリスト：ポートフォリオ、プレイ記録、改善提案

未経験から応募するなら、採用側が知りたいのは「現場で伸びるか」と「最低限の実務ができそうか」です。
その判断材料になるのが、ポートフォリオと、思考プロセスが見える記録です。
企画書は1本だけだと偶然に見えることがあるため、複数本＋改善提案＋仕様サンプルがあると強いです。
また、プレイ記録は“感想”ではなく、仮説と根拠（どこでそう感じたか）をセットにすると、プランナーらしさが出ます。

• 企画書：3〜5本（短くても良い、狙いが明確なもの）
• 仕様サンプル：画面遷移、例外、数値表を含むミニ仕様
• 改善提案：既存タイトル1本を深掘り（課題→施策→期待効果）
• プレイ記録：気づきの蓄積（Notion/スプレッドシート等）
• チーム経験：ゲームジャムや共同制作の役割と成果

資格は必要？ゲームプランナーに役立つ知識と取得の考え方

ゲームプランナーに必須の国家資格のようなものは基本的にありません。
採用では、資格よりもポートフォリオ、実務経験、思考の再現性が重視されます。
ただし、未経験や異業種からの転職では、基礎力の証明として資格学習が役立つケースがあります。
重要なのは、資格を取ること自体ではなく、学んだ内容を「企画・仕様・改善」にどう活かすかを説明できることです。

結論：必須資格は少ないが、基礎力の証明に有効なケース

結論として、資格は“必須ではないが、状況によっては有効”です。
特に未経験の場合、学習の継続性や基礎知識の担保を示す材料になります。
一方で、資格だけではプランナー適性（企画力、仕様化、調整力）は伝わりにくいので、必ずアウトプット（企画書、改善提案）とセットにしましょう。
資格はゴールではなく、ポートフォリオの説得力を上げる補助輪として使うのが現実的です。

役立つ領域：マーケティング/データ分析/プロジェクト管理/文章術

役立つ知識領域は、運用・分析・進行に直結するものです。
マーケティングはターゲット設計や施策の意図説明に、データ分析はKPI改善に、プロジェクト管理は進行の安定化に効きます。
文章術は仕様書の読みやすさに直結し、地味ですが差が出ます。
どの領域も、学んだフレームを使って「実際のゲームを分析した例」を作ると、学習が実務に接続されます。

• マーケ：STP、4P、ユーザー理解、施策設計の考え方
• データ：基本統計、SQL/スプレッドシート、ABテストの概念
• PM：WBS、リスク管理、見積もり、合意形成
• 文章：構造化、要点整理、仕様の曖昧さを消す書き方

資格より効く：コンフィデンス（Confidence）など業界情報の読み方と学習習慣

資格以上に効くのが、業界情報を継続的に追い、仮説を持って学ぶ習慣です。
例えば業界紙やニュース（例：コンフィデンス等）で、ヒット作の動向、企業の決算、トレンド（プラットフォーム、課金モデル、IP活用）を追うと、企画の解像度が上がります。
大事なのは、情報を集めるだけでなく「なぜこの施策を打ったのか」「どのKPIを狙ったのか」を自分なりに推測し、企画書や改善提案に落とし込むことです。
この習慣がある人は、入社後の伸びしろが大きいと見られやすいです。

• 決算資料：どのタイトルが伸びたか、何に投資しているかを見る
• アップデート履歴：施策の意図を推測し、KPI仮説を立てる
• ユーザーレビュー：不満のパターンを分類し、改善案にする
• 学習ログ：学んだことを短くまとめ、再利用できる形にする

年収の平均は？給与レンジとキャリアパス（アシスタント→リード→ディレクター）

ゲームプランナーの年収は、企業規模、上場/非上場、勤務地、担当領域（運用か新規か）、経験年数で大きく変わります。
平均だけを見ると実態が見えにくいため、「レンジ」と「どの実績で上がるか」をセットで理解するのが重要です。
キャリアは、アシスタント→プランナー→リード→ディレクターのように上がる道もあれば、運用特化やバトル特化など専門性で伸ばす道もあります。
ここでは相場の見方と、評価される実績の作り方を整理します。

年収の相場：企業規模・上場/非上場・勤務地で変わる（平均の見方）

年収相場は、求人票のレンジや口コミサイトの平均だけで判断するとブレます。
上場企業や大手はレンジが高めになりやすい一方、職位や評価制度が明確で、成果が昇給に反映されるまで時間がかかることもあります。
中小やスタートアップは裁量が大きく、成果が出れば上がりやすい反面、プロジェクトの成否で変動しやすい面もあります。
勤務地（東京圏か地方か）でも差が出るため、比較するときは「基本給＋賞与＋手当＋残業代（みなし含む）」の内訳で見るのが安全です。

• 平均値は参考程度にし、求人レンジと職位（ジュニア/リード等）で見る
• みなし残業の有無で見かけの年収が変わる点に注意する
• 運用型は成果が数値で示しやすく、評価に結びつく場合がある

キャリアの分岐：運用特化/企画特化/マネジメント/ディレクターへの道

キャリアパスは一つではありません。
運用特化ならKPI改善や施策設計の専門性を磨き、リード運用やプロダクト責任に近づく道があります。
企画特化なら新規タイトルのコア設計、レベル/バトルの専門性で価値を出す道があります。
マネジメント志向なら、リードプランナーとして複数人の設計を統合し、最終的にディレクターとして意思決定を担う方向に進みます。
自分が「数字が好きか」「体験設計が好きか」「人を動かすのが好きか」で、伸ばすべきスキルが変わります。

• 運用特化：KPI改善→リード運用→プロダクト責任者寄り
• 企画特化：コア設計→リード企画→新規立ち上げの中核
• 専門職：バトル/レベル/経済圏などのスペシャリスト
• マネジメント：リード→ディレクター→制作統括

評価される実績：数値改善、イベント成果、プロジェクト完遂、レビューでの再現性

評価される実績は、「頑張った」ではなく「何をどう変えて、どう良くなったか」を説明できる形です。
運用なら、継続率や売上などのKPI改善を、施策とセットで語れると強いです。
新規開発なら、担当範囲（例：バトル、レベル、UI導線）と、品質を担保してリリースまで完遂した事実が評価されます。
さらに重要なのが再現性で、成功・失敗から何を学び、次にどう活かしたかを語れると、上位職の評価につながります。

• 数値：KPIをどれだけ動かしたか（期間、比較条件も含める）
• 成果：イベントの参加率、完走率、売上貢献など
• 完遂：担当機能を期限内に出し、品質問題を抑えた
• 再現性：仮説→施策→検証の型を持っている

求人の探し方と転職・就職のコツ（未経験/経験者別）

ゲームプランナーの求人は、職種名だけでは実態が分かりにくいのが難点です。
同じ「プランナー」でも、運用中心なのか、新規開発なのか、レベル/バトルなのか、進行管理まで含むのかで必要スキルが変わります。
そのため、求人票では担当範囲と成果物、使用ツール、KPI責任の有無、開発体制を読み解くことが重要です。
未経験は入口戦略、経験者は実績の数値化と棚卸しが鍵になります。

求人で見るべき条件：仕事内容、担当範囲、スキル必要要件、OKラインを読む

求人票で最初に見るべきは、仕事内容の“動詞”です。
「仕様書作成」「パラメータ設計」「KPI分析」「イベント企画」「進行管理」など、何をするかが具体的に書かれているほど、入社後のギャップが減ります。
次に、必須要件と歓迎要件を分けて読み、必須の“最低ライン”を満たせるかを判断します。
また、運用型ならKPI責任の範囲、コンシューマなら担当領域（レベル/バトル等）を確認し、自分のポートフォリオと一致させるのがコツです。

• 担当範囲：新規/運用、レベル/バトル/イベント/シナリオ等
• 成果物：企画書、仕様書、遷移図、パラメータ表の有無
• 体制：ディレクターの有無、レビュー頻度、分業か兼務か
• ツール：Excel/スプレッドシート、Confluence、Jira等
• OKライン：必須要件を満たし、歓迎要件は“伸びしろ”で補う

未経験転職：アシスタントプランナーから入る戦略と面接での質問対策

未経験は、いきなり主担当よりもアシスタントプランナー（AP）から入る戦略が現実的です。
APでは、データ入力、マスタ作成、テスト、仕様補助、運用補助などを通じて、開発の型を学べます。
面接では「なぜプランナーか」「どの領域に興味があるか」「どんなアウトプットを作ったか」を必ず聞かれるため、企画書や改善提案を持参し、説明できるようにしましょう。
また、好きなゲームの話は“分析”として語ると評価されやすく、感想だけだと弱くなります。

• 入口：AP/運用補助/レベル補助など、実務に触れる枠を狙う
• 面接準備：企画書の狙い、差別化、実現性を3分で説明できる
• 質問対策：失敗経験→学び→次の改善案まで語れるようにする
• 逆質問：担当範囲、レビュー体制、仕様変更の決め方を確認する

経験者転職：職種の棚卸し、実績の数値化、企画書・仕様書でアピール

経験者は、職務経歴書の棚卸しが勝負です。
「何を担当したか」を機能単位で分解し、成果を数値で示します。
運用ならKPI、開発なら担当領域と品質（不具合件数、手戻り削減、リリース達成）など、比較可能な形にすると強いです。
また、企画書や仕様書は守秘に配慮しつつ、構造や書き方が分かるサンプルを用意すると、即戦力の説得力が上がります。

• 棚卸し：担当機能、役割、関係者、意思決定範囲を整理する
• 数値化：KPI改善、イベント成果、工数削減などを可能な範囲で提示
• 資料：匿名化した仕様サンプル、画面遷移、パラメータ設計例
• 再現性：成功要因と失敗要因を言語化し、次に活かす姿勢を示す

企業選び：プロジェクト体制、社内文化、開発工程、運用有無でミスマッチ回避

ミスマッチを避けるには、企業の“作り方”を確認することが重要です。
同じプランナーでも、裁量が大きい会社もあれば、ディレクターの指示を仕様に落とす比重が高い会社もあります。
また、運用があるかどうかで働き方が変わり、イベント締切が連続する体制か、買い切りで区切りがある体制かも異なります。
面接やカジュアル面談では、レビュー頻度、仕様変更の決め方、KPI責任、残業の発生しやすい時期などを具体的に聞くと、入社後のギャップを減らせます。

• 体制：意思決定者は誰か、プランナーの裁量はどこまでか
• 工程：仕様確定のタイミング、レビュー文化、QA体制
• 運用：イベント頻度、年間計画の有無、KPI責任の範囲
• 文化：議論の仕方、ドキュメント文化、コミュニケーションの密度
• 確認方法：逆質問で具体例を聞き、抽象回答なら深掘りする

達川 真人

新宿区在住45年
ライター兼AV男優

新宿区を愛する、新宿生まれ新宿育ちの45歳
HR周りの情報ライターとして活動しつつ、趣味が高じてAV男優として40歳で堂々デビュー
さまざまな職場経験から語られる真相を抉り出す作風に定評あり