[XP]同期レビューの定義と運用事例（2024 Advent Calendar 13日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の13日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

同期レビュー

本記事では同期レビューの定義と自分たちのプロジェクトでの運用を紹介します。

同期レビューはXPのプラクティスには含まれていません。「トランクベース開発」で紹介されているプラクティスの一つです。しかし、私個人の意見としてXPの「全員同席」や「ペアプログラミング」といったプラクティスを実践している場合、同期レビューは自然と導き出されるアクティビティであると考えています。

同期レビューの定義

同期レビューとは、その名の通り「PR（プルリクエスト）が作成できたのでレビューをお願いします。疑問点はその場で解説するので、一緒にPRを見てください」と同期的に人に依頼することを指します。この際、レビュワーはPRをすぐに確認してその場で気になる点を指摘します。指摘事項が解消されてレビュワーが納得すれば即座に承認（approve）を行います。

非同期的なレビュー依頼のようにSlackで「レビューをお願いします」とメンションを送って相手の手が空くのを待つのではなく、PR作成が完了した段階でその場ですぐに確認してもらうのが同期レビューの特徴です。この方法により、レビューの時間を効率化し、チーム内で迅速なフィードバックと進捗が可能になります。

同期レビューの運用

ペアプログラミングが中心のチームでは、同期レビューを次のように実施しています。ペアプログラミングでのコーディングが一区切りついたらプルリクエストを作成し、別の二人のペアにGather上で話しかけてレビューを依頼します。依頼を受けたペアは作業の手を止め、一人がPRのページを開いて画面共有を始めます。この結果2つのペア、つまり4人のエンジニアでコードレビューを行う形になります。

レビューを依頼されたペアは、通常のコードレビューを実施します。コードを読む際に疑問があれば、その場でレビューを依頼したペアに尋ねます。質問を受けたペアは、コードを書いた背景や機能の仕様、意思決定時のトレードオフを口頭で解説します。

ペアプログラミングを実践しているため、もちろん一定のコード品質は担保されています。しかし、そのペアの二人では気づかなかった視点や設計の指摘を受けることがあります。

同期レビューの小さな指摘の対応

指摘内容はごく一般的なものです。例えば、タイポや変数名の改善、コードコメントの追加などです。修正が簡単なものはレビュー中にすぐに直してしまいます。

コードを書いたペアも一緒にPRを確認しているため、たまに人から指摘される前に自分で「もっと良い書き方がある」と気づくことがあります。それが興味深いです。人と一緒に見ることで自分のコードをより客観的に見ることができるのでしょう。

「この人はここを指摘するだろうな」という視点で自分のコードを見ると、その人の実際の指摘より先回りして自分のコードの粗に気がつくのです。人と一緒に同じコードを見ているだけで、他の人の視点をインストールしているのです。

同期レビューの大きな指摘の対応

一方で、クラスの責務に関する指摘など少し大きなリファクタリングが必要な場合は、その場で修正せずに先に承認（approve）をもらってリリースします。

動作自体には問題がないためデプロイしても不具合は発生しません。デプロイ後すぐにリファクタリングを開始し、遅くとも翌日午前中までにもう一度同期レビューを受けてapproveをもらってリリースします。

このプロセスにより、「リファクタリングを後回しにする」という状況が防げます。この手法は後述するインクリメンタルな設計にも関連しています。

同期レビューにかかる時間

同期レビューの時間は短い場合は10分程度ですが、最長で30分かかることもあります。特に、実装が膨らみすぎた場合は20～30分ほどかかることが多いです。そのため、ペア内で「実装が膨らんできたので、そろそろレビューに出しましょう」といった判断を早めに行うよう心がけています。この結果、PRのサイズは比較的小さく抑えられる傾向があります。

また、同期レビューによりレビュー待ちの時間がなくなりました。その結果、常に一つの作業に集中できるため、マルチタスクを避けられます。さらに、仕掛かり中のPRの数は2～3つに収まり、管理がしやすくなっています。

同期レビューにはコミュニケーションコストの削減という効果もあります。具体的には、同期レビューを実施した場合、PRのコメント数は非同期レビューの場合に比べて少ないと感じます。

非同期レビューのPRのコメントは、ペア内での承認（LGTM）や指摘事項を忘れないための簡単なメモ程度で済みます。。また、口頭でコードを説明するため「ここのコードの意図は何ですか」といった実装しゃがヒヤっとするコメントや、それに返答するための説明を長々と書く必要がありません。

概要はPRに記載しており、コード内に仕様が表現されている場合でもコードコメントを追加して補足する程度で済みます。テストコードもあるため、メソッドの挙動はそちらを参照して理解してもらえるようになっています。

さらに、同期レビューによってペアの進捗状況やスプリントゴールの達成に支障がないかまで把握することができます。

ただし、コードを実装した側とレビューした側では理解度に差が出ることがあります。この差を埋めるため、チームではポンチ絵程度の図をFigJamで作成し、「モデリング図」や「データフロー」としてプルリクエストに添付しています。

この図にはデータの流れなどを描き、処理の流れを大まかに把握できるようにしています。これによりチーム内でキャッチアップが必要な場面でも、「ゼロから全てを理解する必要がある」という状況を回避できます。

次回はテスト駆動開発の定義と運用を紹介します。