「もくもくプルリクレビュー」で「プルリクレビュー溜まりがち問題」を解消する

エンジニアの内山です。
足にできた魚の目が痛いです。

最近、私が参加しているプロジェクトで、「もくもくプルリクレビュー」というものが始まりました。決まった時間に、プロジェクトメンバー全員が同時にプルリクレビューを行うというものです。

今回は、「もくもくプルリクレビュー」について紹介いたします。

プルリクが溜まってしまう問題

プルリクレビューを取り入れているプロジェクトでは、__プルリクが溜まってしまう__という問題が起こりがちです。

プルリクが溜まってしまう原因の一つに、__レビュー自体が結構大変な作業であること__があるのではないかと思います。

レビューは以下のような流れで行います。

• 実装すべき仕様を確認する
• ソースコードを差分で確認する
• 仕様がすべて実装されているかを確認する
• わからない部分は質問する

レビュイーは、レビュワーがこの作業をスムーズに行うために、気を使う必要があります。
そのポイントについては、過去の記事でも紹介しています。

ReadableなPull Requestを作る為に心がけていること

しかし、レビュワー自身が担当している作業とレビューを行き来することは、コンテキストスイッチのコストがどうしても大きくなってしまいます。

それならば、いっそメンバー全員で同時にレビューする時間を設けてしまう、という考えになったのが「もくもくプルリクレビュー」です。

もくもくプルリクレビュー

通常のもくもく会では、それぞれのメンバーが自分の作業をします。
もくもくプルリクレビューでは、それぞれのメンバーがレビュワーとなっているプルリクのレビューを行っていきます。

現在、弊社で行っている「もくもくプルリクレビュー」は、以下のようになっています。

• チームメンバー全員がSlack通話で繋がっている状態にしておく
• 制限時間を決めておく(「1時間」「〇〇時まで」など）
• 全員が別々で担当となっているプルリクのレビューをしていく
• 疑問などがあった場合は、即座にその場で実装担当者に訊く
• 複雑になってしまったプルリクの場合は、担当者が画面共有をして解説する

これを毎朝のデイリースクラム後に行っています。
モクモクプルリクレビューには以下のような利点があります。

• 開発などの別タスクとのコンテキストスイッチが発生しない
• 疑問などがあった場合、複数回のやりとりがすばやくできる
• 複雑な仕様だった場合、複数人で確認しながらレビューを行える

これにより、「1週間以上放置されてプルリクが溜まってしまう」といったことがほぼなくなりました。

欠点としては、全体の開発の進捗が落ちてしまう可能性がある__ということでしょうか。
メンバー全員がレビューを行うため、その間はプログラミングによる開発が止まってしまうので、かなり進捗が落ちてしまうように感じてしまうかもしれません。
しかし、__開発とはプログラミングだけでなくレビューされてマージされるまでのこと と捉えると良いのではないでしょうか。

全体的には進捗は改善されているのではないかと考えています。

プロジェクトの状況によっては、モクモクプルリクレビューの頻度や時間制限を調整する必要が出てくるかもしれません。

別原因も考察

今回はプルリクが溜まってしまう問題の原因の一つとして、__レビュワーのコンテキストスイッチのコストが大きい__ということを上げました。

もう一つ、別の原因があるとしたら レビューすることに達成感を感じづらい ということでしょうか。

実装であれば、「masterにプルリクをマージする瞬間」「チケットを完了ステータスに更新する瞬間」などに、ちょっとした達成感を感じることができます。

これに比べて、プルリクレビューはあまり達成感を感じることがありません。ですので、達成感のある他の作業についつい向かいがちになってしまうことが起きてしまっているのではないかと推測しています。

この原因に対する解決策については、今後また何かでき次第、ご紹介したいと思います。

MMMではプルリクレビューで切磋琢磨しながら働ける仲間を募集しています！
リモートワークで自社オウンドメディアを立ち上げたいWebプロデューサー募集
フルリモートワークでチームを率いるフロントエンド領域のテックリード大募集
リモートワークでAWSなサーバーレスシステムに携わりたいエンジニア大募集
リモートワークでチームを引っ張りたい経験豊富なUI/UXデザイナー大募集

uchiko