多様な開発組織のコード／PRレビューを“図鑑”のように紹介する連載「コードレビュー図鑑」。ニーリー株式会社の増田（おます）さんに、コードレビューの“いい塩梅”を探るための実践について紹介いただきました。 [1]
株式会社ニーリーでサクセスエンジニアリングチームのリーダーをしている増田と申します。
ニーリーは、BtoBtoCのVertical SaaSとして「Park Direct」を運営しています。月極駐車場のオンライン契約を、管理会社と借り手の双方にとって扱いやすくするサービスです。私が所属するサクセスエンジニアリングチームは、プロダクトの外側から事業のトップラインを上げるために動きます。業務効率化のためのプラットフォームやアプリケーション開発など、扱う領域は幅広いです。
コードレビューの目的をどう捉えるか
コードレビューは、目的を全部満たそうとすると時間が溶けやすい作業です。どこまで見るべきかの判断にも迷いが出ますし、ドメインやアーキテクチャに詳しいメンバーへ負担が偏りがちです。結果として、その人がボトルネックになり、開発速度が落ちることもあります。
さらに厄介なのが、せっかく指摘しても意図が伝わらない問題です。頭の中の考えを一発で完璧に言語化するのは難しく、経験の差も解像度のギャップになります。短いコメントは曲解されやすく、長い説明は読まれにくいというジレンマもあります。
そんな中、コードレビューで多くの人が探しているのは、品質を担保しつつ負担を抑えたい、「いい塩梅」だと考えています。
そこで今回は、「いい塩梅」を探るための実践を、大きく2つのアプローチに分けてご紹介します。1つは「PRの指摘を減らす」ためのセルフレビュー、もう1つは「指摘を適切に伝える」ためのAI巻き込み型コミュニケーションです。
