こんにちは！株式会社Holmesでエンジニアをしている平田です。最近日本酒にはまり、ネット販売のない酒屋のHPをスクレイピングして入荷したらLINEに通知することで、入手困難と言われる日本酒を飲むことができてエンジニア冥利に尽きる日々を過ごしています。
私は2020年初ごろからHolmesでコードレビュアーを担当しています。現在(2021/03)では開発部28名の中でレビュアー4名体制となりましたが、当時はテックリード1人しかレビュアーがいない状態で、各チームにとってはコードレビューがボトルネックになることがありました。また、レビュアーにとっても負担が大きく、本人のやりたいことに注力できていませんでした。 実際には他にもレビュアーとなれる人はいましたが、エンジニアリングマネージャーであったりと、役割やスピード感、仕様把握の観点から開発者でレビュアーを増やしたいという状況でした。
その中で自分がレビュアーとなるためにしたことを残そうと思います。現状のリソースの中でレビュアーを増やそうとしている組織やレビュアーになろうとしている人の参考になればと思います。
当時のチーム状況
当時の開発の状況は以下の通りでした。本格的な2チーム体制で、各チームがそれぞれミッションを持って開発に取り組んでいます。そのためボトルネックになりそうだというのが容易に想像できるのではないでしょうか。参考：現在(2021/03)のチーム状況はこちら*1
- スクラム2チーム体制
- チーム1
- PO：1
- SM：1
- バックエンド：2（うち1名が当時唯一のレビュアー）
- フロントエンド：2
- チーム2
- PO：1
- SM：1
- バックエンド：1（私）
- フロントエンド：2
- デザイナー：1
- SRE：1
- チーム1
やったこと
ここから私がレビュアーを任せてもらうために、やってきたことを紹介します。
現在のレビュアーから学ぶ
過去の指摘を振り返り
まずは現在のレビュアーの指摘がどのようなものか過去に振り返って確認して行きました。中にはドキュメントに落としづらいような経験からくる観点もあったりするので、話を聞いたりドキュメントを見るだけではなく、実際に行われた実績をみたり、一緒にレビューに立ち会ったりするのをお勧めします。
率先したレビュー指摘修正
並行して、レビュー指摘の修正を率先してやりはじめました。過去レビューの確認だけだと、本を読むのと一緒で手を動かしていないので、実際に指摘された内容の修正をしていくことで、同じことを繰り返さないようにして行きました。最終的にはレビュー依頼を出す前に私の方で確認をしてから依頼を出すという形式にして、指摘数を減らしていくことで、任せてもらえるようになりました。
プロダクトを学ぶ
私は特にここを重視しました。なぜなら私は当時エンジニア4年目のペーペーであり、経験豊富でテックリードを担っているレビュアーと肩を並べようというのですから経験で勝負するものではありません。
仕様に詳しくなる
プロダクトの仕様に詳しくないと、他の機能への影響や他の機能が及ぼす影響に気づくことができません。また、コードレベルでプロダクトを知ることも重要です。物によっては、nullが意味を持っている場合もあるでしょう。そういった（負債のような）違いにも気付き、リファクタリング（適切なdocを書くことも含め）していくことも私たちの組織には求められていました。
役割だけではない、視野の拡大
また、私の場合、様々な側面からプロダクトを見ていました。チーム体制で私はバックエンドと書いていますが、この頃からフロントエンドも兼任しています。また、デザイナーがチームにいたこともあり、UIUXの観点やデザイナーが作成したガイドラインの観点をコードレビューに活かしていました。具体的には、リクエストとレスポンスで空を期待するのかnullを期待するのかということであったり、ボタンの活性制御やエラー後の挙動などが正しく実装されているかというところまで見ていました。
設計を学ぶ
コードレビューの勉強というとリーダブルコードなど、コード自体の改善プラクティスを想像される方も多いのではないでしょうか。それらももちろん大切ですが、私は設計を学ぶことが大切だと思っています。設計論には様々なプラクティスが詰まっていますし、歴史的に何か課題を解決してきた経緯があると思っています。
バックエンド
Holmesでは現在ドメイン駆動設計（以下DDD）を取り入れて開発をしていますが、DDDをしていなくても、DDDが解決したい観点をコードレビューに活かす事はできるということです。
フロントエンド
フロントエンドでも設計パターンなど、特にHolmesでは現在Vue.jsへの移行を行っていますが、例えばVuexやReactの場合Reduxなどを使っていなかったとしてもVuexやRedux、Fluxを学び、また、それが生まれた背景や、そこに起因してMVC、MVVMなど以前からあるパターンを学ぶ事はできます。例えプロダクトが同じ設計パターンを用いてなかったとしても、それぞれの良い点・悪い点を知ることで、汎化してコードレビューに活かしていくことができます。
まとめ
以上が私がコードレビュアーとなるためにやってきたことです。 私がコードレビュアーになったことで、開発完了の定義を満たすまでチーム内で完結できるようになりました。２チームそれぞれがミッションを持ってプロダクトのアップデートに取り組んでいる中で、各チームが高速に開発サイクルが回せる体制ができました。また、レビュアーの負担が分散できたことで、テックリード（当時唯一のレビュアー）にさらなるアップデートの技術検証など、未来にかける時間に注力してもらえるようになってきました。
私自身レビュアーになったこともそうですが、バックエンド・フロントエンド双方に対して強みが持てるようになったので、チームの中でフレキシブルに必要なタスクを取れるようになり、大きく組織に貢献できるようになったと思います。また、Holmesでは新卒採用も行っているので、新入社員の書いたコードのレビューも担当するようになりました。教えるような機会が増え、さらなる自分自身の成長と組織貢献ができるようになりました。
現在は4名体制のレビュアーですが、レビュアーがレビューを受ける機会が少なかったり、レビュアーによって独自の観点を持っている部分もあるので、それらを改善していくのが今後の課題となります。
余談ですが、先日初めてOSSにPull Requestを出してレビューで指摘を受けたのですが、普段仕事で書くのとは違うコードだったりするので、新鮮なレビューが受けられて新しい学びが得られました。
最後に
Holmesでは、スタートアップのスピード感をレビュープロセスなどの品質担保で支えたいエンジニアを募集しています。 共にプロダクト作りを通して、社会・組織を良くしていきましょう！ 興味がある方はぜひこちらからご連絡ください！
