コードレビューの完了時間を30%削減した時の取り組み #開発プロセス

この記事では

「プルリクエストをマージするまでの時間を削減したい」
そのような方向けに、チームで行った取り組みをいくつかご紹介します。

私の所属するチームでは「プルリクエストを作成してからマージされるまでの期間が長い」という課題を抱えていました。
変更行数が数十行のものでも０～３日、変更行数が多かったり新人のものだと１週間以上・・・

その課題は、さらに以下のような課題の原因となっていたよう思われます。

大きな原因としてはまず、各プルリクエストをメンバー全員（開発者５名ほど）でレビューしていることが考えられます。ただ、全員レビューの目的もありますので（おまけ参照）、まずは全員レビューを維持した上での取り組みを検討することにしました。

開発メンバー全員で原因をディスカッションしたところ、以下があがりました。

ディスカッションした内容を元に、以下を行うこととしました。

残念ながら、１回のプルリクエスト内の変更量を削減するための取り組みはまだできていません。

原因にありましたが、元々レビューの優先度は開発者の中では高くないようでした（そりゃコード書く方が楽しい）。
とはいえ全体の生産性に関わるため、開発者のマインドを変えるべく、以下を提案しています。

※いきなりこんなことを言うと反発を生むので、自分事として捉えてもらうための活動は必要と思います。雑談に含めたり、メンバー間で問題点を話し合ったり。

プルリクエストの承認状況をデイリースクラムで共有するようにしました。
Googleスプレッドシートで画像の内容を見えるようにしています。（変更行数多いな・・・）

15~30分のデイリースクラム後、30分のレビュー時間を確保するようにしました。
全員オンラインの状態を保ち、確認点あれば口頭または画面共有で確認します。そして、口頭での結論のみをプルリクエスト内に残します。

記載内容の統一化のため、プルリクエストのテンプレート機能を利用することとしました。
「あれどうなった？」という余計なコミュニケーションを生まないという効果を見込めます。

見るべきものがわかりやすいよう、タイトルにキーワードを埋め込むようにしました。キーワードは【簡単】【至急】などです。
ささいな工夫ですが、精神的負担を減らす、優先順を迷わないようにする、といった効果があります。

運用を変えてから１ヶ月後、改善効果を測るために運用改善前後を同条件で比較してみたところ、画像のようになりました。

中央値こそ変わりませんが、平均およびバラつき（分散・標準偏差）の改善を確認できています。１日で確認を終えているものの割合が減った理由は、新機能追加のチケットの割合が多いためと思われます。
全員コードレビューの体制を維持しつつ、日数を削減できたことはとても良いことと思われます。

メンバーからも「感覚的にもプルリクがマージされやすくなった」「ちょっとした口頭のコミュニケーションが取りやすくなった」「開発リズムが安定した」といったポジティブな声が出ています。

１回のプルリクエストの変更量を下げる取り組みなど、継続して改善活動を続けていく予定です。