開発レビューをモブでやるようにしてみたら、

もともとレビュワーだった私としても、チーム全体としても、得られるものがとても大きくておすすめだよ、というお話です。

はじめに

私が所属するチームでは約半年前から、以下の3つのレビューをモブ形式で実施しています。

• PRレビュー
• テストケースレビュー
• リリースノートレビュー

本記事では、モブレビューを始めたきっかけ、始め方、大まかな流れ、効果を記載します。

前提

• チームメンバーは多拠点にまたがり、全員フルリモート勤務
• ミーティングは基本的にGoogle Meet、一部oVice
• チーム内で複数のサブシステムを担当しており、担当メンバーがある程度わかれている（1サブシステムにつき2～4人）

モブレビューを始めたきっかけ

冒頭で約半年前からモブレビューを始めたと記載しましたが、それ以前は、基本的にマネージャーである私が全てのPR／テストケース／リリースノートに目を通し、承認していました。

しかしながら、以下のような問題意識がありました。

• 特に開発締め前後にPRやテストケースのレビュー依頼が集中するため滞留しがち
• レビュー機会をマネージャーが独り占めするのはメンバーにとっての重大な機会損失

レビュー滞留問題

私のチームは、プロパーメンバー・業務委託メンバーを合わせると、私以外に8名の開発者がいます。
その8名が、各々のタイミングで、各々の案件のレビュー依頼を提出します。
それに対してレビュアーは私1人。

モブレビュー導入以前も、私が判断に迷うものや、修正量が多いものについては、開発者に説明を依頼したり、モブ形式でのレビューを随時開催はしていました。¹

とはいえ、なるべく自分で理解しようとして、時間が経って、MTGに参加する時間が来てレビューしきれなくて、その間にもどんどんレビュー依頼が舞い込んできて・・・そして子供のお迎え時間が来て・・・ああ今日もレビューしきれなかった・・・

少しでも円滑にチーム全体の開発プロセスを回せるように、PRレビューとテストケースレビューであればPRレビューを優先してレビューしたりもしました。
その結果、せっかく早く依頼を出してくれていた開発者のテストケースレビューを1週間滞留・・・なんてことも起こっていました。

完全に自分がブロッカーになっていることは認識していました。

メンバーの開発業務にも支障をきたしてしまう状態で、滞留させないためにはマネージャーががんばる、無理をする必要がある状態。
こんなの長続きしない。どう考えてもよろしくない！

レビュー機会損失問題

レビューを一手に引き受けるのは本当に大変でした。
一方で、日々とてつもなく勉強になり、ありがたく感じていました（集中すると本当にめちゃくちゃつらいんですけどね）。

ソースの書き方1つとっても、
「なるほど、こんな記法があるのか！」
「このオブジェクトはこういうときに効果を発揮するのか！」
「この設計手法をこうやって実践的に使えるのか～」
と新たな発見が日々あります。

PRへの補足説明の粒度やテストケースの観点の分け方、スクリーンショットや関連ドキュメントの添付の有無などもレビュイーによって異なり、レビューしやすいPR／テストケースというのが見えてきます。

正直めちゃくちゃ役得です。レビュー依頼は定期的に、勝手にやってきます。そのたびにコードを読む機会があり、理解する機会があり、解説してもらう機会があります。
この学習機会を私が独り占めしてるって、いかがなものだろう？

そうだ、みんなでレビューしてみよう！

2つの問題は、いずれも私がレビューを独占しているからこそ生まれてしまっているように見えました。
ならば、みんなでレビューすればいいんじゃない？
機会均等、負荷分散。モブレビュー、よさそうですよね。
ただし、言うまでもなく大きなデメリットがあります。

そう、メンバーの時間を消費することです。

これまで負荷は高くとも1人で捌いてきた理由の筆頭が、「レビューは時間がかかるから、メンバーの開発時間を減らしたくない」でした。
しかし、レビューはとても効果の高い学習機会だとも感じていたので、時間をかけて余りあるメリットの1つになるはずです。

とはいえ、一気に、自分勝手にモブレビューを導入したらきっとメンバーは動揺したり、もしや反発したりするかもしれない・・・

ということで、少しずつ導入することにしました。

モブレビュー導入までの道のり

導入するまでを割と丁寧に進めました。
大きくは以下の3つ。

1. メンバーに想いを伝える
2. モブレビュー導入順を決める
3. モブレビューの流れとポイントを明文化し、メンバーに説明する

メンバーに想いを伝える

まずはモブレビューをしたいと思っていること、その理由、その時点で考えているモブレビューの大まかな流れを、各メンバーとの1on1などで伝え、率直な意見を聞いてみました。

思った以上に肯定的でした。やはりプロセスを前に進められないのはみんな課題を感じていたようです。
とりあえずやってみましょう！というのがほぼ共通の意見でした（もしかしたら私の力説に圧されて反論できなかったかも・・・ごめんなさい）。
あと私の負荷を心配する声があったので涙が出るかと思いました。みんなやさしい・・・

というわけで、モブレビュー計画を本格始動させました。

モブレビュー導入順を決める

はじめにに書いたとおり、私たちのチームでは3つのレビューがあります。
それを最初からすべてモブ形式にすると動揺や渋滞が起こってネガティブな印象になってしまうことが懸念されました。

あと、私自身もモブレビューに少しずつ慣れていきたいと感じたので、これはメンバーも同様だろうと予想しました。

なので、以下の順番でモブレビュー化していくことにしました。

1. PRレビュー
2. テストケースレビュー

半年間でレビューのモブ化を果たそうと計画していたため、最初の3ヶ月間でPRレビューを軌道に乗せ、その後の3ヶ月でテストケースレビューもモブ化することにしました。

各モブレビューの流れとポイントを明文化し、メンバーに説明する

何かを始めるときは、最初は手順が決まっていた方がプロセスに集中できると思います。
あと何よりもモブレビュー全体のファシリをする自分がテンパらないようにするため。
なので、ちょっと細かすぎじゃない？と思うレベルに手順を決め、メンバーに共有²しました。

細かな流れやルールは後述するのでここでは割愛します。

メンバーに一旦説明はしたものの、細かいから実際やってみないとわからないよね～ということで、その時点での疑問点や改善点があれば挙げてもらい、そのうえでとりあえずやってみましょう、で説明はひとまず完了。

ついでにリリースノートレビューの効率化も図る

リリースノートレビューは正直そこまで負担ではなかったので引き続きこのままでもいいか・・・と思っていたのですが、最終的にテストケースレビューに組み込むことにしました。

• テストケースフォーマットにリリースノートに記載するのとほぼ同内容を記載する箇所（概要シート）がある
  • ヒアリングの結果、どのチーム・どの部署もプロセスとして利用していないことが発覚（つまり形骸化されたフォーマット）
• チーム内でも概要シートを記載する意義が正直見いだせていない
• リリースノートはイテレーション内のすべての開発プロセスが終わるまでに書けばよく、大体最後まで後回しにしがちで「思い出す」というプロセスが発生してしまい、非効率
  • 実はテストケースと一緒にレビュー依頼を出してくれていたメンバーもいたが、結局私がレビューを後回しにしがち（そして私に「思い出す」という作業が発生する）

以上のことから、概要シートの記載を廃止し、リリースノートをテストケースレビューまでに記載して概要シートの代替とすることにしました。

これにより、リリースノートのレビューはするものの、プロセスとしてはテストケースレビュー内に組み込み、レビュータイミングを1回減らすことに成功しました。

レビューの大まかな流れ

PRレビューもテストケースレビューもほぼ同じフローなので、PRモブレビューを例に記載します。

1. [ファシリ] 今日のレビュー一覧を見て上から順にレビュイーに内容の解説を依頼する
2. [レビュイー] レビュー対象のPRやチケットをMeetのチャット欄などで共有
3. [レビュイー] 自信の画面共有をして内容を説明
4. [レビュワー] 適宜質問や改善点の指摘
   • ここで議論が巻き起こることもしばしば
   • [ファシリ／レビュイー]改善点の指摘があった場合はPR上にコメントを残す
5. [ファシリ] 指摘がなければその場でマージ
6. [レビュイー]修正内容のボリュームによっては再度PRレビュー依頼、ボリュームが小さい場合はPR上でやりとり（実際にはコメントがSlackに即時通知されるのでSlack見つつPRにコメントしつつ）³

これらをレビュー依頼があった数分繰り返します。

テストケースレビューの場合はレビュイーが冒頭でリリースノートの解説を入れ、コメント／承認を行います。

レビュールール

• 毎朝10:00に未レビューのPR一覧をSlackで通知（利用ツール）
  • その一覧から今日レビューが必要なPRを確認し、基本的には上から順にレビュー
  • テストケースレビューはリスト化できていないため、本記事投稿時点では別チャンネルで投稿されているレビュー依頼の確認やレビュイーによる挙手制で補っている
• 毎日11:00-12:00で開催しているデイリーMTGの最後のトピックとして取り上げる
  • デイリーMTGが30分前後前倒しで終わることが多かったため
  • 数が多い、時間が足りない場合は毎日16:00-17:00に実施している「モブワークタイム」でおかわり
  • それでも足りなさそうな場合、急ぎレビューが必要な場合は別途レビュースケジュールを登録
• 全体のファシリはマネージャー、画面共有はレビュイー
• 複数サブシステムのレビューがある場合、担当者は全員残る
  • レビュー順は冒頭にファシリが決定
  • 2番目以降になったサブは、他サブのレビュー中は作業していてOK（レビュワーとして参加してももちろんOK）
  • 自担当サブのレビューがすべて終わったメンバーから退出してOK
• モブレビューを必須にはしていない
  • 軽微なもの、急ぎのものはマネージャー判断でモブレビューのタイミングを待たずに通すことも

モブレビューの効果

レビューを滞留することがほぼなくなった

レビューの滞留が1営業日以上にまたがることがほぼなくなりました。

レビュー依頼は1日あたり5件未満なので、基本的にはデイリーMTG内で1営業日以内に挙がってきたレビュー依頼は捌ききることができます。
開発締め前後のレビュー繁忙期でも、夕方のモブワークタイムでほぼ捌ききれます。

そして私の負荷も当然ながら大きく減りました。本当にありがたい・・・！
あと問答無用でレビュー時間を取るって、実は大事なんだなと実感しています。そうでなければ自分の業務の合間でレビュー時間を「作らなければいけない」ので、ステップが1つ多かったんだなと。それもまた負担の1つになっていたんだなと感じました。

個々の案件やPRの内容、ひいてはサブシステムそのものへのチーム全体の理解が深化する

レビュー機会損失問題セクションで申し訳ないと記載していた点でした。
やはりこれはチーム全体にとって大きな効果だと感じています。

レビュイーがPRやテストケースの内容を解説するために、「そもそもこれはどういう不具合／機能強化なのか」「絡んでくる周辺機能は何か」といった内容にも踏み込んでくれたり、実際に画面でデモをしてくれたりします。
PRに記載してくれていることも多いですが、やはり開発者本人から直接説明を聞くのには勝てないな、と感じます。

また、レビューにはレビュワーとして若手もベテランも参加しますし、得意分野も少しずつ異なります。
ある人からはプログラミング言語やプラットフォームの背景などを踏まえたより良いコーディングの指摘が入ることもあれば、別の人からはコードをざっと読んだだけでは読み取れなかった仕様や業務ドメインを踏まえた制約などを教えてもらうことができます。⁴

レビュイーによる解説やレビュワーによる指摘を通して、それらを知る機会が圧倒的に増えました。

コーディングの共通認識を即座に作ることができる

コーディング時に「私は感覚的にこっちなんだけど、みんなどう思う？」と聞くと、それに対する肯定／反対意見を述べてくれ、議論が白熱したときは、どうあるべきかをみんなで書籍、ネット記事、生成AIなどを参考に考えて「チームとしては原則これで行こう！」という話ができたりします。

こういう議論は、わざわざ腰を据えてできる類のものではないと個人的には思っています。
都度問題提起すればいいのかもしれないけれど、鮮度が低くなってからではなかなかハードルが高くなってしまいます。

なので、自然発生的にこういった会話を、メンバーとできるのは、1人でレビューしていたときにはできなくて、モブならではの効能だと思っています。

レビュワーとしての視座を得られる

これももともと私が1人でレビューをさばいていた時に「機会を奪っているな・・・」と感じていた点の1つでした。

メンバーがレビュワーになることで、「なぜこの書き方がいいのか／悪いのか」に触れる機会が圧倒的に増えます。
最初は「そういう観点があるのか～」で止まってしまうかもしれませんが、何度もレビューしているうちにだんだんそういった違和感を感じ取れるようになってきているはずです。
実際、モブレビューの回数を重ねるごとに、私以外のメンバーからの質問や指摘が増えてきたなと感じます。

また、別の利点として、レビュイーとして説明した方がいいポイントの勘所が掴めるようになります。
どこにどういう解説があったらわかりやすいだろう？を、想像するのと体験するのとでは理解度が段違いです。
全員レビュワーになることで、レビュワーの視座を得られるのはもちろんですし、レビュイーとしての質も底上げされていると感じます。

おわりに：実はモブレビューは従前の開発プロセスを改良しただけ

大層にモブレビューについて書いてきましたが、実は少し前までは若干形は違えどモブレビューを開催していました。
これは、Gitを導入する前にコード管理ツールとしてSubversion（SVN）などを使っていたことが理由の1つにあると予測します。

SVNでは、PRのような形式でオンライン上でレビューをした上でマージ（SVN的にはコミット）することができまません。そのため、あらかじめ関係者にコミット前に差分を解説する必要がありました。
それがGitになったことで、PR上でほとんどを表現できるようになったため、自然に対面レビューではなくPR画面を利用した非同期レビューに移っていきました。

当時はレビューに多くの時間を取られてつらいな、この時間でコーディングしたいんだけど・・・などと思っていましたが、実は得難いキャッチアップの場だったんだなと認識を改めました。

チーム内外の状況に応じて再びモブ形式でなくす日が来るかもしれませんが、ひとまずはこの体制を継続してみようと思います。

1. マネージャーと言えども記事投稿時点でようやく1年が経とうとしている程度で、チーム生え抜きマネージャーでもありませんでした。そのため、自チームのすべての仕様やコードを掌握しきれている自信は残念ながらありません。適宜メンバーの力を借りていました。 ↩

2. 各モブレビューが開始する数日前に共有しています。でないとみんな忘れてしまうので。それに伴って、PRモブレビューとテストケースモブレビューのプロセスの清書は時期が3ヶ月ずれていました。 ↩

3. 指摘内容は基本PRに残しています。その後コメントベースでやり取りをする場合も同様です。Slack上でやり取りをする方がもちろん簡単ですが、将来的にその案件を辿るときにはチケットやPRが起点になるので、PR上に足跡を残しています。 ↩

4. PRから読み取れないなんてクソコードだろ、とか、レビュワーのレビュー力の問題じゃね？といった声が聞こえてきそうですが、20年近くにわたって熟成されたソースコードのためご容赦ください。豊富な機能を持つサブシステムだと、知らない機能や仕様がとどまりません。 ↩