マトリックス組織×リモートでコードレビューのリードタイムを50%以上短縮した取り組み

2026/09/30 に「コードレビューどうしてる？ ボトルネックに向き合う仕組み化Tips共有会」で発表した登壇資料です。
https://findy.connpass.com/event/406145/

株式会社ZOZO
ブランドソリューション開発本部 WEAR開発部 バックエンドブロック/Webブロック
ブロック長
伊藤 豪哉

#コードレビュー_findy

Transcript

1. マトリックス組織×リモートで コードレビューのリードタイムを 50%以上短縮した取り組み コードレビューどうしてる？ ボトルネックに向き合う仕組み化Tips共有会（Findy主 催）／ 2026.09.30 株式会社ZOZO ブランドソリューション開発本部 WEAR開発部 バックエンドブロック/Webブロック ブロック長 伊藤 豪哉 Copyright © ZOZO, Inc. 1
2. 株式会社ZOZO ブランドソリューション開発本部 WEAR開発部 バックエンドブロック/Webブロック ブロック長 伊藤 豪哉 2022年にZOZOに入社。以来、ファッションコーディ ネートアプリ「WEAR by ZOZO」のバックエンド開発 に従事し、現在はバックエンドとWebフロントエンドの 2チームのマネジメントを兼務。チームの開発生産性向 上や開発プロセスへのAI活用に取り組んでいる。 © ZOZO, Inc. 2
3. https://wear.jp/ • あなたの「似合う」が探せるファッションコーディネートアプリ • 2,000万ダウンロード突破、コーディネート投稿総数は1,500万 件以上（2026年9月末時点） • コーディネートや最新トレンド、メイクなど豊富なファッション 情報をチェック • AIを活用した「ファッションコア診断」や、フルメイクをARで試 せる「WEARお試しメイク」を提供 • コーディネート着用アイテムを公式サイトで購入可能 • 診断・提案・説明・試着の一連体験で“似合う”が見つかる機能 「似合うルーム by ZOZO」を2026年9月15日にリリース • 2013年公開の長期運用サービス。バックエンドは約10名 © ZOZO, Inc. 3
4. 約10名が複数チームに分散している • • • © ZOZO, Inc. バックエンド約10名が、複数のスクラムチームに1〜3名ずつ分散 開発はスクラムチーム単位、レビューはバックエンドブロック内で相互に依頼 全員フルリモート 4
5. 三つの詰まり方 • • • © ZOZO, Inc. レビューが「仕様の理解」から始まる（担当機能が違うため） レビュアーはランダムアサイン → 担当チームの実装と、別チームのレビューが競合する オフィスなら自然に起きる「ちょっと見てほしい」が、リモートでは発生しない 5
6. 可視化はできていた。足りなかったのは仕組み • • • © ZOZO, Inc. Findy Team+ はもともと導入済み。リードタイムは可視化されていた 見えていた実態：約26時間（〜2024/3）。オープンからマージまでの平均 個人の意識に頼る改善には限界。仕組みで解く必要があった 6
7. 見る数字を三つに分ける • • © ZOZO, Inc. 見る数字は3つ。いずれも目標値として置いている 分けると、着手が遅いのか往復が長いのかを切り分けられる 7
8. 5名×2グループに分割した • • • © ZOZO, Inc. 約10名全員で10名分のPRを追う状態をやめる 追うコンテキストの範囲を狭めて、レビュー着手のスイッチングコストを下げる 2024年4月から、5名×2グループへ 8
9. グループ編成の三基準 • • • © ZOZO, Inc. 同じスクラムチームの人を、同じグループに（背景の共有が最小限で済む） 扱うドメインが近い人を、同じグループに ベテランを片方に偏らせない（人数を揃えるより優先） 9
10. 26時間 → 16時間、そして残った問題 • • • © ZOZO, Inc. 約26時間 → 約16時間。Findy Team+ で置いた16時間の目標に到達 グループ単位で振り返りと改善を回せるようになった ただし追う範囲が狭まっただけで、「いつ見るか」は決まっていない 10
11. 分けただけでは足りなかった • • • © ZOZO, Inc. レビューは依頼された後、いつやるかが決まっていない → 自分の実装が優先される 2025年8月頃、生成AIの普及でPRが週4〜6件から週8〜12件へ倍増 仕組みが同じまま流量が倍になり、約18時間へ悪化 11
12. レビューを1日のリズムに埋め込む • • • © ZOZO, Inc. 全体朝会 30分 → グループ朝会 30分 グループ朝会で Open PR を全部確認し、レビュー依頼をリマインドする 新規PRは、作成者が画面共有で背景を説明する 12
13. もくもくレビュータイム • • • © ZOZO, Inc. Gather の仮想オフィスに集まり、レビューだけをやる時間（1日2回） メンションされたレビュアーは、その時間に対応するのが必須 約18時間 → 約11時間（2025/10〜）。改善前比58%削減 13
14. グループ間比較で競争が生まれた • • • © ZOZO, Inc. 週次で、2グループの数字を並べて見る 勝ち負けではなく、差がついた理由を説明し合う場として使う 翌週の改善アクションが、チームから自発的に出てくるようになった 14
15. 数字の信頼性を毎週点検する • • • © ZOZO, Inc. 計測対象の除外漏れ（自動生成のPRなど）を毎週確認する 数字が信用できなくなった瞬間に、比較も競争も成立しなくなる チームに委ねるのは改善、こちらが担保するのは数字の信頼性という分担 15
16. 現在地：AI活用と自動化 • • • © ZOZO, Inc. PR数は倍のまま、リードタイムは約11時間を維持できている AIレビューの多段化 ／ 必要Approve数の自動判定 ／ 依存関係更新の自動マージ 運用の型ができた上に乗せているから効いている、というのが実感 16
17. やったことは三つ © ZOZO, Inc. 17
18. まとめ • • • © ZOZO, Inc. レビューが遅いのは人の問題ではなく、追わなければならないコンテキストが広すぎる問題だった 約26時間 → 約11時間（58%削減） 詳しい経緯: https://techblog.zozo.com/entry/code-review-leadtime-reduction 18