ゲームエンジニアのフリーランス案件｜報酬の決まり方と単価を上げる考え方

ゲームエンジニアのフリーランス案件の報酬は、クライアント・サーバー・エンジンやツール・運営のどこを担うか、開発のどの局面に入るか、どのプラットフォームに対応するか、出社や開発機材の条件、稼働日数、商流で決まります。ゲームエンジニアの単価について公的な統計はなく、同じ「ゲーム開発」でも担当によって案件の性格が大きく変わります。

報酬を上げる近道は、「動く機能を作る人」から「遅い・落ちる・間に合わないを解決できる人」へ役割を移すことです。この記事では、ゲーム開発に特有の報酬の上がり方・下がり方と、案件を比べるときの見方を整理します。報酬の仕組みそのものはフリーランスの単価はどう決まるかで解説しています。

担当する領域で、報酬の決まり方が変わる

ゲームの開発現場では、エンジニアの担当がいくつかに分かれます。どの領域の経験かによって、比べるべき案件も評価の軸も変わります。

同じゲームエンジニアでも、クライアントの機能を作る案件と、エンジンの描画を直す案件では、求められる経験の深さが違います。エンジンやツールの領域は、扱える人が限られるため、条件が高くなりやすい傾向があります。一方で、案件の数は多くありません。

なお、Unityを主に使う案件の報酬の考え方は、Unityエンジニアの記事で扱っています。この記事では、Unreal Engineや自社開発のエンジン、サーバー・運営を含むゲームエンジニア全般の話をします。

開発の局面で求められる役割が違う

ゲームの開発は、企画の検証から運営まで、局面ごとに求められる役割がはっきり変わります。参画する局面によって、評価される経験も、働き方の負担も違います。

報酬が上がりやすいのは、試作・立ち上げで方針を決める役割と、リリース前に性能や品質の問題を片づける役割です。量産の局面は人数が多く、条件が横並びになりやすくなります。

運営の局面は、契約が長く続きやすい点が強みです。その反面、障害のときに呼ばれる当番があるかどうかで、実際の負担が変わります。当番の有無と、その時間の扱いは、月額とあわせて確かめておきましょう。

プラットフォームと開発環境が条件を左右する

ゲームは、家庭用ゲーム機、PC、スマートフォンなど、どこで動かすかによって開発の進め方が変わります。

• 家庭用ゲーム機：開発用の機材や情報は、プラットフォームを提供する会社と取引先との契約のもとで扱われるのが一般的です。機材のある場所での作業が条件になり、出社の多い案件になりやすくなります
• PC：配信サービスごとの対応や、幅広い性能の機器での動作確認が求められます
• スマートフォン：ストアの要件に合わせた更新が毎年のように発生し、運営タイトルではその対応が継続的な仕事になります

家庭用ゲーム機の開発経験は、扱える人が限られる一方で、出社や機材の条件と一体で考える必要があります。報酬だけでなく、通勤の時間や作業場所の制約も含めて比べましょう。

報酬が上がりやすい要素と下がりやすい要素

報酬が上がりやすいのは、次のような経験です。

• 性能の問題を数字で追える：フレームレートの低下、メモリの不足、読み込みの遅さを計測して原因を特定し、直した経験
• エンジンの内側に手を入れられる：Unreal Engineなどのソースに手を入れたり、エディタの拡張やビルドの仕組みを作ったりした経験
• 本番の運営を任された：負荷の高いイベントの前後の備えや、障害時の切り分けを担った経験
• リリースまで持っていった：ストアやプラットフォームの提出の対応まで含めて、出すところまで担った経験

一方で、次の場面では条件が伸びにくくなります。

• 決まった仕様の画面や機能を作るだけの役割が長く続いている
• 担当した範囲を説明できず、チーム全体の成果との区別がつかない
• 開発中に参画と離任を繰り返し、リリースや運営の経験がない
• 特定の社内ツールや自社エンジンの経験だけで、ほかの現場に通じる言葉で説明できない

自社エンジンの経験は、それ自体が弱みになるわけではありません。「描画の負荷をどう測り、どう下げたか」のように、ほかのエンジンにも通じる形で話せれば、評価の材料になります。

稼働の波と契約の形を確かめる

ゲーム開発では、リリース前や大型の更新の前に作業が集中しやすくなります。準委任の契約では、精算の幅（月の基準時間の上限・下限）を超えたときの扱いが、実際の報酬に影響します。

1. 精算の幅：上限を超えたときに超過分が支払われるか
2. 集中する時期：リリース日や更新日が決まっているか、その前後の稼働の見込み
3. 当番の扱い：夜間・休日の待機や呼び出しが、稼働時間に含まれるか
4. 出社の頻度：機材のある場所での作業が、常にか、検証のときだけか

精算の計算方法は精算幅の記事で解説しています。機能の一部を成果物として納める請負の契約では、何をもって完成とするかを先に決めておくことが大切です。違いは準委任契約と請負契約の違いをご覧ください。

単価を上げるための考え方

領域を一つ決め、隣を一つ足す

「クライアント×性能の改善」「サーバー×運営」「エンジン×ツール」のように、軸の領域と、そこに足す経験を決めると、案件の条件と合いやすくなります。軸が決まると、面談で話す経験も選びやすくなります。必要なスキルの全体像はゲームエンジニアに求められるスキルにまとめています。

改善の前後を記録しておく

性能の改善や障害の対応に関わったら、何を測り、何を直し、どう変わったかを記録しておきます。タイトル名を出せない場合も、改善の手順と考え方は次の面談で話せる材料になります。

更新前に、広がった範囲を示す

条件の見直しを相談するときは、次のような事実が材料になります。

• 参画時より広がった担当の範囲（クライアントからサーバー側の調整まで、など）
• 任されるようになったレビューや、新しく入った人への説明
• 改善した性能の指標と、その後の維持の仕組み
• 運営で担った障害対応の件数と、再発を防ぐために整えたこと

伝え方は単価交渉の記事にまとめています。

よくある質問

ゲームエンジニアの単価の相場はどのくらいですか？

ゲームエンジニアの単価について公的な統計はなく、担当する領域、開発の局面、プラットフォーム、出社の条件、稼働日数、商流によって大きく変わります。まず自分の経験をクライアント・サーバー・エンジンやツール・運営に分け、同じ領域の案件どうしで条件を比べると判断しやすくなります。

未発表のタイトルばかりで、実績を話せません。報酬で不利になりますか？

タイトル名を出せなくても、ジャンル・プラットフォーム・担当した領域・改善の手順は、契約の範囲で話せることが多くあります。何をどこまで話せるかは、秘密保持契約の内容によります。考え方は秘密保持契約（NDA）で確認することをご覧ください。

運営の案件と新規開発の案件では、どちらが報酬は高いですか？

一概には言えません。新規開発は立ち上げの局面で条件が高くなりやすい一方、期間が読みにくい面があります。運営は長く続きやすい反面、当番や障害対応の負担が伴うことがあります。報酬の額だけでなく、期間の見通しと負担を並べて比べましょう。独立の準備はゲームエンジニアがフリーランスになるにはで解説しています。