abceed開発チームのPRレビュー促進活動

Globeeでエンジニアリングマネージャをしています、鈴木です。
今日は弊社の開発チームの様子について、Pull Requestの相互レビュー文化の観点からお伝えできればと思います。

経緯、前提

レビュー依頼はPull Request上の「Reviewer」にレビュアーを設定することで行っています。
GitHubからSlackに通知を流している + 全員Slack上のGitHubプラグインに認証してもらっているので、これでレビュアーにメンションが届く形です。

もちろん埋もれてしまうこともあるので、Webの通知欄やGitHubのiOS/Androidアプリで通知を受け取っている人もいます。

その他細かい部分では以下のような運用もあります。

• 1 approveあればマージして良い。

• コメント種別 must,imo,nits,askを使い分ける。

• iOS,AndroidはPRごとにベータ版をDeployGateにアップしてレビュー負荷を下げる工夫をしている。

以前はレビュー依頼はSlackで個別に行っていたのですぐ埋もれてしまったり、何より手間というのがあったので、この状態でもかなり改善された状態だと思います。
しかし依然として課題がある状態でしたので、早速本題に入っていきます。

課題

なかなかレビューされない（レビューリードタイム)

せっかくPRを出したのに数時間、下手すると数日以上放置される状態、まあよくあるじゃないですか。
いわゆるリソース効率が高くフロー効率が低い状態ですよね。（本当にリソース効率が"高い"のか？というのは聞いてはいけない笑）

リソース効率が高いのは悪いことではないのですが、個人開発ではなくチーム開発ですので、一般的にはフロー効率を優先したほうがメリットを得られるはずです。
「自分の仕事が終わっていないからレビューできない」という声も聞くのですが、自分の仕事が終わってなかったら人の仕事の邪魔をしてもいいのでしょうか？そんなことはないはずですよね。
どんなに忙しくてもレビュー依頼に対しては秒で反応する、そんな文化をよしとしたいと思っています。
「これそろそろレビューしてもらいたいです！」ってお願いするのはせいぜい月に1回くらいにしたいのです。

とはいえPRが放置されるのはどんなに「ハイレベル」と言われるチームでも目にしてきたので、これを本気で実現するにはメンバーの責任ではなく、チームの環境の問題として捉え直したほうがいいと考えるようになりました。

対応

ここからが具体的な対応の話になります。
レビューリードタイムに対して課題感を持ってはいたものの、まずはそれを可視化しないと対策の効果も測りづらいので、以前から可視化ツールを探していました。
実は巷で話題のちょうど良さそうなツールもあったのですが、チーム規模に対して費用感が合わず断念した経緯があります。
流石に自作するのは大変かと思いつつもGitHubのAPIを見ていたところ、ちょうどよさそうなのを発見しました。

Timeline API

Timeline event API
こちらのAPIを使うと、いつレビュー依頼され、いつレビューがつき、いつapproveされ、いつマージされたのかというのが全て取得することができました。
これがあれば軽いノリで自作できそうです。助かりました。
実際に動かしてみたところ、取得できるイベントとしては以下のようなものがあるようでした。（多分まだ不足あると思いますのでご利用の際は自己責任でm）

enum Event: String, Codable {
    case closed
    case commented
    case committed
    case head_ref_deleted
    case merged
    case review_requested
    case reviewed
    case mentioned
    case subscribed
    case renamed
    case cross_referenced = "cross-referenced"
    case base_ref_changed
    case commit_deleted
    case assigned
}

ナイスレビュー率

非常に簡素な実装ですので詳細は省きますが、以下のように特定のPRが「ナイスレビュー」だったかどうかを出すスクリプトが書けました。
「ナイスレビュー」に関しては、レビュー依頼から最初のレビュー（commentやapproveなど）までの時間を「レビューリードタイム」として、これが2時間以内であるという条件にしました。ちょっと甘めかもしれません。

ナイスレビュー！

あとは直近マージされたPR番号を時系列等で抽出して渡してあげれば、「最近のナイスレビュー率」を出すことができますね。
チームでは一旦「直近10PRのナイスレビュー率」を出すスクリプトにまとめ、週1程度で実行していこうと思っています。
マージリードタイムは直近ではあまり課題に感じてないのですが、一応使えるようにしてあります。

可視化による効果

ということで、「こんなツール書いたんよ〜」という話を1on1で一部メンバーにしたところ、早速変化が現れました。iOSのレビューリードタイムが体感的にもずっと課題だったのですが、この1週間でなんと20%も改善しています。このまま続くといいなあと思います。
効果測定のための可視化だったつもりが、もしかして必要だったのは可視化そのものだったのかもしれませんね。

チームのナイスレビュー率推移
現状エクセルで手運用ですが十分有用です

可視化ツールの課題

一方で自作することにより、こういった可視化ツールの難しいところも見えてきました。例えば以下のようなケースは拾えなかったりするので若干モヤッとします。

• 19:00くらいにレビュー依頼して翌朝レビューされればナイスレビューでもいい気がするがそうならない（深夜だろうがなんだろうが2時間基準）

• レビュー依頼される前に爆速でapproveされたものはイベントが足りないので計算できない

前者に関してはみんながいる時間にレビュー依頼するようにする、
後者に関してはapprove時点をレビュー依頼された時間とみなすように一旦改修、
といったところである程度カバーできるかなと思っていますが、多分まだまだ拾えてないエッジケースがありそうです。使いながらチームの運用に合わせて改善していきたいと思います。
とはいえ正確に計測することよりは可視化されていて推移が追える状態というのが重要だということがわかったので、ほどほどに楽しんでいこうと思います。

まとめ

いかがだったでしょうか。日々の開発の何かの参考になりましたら嬉しいです。
もう一点最近改善を行った課題もあるのですが、長くなりましたのでそちらは次の記事に分けようと思います。

♦︎ カジュアル面談

現在株式会社Globeeでは「エンジニア職種」を中心に採用活動を積極的に行なっております。
弊社が「教育」にかける思いや「ものづくり」の考え方について、お話が出来ればと思いますので、皆様お気軽にご応募下さい。

meety.net

♦︎ 採用情報

Globee 採用情報 | Notion