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

XRエンジニアのスキルシートは、冒頭で「どの用途の体験を、どのデバイスに、どの開発環境で作り、どの役割を担ったか」を示し、プロジェクトごとに実機で解いた問題と、配布や現地での導入まで担った範囲を書くのが基本です。XRの経験は「VRアプリ開発」と一言でまとめられがちですが、それでは読み手が自分の案件と近いかを判断できません。

全体の構成はスキルシートの基本で解説しています。Unityの版やレンダーパイプラインの書き方はUnityエンジニアのスキルシートの書き方にまとめているため、この記事ではXRに特有の書き方に絞って説明します。

要約は「用途・デバイス・開発環境・役割」の4点で書く

案件の担当者は、要約を読んで「自分の案件に近い経験か」を最初に判断します。XRの場合、次の4点が分かれば判断しやすくなります。

要約の1〜2行目には、軸の用途と役割を書きます。「製造業の作業訓練を中心に、スタンドアロン型ヘッドセット向けの開発と、複数台への導入までを担当」のように、1文で全体像が伝わる形が理想です。

デバイスと開発環境は「組み合わせ」で書く

XRでは、同じエンジンでも、どのデバイスにどの仕組みで出したかで経験の中身が変わります。デバイスの名前と開発環境を別々に並べるより、組み合わせで書くと読み手に伝わりやすくなります。

OpenXRはKhronos Groupが策定する共通のAPIで、Khronosの公式ページ（2026年10月時点）では多くの提供元の実装が適合済みとして掲載されています。一方、Appleの開発者向けページでは、visionOSの開発はXcodeとvisionOS SDKを起点にSwiftUIやRealityKitで行う形が案内されています。どちらの経験なのかを書き分けておくと、面談で前提の確認に時間を取られにくくなります。Androidの公式ページで案内されているAndroid XRのように新しいプラットフォームに触れた経験も、試した範囲を正直に書けば判断材料になります。

実機で解いた問題を書く

XRの経験で読み手が一番知りたいのは、実機で何が起き、どう解決したかです。次の順で書くと伝わりやすくなります。

1. 任された範囲：どの体験、どの仕組みを担当したか
2. 実機で起きた問題：処理落ち、表示の位置のずれ、操作の分かりにくさ、酔いやすさなど
3. 方法：何を測り、何を変えたか
4. 結果：目標を満たしたか、利用者の反応がどう変わったか（数値は出せる範囲で）

「最適化を担当」と書くより、「大型設備のモデルを表示する場面で目標のフレームレートを下回っていたため、実機で計測して描画の負荷が原因と特定し、距離に応じて表示を切り替える仕組みを入れた」と書くほうが、同じような課題を持つ案件の担当者に響きます。

体験の質に関わる工夫も書く

移動の方法、文字の大きさと距離、初めて使う人への案内など、体験の質を上げた工夫は、XRならではの実績です。発注元や利用者の声を受けて直した経験があれば、何を変えたかを短く書いておきましょう。

配布・運用・現地作業の経験を書く

研修や展示の案件では、開発だけでなく、複数台への配布、更新、会場や現場での設置まで担える人が求められます。次のような経験は、項目を分けて書いておくと判断材料になります。

• 台数と配布の方法：何台のデバイスに、どの方法で入れて更新したか
• 現地作業：工場、病院、展示会場などでの設置、位置合わせ、試運転
• 運用の引き継ぎ：発注元の担当者向けの手順書を作り、引き継いだ
• 体制：発注元の担当者、3Dアーティスト、業務の専門家とどう分担したか

動画やデモの扱い

XRの経験は文章では伝わりにくいため、動画やデモを添えたくなります。ただし、業務用のアプリは発注元の設備や業務手順が映るため、外に出せないことがほとんどです。次のように分けて扱いましょう。

• 公開されている体験：ストアのページや公開済みの紹介動画など、誰でも見られるものだけを示す
• 公開できない体験：動画は添えず、用途と規模をぼかして文章で説明する
• 自分で作った検証：個人で作ったデモやリポジトリを、補足として示す

考え方はスキルシートと守秘義務の記事、個人の作品の見せ方はGitHubとポートフォリオの記事で解説しています。

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

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

案件概要：（架空）建設会社向け 施工現場で完成形の3Dモデルを重ねて確認するMRアプリの開発
期間・体制：（架空）約1年、エンジニア3名・3Dデザイナー1名
使用技術：C#、Unity、OpenXR、各社の空間認識の拡張機能、Git
デバイス：MR対応のスタンドアロン型ヘッドセット
担当：BIMデータの取り込みと軽量化の仕組み、現実の空間との位置合わせ
解いた問題：屋外に近い環境で表示の位置がずれやすかったため、基準となる目印を使った位置合わせの手順を設計し、現場の担当者だけで合わせ直せるようにした
現地作業：現場での試運転に複数回立ち会い、手順書を作って引き継いだ

案件概要：（架空）医療系の教育機関向け 手技の手順を学ぶVR研修アプリの改修
期間・体制：（架空）約8か月、エンジニア2名、監修の専門職と定例で確認
使用技術：C#、Unity、OpenXR、Git
デバイス：スタンドアロン型ヘッドセット2機種
担当：2機種の入力の違いを吸収する層の設計、手の追跡を使った操作の実装
解いた問題：コントローラーに慣れない受講者がつまずいていたため、手の追跡での操作を主にし、迷ったときに案内が出る仕組みに変えた
配布：研修で使う複数台への配布と更新の手順を整えた

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

プロジェクト欄とは別にスキル一覧を作る場合、XRでは次のように分けておくと、読み手が判断しやすくなります。

新しいデバイスやプレビュー段階のSDKは、触れたことがあるだけでも関心を示す材料になりますが、実務の経験と同じ欄に並べると誤解を生みます。区分を分けて正直に書くことが、面談での信頼につながります。

よくある質問

触ったことのあるデバイスは全部書いたほうがよいですか？

全部並べるより、開発して公開や納品まで担当したデバイスと、検証で試した程度のデバイスを分けて書くほうが伝わります。「どこまで作ったか」が分かると、読み手は案件との距離を判断しやすくなります。

展示用の短期の案件が多い場合は、どうまとめればよいですか？

一つずつ書くと長くなるため、似た案件をまとめて「展示用の体験コンテンツ（短期・複数件）」とし、代表的なものを1〜2件詳しく書く形がおすすめです。現地での設置や来場者対応の経験も書いておきましょう。

面談では何を聞かれますか？

スキルシートに書いた実機での問題の解き方や、デバイスの選び方を深く聞かれることが多くあります。質問の傾向と答え方はXRエンジニアの面談の記事で扱います。