Unityエンジニアの参画初月にやること｜現場で信頼される進め方

Unityエンジニアの参画初月は、プロジェクトの版と構成、ビルドと実機確認の手順をつかみ、小さな変更を一度最後まで通し、月末に「気づいた課題」と「改善の案」を出すところまでを目標にします。最初の1か月で求められるのは、大きな機能を作ることより、この人なら既存の作りを壊さずに任せられると発注側が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、Unityならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：環境をそろえ、構成をつかむ

最初にそろえるもの

Unityの案件は、環境がそろわないと何も始められません。初日から数日のうちに、次の順で確かめます。

1. Unityの版：プロジェクトが固定している版と同じものを入れる。新しい版で開くと変換が走るため、開く前に確かめる
2. ライセンスとアカウント：どのシート（ライセンス）で作業するか、組織への招待が済んでいるか
3. リポジトリと大きなファイルの扱い：ブランチの運用、大容量のアセットの管理方法、最初の取得にかかる時間
4. ビルドの手順：手元でのビルド方法と、自動ビルドの仕組みがあるか
5. 実機と機材：検証用の端末やヘッドセット、開発機材の場所と借り方

環境の再現でつまずいた点は、そのままメモに残しておきます。次に入る人が同じところで止まらないよう、後で共有できる形にしておくと、それ自体が小さな貢献になります。

構成を読む

環境がそろったら、プロジェクトの構成を読みます。見る順番は次のとおりです。

• 起動から最初の画面までの流れ（最初に読み込まれるシーンと、初期化の処理）
• フォルダとアセットの置き場所、命名の決まり
• 使っているパッケージとプラグイン、レンダーパイプラインの設定
• シーンとPrefabの分け方、誰がどこを触るかの決まり
• 調整用のデータの持ち方（プランナーが値を変える仕組み）

この段階では、良し悪しを判断しません。「なぜこうなっているのか分からない」点は、仮の疑問としてためておきます。

2週目：小さな変更を最後まで通す

最初の作業は小さく選ぶ

2週目には、小さな不具合の修正や、既存の画面の改修など、影響範囲が限られた作業を一つ引き受けます。目的は成果の大きさではなく、実装からレビュー、ビルド、実機確認、取り込みまでの流れを一度通すことです。流れを一度通すと、その現場で何に時間がかかるか、誰の確認が要るかが見えてきます。

実機で確かめてから報告する

変更したら、エディタ上だけでなく、対象の実機で動作を確かめます。報告には、どの機種で、どの場面を確かめたかを添えます。実機が手元にない場合は、確かめられていない範囲をはっきり書いておきます。

報告の形を合わせる

窓口やリードに、どの頻度で、どの粒度の報告がほしいかを確かめます。チャットでの報告の工夫はチャットでの報告の記事、リモート中心の案件での進め方はUnityエンジニアのリモートの記事でも触れています。

3〜4週目：課題を整理し、改善の案を出す

気づいた課題をまとめる

1〜2週目にためた疑問と、作業の中で困った点をもとに、課題を整理します。Unityの現場で挙がりやすいのは、次のような点です。

• ビルドに時間がかかる、手順が人によって違う
• 特定の機種で重い場面がある、メモリの使用量が多い
• シーンやPrefabの衝突が起きやすい
• 版やパッケージが古く、更新の計画が決まっていない
• 調整用のデータを変えるたびにプログラマの作業が要る

改善の案は選択肢で出す

課題を並べるだけでなく、取れる手と、それぞれにかかる手間、影響を添えて出します。一つの案だけを出すと、「今の作りを否定された」と受け取られやすくなります。どれを進めるかは、リードや発注側に選んでもらいます。性能の課題であれば、計測した機種と数字の取り方を添えると、判断の材料になります。

案件の型によって初月の重心は変わる

同じUnityの案件でも、型によって初月に力を入れる場所が違います。

運営中タイトルの改修・保守

既存のコードとアセットが大量にあり、壊さないことが何より大切です。初月は、構成を読む時間を多めにとり、変更の前に影響範囲を確かめる習慣を示すことに重心を置きます。

版上げ・移行の案件

最初の数週間は調査が中心になります。使っているパッケージとプラグインの一覧、新しい版で動かなくなるものの洗い出し、確認が要る機種の一覧を作り、月末に移行の順番の案を出せることを目指します。

XR・産業用途の案件

機材や設備がないと確かめられない作業が多く、出社や現地での確認の段取りが初月の要になります。どの機材をいつ使えるか、現地での確認に誰が立ち会うかを早めに決めておきます。

新規開発・立ち上げの案件

まだ構成が固まっていない段階で入る場合は、構成の方針、アセットの管理、ビルドの仕組みを関係者と言葉で合わせることが初月の中心になります。月末には、構成の骨子と、決めきれていない論点の一覧を出せることを目指します。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事、Unityでつまずきやすい場面はUnityエンジニアのフリーランスがつまずきやすい点と対策で整理しています。前任者からの引き継ぎがある場合は引き継ぎの記事も参考になります。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• プロジェクトの版、構成、ビルドの手順を、自分の言葉で説明できるか
• 小さな変更を、実機確認まで含めて最後まで通せたか
• 気づいた課題と改善の案を、リードや窓口に伝えられたか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 機材やライセンスの扱いで、困っていることが残っていないか
• 稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。ゲームの領域全体の初月の進め方はゲームエンジニアの参画初月、XRの場合はXRエンジニアの参画初月も比べてみてください。

よくある質問

環境がそろわず、最初の数日作業ができません。どうすればよいですか？

何が足りず、誰の対応を待っているかを窓口に伝え、待っている間にできることを提案します。構成の資料やコードを読む、手順書の抜けを書き留める、といった作業は環境がそろう前でも進められます。待ちが長引く場合は、その状況を記録に残しておくと、稼働の扱いを相談するときの材料になります。

初月から大きな機能の実装を任されたら、どうすればよいですか？

引き受ける場合でも、最初に既存の構成と影響範囲を確かめる時間をとり、途中の段階で一度レビューを受ける形を提案するのがおすすめです。早い段階で方向のずれを直せると、手戻りが小さくなります。

既存のコードの質が低いと感じたら、すぐに指摘してよいですか？

初月は、なぜその作りになっているのかを理解することを優先します。納期や過去の事情で今の形になっていることも多いためです。気づいた点は課題の一覧にためておき、月末に、影響と直す手間を添えた改善の案としてまとめて伝えるほうが、受け入れてもらいやすくなります。