こんにちは！新卒入社してからいつの間にかもうすぐ4年目が終わるという驚愕の事実に震えているグロースエンジニアリング部の若林 (@wakakuuma)です。
さて今回の内容は、題して「レビュー見る会」~ Meetingひとつでレビューにかかる時間を平均37時間削減した話 ~です！！
まず「レビュー見る会」について簡単に説明すると、スプリント開始直後に行う事前スプリントレビューのようなものです。
事前にやるスプリントレビュー？？何言っとんねんと思われている方、安心してください！この後じっくり説明させていただきます。早く内容を知りたい方は「レビュー見る会について」までスキップしていただければと思います。
では早速説明していきます。この記事によりレビュー時間に課題を抱えている方、他チームとの連携がうまく取れてない方、リードタイム短縮を目指している方などの解決の手助けになれることを願っています。
本記事は kubell Advent Calendar 2024 (シリーズ1) 12月17日の記事となります。 前日はこちらの2本でした。
前提と背景
まずレビュー見る会について説明する前に簡単に当時の組織構造と各チームで抱えていた課題について説明させていただきます。
当時の組織構造
グロースFeatureチーム (以後FTチームと呼ぶ)
- ミッション: グロースを掲げ、素早くユーザーに価値提供を行う
- 開発手法: スクラム方式(1週間単位のスプリント)
- 主な役割: 新機能の開発とユーザー体験の向上
iOSPlatformチーム (以後PFチームと呼ぶ)
- ミッション: 安定した開発環境の提供
- 開発手法: カンバン方式
- 主な役割: マルチモジュール化、リアーキテクチャ、開発環境の整備
上記の組織構造の元、両チームは同じプロダクト（ChatworkのiOSアプリ）を触り、異なる視点から価値を提供していました。また、FTチームが素早く価値提供を行えるように、PFチームが技術的な基盤を整備するということもしていました。
ここで問題となるのは、FTチームが実装する内容は影響範囲が大きくなることが多いため、コードの書き方が方針に添えているか、品質を保てているかを確認するために、PFチームにレビューを都度出すことが求められていた点です。
また、PFチームがレビューを必須としていた背景には、技術的負債による影響範囲の不透明さが一因としてありました。たとえば、分析のために仕込んだイベントでパラメータを増やしただけにもかかわらず、クラッシュ数が増加するという事例がありました。このようなリスクを回避するためにも、PFチームによるレビューが必要とされていたのです。
その結果、レビューを毎回出す必要があり、各チームでは以下の課題を抱えることとなりました。
各チームの課題
- FTチーム
- 大小関わらず全ての実装に対して、チーム内レビューとPFチームレビューの2ステップが必要でレビューの待ち時間が発生していた
- レビューの待ち時間により、その週のリリースに混ぜれない、機能を落としてのリリースが行われていた
- PFチーム
- リソースの半分をFTチームのレビューにさいており、本来やりたいことが進められない
これらの課題を解決するために行われたのが「レビュー見る会」になります！
ここから実際にレビュー見る会を行う目的、どのように行うのかを説明していきます。
レビュー見る会について
目的
- FTチームとPFチームの連携を強化し、品質を保ったまま素早い価値提供を行えるようにする
目標
- FTチームが一定の品質を担保しつつ、レビューをチーム内で完結できるようにする
- PFチームがFTチームの実装範囲を事前に把握し、問題が発生した際に迅速に連携できる体制を整える
- PFチームがFTチームのために整備した内容を実際に試し、フィードバックを行い改善に役立てる
内容と進行方法
- 頻度
- 毎週、FTチームのスプリントプランニング後に30~60分の時間で行う
- 参加者
- FTチーム: iOSエンジニア + その週にiOS開発を行うエンジニア
- PFチーム: 特定の代表者
- 事前準備: 以下が書かれた資料を会の前に用意する
- 先週、FTチームがdevelopにマージした内容
- スプリントプランニングで決まった、今週対応する内容の仕様と実装方針
- その他、両チームの相談共有事項
- 会議の流れ
- 事前に準備した資料をもとに、FTチームが先週マージした内容についてPRを見ながら説明する
- PFチームは実装が問題なかったか、指摘箇所等があればここでフィードバックする
- 今週行う内容について、FTチームが簡単に実装方針と必要であれば仕様の共有
- 事前に注意しておくべきポイントの共有や技術的相談を行う
- 共有した内容でレビューをチーム内で閉じて良いかをPFチームと確認
- 見返せる用に判断理由もメモしておく
- その他両チームでの相談共有事項の確認
- 事前に準備した資料をもとに、FTチームが先週マージした内容についてPRを見ながら説明する
これらの内容をもとに「レビュー見る会」を1年ほど行ってきました。ここからはこれによりどのような効果が出たかを定性と定量データを元に説明していきます。
1年やってみての効果
定性データ
- PFチーム側がレビューにかける時間をだいぶ減らせた
- 実装前の段階でFTチームの内容を把握できて良い
- 実装前に注意するべきポイントやスケジュール感、技術的内容などを相談できる
- レビュー待ちの解消により開発リードタイムが向上している
上記は「レビュー見る会」の振り返りを行った際に参加者から出てきた意見です。冒頭で述べた、「事前に行うスプリントレビュー」というセリフも、振り返りででた言葉で、とてもわかりやすくこの会を表現しているなと思ったのでそのまま使わせてもらっています(笑)
また、個人的にこれを行ってからは、事前に設計を行う必要があるのでいきなりコードを書く癖が直ったり、事前にどう実装するかを相談できるので安心してスピード感を持った開発ができるようにもなりました。これだけでもジュニアエンジニアの方には成長の機会になるのではと感じています。
定量データ
| 指標 | レビュー見る会以前 (2023/05/01 ~ 2023/10/31) | レビュー見る会以降 (2024/05/01 ~ 2024/10/31) |
|---|---|---|
| 平均変更行数 | 287.8 行 | 298.9 行 |
| オープンからレビューまでの時間 | 21.6 時間 | 13.4 時間 |
| レビューからアプルーブまでの時間 | 38.9 時間 | 10.3 時間 |
| PFチームにレビュー依頼していた数 | 32 回 | 1 回 |
| 不具合発生総数 | 4 件 | 5 件 |
＊比較対象期間について
- 2023年：チーム発足から「レビュー見る会」を開始するまでの期間（2023/05/01 ~ 2023/10/31）
- 2024年：「レビュー見る会」実施後、同じ期間を対象（2024/05/01 ~ 2024/10/31）
＊Findy Team+から参照
上記のデータから実装量は以前と変わりないが、レビューが開始されてから完了するまでの時間を大幅に削減(前後差で37時間)することに成功したことがわかります。
さらに実装について事前に共有し気をつけるべきポイントの会話をすることにより、チーム内でレビューを閉じれる件数が大幅に増え、その分PFチームはレビューにかける時間を短縮できたこともわかります。
不具合としては前年より＋１件と、重大な品質低下にはつながっていないと言えます。ただ、ここはなるべく0にできるよう改善していく必要もあります。
以上のことから「レビュー見る会」により品質を担保した状態でレビューにかかる時間を大幅に削減したことがわかるかと思います。
最後に
いかがだったでしょうか？本記事では「レビュー見る会」で品質を担保したままレビューにかかる時間を大幅に削減した方法について書かせていただきました。
「レビュー見る会」は参加者からとても評判が良く、尚且つとても簡単にできるもののため再現性も高いと感じています。もしチーム連携やレビュー時間に課題を抱えている方は是非試していただければと思っています。
今後の展望として、別のミッションを持ったFTチームが新しくできた際には今回の成功体験をもとに横展開していき、各チームで品質を保ったまま素早い価値提供を行える仕組みを整えていければと思っています。
内容をかいつまんで書いた部分もあるので少しわかりにくい箇所もあったかとは思いますが、本記事により少しでも改善活動のヒントになれることを願っています。
ここまで読んでいただきありがとうございました！
