はじめに
本記事は、2025/03/06に開催された下記イベントの登壇内容を記事化したものです。
その際利用した登壇資料はこちらです。
スライドをご覧いただくだけでも問題ありませんが、登壇時に口頭で補足した内容や、LT時間の都合上端折った内容などもあるので、文章としても内容を残します。
もくじ
- この記事で書くこと・書かないこと
- 本記事であつかう開発グループのバックグラウンド
-
本題：よりよいレビューフローを求めた奮闘の記録
- やってみた 1：マネージャーが全チームの全PRをレビュー
- やってみた 2：全PRを全チームメンバーでモブレビュー
- やってみた 3：全PRを全チームメンバーで非同期レビュー
-
やってみた 4：チームごとに最適化
- チーム 1：全メンバーでのモブレビューに回帰
- チーム 2：全メンバーによる条件付き非同期レビューに変更
お急ぎの方は本題部分にジャンプしてご覧ください。
この記事で書くこと・書かないこと
書くこと
私が所属する開発グループでこの 2 年間で改善を続けているPRレビューの流れについて書きます。
2025 年 3 月時点でのお話です。
私たちの開発グループは、PRレビューの流れを、約 2 年にわたって議論しながら改善を続けてきました。
その中で実際にやってみたレビューフローのやり方と、どういった点を いい点やイマイチな点と感じて、さらに改善するに至っているかを記載します。
具体的には以下のような内容です。
- 誰が、いつ、どこでレビューするのか
- やってみた方法 4 つのいい点、イマイチな点
また、私たちの開発グループにおけるPRレビューの位置づけの話にも少し触れます。
書かないこと
PRレビューの中身の話は本記事では扱いません。
具体的には以下のような内容です。
- PRの中身のレビュー方法
- コードレビューの観点
本記事であつかう開発グループのバックグラウンド
作っているもの
私たち WHI では、「COMPANY」という大手法人向けの統合人事システムを自社開発しています。
その中で私たちの開発グループでは、「就労・プロジェクト管理」という勤怠管理プロダクト、その中の2つの業務ドメインにあたる機能群を担当し、機能強化したり保守したりして育てて続けています。
チーム構成
私たちの開発グループ（弊社は開発組織の単位を「グループ」と呼んでいます）にはマネージャーである私含め9名が所属しています。
業務ドメインに応じてチームも 2 つに分けています。
こんな感じです。
前提
- チーム
- アジャイル開発
- 開発サイクルは 1 ヶ月
- チームイベントとして、毎日11:00-12:00で朝会（朝とは）、16:00-17:00で夕会（通称：モブワークタイム）を開催
- メンバー
- 全メンバーフルリモート（拠点も全国津々浦々）
- 全員プロパー（業務委託は現在なし）
- マネージャーは 2 チーム兼務
チーム 1
- マネージャー ＋ 開発メンバー 3 名
- 1 st リリースから約 20 年の機能群を担当
- 他ドメインとのつながりが深く、開発難易度は高め
- PR 数は 3 ～ 5 件／月
- 開発経験／ドメイン知識豊富なメンバーが中心
チーム 2
- マネージャー ＋ 開発メンバー 5 名
- 1 st リリースから約 15 年の機能群を担当
- まだまだ成長途上の機能強化フェーズ
- PR 数は 15 ～ 30 件／月
- 若手メンバー多め
本題：よりよいレビューフローを求めた奮闘の記録
私たちの開発グループでは、そのときどきの状況に応じて、大きく 4 回レビューフローを変えてきました。
- マネージャーが全チームの全PRをレビュー
- 全PRを全チームメンバーでモブレビュー
- 全PRを全チームメンバーで非同期レビュー
- チームごとに最適化
a. チーム 1：モブレビューに回帰
b. チーム 2：全メンバーによる条件付き非同期レビュー
やってみた 1：マネージャーが全チームの全PRをレビュー
まず最初は、マネージャーが全チームの全PRをひたすら捌いていく、というやり方でした。
やり方
- 2 チームのPRをひたすらマネージャーがレビューする。全部レビューする
よい点
開発メンバーが PR レビューに時間を取られない
なにより開発メンバーが PR レビューに時間を取られません。
開発メンバーは自身の実装に注力することができます。
イマイチな点
マネージャーがブロッカーとなり、レビュー遅延が発生する
マネージャー ＝ 私がなかなか PR を見る時間を取れなかったり、開発締め間際で PR の提出が集中したりすることで、レビューが滞留しやすい状態が生まれやすかったです。
ドメイン知識不足・スキル不足により、レビュー遅延に拍車がかかる
自グループの持つすべてのドメイン知識やコードを把握できてはいないので、ドメイン知識不足やスキル不足によって、1 つ 1 つのレビュー自体も時間がかかり、遅延に拍車をかけてしまっていました。
レビュー ＝ 最良の学習機会をマネージャーが独占してしまう
レビュー遅延を申し訳なく思ったり、負荷が高いと感じている一方で、私個人としてはすごく勉強になっていました。
PRを通して日々いろんな知識をメンバーから学べますし、こういう PR だとレビューしやすいんだ、というのも見えてきます。
こんな最良の学習機会を、マネージャーが独り占めしてしまっているのは、グループ全体にとって大きな損失だよな、とすごく感じました。
やり方 1 への課題感
いずれの問題も、マネージャーが PR レビューを 1 人で担っていることに起因していると感じました。
やってみた 2：全PRを全チームメンバーでモブレビュー
そこで2つ目のやり方を取ろうと思い至りました。
全部のPRをチームメンバー全員で集まってレビュー、つまりモブレビューしてみよう、というものです。
思い至ったはいいものの・・・
メンバーとしては「今までなかった『PRレビュー』という仕事が増える」というネガティブな感情があるかもしれない・・・という不安があったので、モブレビューに際して以下をメンバーに伝えたうえで、「レビューフロー変えませんか！？」という提案をしました。
- 現状のレビューフローの会代官とモブレビュー導入への想いを伝える
- 「一旦やってみて、イマイチなら戻そう！」もちゃんと伝えて退路を作る
- モブレビューの流れを明文化し、フローに迷わないようにする
メンバーは好意的！相談してよかった・・・
するとメンバーはかなり好意的で、「とりあえずやってみましょう！」となりました。
今思えばめちゃくちゃ振り切ってますし、よくフロー変更受け入れてくれたななどと・・・
やり方
- 朝会（Meet開催）の最後のアジェンダとしてモブレビューの時間を設ける
- 朝会までに上がったPRの担当チームが残り、マネージャー＋チームメンバー全員でモブレビュー
- レビュイーが簡単にPRの内容を説明した後、その場でレビュアーがコメント／マージ
よい点
たくさんありました。
1 営業日以上のレビュー滞留がほぼなくなった！
これが何より大きかったです。朝会までに上がったPRを朝会の中で見るため、すぐにレビューされて開発サイクルを前に進めることができます。
開発締めが近くなると、朝会では捌ききれない数のPRが上がってきたり、両チーム一斉にレビュー依頼が舞い込んだりするので、そのときは夕方のモブワークの時間で延長戦をしたり、別途追加のレビュー時間を押さえてとにかくレビューをみんなで捌きました。
メンバーがレビュー経験を積めたうえに、レビュイースキルも上がった
メンバーがレビューを経験することで、レビュアーとしての視座を得ることができました。
レビューする立場になると、以下のようなことも見えるようになってきて、レビュイーとしての質も底上げされました。
- あらかじめPRの説明文やコード上の補足として書かれているとレビューしやすい内容
- レビューしやすいコミットの分け方／PRの大きさ／PRの粒度
チーム全体のチームの持ち物に対する理解が深化した
レビュー対象のPRの内容はもちろん、それまで見えづらかったメンバー同士の担当案件の内容や、メンバーが持っている機能仕様や業務ドメインの知識も共有されて、チーム全体の持ち物の理解度が底上げされました。
自力で調べようとしたら途方もない時間や労力、考古学的センスを求められるような内容も、ベテランメンバーたちから若手メンバーたちにどんどん伝播されていくので、レビューの速度も上がりました。
コーディングルールの確認・醸成
コーディングルールをその場で確認し合ったり、議論が巻き起こるようなものはその場でルールを作ったりできました。
レビュアーとして「PR見る場を作る」というタスクが減った
毎日PRを見る時間が強制的に朝会に組み込まれたことで、PR見る場を作るというタスクが減って、すごくラクになりました。
マネージャーはミーティング多くなりがちなので、その間隙を縫ってレビュー時間を確保するというのはかなり至難の業だと思います。
それが勝手に組み込まれて舞い込んでくれるのは想像以上に負荷が軽くなります。
余談
ここまでのお話をより詳細に書いたものがあるので、よければご覧ください。
イマイチな点
しばらくはよかったんですが、次第にイマイチな点も出てきました。
個々のレビューの品質が下がりやすくなった
大きかったのは、レビュー品質が下がりやすくなったことです。
「モブレビューの時間に確認すればいいや」となってしまい、モブレビューで初めてPRの中身を見る、ということが増えてしまいました。
その結果、表面的なコーディングの指摘に終始しやすくなってしまいました。
PRの中には、本来はソースの前後関係を汲んだうえでのレビューが必要な更新もありましたが、特に考慮せず一律でモブレビューしてしまっていたため、PR上の修正内容のみに指摘がとどまりがちになりました。
“空気読んでApprove”も発生
メンバーの誰か 1 人が少しの引っ掛かりや違和感を感じたとしても、「周りがApproveしているから大丈夫なのか・・・」「〇〇さんがOKと言っているからきっと大丈夫」のような雰囲気も出てきてしまっているように感じました。
モブレビューのフローが重い場面も
モブレビューを謳いつつも、締切直前の駆け込み PR をマネージャーとレビュイーのみでレビュー＆マージしてしまう、ということも発生していました。
やり方 2 への課題感
品質が下がるのは本末転倒です。
また、私がイマイチだと思っていたのと同じことはメンバーも感じていて、次第にメンバーからも「PRもっとちゃんと見たいです」「やり方変えませんか？」という声があがってきました。
やってみた 3：全PRを全チームメンバーで非同期レビュー
そこで３つ目のやり方をやってみました。
全PRを全チームメンバーで見ることは変えず、モブではなく非同期でレビューしてみよう、というやり方です。
非同期レビューとは
これまでの「モブレビュー」が関係者が一同に介して（＝同期的）レビューしていたのに対して、
非同期レビューは、個々のレビュアーが、自分のタイミングでレビューすることを指します。
やり方
- チーム単位でレビュアー（マネージャー ＋ 同じチームの他メンバー）が、各々のタイミングでPRレビュー（＝ 非同期レビュー）
- 全レビュアーのApproveを以てマージ
- レビュイーに解説してほしいもの、他のレビュアーと議論したうえでApproveやコメントしたいものは朝会でモブレビュー開催
よい点
PR をじっくりとレビューできるようになった
やはり PR そのものをじっくり見られるようになりましたし、
必要に応じて、その前後関係も見たうえでコメント／Approve することができるようになりました。
チーム内のレビュー観点の醸成やノウハウ共有もPRコメントを通して継続できた
PR コメント上でメンバー同士議論ができていました。
また、メンバーのレビューコメントを他メンバーが見に行く、ということも意識されており、レビュー観点を作ったりノウハウを共有したりもPR上で継続できていました。
イマイチな点
再びレビュー遅延が発生するように
じっくり PR を見られるように、を重視した結果、再びレビュー遅延が発生するようになりました。
レビュイーによる口頭説明もなくなって、読み解き難易度があがってしまったこともあり、じっくり見るという名目でついついレビューが後回しになるようになりました。
全メンバーによるApproveを待つという点も特に緩めていなかったため、遅延に拍車をかけていました。
長いものだと 2 週間近くマージされない PR なども出てきてしまいました。
レビュー遅延により開発サイクルが前に進まなくなる
レビュー滞留によって、レビュイーはなかなか開発サイクルを次に進められず、以下のようなデスマーチが発生しつつありました。
PRがマージされない → 仕方ないから他の開発に着手 → 終盤に一気にレビュー → マルチタスク化、共倒れのリスク発生
やり方 3 への課題感
レビュー遅延時の考慮不足
レビューが遅延した際の考慮が全くできていなかったことが大きかったです。
1つ目のやり方でマネージャー1人での非同期レビューですら遅れていたのに、それがメンバー全員による非同期レビューになったら、何かしらの対策を講じないとレビュー遅延が発生することは予測できていたはずでした。
レビューの優先順位付けの認識合わせができていなかった
メンバーの様子を見ていると、レビューよりも自身の実装を優先している傾向があるように感じました。
そのとき、チーム開発でレビューが通らないとモノが出せないんだよ、レビューっていうのはチーム開発において最優先事項なんだよ、というような話を、改めて話したことがなかった（＝暗黙の了解感）があったことに気づかされました。
やってみた 4：チームごとに最適化
現在やってみているやり方は、2 つあるチームで統一のレビューフローを取るのではなく、それぞれで最適なフローで回してみています。
3 たびフローを変える、その前に
レビュー優先度に関する勉強会を開催
反省点の1つとして挙げていた、「レビューっていうのはチーム開発において最優先事項なんだよ」という認識合わせをするための勉強会を開催しました。
その時の内容を下記にまとめています。
なお、そのときにチームメンバーの作業スタイル共有会をして、各々の快適な開発スタイルは？を共有しあうというワークをしました。
作業スタイルを大きく 2 パターン提示し、どちらかと言うとどっち？を投票するというごく簡単なものです。
その結果、ほとんどのメンバーが「1 チケット集中型」でマルチタスクしたくない！という意見だったので、やはり相手のレビューを優先して、自分のせいでマルチタスクを引き起こすことは避けよう、とより強固な共通認識を作ることができました。
改善版レビューフローのたたき台を作成、ブラッシュアップ
私が改善版のレビューフローのたたき台を作成し、メンバーと一緒にブラッシュアップしました。
ブラッシュアップの中で、チーム 1 のメンバーから、改善案に対して「チーム1 は改善案のやり方より、以前やっていたモブ形式の方が合っていると思う」と意見があがりました。
ならチームそれぞれで、自分たちに合ったやり方を考えてみましょう！となりました。
具体的には、
チーム 1 はモブレビュー形式に戻し、
チーム 2 はたたき台をベースとした全メンバーによる条件付きの非同期レビューという形式に変更しました。
やってみた 4 - 2 ：全メンバーによる条件付き非同期レビュー
やり方
やり方 3 の非同期レビューの形式に加え、以下の条件を加えました。
- 期限の制約：1 営業日以内の非同期レビュー
- それ以降の滞留／必要に応じてモブレビュー開催
- マージまでの制約（緩和）：マネージャー＋メンバーの過半数のApproveでマージ
- 新規配属メンバーは他メンバーと同様にレビュアーになってもらうが、約 6 ヶ月は過半数の対象に含まない（そのメンバーの配属までのバックグラウンドによって適宜調整）
- これらの確認を朝会の最後のアジェンダとして追加
- 下記だと、赤枠は
a day staleになっているのでモブレビュー開催、青枠は5 hours staleなので各自で非同期レビュー
- ちなみにSlack通知はこちらを利用しています：https://github.com/integrations/slack
- 下記だと、赤枠は
よい点
非同期レビューのよい点はそのままに、期限が設けられたことで以下が改善されました。
レビュー遅延が発生しなくなった
期限の制約がついたため、レビュー遅延が発生しなくなりました。
レビュー優先度に関する勉強会、作業スタイル共有会も功を奏し、レビューが来たら優先して見よう！という意識が醸成されているのも感じています。
遠慮なくモブレビューを依頼するメンバーが増えた
これも期限の制約が設けられたことに起因していると思いますが、メンバーが無理して自力でPRを読み解ききろう、としすぎなくなり、モブレビューを開催することが増え、ちょっと読み解きが難しいようなPRも早くレビューが進むようになりました。
イマイチな点
まだこのレビューフローの運用を始めて 2 ヶ月ちょっとなので、そこまで出てきていませんが、今後課題になってきそうな点を挙げておきます。
今後また若手メンバーが増えてきたときにこのフローで回るのか？
マージまでの制約を緩和できたのは、ここまでの約1年半において、チーム 2 のメンバーの成長が著しく、「緩和しても大丈夫だよね」と踏み切れたという背景がありました。
現在でも未経験で配属されたメンバーが 1 人おり、その方とは 1 on 1 などで状況を聴きつつ、フローを微調整しています。
一気にメンバーが増えたときなどは、一時的に一部モブレビューに戻す、などの改善をする必要があるかなと思っています。
（しいて言えば）たとえばあと1人で過半数というときにモブレビューを開催するか迷ってしまう
本来は迷うことなく強制的にモブレビュー敢行というルールですが、今のところは朝会や夕会で未レビューメンバーに声掛けすることでまかなえているので、敢えて厳格にはやっていません。
おわりに：至高のレビューフローは存在しない
至高のレビューフローなんてものは存在しないと痛感する日々なので、そのときどきのチームにとっていい塩梅にレビューフローを整える必要があります。
ただ整えるためには、チームが PR レビューに対して求めるポイントを明らかにしておくことが重要だと思います。
たとえば私たちのグループでは
機能の品質を担保できる、ということは大前提としつつ、以下を大切にしています。
- 滞留せず、快適に開発を進められる
- チームメンバーの成長の場である
- "今"のレビューフローに納得感が持てる
上記に加えて、
- チームメンバーの人数やスキル
- チームが持つ担当機能群のフェーズ
- 案件状況
などさまざまな要因を加味しながら、今後またチームの状況が変わった場合でも、柔軟にフローを改善していきたいと思います。
