本記事はCraft Egg Advent Calendar 2021の12/15の記事です。
12/14の記事は@YuheiTakagawa さんの「ゲーム業界を志望してなかったサーバエンジニアが知った、ゲームならではの驚きポイント」でした。

#はじめに

株式会社Craft Eggの新卒でUnityエンジニアをしている東です。
今回は、社会人１年目のエンジニアとして仕事をしていく上で心掛けてきたことを書いてみようと思います。

#技術面

技術面では主に設計の基礎的な部分を心がけました。
私自身、チームでの開発経験が多いわけでもなく、大規模なプロジェクトに携わった経験もあまりないので、初めはPRでたくさんレビューコメントをいただいてしまいましたが、基礎的な部分を心がけるだけでも設計に関するコメントは減ったように感じます。
具体的には@Tomy_0331さんの「新卒2年目までに学んだ、コーディングで意識すること」で書かれていることが的確だと思います。
自分は初めのうちは特に以下の事項を意識していました。

メソッドが単一責任になっているか

かなり基本的なことではありますが、メソッドやクラスが役割を持ちすぎていないかという部分を意識しました。
例えば、ユーザ情報を取得するメソッドが内部でデータのパースをしたりしていると拡張性にも乏しく、利用用途も少なからず限定されてしまうため、必要な範囲で汎用的なメソッドを作るようにしました。

ViewやControllerが不適切な役割を担っていないか

これも基礎的なことですが、クラスにはそれぞれ役割が存在します。
ViewがButtonに登録する処理の内容を詳しく知っていたり、逆にControllerがUIの実体を持ってしまっているとコードが把握しづらくなるだけでなく、だんだんとスパゲッティのようになってしまうため、最低限分離させることを意識しました。

コードのレベルは合わせる

コードのレベルを合わせると見通しがよくなって可読性が増します。
逆に、コードのレベルが揃っていないと全体像を把握しづらいだけでなく、その実装には何か特別な意図があるのかと読み手を混乱させてしまうこともあります。

・レベルの揃っていないコード

void Awake()
{
    SetupButton(onClickButtonA);
    ButtonB.RegisterCallback(onClickButtonB);
}

void SetupButton(Action callbackA)
{
    ButtonA.RegisterCallback(callbackA);
}

・レベルの揃っているコード

void Awake()
{
    SetupButtons(onClickButtonA, onClickButtonB);
}

void SetupButtons(Action callbackA, Action callbackB)
{
    ButtonA.RegisterCallback(callbackA);
    ButtonB.RegisterCallback(callbackB);
}

既存コードの扱いに気をつける

開発を行なっていると、既存コードに手を付ける必要が出てきたり、既存のコードを参考にすることが出てきます。
初めのうちはついつい楽をしようと、工夫次第では触る必要ないにも関わらず、既存のコードに手をつけたりしてしまいました。
しかし、既存のコードのロジックが変わると、これまでの振る舞いが担保されなくなるだけでなく、他箇所に影響が及ぶ可能性もある指摘を受け、必要のない変更は加えないコーディングを意識するようになりました。
逆に、例えば機能追加によってコードのレベルが揃わなくなってしまうような、既存のコードにも修正を加えた方が好ましいケースも存在します。
また、機能開発にあたって類似機能のコードを参考にする際も、そこのコードが現在でも適切かということを考える必要があります。
例えば、参考にしたコードは２年前に書かれたもので、実は１年前に類似機能を持ったより推奨されるメソッドが用意されていた、といったこともあります。
既存コードを参考にする場合は鵜呑みにせず、常に「今良いとされるコード」を書く必要があります。

業務編

タスク管理

業務では、定常業務と並行して複数のミーティングが行われます。また、新卒の間は研修も行われます。
初めはプロジェクトに慣れることさえ苦労しているなかで、ミーティングや研修もあって、なかなか実装の時間が取れず、何かとあたふたしてしまいました。
また、自分自身結構忘れっぽい性格なので、タスク管理にもある程度力を入れるようになりました。

###今ある作業を書き出す

定期的に、今持っているタスクを全て書き出すようにしました。
私はTrelloというWebサービスを使っています。
基本的には終業時間間際に、あとは適宜キリの良いタイミングでTrelloを開き、終えたタスクを消去して、次取り掛かることや残タスクを書き出しています。
機能開発に携わる際は、仕様や見積もりから必要な作業を洗い出して書き出したりもしています。
これを心がけることで、作業漏れを抑えられたり、ミーティング終わりに「あれ、今何をどこまでやってたんだっけ」みたいな思い出しの作業を発生させずに済むようになりました。

###作業を優先づけする

仕事をしていると開発だけをしていれば良いというわけはなく、さまざまな業務が発生します。
事前に期限が決められているものもあれば、突然情報の共有が必要になる場合もあります。
こういった様々なケースに柔軟に対応するために、自分の中で作業に優先順位をつける必要があります。
基本的に私は以下の要素に基づいて、脳内で優先順位をつけていました。

・納期
・工数感
・気になり度

優先づけとしてはザックリ以下のような感じで考えていました。

・今すぐやる
・後でやるけど今日やる
・明日以降にやる

当然ですが、納期が一番大事なので、急ぎの案件ほど優先的に処理します。
とはいえ「重いけど明日中の仕事」と「すぐ終わるけど今週中の仕事」だと、後者を優先するようにしていました。経験的に、納期も工数感も低い案件は忘れてしまう危険がありますし、そうでなくても脳のリソースを消費してしまう可能性もありますし、このタイプのタスクは情報共有や連絡の類が多いので、双方にとって早々に処理してしまうことが望ましいです。
また、工数は重いけど緊急度の高いものはTrelloのタスクボードの目立つ位置に置くようにしていました。
こういった作業が生じた場合は早めにチーム内や上長に共有することが望ましいです。

###質問の際は自分の考えや状況も伝える
これも基礎的なことですが大事です。
初めのうちは「ここの実装こういう作りにしたいんですけどどう思いますか？」みたいな質問の仕方をしていたのですが、「何を達成したいのか」「何を聞きたいのか」などが不明瞭だと、その分コミュニケーションコストが生じてしまいます。

###分からないことは質問する
これも当たり前のことですが、考えても分からないことを考え続けても分からないので、そういう場合は質問しましょう。
さすがに自分で調べたり考えたりしないで質問するのは良くないですが、適切なタイミングで質問することは非常に大事で、先輩社員が的確なアドバイスをくれて倍速で問題解決できたり、質問中に自分で最適解に気づいたり、ということもあります。

###連絡はこまめにチェックする

開発に集中しているとついつい連絡のチェックを忘れてしまうこともありますが、急ぎの連絡が来ている場合や仕様に関する共有事項がある場合もあります。
自分はUnityをリロードする際やgit操作を行う時など、わずかな待ち時間が生じる隙を見計らってこまめに連絡チェックを行うようにしています。

##さいごに

今回は新卒エンジニアとして私が心掛けてきたことを紹介させていただきました。
当然私もまだまだ駆け出しの身なので、業務効率化やコーディング手法にはまだまだ改善の余地があると思います。
仕事も技術も常にアップデートが必要ですので、そういった姿勢は忘れないで業務に取り組んでいきたいです。

アドベントカレンダーの明日の記事は @ishiguro_takuya です。お楽しみに！