Now in REALITY Tech #101 チキチキ PRのレビューを素早くやろう選手権でレビュー速度を改善！
みなさんこんにちは。
REALITYのエンジニアリンググループというところでマネージャーをしているションローです。
最近、妻から良い感じの傘をプレゼントしてもらったのですが、良い傘を持つと雨の日が好きになるということを学びました。
大事な人へのプレゼントとしてオススメです！
REALITY エンジニアリングチームの開発生産性の話
さて本題です。
自分はマネージャーとしてエンジニアリンググループ全体の開発生産性に対して責任を持っており、生産性を上げる事でユーザーへの価値提供スピードを高めるのが主要なミッションです。
今回はその中で取り組んだ「チキチキ PRのレビューを素早くやろう選手権」について紹介したいと思います。
「チキチキ PRのレビューを素早くやろう選手権」とは一体何なのか
名前から想像される通り「PR (Pull Request)に対するレビュー」を「レビュアーが素早く実施できるようにする事」を目的としたキャンペーンです。
開発チームのパフォーマンスを示す指標であるFour Keysにおける「Lead time for changes」の一部であり、ここを改善することでリードタイムを短縮することを目指して実施しました。
取組期間としては 2023/8~12 で実施、対象メンバーはREALITYの開発チーム
のソフトウェアエンジニア（6チーム、40名程度）になります。
レビューの速度については Findy Team+ を利用して定量的に評価しました。(Findyさんいつもお世話になっております。)
改善の進め方
エンジニアリンググループ全体での目標値を決め、その配下にある各チームのマネージャーと認識合わせをしながら進めました。
チームの目標数値を決める
レビューに時間がかかっている原因を特定する
個別の問題に対して改善を行う
目標数値
エンジニアリンググループ全体目標として「レビュー依頼からレビューがつくまでの時間」の平均が 24時間 以内になることを目標としました。（ストレッチ目標 12時間 も）
選手権開始前の数値感は各チームごとにかなり違いました。1日くらいでレビューがされることもあれば、数日かかることも。
各チームとの議論の結果「レビュー依頼をしてから1日以内にはコメントが帰ってきてほしい！」という思想で統一し、上記の数字を目指すこととしました。
レビューに時間がかかっていた原因
チームごとに色々と事情はありましたが、だいたい以下の3つが主要な問題として出てきました。
PRの依頼自体に気づいていない
PRの粒度が大きくて、レビューに時間がかかる
特定の人間にレビュー依頼が集中してしまい、ボトルネックになっている
実際に行った改善
上記の問題をうけて、以下のような改善を行いました
PRのレビューが依頼されている事に気づきやすくする
PRの粒度を小さくし、レビュアーがレビューしやすいようにする
特定の人にレビュー依頼が集中してしまう状況を改善する
1については、GitHub と Slack のインテグレーション設定の追加や、リマインドの仕組みを導入したりして気づきやすい状態を作りました。
すごい地味だけど、Slack通知（特にリマインド）で気づきやすくなったという声も結構あったようです。
2についてはPRの粒度をチームに合わせた形で最適化する取り組みを進めました。
チームによって取り組み方が違いましたが、面白かったものとして「レビューを依頼する人とPRの分割の仕方を事前に内容をすり合わせておく」というものがありました。
PRのサイズや分割の仕方について、お互いに事前に確認することでお互い納得感を持ちつつ素早くレビューに入ることにつながったようです。
3については主に「マネージャーとテックリードにレビュー依頼が集中する」という状況でした。
また、Findy Team+の数値を確認したところ、特にバックエンドのチームで顕著に表れていました。
レビュアーはランダムアサインで決まる運用を行っていたのですが、マネージャー / テックリードはそれに加えて個別にレビュー依頼が飛んでくること、さらに個別に依頼されるPRレビューは「重い」内容で時間がかかりがちということもわかりました。
そこで、バックエンドのチームについてはマネージャーとテックリードは「個別にレビュー依頼されたPR」のみ対応を行うこととして、レビューの量をバランシングすることとしました。
選手権の結果
取組の結果としては以下のようになりました。
PRをオープンしてから最初のレビューがつくまでの時間が 平均 50時間 -> 17時間に改善した（定量）
選手権前後で、レビュープロセスにおける体験が改善した（定性）
定量面での評価
以下は取り組み前と取り組み中の「オープンからレビューまでのリードタイム」平均値になります
取り組みの最終月である2023/12の数値としては、「オープンからレビューまでのリードタイム」 は 5 時間でした！めっちゃ早い！気がする！
お昼前にレビューを依頼すると、夕方ころにはレビューされているような状態ですね。
以下は Findy Team+ の サイクルタイム分析 画面で確認できる「オープンからレビューまでのリードタイム」を時系列で表したグラフになります。
取り組みを開始した8月から徐々にリードタイムが短くなっていっている様子がわかります。
普段の開発項目や内容によって数値が影響を受ける部分もありますが、スピードが早い状態を一定期間維持できているのは非常に良かったです。
定性面での評価
定性面での評価は、取り組み後にアンケートを実施して評価を行いました。
アンケートは以下のような構成で実施しました。
レビュイー（レビューを依頼する立場）で、PRのレビュー体験が変わったかの質問
レビュアー（レビューを実施する立場）で、PRのレビュー体験が変わったかの質問
PRのレビュープロセス全体に関わる質問
今回は、アンケートの結果から質問と回答をいくつか抜粋してご紹介します。
以下は「待ち時間が早くなったか」の体感を解答してもらった結果ですが、多くの人が体感で早くなった実感を得ることが出来ました。
また、待ち時間について自由記述でもらったコメントは以下になります。
コメントが付くまでだいぶ早くなったので、修正をするのも早くできるようになった。また、マージを早くできるようになったのでコンフリクトの発生頻度が下がった
レビューに対する意識が変わったのか、後回しにされることが少なくなったかなと言う印象です。
次に、レビューは早くなったが、レビューの品質が低下していないだろうか？という観点での質問に対する解答です。
概ね変わらず、一部の人は質が上がったと感じているようでした。
品質は特に変わらないように思いました
変化なし
他にも色々な解答を頂いたのですが、量が多いので今回はこれくらいで。
全体的にポジティブな意見が多く、定性面でも良い取り組みになったと感じています。
一方で、今後の課題となりそうなコメントもいくつかもらったので、引き続き改善の取り組みを続けていく所存です。
レビューを早めに返すためにコンテキストスイッチは発生しやすかったように感じる
まだ12hではないので、その水準を目指したい
PRのサイズが大きい場合が多く、すぐにレビューするには心理的負担が大きい PRをなるべく細かく分けたい
たまに、レビューの段階で指摘するには遅い問題を見つけた場合にどうするかちょっと悩む
まとめと今後の展望
REALITY エンジニアリンググループの開発生産性向上の取り組みについて紹介しました。
現在は「サイクルタイム全体」をスコープに広げつつ、開発生産性を改善する取り組みや、いわゆる「フロー効率」にフォーカスした改善を進めています。
その取り組みも今後ご紹介していければと思っています。
開発生産性の向上を通してプロダクトの進化を爆速にし、ユーザーの皆様に価値提供していくスピードを高めていきたいと思っています。
REALITYの今後の進化にご期待ください！