Unityエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

Unityエンジニアのスキルシートは、最初に「どの領域で、どのUnityの版を、どのプラットフォームに出したか」を示し、プロジェクトごとに自分の役割と解いた問題を書くのが基本です。Unityはゲーム・XR・産業用途と使われる領域が広く、同じ「Unity経験◯年」でも中身がまったく違います。読み手が領域と環境を取り違えないように書くことが、最初の関門です。

全体の構成はスキルシートの基本で解説しています。この記事では、Unityのエンジニアが書くときに迷いやすい部分に絞って説明します。

要約は「領域・版・プラットフォーム・役割」で書く

案件の担当者は、まず自分の案件と近い経験があるかを見ます。Unityの場合、次の4点が分かれば、読み手は判断しやすくなります。

要約の1〜2行目には、軸の領域と役割を書きます。複数の領域を経験している方は、応募する案件に近い領域を上に持ってきます。

Unityの版とレンダーパイプラインを正確に書く

Unityの版は、プロジェクトの環境そのものを表します。Unity 6以降は、Unityのマニュアルでも「6000.3」「6000.6」のように番号が振られ、LTS版とUpdate版が並んでいます。シートでは、担当した期間に使っていた版を書きます。版上げを担当した場合は、前後の版を矢印でつなぐと伝わりやすくなります。

あわせて、レンダーパイプライン（Built-In・URP・HDRP）、主に使ったパッケージやSDK、バージョン管理の方法も書いておきます。どのLTS版がいつまでサポートされるかなどの動向はUnityエンジニアの将来性の記事で扱っていますが、シートでは版を正確に書くことと移行した場合は前後を書くことで十分に伝わります。

役割と「解いた問題」を書く

Unityのプロジェクトは、エンジニアの役割の幅が広く、担当範囲を書かないと読み手は判断できません。工程の名前より、何を任され、何を解決したかを書きます。

1. 任された範囲：どの機能のまとまり、どの仕組みを担当したか
2. 解いた問題：性能、不具合、作業の流れなど、何が困っていたか
3. 方法：どう調べ、何を変えたか
4. 結果：何が良くなったか（数値は出せる範囲で）

「性能改善を担当」と書くより、「低い性能の端末で起きていた処理落ちを、Profilerで描画の回数が原因と特定し、まとめて描く仕組みに変えた」と書くほうが、任せられる深さが伝わります。

他の職種との関わりも書く

Unityの開発では、デザイナー、アーティスト、プランナーとの受け渡しが仕事の大きな部分を占めます。エディタ拡張で入力のツールを作った、アセットの命名ルールを決めて自動で検査した、といった経験は、チーム全体への貢献として評価されます。実装の行とは分けて書くと目に留まりやすくなります。

実機と現地作業の経験も書いておく

XRのヘッドセット、家庭用ゲーム機の開発機材、産業用の設備や車載の機器を使った経験は、同じような体制の案件で判断材料になります。「展示会場での設置と調整を担当」「シミュレーターの筐体と通信する部分を実装」のように、機材と作業の場所が分かるように書きます。

スキル一覧は「使える深さ」で分ける

プロジェクト欄とは別にスキル一覧を作る場合、技術の名前を並べるだけでなく、使える深さで分けておくと読み手が判断しやすくなります。たとえば「設計から任せられる」「実装で日常的に使った」「触れたことがある」の3段階に分け、Unityの版、レンダーパイプライン、プラットフォーム、SDK、バージョン管理、ビルドの自動化の仕組みなどを振り分けます。触れた程度の技術を上の段に書くと、面談で深く聞かれたときに答えに詰まる原因になります。

守秘義務とタイトル名の扱い

Unityのエンジニアが迷いやすいのが、関わったタイトルや製品の名前をどこまで書くかです。公開されたタイトルでも、開発に関わった会社や担当範囲を外に出してよいかは、契約や在籍した会社の方針によって違います。

• 書いてよいか分からないもの：タイトル名を伏せ、「運営中の対戦型モバイルゲーム」のように種類と規模で書く
• 未発表のもの：ジャンルや用途もぼかし、技術的な内容だけを書く
• 数値：売上やユーザー数などは書かない。性能の改善は「読み込み時間を半分程度に」のように比率で書くか、書かない

考え方はスキルシートと守秘義務の記事で解説しています。個人の作品は、補足としてストアのページやリポジトリ、動画のURLを載せてかまいません。見せ方はGitHubとポートフォリオの記事を参考にしてください。

プロジェクト欄の記入例（架空）

次は書き方の型を示すための架空の記入例です。実在の案件・タイトル・会社ではありません。ご自身の経験に置き換えてください。

期間：○年○月〜○年○月（1年程度）
案件概要：（架空）製造業向け 設備の操作訓練用XRアプリの開発
規模・立場：全体十名程度、うちUnityのエンジニア数名（機能リード）
使用技術：C#、Unity 2022.3→Unity 6.0（版上げを担当）、URP、OpenXR、Git
プラットフォーム：スタンドアロン型のXRヘッドセット、Windows PC
担当内容：訓練の手順を進める仕組みの設計と実装。CADから変換した設備の3Dモデルの取り込みと軽量化の手順づくり
解いた問題：ヘッドセットで描画が重くなる場面を計測し、モデルの分割と表示の切り替えで目標のフレームレートを保てるようにした
その他：訓練の担当者に向けた手順の入力ツールをエディタ拡張で作成。導入時は現地で設定と動作確認を担当

期間：○年○月〜○年○月（2年程度）
案件概要：（架空）運営中のモバイルゲームのクライアント開発
規模・立場：クライアントのエンジニア十名程度（メンバー）
使用技術：C#、Unity 2021.3、Built-In Render Pipeline、Android、iOS
担当内容：イベントの画面と機能の実装、アセットの読み込みの仕組みの改修
解いた問題：イベント開始時に読み込みが長くなる問題について、読み込むアセットの単位を見直し、待ち時間を短くした

この例では、領域、版と版上げ、プラットフォーム、全体の中での位置、解いた問題が読み取れる形にしてあります。

よくある質問

ゲームと産業用途の両方の経験がある場合、どう書けばよいですか？

応募する案件に近い領域を上に持ってきて、もう一方は別のまとまりとして書きます。共通して使える経験（性能の改善、エディタ拡張、版上げなど）は、それぞれのプロジェクトの中に具体的に書くと、領域をまたいだつながりが伝わります。

個人で公開しているゲームは、スキルシートに書いてよいですか？

書いてかまいません。ただし、仕事としてのプロジェクトとは欄を分け、補足として載せます。使った版や技術、自分で工夫した点を短く添えると、技術の力を示す材料になります。

Unity以外のエンジンの経験も書いたほうがよいですか？

書いておくと判断材料になります。ほかのエンジンでの描画や性能の経験は、Unityの案件でも生かせる部分があるためです。スキル一覧ではUnityと分けて、期間と使い方の深さを書いてください。ゲームの領域全体での書き方はゲームエンジニアのスキルシートの記事で扱います。