ゲームの企画職に応募しようとすると、最初につまずくのが提出物です。
デザイナーなら作品集、プログラマーならコードやプロジェクトを出せますが、企画職は何を出せばよいのかが分かりにくい。
「面白い企画を考えました」という書類は、それだけでは判断の材料になりません。
ここでは、企画職で何が評価の対象になるのかを整理し、未経験の段階で用意できるものをまとめます。
面接で何を聞かれるかはゲーム業界の面接は何を聞かれる?で扱っており、この記事は選考の前に何を作るかに絞ります。
企画職は作品ではなく判断で見られる
アイデアそのものは評価対象になりにくい
企画職の応募でよくあるのが、思いついた新作の構想を書いて提出する形です。
これは評価につながりにくい提出物です。
理由は単純で、アイデアの良し悪しは検証しないと分からないからです。
読む側は、その案が当たるかどうかを判断できません。
判断できるのは、その案にたどり着くまでに何を見て、何を根拠にしたかのほうです。
見られるのは決めた範囲と、決めた理由
企画職の選考では、担当した仕様の範囲と、その仕様にした理由が中心になります。
数値の設計、進行の導線、報酬の組み立てのうち、どこを自分で決めたかが問われます。
つまり、提出物にも同じ構造が要ります。
何を決めたのか、なぜそう決めたのか、そう決めた結果をどう確認するつもりなのか。
この3つが書かれていない書類は、企画書ではなく感想文として読まれます。
ビジュアル職とは提出物の性質が違う
3DCGやUIのデザイナーであれば、作品そのものが技術の水準を示します。
同じ「モデリング担当」でも、出来上がりを見れば差が分かるためです。
ゲーム業界の採用ニーズは経験・実績・ポートフォリオを持つ即戦力に集中しているとされており(出典: シリコンスタジオエージェント)、制作職ではこの傾向が強く出ます。
企画職の場合、書類の見た目が整っていても中身の水準は分かりません。
評価されるのは資料の完成度ではなく、そこに書かれた判断の筋道です。
この違いを踏まえずにビジュアル寄りの資料を作り込むと、時間の使いどころを外します。
プランナーの仕事は一つではない
仕様を書く役割
レベルデザイン、バトルの設計、UIの導線、チュートリアルの構成といった、ゲームの中身を仕様として定義する役割です。
実装する側が迷わない粒度まで書き下ろす作業が中心になります。
この役割では、曖昧さを残さない書き方ができるかが問われます。
「気持ちよく感じるように」ではなく、数値と条件で書けているかという点です。
運営とイベントを設計する役割
すでに稼働しているタイトルで、イベントの内容、報酬の設計、スケジュールを組む役割です。
既存のユーザーがいる状態で判断するため、前回の結果を踏まえた設計になります。
新規開発とは求められるものが違います。
運営の経験は、数字を見て次を決めた経験として説明できます。
数値を設計し、分析する役割
経済のバランス、成長曲線、確率の設定を決め、稼働後の数値を見て調整する役割です。
分析の担当が別に置かれている会社もあります。
企画職として応募する場合、この3つのうちどこを志望するのかを決めてから準備すると、作るものが定まります。
職種の全体像はゲームのデベロッパーとパブリッシャー、何が違う?にまとめています。
未経験から用意できる提出物
既存タイトルの分析レポート
新作の構想より作りやすく、判断の筋道を示しやすいのが、既存タイトルの分析です。
自分が実際にプレイしたタイトルを一つ選び、特定の仕様がなぜそうなっているのかを説明します。
対象は狭くします。
ゲーム全体を論じるのではなく、チュートリアルの初回30分、報酬の受け取り導線、特定のイベントの設計といった単位に絞ります。
範囲が狭いほど、記述は具体的になります。
構造を先に決める
分析レポートも企画書も、書く順序を先に固定すると迷いません。
前提、課題、打ち手、確認方法の4つで組みます。
| 項目 | 書く内容 |
|---|---|
| 前提 | 対象のタイトル、対象の範囲、想定しているプレイヤー層 |
| 課題 | いまの仕様で何が起きていると考えるか、その根拠 |
| 打ち手 | どう変えるか。数値と条件まで書く |
| 確認方法 | 変えた結果を何の指標で確認するか |
4つ目が抜けている書類が多くあります。
ここが入っているだけで、思いつきではなく検証の前提を持って書いていることが伝わります。
数字の扱いに注意する
分析レポートで気をつけたいのが、根拠のない数字を置かないことです。
売上や利用者数の公開情報は限られており、推測で数値を作ると、その一点で書類全体の信頼が落ちます。
公開されている情報だけで足りない場合は、自分で観測できる範囲に置き換えます。
プレイして計測した時間、操作の回数、到達までの手数であれば、自分の手元で確認できます。
分からない部分は分からないと書くほうが、埋めるより評価されます。
分量より構造
ページ数を増やしても評価は上がりません。
前述の4項目が通っていれば、数ページで足ります。
読む側は複数の応募書類を見ています。
長い資料ほど丁寧だという判断はされません。
書類の準備全体の順序は職務経歴書はいつ作ればよいかにまとめています。
前職の経験をどう接続するか
他業界の経験が対応する場合がある
異業界から入る場合でも、前職の経験が無関係になるわけではありません。
進行管理の経験はプロジェクトマネジメント、データ分析の経験は運営職、接客の経験はカスタマーサポートに対応します。
企画職に近いのは、数字を見て施策を決め、結果を確認した経験です。
業種を問わず、この形の仕事をしていたなら、そのまま書ける材料になります。
説明の単位をそろえる
前職の経験を書くときは、何を担当したかだけでなく、どこまで自分で決めたかを分けます。
決められた施策を実行したのか、施策そのものを設計したのかでは、示せる範囲が変わります。
この分け方は、企画書に求められる構造と同じです。
前職の説明と提出物の構造がそろっていると、書類全体の筋が通ります。
志望動機の組み立て方はゲーム業界の志望動機で見られるのは?にまとめています。
求人とサービスの見方
職種名が会社ごとに揺れる
企画職の募集名は、プランナー、ゲームデザイナー、レベルデザイナー、ディレクター候補と揺れます。
同じ仕事が別の名称で募集されていることがあり、名称だけで検索すると求人を取りこぼします。
そのため、職種名ではなく業務内容の欄を読みます。
仕様を書く仕事なのか、運営の施策を回す仕事なのか、数値の設計をする仕事なのかで、準備する提出物が変わります。
求人票のどこを読むかは求人票のどこを読むかにまとめています。
要件を数えてから作る
提出物を作る前に、求人票の必須要件を10件ほど並べます。
運営の経験を求める募集が多いのか、新規開発の経験を求める募集が多いのかで、書くべき題材が変わります。
会員登録の時点から求人を見られる登録型のサービスは、この作業に向いています。
当サイトのデータでは、G-JOBエージェント、ゲーム転職はシリコンスタジオエージェント、レバテッククリエイター、転職ボックスが登録型で、いずれも全国が対象です。
対象条件を先に確認する
面談を伴うサービスには、対象条件が定められているものがあります。
CREATIVE JOBは面談実施型で、対象年齢20〜49歳、映像・ゲーム・Web・広告関連の業界または職種での経験年数1年以上を条件に挙げています。
AnyKanは面談実施型で、対象は東京都に就職可能な23〜44歳の業界業種実務経験者、対応地域は東京・京都です。
HIGHFIVEは面談実施型で対象年齢20〜49歳、Geeklyは面談実施型で、一都三県での転職を希望する方が対象です。
業界経験を条件にしているサービスが複数あるため、未経験の段階では登録型から始めるほうが進めやすくなります。
方式ごとの違いはゲーム業界は面談なしで求人を見られる?、業界全体の採用傾向はゲーム業界への転職はどう進める?にまとめています。
まとめ
- 企画職はアイデアではなく、仕様を決めた理由と検証の手順で評価される
- ビジュアル職は作品で水準が伝わるが、企画職は資料の見た目では伝わらない
- プランナーの仕事は仕様を書く・運営を設計する・数値を分析するに分かれる
- 提出物は前提・課題・打ち手・確認方法の4項目で組む。
確認方法が抜けやすい - 根拠のない数字を置かない。
分からない部分は分からないと書く - 職種名が会社ごとに揺れるため、求人票は業務内容の欄で読み分ける
- 業界経験を条件に挙げるサービスがあるため、未経験の段階は登録型から始める



