こんにちは。ECプラットフォームサービスSREチームリーダーの川崎（@yokawasa）です。本記事では、コードレビューを通じたチームのパフォーマンス向上のための取り組みについてご紹介します。なお、コードレビューそのもののテクニックに関する話はしないので、あらかじめご了承ください。
目次
はじめに
まずはじめに、我々はGitHubのPull Request（以下、PR）機能を活用してコードレビューをしています。下記の記事でも書いているようにIaCとCI/CDを基本ルールとしています。可能な限りすべての構成はコードで管理し、PRレビューでApprovalされた更新内容をメインブランチにマージし、CI/CDを通じて環境にデプロイします。よって、本記事におけるコードレビューはPRにおけるレビューと同義になります。
コードレビューはチーム全体のパフォーマンス向上のため
コードレビューは一般的に「ソースコードの品質向上」の観点で語られることが多いかと思います。コードの保守性・効率性・信頼性の確認、規約・ルールの徹底、テスト内容や関連ドキュメントの確認などさまざまな目的があります。しかし、我々がコードレビューをする理由はこれだけではありません。我々はコードレビューを通じて究極的にはチーム全体のパフォーマンス向上を目指しています。我々が考えるパフォーマンスの高いチームとは、高いレベルで知識の共有がされ、十分にコラボレーションが促進されているチームを指します。順を追って説明します。
コードレビューは、レビュアーとレビュイー間で知識や技術のトランスファーを行い、互いに学びあえる最高のスキルアップの場です。レビュアーはレビュイーや他のレビュー参加者により良い解決策やアイデアの提示、ベストプラクティスなどの共有ができます。また、他人が書いた洗練されたコードをみることで技術力向上にもつながります。
また、お互いのシステムや活動を深いレベルで理解できるようになると、より具体的なコミュニケーションが取りやすくなりチーム内コラボレーションの促進が期待できます。さらに、これを複数チームに広げることでその組織全体のコラボレーション促進が期待できます。結果、チームや組織全体のパフォーマンスの向上が期待できるというわけです。
複数ユニット、複数チームで行う
我々は複数ユニット、複数チームでクロスコードレビューをしています。
主担当外のユニットやチームが関わることはスピードや効率性の低下、ノイズの増加につながるといったマイナス面はあるかと思います。しかしながら、我々はZOZOTOWNの成長に伴い担当者が増えたとしても組織がサイロ化することなくスケールできることを目指しており、そのためには必要なトレードオフだと考えています。
クロスコードレビュー推進の発端は、2021年当時私が所属していたZOZOTOWNマイクロサービスを担当するSREチーム（以下、PF-SREチーム）の拡大に伴い生じた課題感からでした。
PF-SREはZOZOTOWNリプレイスを推進するSREチームとして2020年4月に発足しましたが、リプレイスの進行とともにチームは拡大し担当するシステムやサービスが増えていきました。そうなってくると、全員がモノリシックにすべてを見るわけにもいかなくなってきたので、チームで担当するシステムを適度な粒度のドメインに分けてドメインごとにユニットを組んで動くようしました。
そこで生じてきた問題がサイロ化です。担当ユニットの専門分野については詳しいが、隣のユニットのことはよく分からない状況が見られるようになってきました。各システムの更新頻度を考えると全メンバーが勉強会・定例会などで同期するには難しい状況がありました。コードレビューにおいては、一部のユニット担当者でのみ議論がなされるようになり、他のユニットで生まれたベストプラクティスや課題感がうまく全体に共有されづらくなりました。また、レビュアーがユニットごとで属人化するようにもなりました。
そうした課題の解決策の1つとして行ったのが、複数ユニットによるクロスコードレビューです。定例会や勉強会と比べ非同期でできるため時間的制約が少なく、また高頻度で回せることが魅力でした。そして、実施した結果、サイロ化は緩和され、知識共有とコラボレーション濃度は高まり、チーム力の向上がみられました。
なお、PF-SREチームはチーム内複数ユニット体制から今では下図のようなドメインを責務とした複数チームに分割されていますが、引き続き複数チーム間でクロスコードレビューをしています。
さらに、これは実験的でありますが、2022年4月よりコードレビュー参加対象をマイクロサービス担当チームに限らずZOZOTOWNを担当するSRE部配下すべてのチームに広げて実施しています。この試みについてはまだ目立った効果は見られないものの、他チームのシステムに対する関心度が変わったであるとか、他チームのレビュー参加意欲が上がったなどポジティブなフィードバックが得られはじめています。
活動状況を定量的に評価する
コードレビューの活動状況は定量的な数値データを元に把握し、継続的な改善に努めています。その取組について簡単に紹介します。
まず、コードレビューの活動状況を定量的に把握するためにFindy Teamsを活用しています。Findy Teamsは、GitHubにおけるPR作成数、レビュー数などさまざまな活動をメトリクスとして可視化してくれるサービスです。活用することで、個人やチームレベルの活動状況を定量的に把握できます。
下記はチームの活動状況が確認できるFindy Teamsの「チームレポート」ページのスクリーンショットになります。
中でも、とくに参考にしているのはコードレビューの活動量を示す以下のメトリクスになります。
- レビュー数： PRに対してレビューした数（PRコメント除く）です
- 自分がレビューしたプルリク数： レビューに関わったPRの数です
- プルリクに対する自分のコメント数： PRへのコメント総数です。コメント数が多いほど多くの議論が行われている可能性があります。一方、コメントする必要のない良質なPRもあるので多いから良いという判断は一概にはできません
- 自分が最初のレビューをするまでの時間： 最初にレビューするまでの時間です。数値が短いほどよいと言えます
この結果データは定期的にレビューしています。Findy Teamsを使い始めて最初の半年くらいは、”マネージャーごと”として一人もくもくとチームの活動状況を眺めていました。結果が思わしくないようだったらどうすればコードレビューが促進されるのかチームミーティングで議論を促していました。しかしそれではスケールしていかないだろうと考えを改め今年から”チームごと”としてメンバー全員で結果データを見ていくようにしました。現在は、週次のチームミーティングのアジェンダの1つとして「チーム生産性活動レビュー」を設け、チーム全員で結果データをみて振り返りを実施しています。
コードレビュー体験を向上させる
ここではコードレビューの体験を向上させるために実施したことや、結果的に実施したことでコードレビュー体験が向上したことについてご紹介します。
レビュアーの負担を減らす
レビュアーの負担を減らしレビュアーフレンドリーなPRにすることで、レビュアーのストレスは減り、コードレビューの速度は加速されます。以下、レビュアーの負担を減らすために実践していることを簡単に紹介します。
- PRの粒度は小さくして目的を絞ります。巨大なPRは見るのが億劫になります。また、1つのPRに複数の目的が混在している場合も同様です。PR粒度を小さくする理由についてはGoogle - eng-practices - Small CLsが参考になります
- PR説明は簡潔で分かりやすく書きます。PRテンプレートを活用し、PRの目的、関連Issue/PR、テスト内容、変更による影響範囲などPRへの記入項目をあらかじめ用意します
- 作成されるPRにはGitHub Actionsでラベルを自動付与します。ラベルはレビュアーが同様の種類の課題をすばやく整理して集約するのに役に立ちます。ラベルの自動付与はGitHub Actions経由で、labelerを活用しています
- PRで提案されるコードは、可能な範囲でGitHub Actionsにより事前に自動チェックし、レビュアーの負担を軽減します。たとえば、フォーマットや規約遵守、デプロイ先環境との差分、利用APIやパッケージのセキュリティ課題などがあります
同期・非同期コミュニケーションを使い分ける
非同期・同期コミュニケーションをうまく使い分けることで、コードレビューを効果的にすすめることができます。
コードレビューは非同期コミュニケーション中心の活動になりますが、非同期で効率的に時間を有効活用できる一方、フィードバックが得られるまでのリードタイムが長くなるという課題があります。また、複雑な内容になってくると文章だけではツラいです。
このような課題に対して弊チームでは、非同期コミュニケーションに固執することなく、同期コミュニケーションをうまく取り入れるようにしています。素早い返信を要したり、濃度の高い会話が必要と感じたらビデオ会議で直接会話したり、一緒にモブプロを行うなど同期コミュニケーションにスイッチします。必要に応じて同期・非同期を行き来します。 また、レビュアーと一緒にモブプロしてからPRを作成するという流れもあります。この場合のレビューは間違いなくリードタイムが短くなります。
参加しやすい雰囲気を作る
先述のとおり、コードレビューを通じて知識のトランスファーやコラボレーション促進を目指しています。したがって、コードレビューにはできるだけ多くのメンバーが参加することを期待しています。以下、コードレビューに参加しやすい雰囲気を作るために工夫したこと2点紹介します。
1. 心理的な安全性を高める
担当外の案件のコードレビューだと関連システムを熟知しておらず的確なレビューができず億劫になりがちです。ただし、コードレビューは学びの場であり、コミュニケーションの場でもあります。システムを熟知していないメンバーも議論に参加できるように、PR上ではレビュアーが仕様や不明な点をレビュイーに気兼ねなく質問できる場であるという、雰囲気づくりを心がけました。
2. チームの共通目標にする
私がリードを務めるチームではチーム目標の1つに"クロスレビューへの貢献"をかかげています。全員が同じ方向を向いてコードレビューを盛り上げていくことを共通目標とすることで、レビューに参加し貢献することのモチベーションはあがり、協力しやすい雰囲気が生まれやすくなります。先述のとおり週次ミーティングでコードレビューの活動結果をレビューして、継続的な改善に努めています。全員が同じ目標をもっているので改善のためにの活動も足並みを揃えて実施できます。
さいごに
コードレビューにはさまざまな目的があるかと思いますが、我々はコードレビューを通じてチーム全体のパフォーマンス向上を目指しています。本記事ではそのための取り組みについてご紹介しました。我々の取り組みが少しでも参考になれば幸いです。
なお、リモートワーク下においてはコードレビューの実施意義はとくに大きくなったと感じています。コードレビューは時間や空間に囚われることなく行える有用な非同期コミュニケーションツールの1つです。ZOZOではコロナ禍を機に多くの社員がリモートワークを行うようになりましたが、柔軟に時間を調整して実施できるコードレビューのリモートワークとの相性の良さを強く実感しています。
さいごに、ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
https://hrmos.co/pages/zozo/jobs/0000010hrmos.co
また、カジュアル面談も随時実施中です。まずは話を聞いてみたいという方は、以下のリンクからご応募ください。
