はじめに

こんにちは。ウォンテッドリーのバックエンドエンジニアの西野です。本記事では、開発チームの課題であったコードレビューの遅延を解消するために実施した取り組みを紹介します。

10月初旬、チームのバックエンドエンジニア間で「コードレビュー完了までの待ち時間が長い」ことが問題になりました。レビュー依頼から完了（Approve）までに1日以上かかるケースが多く、時には次の作業に着手できずにスケジュールが遅れることもありました。この状況を改善するために、私たちはレビュープロセスの見直しに着手しました。

なぜコードレビュー完了までに時間がかかるのか

バックエンドメンバー間で議論した結果、レビューが滞る根本的な原因は「プルリクエストの内容理解にかかる負荷が高く、それがレビュー着手への心理的ハードルにもなっていること」にあると判明しました。具体的には以下の2点が主要な要因です。

①依頼されたレビューのコンテキスト理解に時間がかかる

一つ目の要因は、コードの変更意図や背景を理解する難易度が高いということです。チーム内のバックエンドエンジニアは2名体制で、互いにレビュアーとレビュイーを兼ねています。しかし、それぞれが別の施策を担当する場合が多く、事前知識が少ない状態でレビューを行う必要があります。そのため、プルリクエストから「なぜこのような変更にしたのか」という文脈を読み解く作業に多くの時間を要していました。

②プルリクエストに含まれる変更量が多い

二つ目の要因は、一回のプルリクエストに含まれる変更量が多いことです。複数の機能の改修が含まれていたり、機能追加だけではなくリファクタリングも含まれているような場合は、変更の目的が多岐にわたっているため全体像を把握するのに時間がかかっていました。

これらを踏まえ、私たちは単に量だけでプルリクエストを小さくするのではなく、「レビュアーが理解しやすい粒度に分割する」という方針を固めました。 しかし方針は決まったものの、具体的にどのような粒度が適切なのかという新たな疑問が生まれました。一つの機能が動作する単位でプルリクエストをまとめるとレビュアーも動作確認しやすい利点はありますが、機能単位にこだわると改修範囲が広く修正量が多い場合はプルリクエストが肥大化する欠点もあります。また、機能開発の過程でリファクタリングを行いたい場合に、その修正をどこに含めるべきか。含めた方がわかりやすいのか、含めない方がシンプルになるのか、ということも悩みどころでした。

『Tidy First?』が推奨する分割の単位

解決の糸口は、9月下旬に開催された Kaigi on Rails 2025 のキーノートで紹介された書籍『Tidy First?』（O’REILLY社 Kent Beck 著）にありました。チーム内でレビュープロセスについて議論していた10月当時、私は同カンファレンスをきっかけに本書を読み進めている最中でした。その中で、私たちの課題解決に直結する記述を見つけました。

焦点を絞ったプルリクエストであれば、レビューも速くなる（第II部 16章「分けて整頓する」より）

焦点を絞るとは、どういうことなのでしょうか。

焦点を絞ったプルリクエストを作る

『Tidy First?』では、システムの振る舞いを変えずに構造を変える変更を「整頓（Tidy）」と定義しています。そして、この「整頓」と「振る舞いを変える変更」は、別のプルリクエストに小分けするよう推奨されています。また「整頓」や「振る舞いを変える変更」が複数ある時は、作業順序を考慮しながらさらに小分けします。

具体的にどのような単位で分けていくのか、架空の「日記機能」の改修を例に挙げて説明します。

例：日記機能をプロトタイプ版から正式な機能に変更する

過去に検証用としてプロトタイプを作成した日記機能を、正式な機能としてリリースすることになったケースを想定します。プロトタイプ版には既に基本機能が実装されており、これを拡張していくのが良さそうです。しかし正式版では要件が増えているため、今後の開発のしやすさを考えて、一部のソースコードを別ファイルに切り出してから（移動してから）、機能拡張のための変更を加えました。その後、最終的に不要になったソースコードは削除しました。

全てを一つのプルリクエストにまとめた場合

プルリクエストには以下の変更点が混在することになります。

• ソースコードの移動（整頓）
• 日記機能の拡張（振る舞いを変える変更）
• 最終的に不要になったソースコードの削除（整頓）

この状態で特に問題となるのが、GitHub などのツールでの差分のわかりづらさです。ファイル移動と削除が混在していると、画面上で「削除」となっている箇所が、別のファイルへ移動したのか、不要だから削除したのか、一見して判別できません。レビュアーはソースコードを追いながら判断する必要があり、そこに機能拡張の差分も加わるため、把握すべき情報量が膨大になり負担がかかることになります。

変更の種類ごとに分割した場合

これが「ソースコードの移動」「日記機能の拡張」「最終的に不要になったソースコードの削除」と3つのプルリクエストに小分けされていれば、それぞれのプルリクエストの焦点は絞り込まれた状態になり明瞭です。そのため、レビュアーへの負担を少なくすることができます。

改善の取り組みと成果

実際の開発でも「整頓」と「振る舞いを変える変更」のプルリクエストは分けるということを徹底しました。作業時には、同じプルリクエストに含めて良い変更なのか、分割した場合はプルリクエストの適用順位はどうなるかを常に意識し、変更の焦点を絞り込むよう努めました。その結果、「コードレビューに時間がかかる」という課題に対して、明確な改善が見られました。以下は改善に取り組む前の2ヶ月と後の2ヶ月における実績を比較したものです。

実績が示す通り、レビュー完了までの平均日数は1.42日から0.6日へと半減し、多くのレビューが1日以内に完了しています。レビューが滞らずに進むことで、開発の待ち時間を減らし、スムーズに次の作業へ移行できるようになりました。

おわりに

今回は書籍『Tidy First?』で推奨されている「構造変更と振る舞い変更の分離」という手法を取り入れ、レビュー完了までの時間を大幅に短縮させた事例を紹介しました。テンポの良い開発サイクルは、チームの開発スピードの向上に寄与します。今後も試行錯誤を続けながら、ウォンテッドリーの価値観である Move Fast を体現する開発体制を強化していきます。