これはSupershipグループ Advent Calendar 2020の13日目の記事です。
#はじめに
今年4月に新卒入社し、3ヶ月間の研修を経て7月にAd Generationの管理画面開発チームに本配属されました。
配属されてからあっという間に5ヶ月が経ちましたが、その中で私が初めてチーム開発を経験して気が付いた事について書いてみようと思います。
##入社前
学生時代の研究ではJavaを使ってAndroidアプリの開発をしていました。
研究では週一の進捗報告会があるのみで、基本的には一人（時々教授のアドバイスをもらいながら）で研究を進めるという方針でした。
日々の開発で必要不可欠なツールであるGithubは研究室内でソースコード引き継ぐためだけに使っていました。
同じリポジトリに対して複数人でコミットするといった事はもちろん皆無です。
研究が落ち着いた２月頃から内定者インターンに1ヶ月程度参加し、そこで初めてチーム開発というものを経験しました。
##配属されたチームについて
インターンで参加した時と同じチームに配属されました。
自分含め６人のメンバーで管理画面の開発を行なっています。
新卒だからと言ってコードを触らせてもらえないということはなく、インターン時代には既にコードを触らせてもらっており、細かい機能や修正をちまちまリリースしていました。
私達のチームでは主にRailsを使って開発を行なっています。
私自身、Railsはインターン時代から触り始めたのですが、ある程度使いこなせるレベルまでには成長してきたと思います。
#チーム開発を経験して思ったこと
##技術力が上がりやすい
学生の頃はちょっとしたアプリケーションを作れるくらいにはコーディングができたのですが、「一応動いてるけど、本当にこのコードでいいのか？」と自分の書いたコードに対して漠然とした不安がありました。
当たり前の事だと思いますが、自分の書いたコードに対してレビューをしてもらうのは様々なことを学ぶいいきっかけになります。
特に、
・メソッドや変数の名前
・将来の変更のし易さ
・N+1問題
のような、挙動の上では変わらないようなものについては初心者だと中々気を配れなかったりしますし、私自身もレビューして頂いて初めて気が付いたという事もありました。
一人でコーディングしていた時は気づかないうちに悪い癖が付いてしまったり、視野がなかなか広がりにくい事がよくありました。
チーム開発を経験する前と比べて、今はそれなりに技術力が上がってきたように思います。
特にベテランエンジニアに囲まれながらコードを書くとよりレベルが上がりやすいです。
コードはある程度書けるようになったけど、そこからどうレベルアップして良いか分からない人はインターンに参加するor友達同士でチームを組んで開発を進めてみるという方法も良いのかなと個人的に思います。
##プルリクエストの説明は気を遣った方が良い
最初のうちは自分が書いたプルリクエスト（以下、PR）で実現したい事やコードの意図がレビュワーに伝わりにくいことが多々あります。
チームに配属された当初はPRの説明を相当雑に書いていたと思いますが、今では可能な限りレビュワーの負担を減らせるような説明を残すようにしています。
具体的には、
・PRの目的の詳細 ←PRのタイトルだけでは分からないこと
・その目的に対してどうアプローチしたか
・そのアプローチを採用した理由
などを出来るだけ簡潔に書くようにしています。
レビュワーに指定したメンバーが私の行なったタスクを１から１０まで把握しているということはありませんので、PRのコードを読むための前提となる情報がそのレビュワーには不足している状態です。
PRの説明が十分でなければ、レビュワーは情報を集めるためにPRで余分な質問したり、タスクに関連するSlackのチャットログを見に行ったりしなければなりません。
PRの説明を見ただけで実現したい事の全体像を掴めようにできればこれらの負担をある程度は減らせると思います。
コードについてもレビュワーの負担軽減のため、複雑な箇所にはコメントを残すようにしています。
例えば、新しく定義したメソッドで実現したい事がコメントに書いてあれば、レビュワーはその情報を元にメソッドの中身を読み進める事ができます。
コードを読み進める前に実現したい事が頭の中にあれば、「この箇所は何をしてるの？」という疑問を解消する作業が一つ減るのでレビューがよりスムーズに進むと思います。
私が当初書いていたPRやコードの説明は情報が大きく不足していたため、レビュワーの方に相当負担をかけてしまいました。
##新人にとってのコードレビュー
新人だからといってコードレビューを依頼されないという事は無いです。
時間をかけてでもコードをしっかりと読み、変更が加わった箇所の挙動を確かめ、どうしてその実装になっているのかが分からない時は質問するという事を心がけています。
ただ、最初のうちはどうしてもレビューをしていてバグを見逃してしまうこともよくあります。
そういう時は一緒にアサインされた他のレビュワーが残したコメントを読み、自分にはなかった視点を得ることもまた勉強になります。
レビューを依頼されてどうすれば良いか分からなかった時に参考になった記事です。→コードレビューの際に気をつけること
##他のメンバーとの関係性
コードを書く上でのチーム内の人間関係はさほど重要では無いと考えていましたが、仕事と関係ない話題で盛り上がれるくらいの関係は築いておくべきだと個人的に思うようになりました。
私達のチームではゲーマーが多いので、新しいゲームソフトが発売されるとその話で盛り上がったりします。
チーム内の人間関係は良好な方で、些細な事でもすぐに相談しやすい環境が整っています。新卒１年目の私には大変ありがたい事です！
他のメンバー同士のチャットでのやりとりを覗いたりするのですが、より良いコードを書くための建設的な議論が交わされてたりします。
チームで働く際に大切な事がTeamGeekという本に書かれているのでオススメです。
#まとめ
私が初めてチーム開発を経験して思ったことをいくつか書いてみました。
駆け出しエンジニアの場合は技術そのものにばかり目が向いてしまいがちで、チームで協力してコードを書くということには関心が向きにくいのかなと思います。
私自身もそうでしたが、実際に経験してみるとレベルアップの機会があちこちに転がっている事に気付くものです。
これからWebエンジニアとして就職し、チームで開発を行う予定の方々にこの記事が参考になれば幸いです。
#最後に
Supershipグループではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
Supership株式会社 採用サイト
是非ともよろしくお願いします。