はじめに

株式会社QualiArtsでUnityエンジニアをしている入社1年目の岩井春樹です。2021年6月リリースの「IDOLY PRIDE」（以降、アイプラ）のアウトゲーム開発に携わっています。配属から半年が経ち、開発の進め方も徐々に慣れてきました。 本記事では配属当初、開発力ほぼ0だった自分が、Unityエンジニアとして実際に開発を行っていく中で「学んだこと」、「つまずいたこと」について振り返ってみます。

入社時の技術力

大学1年の時にUnityを知り、入門書などを参考に個人で簡単なゲーム開発を行なっていました。当時は、設計や共通化などの知識や考えは一切なく、実装したい機能を思いつくたびに同じコードやオブジェクトを作成していたりしました。

実際の開発でつまずいたこと

配属されてからの半年間、細かな機能修正から、ピックアップガチャやボックスガチャ機能の追加など、様々なタスクに携わって参りました。そしてタスクをこなしていく上で成長を感じることもあれば、反省して改善していくべきことも多く見つかリました。

そもそもコードが追えない

サイバーエージェントでは内定から入社までの間に、実際の業務を経験できる仕組みがあります。しかし、私はこちらを利用していなかったため、入社するまで企業レベルのコードを読む機会がありませんでした。 先に業務に携わっていた同期のエンジニアからは「最初は全くコードが読めなかった」という話を聞いていましたが、「まぁ少しくらいは読めるだろう」という甘い気持ちでいました。 そして配属後、環境構築も問題なく完了して実際のコードを見ると、誇張なしで本当にほとんど読めませんでした。これは完全に自分の知識・技術不足が原因なのですが、ここまで読めないのかと今後への不安を感じていたことを覚えています。

設計思想が分からない(MVPパターン)

私がコードを全く追えなかった１番の要因が設計思想を全く勉強してこなかったためです。アイプラのクライアントではMVPパターンによって開発が行われています。 学生時代、我流のコードで思いつきの実装ばかり行ったきた私は、MVPパターンが分からず「どこに何の情報があるのか」、「どこに繋がるコードなのか」すら分からない状態でした。

そんな状態を抜けるために私は、いきなり実際使われているコードを読むのは無理があると思い、まずはMVPの概要についてから学習を進めました。 具体的には、こちらの記事を読んでから実際に手を動かし、また新しく分からないことが見つかると再び記事を読むというサイクルを繰り返してきました。 ある程度概要が分かるようになった後は、学んだ内容が実際のコードではどの部分に当てはまるのかを意識してコードを読むことによってさらにMVPについての理解を深めていきました。 その結果、全く読めない状況から少しずつコードを追えるようになりました。

私のように我流のコードで、実装したい機能を思いついた方法でとりあえず試してみてるという方、実は少なくないのではないでしょうか？Unityを始めて日が浅い内は、Unityの機能に慣れるという意味でも悪くないかもしれないです。しかし、ずっとそのような開発を進めていくと、いつかチームで開発を行っていく時必ず後悔すると思います。 この記事を読んで自分にも当てはまると思った方、今日から少しずつでも設計を意識してみると将来役に立つと思います。

UniTask、UniRxなどのライブラリを使いこなせていない

UniTask、UniRxといえばUnity向けのC#ライブラリです。詳しくは分かっていないけど名前は知ってる、少しくらいは触ったことがあるという方も多いと思います。実際私も入社当時は、コードを見て実際にどこで使われているかは分かる程度の理解度でした。そのため、最初はMVPパターンが理解できていなかったことも加わって、なぜそこで使われているのかが分からず、曖昧なままタスクをこなそうとして、後から大変な思いをした経験もありました。

今でもUniTaskとUniRxを完全に理解しているわけでは全く無く、まだまだ分からないことばかりです。ただ、入社したばかりの頃とは違い、分からないことが見つかるたびに調査を行い実際に試してみて、もう一度使われている部分を見てみるというサイクルを繰り返し、曖昧なままにしないよう行動できるようになりました。

スケジュール計画、工数見積もりの難しさ

配属後から小さめの改修タスクをこなし、理解できる部分が増えてきた頃に、今までより大きめのタスクを頂く機会がありました。そこで初めて本格的に工数出しや見積もりを行いました。 その時、「この部分の実装に今の自分の技術力なら何日必要なのか」、「期限から考えてどの程度の工数を取るべきなのか」などを自分のことなのに全く想像できませんでした。結果としてそのタスクは、見積もりの甘さが原因で自分が出した工数通りに進めることができず、当初予定されていた全ての部分を担当することができませんでした。 当時はこんなに上手くいかないのかとめちゃくちゃ落ちこみましたが、この経験があるからこそ工数見積もりには、自分の実力を把握してどこに比重を置くべきか意識することが重要だと学べました。

開発を通して学んだこと

調査を行い、根拠を持って実装を行う

「既存のコードを改修する」、「新しくコードを追加する」そのどちらにしても事前に調査を行い、根拠を持った実装を行うことが重要だと学びました。 もし根拠を持てないまま実装を進めてしまうと様々な危険性を排除できず、チーム全体に迷惑をかけてしまう可能性があります。 これらの事を踏まえた上で私は、実際に開発を進めていくときに感じた危険性に対してどのような対策を取るべきか考え、意識していくことが重要だと学びました。

ヒアリングの仕方

既存コードを更新する場合など、前任者にヒアリングすることがあります。しかし、質問内容が固まっていない状態でヒアリングを行なってしまうと、相手の方に余計な手間や時間をかけさせてしまいます。 実際私も頭の中では意見が纏まっているつもりでヒアリングを行ったのに、いざ質問すると最終的に何を知りたいのかが相手に伝わっておらず、質問予定時間を大幅に超えてしまう失敗をしました。 現在は上記のような失敗を経験したことによって、事前に以下の項目が明確になっているかを確認してから、ヒアリングを行うようになりました。

1. どんな事をやろうとしているのか
2. 今何が聞きたいのか
3. 1と2を聞いた上で懸念点や疑問点があれば質問する

報連相はめちゃくちゃ大事

報連相は社会人として、できて当然のことかもしれません。しかし自分の報告を受ける側になって考えてみると、出来ているつもりになっているだけで、実際には出来ていない場面が多々あったことに気づきました。 特に最初に提出した見積もりから遅れが生じそうな時、「無理すればなんとか終わらせられるかも」と考え共有が遅くなり、余計に迷惑をかけてしまうという失敗経験が一番記憶に残っています。

どうしても計画通りに進まないと焦りや不安から視野が狭くなりがちですが、そんな時こそ自分だけでなんとかできると思わず、今の状況と今後の計画を共有することが自分にもチームにとっても重要だということが学べました。

知らないことを恥ずかしがっていては前に進めない

私がUnityエンジニアとして働いていく上で最も意識していることは、分からないことはちゃんと分からないと言うこと、そして必ずそのままに放置せず、解決方法を模索することです。 当たり前のことかもしれませんが、実際この半年間を振り返ってみて、できていない場面がいくつもありました。 これすら分からないのかと思われることが恥ずかしく、なんとなく分かったフリをすることもありました。ただそれではその場しのぎにしかならず、仕事の場ではチームの方全員に迷惑がかかってしまいます。また実際分からないことを質問して嫌な顔をする先輩は一人もおらず、むしろ理解できるまで丁寧に教えてくださりました。

この時、自分は誰も得をしない全く無意味なプライドを守ろうとしていたんだなと実感しました。 これらの経験から、今の自分を力量を理解して、必要に応じて助言を求めることも、仕事をする上で重要だと学びました。

おわりに

半年間Unityエンジニアとして、アイプラの開発に関わって感じたことをまとめてみました。改めて振り返ってみると、技術的なことから仕事に対する考え方まで半年間で多くのことを経験させて頂きました。 私は、まだまだトレーナーのサポート無しでは担当できるタスクが少なく一人前のエンジニアとしては実力不足です。今後はこの経験を糧にして、先輩方のように開発で貢献できるエンジニアになれるよう努力していこうと思います。

本記事がゲーム開発を目指している方、興味がある方の参考に少しでもなれれば幸いです。