📝
チームのレビュー体制を見直してFourKeysの計測と改善をした話
はじめに
今回は、チームのレビュー体制を見直すチャレンジをした際に、どのような課題を見つけて、どのようなアプローチをしたのかをまとめます。
これらの取り組みにより、リリースが多い週でも変更のリードタイムが伸びることがなくなりました。結果的にリリースの頻度も増加し、チーム全体の生産性が向上したと考えています。
はじめに 課題感 仮説を立てる ゴール設定 マイルストーン レビューの重要性を改めて確認・周知する 全員で同期的にレビューをする会を定期的に行う PRのテンプレートを変更してみる レビュー担当者を1名にする 「初回レビュー」という概念を導入して、BOTで通知させてみる OpenになったままのPRのclose、ラベル貼り 結果
課題感
当時私たちのエンジニアのチームでは、レビュー待ちのPRが溜まりがちだったり、スクラムで「これは実装できているのですが、レビュー待ちですね…」という状態のタスクが増えるという課題に直面していました。（スクラム開発ですが、レビューはチーム横断で行っています）
皆がやるべきメインタスクがある中でレビューしていくのは大変ですよね。
しかし、レビューが遅れるとデプロイの頻度が下がり、変更のリードタイムも延びてしまいます。また、タスクの見積もりにも影響が出てしまうので改善したいと考えてチャレンジしました。
みんなのっていきをしてくれて非常にありがたかったです🚀
のっていきとは：
仮説を立てる
改善案を考える前に、そもそもなぜこのような状況になるのか考えてみました。
もちろん、人数や忙しさなど恒常的な理由はどの会社でもあると思いますが、ハンドリングできそうな部分をポジティブに考えてみました。
思い当たった理由、インタビューをした際に挙がった理由は次の通りです。
- レビューするPRの前提知識がない・難しい
- レビューするPRの動作確認方法の調査に手間がかかる
- 自分以外のレビュワーもいるので、その人がやってくれそう・やった方が早そう
- レビューに対する重要度が低い：まとまって割く時間が取れない、後回しにしてしまう
特に、4に関してはレビューが早くなることでどのような良いことがあるのか、ビジネスインパクトがあるのかを示す必要がありそうだと思いました。
ゴール設定
まず、今回の取り組みに関してゴールを2つ決めました。
1つ目は、FourKeysの「デプロイの頻度」と「変更のリードタイム」を改善することです。
2つ目は、OpenになっているPRが特定の数以下になることです。
計測をしましたが、今回具体的な数は公開しません。
最終的なゴールを達成するために、皆んなで楽しみながらレビュー体制を改善したいと考えたので次にマイルストーンを敷きました。
マイルストーン
仮説の1〜4を解決するために、次のような流れで改善の活動を行ってみることにしました。
- レビューの重要性を改めて確認・周知する
- 全員で同期的にレビューをする会を定期的に行う
- PRのテンプレートを変更してみる
- レビュー担当者を1名にする
- OpenになったままのPRのclose、ラベル貼り
- 「初回レビュー」という概念を導入して、BOTで通知させてみる
1つ1つ行った取り組みに関して説明します。
レビューの重要性を改めて確認・周知する
まず、レビューの重要性を改めて確認し、チーム全体で共有することから始めました。
レビューは単なるコードのチェックではなく、それぞれが担当している領域の知見の共有にもなります。また、レビューが通ればデプロイすることができるので、ユーザーへの価値提供にも直接繋がります。
オフラインでエンジニア全員が集まる機会があったので、モバイルチームも含めてその認識のすり合わせをし、ここでレビュー体制を改善していくこと・同期的にレビューする会を企画することを決めました。
これまでも同期的なレビュー会は企画されることがあったのですが、いつの間にか流れてしまうことが多かったです。今回は、今後企画するレビュー会をシニアエンジニアが「キープアップミーティングと同じくらい重要な会」と明文化してくれたのもありがたかったです。
キープアップミーティングとは、社内で行われている非常に重要なMTGの名称です
全員で同期的にレビューをする会を定期的に行う
次に、上記のMTGで決めた「全員で同期的にレビューを行う会」を定期的に開催しました。
この会では、Metalife上で何名かのチームに分かれて、そのタイミングでレビューすべきPRをドラフトしてレビューをしました。
ゲームキャラクターのようなアイコンで動き回りながら話すことができるので、楽しみながらレビューを行うことができました。
この会では、疑問点や不明点はその場で実装者や経験のあるエンジニアに質問できます。これにより、当初課題に挙げていた「レビューするPRの前提知識がない・難しい」と「レビューするPRの動作確認方法の調査に手間がかかる」の解決につながりました。
また、会の終了10分前にそれぞれのチームで合流し、今回レビューで得た知見をNotion上でシェアするようにしました。
1つ工夫ポイントとして、毎週レビューするカテゴリを変えました。具体的には、次の通りです。
| 1週目 | long-termラベルのついたPR |
|---|---|
| 2週目 | フリー |
| 3週目 | dependabotが作成したPR |
| 4週目 | フリー |
| 5週目 | フリー |
dependabotのPRなどは「調査をするぞ！」の気持ちも必要なので「レビュー会で一気にやってしまおう」という空気感が出たのも良かったです。速で対応することももちろん大切ですが、レビュー会がきっかけになるのも良かったと思います。
ちなみに「レビュー会」だと寂しいので会の名前はみんなで大喜利をしました。
面白い名前になりましたが、ここでは割愛します。
PRのテンプレートを変更してみる
改めて、課題感として「レビューするPRの前提知識がない・難しい」と「レビューするPRの動作確認方法の調査に手間がかかる」というものがありました。同期的なレビュー会ではその場で聞けるとはいえ、恒常的に起こっているこの問題が解決されるべきです。
そこで、PRのテンプレートに工夫をしました。
行った工夫は次の通りです。（一部だけ紹介します。）
この項目をテンプレートに追加しました。
また、期限が決まっているPRのタイトルには【期限: 7/10 17:00】といった時間を入れてもらう運用をしました。
もともと期限はPRのテンプレートに書いていたのですが、タイトルに書くことでPRの通知botのメッセージや、PRを一覧で見たときに優先してレビューするべきPRが一目でわかります。
また、目的を書くことでこのPRが何のために作成されたのか背景がわかります。更に、「テーブル設計、関連するページ、テストデータの作り方などを書きましょう。「といった記述をすることで、実際のseedコマンドやリンクなどが添付されてよりレビューのハードルが下がりました。
もちろん、FileChangedを見れば何となくどういう操作をすれば良いかわかるのですが、この辺りの説明があった方がよりスムーズになります。Routingの脳内変換とかも にアクセスしてくださいという記述があるだけで不要になります。
PRのテンプレートはもともとさまざまな工夫がされていましたが、今回レビューの速度を上げるにあたって、PRの説明を見ればその時の実装の背景や再現手順が分かれば良いなと思いました。
An Architectural Decision (AD) is a justified design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on the architecture and quality of a software and/or hardware system. An Architectural Decision Record (ADR) captures a single AD and its rationale; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM), but ADR usage can be extended to design and other decisions (“any decision record”).
方針を決める上でこちらの記事が非常に参考になりました。
ありがとうございました🙏
レビュー担当者を1名にする
「自分以外のレビュワーもいるので、その人がやってくれそう・やった方が早そう」の改善です。
従来のレビュー体制では、2名のレビュアーが割り当てられていましたが、これをあえて1名に変更しました。担当者が1名になることで、責任が明確になり、レビューの遅延が減少すると考えたためです。
ここから管理できました。
一方で、その担当者が全て一人で責任を持って見るという体制は望ましくなく、多くのエンジニアがレビューをできた方が良いと考えたため、次の施策もあわせて行いました。
「初回レビュー」という概念を導入して、BOTで通知させてみる
「初回レビュー」という概念を導入しました。まず、最初にレビューしてみることを指します。
これは、担当になった1名がPRのApproveまで責任を持つのではなく（持ってももちろん良いですが）2時間以内にまず1ファイルでも良いからレビューができることを目標に導入しました。
これにより、全く一度も見られていないPRが減少しさらに誰かが一度少し見たPRを増やすことでレビューのハードルが下がりました。
この仕組みを成立させるために、レビューの担当になった人に対してGithubActionsで通知するBOTを作成しました。PRがレビュー待ちになると、Slack上で下記のメンションがされます。
もし、メンションが来た時点でMTGなどで難しい場合はランダムにメンションできる機能を使って、他のエンジニアをアサインします。これにより、2時間以内にまず1回はレビューされるという状態を目指しました。
OpenになったままのPRのclose、ラベル貼り
Openのまま放置されているPRについては、定期的に整理を行い、不要なものはクローズし、検証などのために必要なものには「stale」か「long-term」ラベルを貼るようにしました。
また、毎週のミーティングでこれらのPRを確認し、進行状況を把握するようにしました。こ
れにより、古いOpenなPRが溜まることを防ぎ、常にレビューすべきPRが明確になるようにしました。運用にもよると思いますが、Pull Requestsの横の数字が小さいと嬉しいですよね。（と思っている）
結果
これらの取り組みにより、リリースが多い週でも変更のリードタイムが伸びることはありませんでした！
結果的にリリースの頻度も増加し、チーム全体の生産性が向上したと考えています。
ただし、まだ「変更障害率」「サービス復元時間」への影響は大きく出ていません。
今回の施策は、最終的にはFourKeys全てに良い影響をもたらすことができると思いますが「変更障害率」「サービス復元時間」に効果が出てきたと分かるのは、自分の担当領域以外のレビュー回数がより増えて知見が溜まっていった後ではないかと思います。
しかし、チームメンバーからは、「知らない領域を見ることができて良かった」「レビューする際にまず何を見れば良いのか、どういう観点でレビューすれば良いのかわかった」という声も上がり、知見の広がりやスキルの向上が見られました。
大前提として、チームののっていきがあったのでこのようなチャレンジができました。
改めて感謝！！！
これからも引き続き改善を行い、より良い開発体制を目指していきます！🚀🚀🚀