新卒でいきなり運用タイトルに携わった自分がやってて良かったこと / やるべきだと思ったこと

本記事は、サムザップ Advent Calendar 2022 の12/12の記事です。

はじめに

こんにちは、今年入社したSumzapの福田です。
この記事は、業務経験がほとんどなかった自分が学生時代に色々やっていたおかげで、うまーくエンジニアとして立ち回れてきたので、学生時代にやって良かったこととやるべきだったなと感じたものをまとめてみました。
いち個人の考えですので、暖かい目で読んでもらえると嬉しいです。

読んでくれたら嬉しい人

現在学生で、エンジニアでの就職を考えている人（特にゲーム）

筆者のステータス

• 情報系の大学院卒
• 2022年度4月にCyberAgentにゲームクライアントエンジニアとして入社
  • 内定時期に業務に関わるバイトができるのですが、僕は学生時代に時間的余裕が無かったためできませんでした
• 中高生にゲームプログラミングを教えるバイトに従事
• 会社に入る前までは、運用タイトルに関わったことがなく基本的にハッカソンでゲームを制作
• 学生時代は大規模ゲームの開発は未経験
  • 大規模は何年もかけて複数の職種・人数に分かれて開発することを指しています

ステータスとしてはこんな感じです。
ゴリゴリの技術人間というより、ものづくり楽しんできた系人間なんだなと思ってくれたら十分だと思います。

やってて良かったこと

新卒ゲームクライアントエンジニアとして入る上で、学生時代にやってて良かったなと思うことを書いていきます。

興味のある技術を頻繁にキャッチアップしていたこと

まず1つ目に、常にTwitterやQiitaなどで興味のある技術系の内容を頻繁にキャッチアップしていたことです。
自分自身バイトや学生生活が忙しかったり自分の時間も少しは大事にしたいタイプだったのであまり業務開発系のインターンに参加することはほとんどありませんでした。
ただ、SNSなどで発信されている技術的な部分のキャッチアップは頻繁にしていたなと思っています。
新しい技術に興味はありましたし新しく注目されているライブラリあたりを見て「こんなん作れそうやん。」って試しに触ってみるのは好きだったので自分なりに工夫してキャッチアップしてました。
興味のある技術のキャッチアップが今でも活きてるなと感じる場面はありますし、学生時代の自分にやってて良かったぞと言いたいです。

キャッチアップのメリット

キャッチアップを頻繁にしていたことによって、新卒ながらも技術的な話についていくことができ、最低限業務で話している内容が全くわからないということがほとんど無かったことです。

キャッチアップの方法

基本的にはTwitterで情報をキャッチアップをしていました。
Twitterはいろんな情報が転がっています。その中で自分が興味のある情報をキャッチアップする時に工夫をしていたのでその方法を紹介します。

興味のあるものに関してはリストに入れて、興味のある情報のみのタイムラインを作成していました。

アカウントを複数管理して技術情報をキャッチアップするアカウントを作成して技術アカウントにするという方法もあるのですが、僕自身がかなりのめんどくさがり屋なのとでアカウント複数管理するのが結構苦手だったので、このような方法でキャッチアップしていました。
この方法のメリットとして、他のタイムラインと情報が重なることがないので欲しい情報のみのタイムラインが完成するので情報のキャッチアップに専念できます。
ただ、デメリットとしてはリストを作成するとなるとアカウントをフォローする必要がないので、自分を相手に知ってもらうという発信という観点では効果が薄くなってしまうので、要注意です。

また、キャッチアップしたもので気になったものに関しては、以下の方法でまとめていました。

1. Notionで技術系の記事を一覧化できるデータベースを作成
2. 参考になりそうだったり、これは読んでおきたいと思う記事に関してはWebClipで保存

以下のような感じでデータベースが出来上がってきており、知識をまとめるのがかなり楽になりました。
以下のようにUnityに限らず参考になった記事は全てここに集約してもよかったなという反省点はありますが、自分にとっての振り返ったりできる第2の脳みそになりかけています。

これらの方法でキャッチアップをして、実際にハッカソンや自分の個人開発等で応用してみて学習に繋げていました。
逆にハッカソンとかで得た知識もこのデータベースに蓄えたりもしました。

チームでの開発をたくさん経験してきたこと

2つ目に良かったこととして、チームでの開発を多く経験したことです。
その中でもハッカソンでの経験は今でも活きているなぁと実感しています。

チームで開発するメリット

チームでハッカソンをすると以下のメリットが得られると個人的に考えています。

• 短期間で実装力の向上が見込めること
• 開発する上で必要なコミュニケーション能力がつくこと
• 技術のキャッチアップに繋がること

ハッカソンは短期間でプロダクトを作るため、短期間でコードを大量に書く必要があります。
とりあえず機能を実装するためにコードを書かないと始まらないので一旦無心でコードは書きますし、通常よりもコードを書く必要があるので自然と実装するための力がついてきます。

また、チームで開発するハッカソンだと綿密なコミュニケーションとお互いの進捗確認を頻繁に取ることになるので、開発する上で必要なコミュニケーション能力も同時についてきます。
例えば、進捗確認の部分であったり、どこで詰まっているのかをお互いが理解するためにはどういったコミュニケーションをとれば良いのか、チームとして開発へのモチベーションを今よりも120%上げるにはどういったコミュニケーションを取るべきなのかを考えたりしました。
この経験が、現在新しく入った運用プロジェクトでのチームコミュニケーションの取り方が円滑に開発できている実感があります。

さらに、チームの方針にもよると思うのですが、ハッカソンでは基本的に触れたことない技術（ライブラリ周り）に触れていたので短時間でライブラリの仕組みを理解する力もつきました。
これが、かなり自分にとって力になったと思っています。
この経験を何度か繰り返していたので、機能実装に必要な情報を抽出してどのように使うのがいいのかという勘所を掴むことができました。

ハッカソンはUnity1weekやHackUとかによく参加していました。

Unity以外の技術にも触れていたこと

3つ目の良かった点として、Unity以外の技術にも触れていたことはかなり業務でも役に立っているのかなと思っています。
学生時代は情報系の学部で主にC言語を扱うことが多かったので、型に厳密でメモリの管理が必要な言語やPythonやJavaScriptも興味本意で触っていました。

触れてたことによるメリット

特に、バイト時代では主にスプレッドシートで管理や作業することが多かったので、作業や管理の効率化を行うためにGAS (GoogleAppsScript) を使ってシートの自動入力とかをやっていました。
そのおかげでGASでできることを知り、いろんな業務内容で様々な場面で効率化できる部分のイメージがつけるようになりました。

また、いろんな言語を触ってきたことによって、業務のトレーナーさんと実装の話をしたりする際に他の言語で例えてくれたりすることがあったので認識の理解が早まった時もありました。

やるべきだと思ったこと

ここまで、入社する前の学生時代にやってて良かったと感じる部分でしたが、入社して初めて運用タイトルに入ってからももちろん苦労した部分も多かったです。

その中でも、入社する前にやっておけば軽減できたのかなと思う部分を挙げたいと思います。

他の人が書いたコードをたくさん見て理解すること

まず1つ目が他の人が書いたコードをたくさん見て理解することです。
もちろん、ハッカソンで他人のコードを見てはいましたが、今の業務ではあり得ないくらいコードをざっと見てマージすることが多かったです。

ではなぜ、他の人が書いたコードをたくさん見て理解することが大事なのかと言うと、長期運用が必要なプロダクトでの開発は自分でコードを書くことと同様にコード読むこともかなり重要になってくる点です。
コードレビューも必要になってきますし、既存の実装を改修する際には、改修するクラスがどういった処理がされているのかを考え、その上で影響範囲が少ない状態で改修するためにはどうすれば良いのかを考えます。
また、もちろん不具合が出た時にもどの処理が不具合を発生させている原因なのか見る必要があるので自分以外の人が書いたコードを見ることの方が多いです。
それくらい、自分が運用プロジェクトに関わってから他の人が書いたコードを見る機会がかなり多いです。

とはいえ、コードを全部見ていくことが最適解なのかというと僕自身の考えとしてはそうではないと思っています。
例えば、以下の項目を意識するだけでもだいぶコードを読む力がついてくるのかなと考えています。

• いいコードの書き方とされてるものと照らし合わせながらコードを読んでみる
• 処理の流れをイメージする

いいコードの書き方とされてるものと照らし合わせながらコードを読んでみるとかなり実務でのコードを読むときに苦労しないかなと思いました。
今思い返すと僕自身、良いコードの書き方などの本はざっと見ていたものの、ハッカソンとかだとコードを綺麗に書く意識を向ける余裕はなかったですし、インプットの割にアウトプットができてないなと感じています。
アウトプットがコードを書くことだけではないですし、コードを追いかけることもインプットに対してのアウトプットにもなると思っています。

そんなこんなで、運用に入るまでその場でなんとか動かす（長期で運用することはあまり考えていない）コードを実装することが多かったです。
なので、運用に入ってコードを見れば大体の処理がわかるコードになっていて読みやすかった反面、自分はコードレビューの際に変数やメソッド名からの推測がつきづらいという指摘がかなり多かったです。
学生時代のいかに自分が分かればいいやコードで実装していた悪い癖が影響して、自分自身がそれを模倣することが想定以上に長くかかってしまったと思っています。
なので、以下の書籍や記事とかを参考にしてわかりやすいコードの書き方を学んでみた上で様々なコードを読んでみると良いと思います。

また、処理の流れをイメージするのもかなり重要かなと思っています。
もちろんメソッド名でどんな処理が行っているかが大体推測つくでも良いと思いますが、実際にコードを追いかけてメソッドの役割の中身を追いかけるのも運用入ってからの大きな力になると思います。

とはいえ、どんなコードを読めば良いのかという話になるのですが、AssetStoreで落としてきたものの中に入っているコードを読んでみるのも良いと思いますし、UnityLearnにあるコードも読んでみてもいいかもです。
中には読みづらいコードがあるかもしれないですが、コードを追いかけてみるというアクションが大事だと思うので、「このように実装した方がより読みやすい実装になるのになぁ」とか「ここの部分はクラスに分けて実装してもいいのになぁ」と考えてみるのも学習の1つになると思います。（もちろん根気も伴ってくると思うのですが...）
ここで、良いコードだけを読めるに越したことはないですが、そもそも読んでみる前にこれが良いコードなのか悪いコードなのかを根拠を持って判断ができるのであればそもそもこのステップでの問題にぶち当たらないのかなと思っています。

パフォーマンス面での知見を最低限持っておくこと

2つ目は、実装する時にパフォーマンス面を意識しながら実装するのも意識しておけばよかったなと思いました。
ハッカソンなどでは、機能を動かすことを最優先にしていたので、特にパフォーマンスを考えることなく実装していることがほとんどでした。
なので、学生時代に書いてたコードを見返してみると、余計にメモリを使用していたり不要にオブジェクトを生成しては破棄をしてを繰り返すコードをたくさん書いていました。

ただ、運用に入ってからはパフォーマンスが悪くなることはユーザー体験を損なわせる部分になってくるので、パフォーマンス面で問題が生じないか考える必要があります。
自分がこの辺の勘所が薄かったため、コードレビューの際に余計にメモリを確保していることへの指摘や他の実装方法を提案されることが多かったです。
なので、学生時代から意識して実装できていたら早い段階でパフォーマンス部分をより改善する上で必要なところを自分から指摘できるレベルに早い段階で上がれたかなと思いました。

パフォーマンス部分に関しては、言われないとわからない部分ではありますが、今はパフォーマンスチューニングに関する本もあるので今僕が学生なのであれば入社するまえにこの本を読ませます。

サーバーサイドでの最低限の知識を知っておくこと

3つ目に、サーバーサイドの知識を最低限知っておくべきだったと思うことを運用プロダクトに入って多々感じました。
これは運用プロジェクトに関わらず大規模プロジェクトに通ずる話だと思います。

サーバーサイドとの通信をしてみることがなかったので、サーバーサイドでの役割がわかってなかったですし、なんならAPIを叩けば勝手にデータがやってくる魔法のようなものでした。
ただ、サーバーサイド側でできることをクライアント側でやろうとしてしまったことや実装する前のタイミングで何ができるのかがわかってなくてシンプルに実装に時間がかかってしまったこともあったので、事前に知識として持っておくに越したことはないなと思います。

サーバーとの通信でどのようなことができるのかを知っておくだけでも全然違いますし、やってみるだけでもかなり違うと思います。
特にここでは非同期的な処理が必要になってくるので、非同期処理の学習にもつながると思うので学習する上で一石二鳥になると思います。

では、ハッカソンでユーザランキングとか実装する時はどのようにしていたのかというと、ある程度無料で使えるサービス（NCMBとかFirebaseとか）を使って実装していました。
ただ、基本はドキュメントどおりにやったら上手くいけたという感じだったので、こういったサービスの恩恵に授かるのもいいですが、ある程度は自前で実装していたら運用プロジェクトに入ったときもっとスムーズに開発が進められたのかなと思います。

最後に

最後に、学生時代に興味のある技術を頻繁にキャッチアップしていたこと・チームでの開発をたくさん経験してきたこと・Unity以外の技術にも触れていたことが運用プロダクトでの開発にも活きています。
また、学生時代に他の人が書いたコードをたくさん見て理解することや、パフォーマンス面での知見を最低限持っておくこと、サーバーサイドでの最低限の知識を知っておけば良かったなと思っています。

ここまで読んでいただきありがとうございました。
入って半年のエンジニアが思ったことを書き連ねていますので、もしかしたら1年後や3年後には考えは変わっているかもしれません。
なので、いろんな考えがそれぞれあると思いますが暖かい目で見てもらえると嬉しいです。

明日は@higuchi_yutaさんの記事です。
お楽しみに！