ぼくらのPRレビューフロー改善奮闘記

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2025 Works Human Intelligence Co., Ltd. 2 自己紹介丸山三香子株式会社Works Human Intelligence Product Div. CSR Dept. Work Scheduling Grp. Grp. Manager 2011 年開発未経験でWHIの前身となる会社に新卒入社コンサルか営業になるつもりだったのに気が付いたらエンジニアになっていた。以来一貫してエンジニア職 2 男児の母・時短エンジニアリングマネージャープレイヤーとマネージャーを行ったり来たりしている現在の開発グループに合流して約 3 年、マネージャーになって約 1 年 8 か月趣味：アカペラ（歌う＆聴く）、ママチャリで疾走出没エリア：Qiita ときどき X

Slide 3

Slide 3 text

© 2025 Works Human Intelligence Co., Ltd. 3 今日お話しすることお話しすること ● 私が所属する開発グループでこの 2 年間で改善を続けているPRレビューの流れ ○ 誰が、いつ、どこでレビューするのか ○ やってみた方法 4 つのいい点、イマイチな点 ● 私たちの開発グループにおけるPRレビューの位置づけの話も少しお話ししないこと PRレビューの中身の話 ● PRの中身のレビュー方法 ● コードレビューの観点

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 2025 Works Human Intelligence Co., Ltd. 6 私たちが作っているもの大手法人向け統合人事システム「COMPANY」 1996 年の誕生以降、膨大なデータを蓄積する人事管理製品を中心に、業務を効率化するサービスから人材戦略を実現するサービスまでの領域をカバーする自社開発製品年末調整申告⾝上届出給与明細照会⼈事考課⼈事情報検索‧照会 Web Service 異動配置案作成発令各種帳票作成福利厚⽣給与/賞与⽀給税務処理退職⾦⽀給社会保険料計算出向費⽤資格管理個⼈情報管理⼈事‧給与勤務予定作成実績⼊⼒勤務状況把握⼯数管理就労‧プロジェクト管理 ID権限申請⼈事情報連携特権ID管理棚卸 Identity Management 要因分析研修管理各種KPIチェック Talent Management 提出物進捗管理⼊社⼿続雇⽤⼿続管理⼊社在職退職

Slide 7

Slide 7 text

© 2025 Works Human Intelligence Co., Ltd. 7 私たちが作っているもの大手法人向け統合人事システム「COMPANY」私たちの開発グループでは主に就労・プロジェクト管理の 2 つの業務ドメインにあたる機能群を担当年末調整申告⾝上届出給与明細照会⼈事考課⼈事情報検索‧照会 Web Service 異動配置案作成発令各種帳票作成福利厚⽣給与/賞与⽀給税務処理退職⾦⽀給社会保険料計算出向費⽤資格管理個⼈情報管理⼈事‧給与勤務予定作成実績⼊⼒勤務状況把握⼯数管理就労‧プロジェクト管理 ID権限申請⼈事情報連携特権ID管理棚卸 Identity Management 要因分析研修管理各種KPIチェック Talent Management 提出物進捗管理⼊社⼿続雇⽤⼿続管理⼊社在職退職

Slide 8

Slide 8 text

© 2025 Works Human Intelligence Co., Ltd. ● マネージャー＋開発メンバー 3 名（全員フルリモート） ● 1 st リリースから約 20 年の機能群を担当 ● 保守フェーズ、要望に応じて機能強化もする ● 他ドメインとのつながりが深く、開発難易度は高め ● PR数は 3 ～ 5 件/月 ● 開発経験／ドメイン知識豊富メンバーが中心 8 私たちの開発グループのメンバー構成全 9 名で 2 つの業務ドメイン領域を担当チーム 1 ● マネージャー＋開発メンバー 5 名（全員フルリモート） ● 1 st リリースから約 10 年の機能群を担当 ● まだまだ成長途上の機能強化フェーズ ● 他ドメインからは比較的独立しており、小回りが利く。開発難易度はチーム 1 よりは低め ● PR数は 15 ～ 30 件/月 ● 若手メンバーが多めチーム 2 ※マネージャーは両チーム兼務

Slide 9

Slide 9 text

© 2025 Works Human Intelligence Co., Ltd. ● マネージャー＋開発メンバー 3 名（全員フルリモート） ● 1 st リリースから約 20 年の機能群を担当 ● 保守フェーズ、要望に応じて機能強化もする ● 他ドメインとのつながりが深く、開発難易度は高め ● PR数は 3 ～ 5 件/月 ● 開発経験／ドメイン知識豊富メンバーが中心 9 私たちの開発グループのメンバー構成全 9 名で 2 つの業務ドメイン領域を担当チーム 1 ● マネージャー＋開発メンバー 5 名（全員フルリモート） ● 1 st リリースから約 15 年の機能群を担当 ● まだまだ成長途上の機能強化フェーズ ● 他ドメインからは比較的独立しており、小回りが利く。開発難易度はチーム 1 よりは低め ● PR数は 15 ～ 30 件/月 ● 若手メンバーが多めチーム 2 ※マネージャーは両チーム兼務

Slide 10

Slide 10 text

© 2025 Works Human Intelligence Co., Ltd. ● マネージャー＋開発メンバー 3 名（全員フルリモート） ● 1 st リリースから約 20 年の機能群を担当 ● 保守フェーズ、要望に応じて機能強化もする ● 他ドメインとのつながりが深く、開発難易度は高め ● PR数は 3 ～ 5 件/月 ● 開発経験／ドメイン知識豊富メンバーが中心 10 私たちの開発グループのメンバー構成全 9 名で 2 つの業務ドメイン領域を担当チーム 1 ● マネージャー＋開発メンバー 5 名（全員フルリモート） ● 1 st リリースから約 15 年の機能群を担当 ● まだまだ成長途上の機能強化フェーズ ● 他ドメインからは比較的独立しており、小回りが利く。開発難易度はチーム 1 よりは低め ● PR数は 15 ～ 30 件/月 ● 若手メンバーが多めチーム 2 ※マネージャーは両チーム兼務

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 2025 Works Human Intelligence Co., Ltd. 15 やってみた１：マネージャーが全チームの全PRをレビューイマイチな点 ● マネージャーがブロッカーとなり、レビュー遅延が発生する ○ 業務多忙 ○ 知識／スキル不足　× ○ PR提出の集中 ● マネージャーが開発メンバーのレビュー機会を奪ってしまういずれの問題もマネージャーがPRレビューを 1 人で担っていることに起因

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2025 Works Human Intelligence Co., Ltd. 17 やってみた２：全PRを全チームメンバーでモブレビューモブレビュー導入に際してやったこと ● メンバーに現状のレビューフローの課題感とモブレビュー導入への想いを伝える ● 「一旦やってみて、イマイチなら戻そう！」もちゃんと伝える ● モブレビューの流れを明文化し、迷わないようにする ↑実際にメンバーに共有したモブレビューの流れ

Slide 18

Slide 18 text

© 2025 Works Human Intelligence Co., Ltd. 18 やってみた２：全PRを全チームメンバーでモブレビューモブレビュー導入に際してやったこと ● メンバーに現状のレビューフローの課題感とモブレビュー導入への想いを伝える ● 「一旦やってみて、イマイチなら戻そう！」もちゃんと伝える ● モブレビューの流れを明文化し、迷わないようにする ↑実際にメンバーに共有したモブレビューの流れレビュー経験積みたい！マネージャーに負荷が集中してるのも気になってました・・・とりあえずやってみましょう！！メンバーからは好意的な意見がほとんど

Slide 19

Slide 19 text

© 2025 Works Human Intelligence Co., Ltd. 19 やってみた２：全PRを全チームメンバーでモブレビューやり方 ● 朝会（Meet開催）の最後のアジェンダとしてモブレビューの時間を設ける ● 朝会までに上がったPRの担当チームが残り、マネージャー＋チームメンバー全員でモブレビュー ● レビュイーが簡単にPRの内容を説明した後、その場でレビュアーがコメント／マージよい点 ● 1 営業日以上のレビュー滞留がほぼなくなった ● メンバーがレビュアーとしての視座を得られた ● PRの内容／各メンバーが担当する案件／機能仕様／業務ドメイン知識へのチーム全体の理解が深化した ● コーディングルールをその場で確認したり作ったりできた ● 毎日PRを見る時間が強制的に訪れるのってラク！

Slide 20

Slide 20 text

© 2025 Works Human Intelligence Co., Ltd. 20 やってみた２：全PRを全チームメンバーでモブレビューイマイチな点 ● 個々のレビューの品質が下がりやすくなった ○ モブレビューではじめてPRの中身を見ることが増えた ■ 「モブレビューの時間に確認すればいいや」 ○ 表面的なコードの書き方に指摘が終始しやすくなった ○ PR上の修正内容のみに指摘がとどまる ■ 中には本来ソースの前後関係を汲んだうえでのレビューが必要な更新もあった ● “空気読んでApprove”も発生 ○ 少しの違和感が流れてしまう ○ 「〇〇さんがOKと言っているからきっと大丈夫」 ● モブレビューのフローが重い場面も ○ 締切直前の駆け込みPRをマネージャーとレビュイーのみでレビュー＆マージしてしまうことも

Slide 21

Slide 21 text

© 2025 Works Human Intelligence Co., Ltd. 21 やってみた２：全PRを全チームメンバーでモブレビューイマイチな点 ● 個々のレビューの品質が下がりやすくなった ○ モブレビューではじめてPRを見ることが増えた ■ 「モブレビューの時間に確認すればいいや」 ○ 表面的なコードの書き方に指摘が終始しやすくなった ○ PR上の修正内容のみに指摘がとどまる ■ 中には本来ソースの前後関係を汲んだうえでのレビューが必要な更新もあった ○ 少しの違和感が流れてしまう ● “空気読んでApprove”も発生 ○ 「〇〇さんがOKと言っているからきっと大丈夫」 ● モブレビューのフローが重い場面も ○ 締切直前の駆け込みPRをマネージャーとレビュイーのみでレビュー＆マージしてしまうことも ● メンバーからも「PRもっとちゃんと見たいです」という声が上がった

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 2025 Works Human Intelligence Co., Ltd. 23 やってみた３：全PRを全チームメンバーで非同期レビューやり方 ● チーム単位でレビュアー（マネージャー＋同じチームの他メンバー）が、各々のタイミングでPRレビュー（＝非同期レビュー） ● 全レビュアーのApproveを以てマージ ● レビュイーに解説してほしいもの、他のレビュアーと議論したうえでApproveやコメントしたいものは朝会でモブレビュー開催よい点 ● PRをじっくりとレビューできるようになった ● チーム内のレビュー観点の醸成やノウハウ共有もPRコメントを通して継続できた

Slide 24

Slide 24 text

© 2025 Works Human Intelligence Co., Ltd. 24 やってみた３：全PRを全チームメンバーで非同期レビューイマイチな点 ● 「レビュアーがじっくりPRを見られるように」を重視するあまり、レビュー遅延が発生した ○ レビュイーによる口頭説明がなくなり読み解き難易度が上がった ○ じっくり見ているという名目でレビューを後回しにしてしまう ● モブレビュー時代と同様に「全メンバーによるApprove」を目指した結果、レビュー遅延が発生した ● 特に開発終盤でのレビュイー側のマルチタスクが頻発した ○ PRがマージされない → 仕方ないから他の開発に着手 → 終盤に一気にレビュー → マルチタスク化、共倒れのリスク発生

Slide 25

Slide 25 text

© 2025 Works Human Intelligence Co., Ltd. 25 やってみた３：全PRを全チームメンバーで非同期レビューイマイチな点 ● 「レビュアーがじっくりPRを見られるように」を重視するあまり、レビュー遅延が発生した ● モブレビュー時代と同様に「全メンバーによるApprove」を目指した結果、レビュー遅延が発生した ○ マネージャーが全PRを一手に引き受けていた以前のやり方を全員でやったようなもの・・・ ● レビュー遅延に起因してレビュイー側のマルチタスクが頻発した誰かのレビューが遅れた場合の考慮ができていなかったチーム開発におけるレビューの優先順位の話、ちゃんとしていなかったメンバーからも「マージが遅れるのしんどいです・・・」という声が上がった

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© 2025 Works Human Intelligence Co., Ltd. 27 やってみた４：その前にレビューフロー改善のためにやったこと ● チーム開発においてコードレビューは最優先事項であると認識合わせをする勉強会を開催 ● 全PR非同期レビューの反省点を踏まえたレビューフロー改善のたたき台を作成 ● たたき台のレビューフローをメンバーと一緒にブラッシュアップ ↑実際にメンバーに共有したレビューフロー改善案

Slide 28

Slide 28 text

© 2025 Works Human Intelligence Co., Ltd. 28 やってみた４：その前にレビューフロー改善のためにやったこと ● チーム開発においてコードレビューは最優先事項であると認識合わせをする勉強会を開催 ● 全PR非同期レビューの反省点を踏まえたレビューフロー改善のたたき台を作成 ● たたき台のレビューフローをメンバーと一緒にブラッシュアップ ↑実際にメンバーに共有したレビューフロー改善案チーム１はモブ形式に戻したい！チーム２は改善案を元にしていきたい！

Slide 29

Slide 29 text

© 2025 Works Human Intelligence Co., Ltd. 全メンバーでのモブレビューに回帰 29 やってみた４：モブレビューに回帰／全メンバーによる条件付き非同期レビューチーム状況に応じた最適なレビューフローに変更チーム 1 全メンバーによる条件付き非同期レビューに変更 ● 1 営業日以内の非同期レビュー、それ以降の滞留／必要に応じてモブレビュー開催 ● マネージャー＋メンバーの過半数のApproveでマージチーム 2 判断の決め手 ● 他ドメインとのつながりの深さ、ソースコードの複雑さから、もともとモブレビューを求める割合が高かった ● PR数も 3 ～ 5 件/月と少ない ● PR数は 15 ～ 30 件/月と多めで、モブレビューだとレビューが飽和状態になる ● メンバーの成長に伴い、全員のApproveでなくても一定の精度維持やノウハウ共有が可能判断の決め手

Slide 30

Slide 30 text

© 2025 Works Human Intelligence Co., Ltd. 全メンバーでのモブレビューに回帰 30 チーム状況に応じた最適なレビューフローに変更チーム 1 全メンバーによる条件付き非同期レビューに変更 ● 1 営業日以内の非同期レビュー、それ以降の滞留／必要に応じてモブレビュー開催 ● マネージャー＋メンバーの過半数のApproveでマージチーム 2 判断の決め手 ● 他ドメインとのつながりの深さ、ソースコードの複雑さから、もともとモブレビューを求める割合が高かった ● PR数も 3 ～ 5 件/月と少ない ● PR数は 15 ～ 30 件/月と多めで、モブレビューだとレビューが飽和状態になる ● メンバーの成長に伴い、全員のApproveでなくても一定の精度維持やノウハウ共有が可能判断の決め手やってみた４：モブレビューに回帰／全メンバーによる条件付き非同期レビュー

Slide 31

Slide 31 text

© 2025 Works Human Intelligence Co., Ltd. 全メンバーでのモブレビューに回帰 31 チーム状況に応じた最適なレビューフローに変更チーム 1 全メンバーによる条件付き非同期レビューに変更 ● 1 営業日以内の非同期レビュー、それ以降の滞留／必要に応じてモブレビュー開催 ● マネージャー＋メンバーの過半数のApproveでマージチーム 2 判断の決め手 ● 他ドメインとのつながりの深さ、ソースコードの複雑さから、もともとモブレビューを求める割合が高かった ● PR数も 3 ～ 5 件/月と少ない ● PR数は 15 ～ 30 件/月と多めで、モブレビューだとレビューが飽和状態になる ● メンバーの成長に伴い、全員のApproveでなくても一定の精度維持やノウハウ共有が可能判断の決め手やってみた４：モブレビューに回帰／全メンバーによる条件付き非同期レビュー

Slide 32

Slide 32 text

© 2025 Works Human Intelligence Co., Ltd. 32 よい点非同期レビューのよい点はそのままに、期限が設けられたことで以下が追加で改善された ● 非同期レビューでもレビュー遅延が発生しなくなった ● 遠慮なくモブレビューを依頼するメンバーが増えた ○ 無理して自力でPRを読み解こうとしすぎなくなったイマイチな点 ● あと1人で過半数というときにモブレビューを開催するか迷ってしまう ○ 今のところは朝会や夕会で未レビューメンバーに声掛けすることでまかなえているので、敢えて厳格にはやっていないやってみた４：全メンバーによる条件付き非同期レビュー

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© 2025 Works Human Intelligence Co., Ltd. 34 まとめ：至高のレビューフローは存在しないたとえば・・・ ● 機能の品質を担保できる ● 滞留せず、快適に開発を前進できる ● チームメンバーの成長の場である ● “今”のレビューフローに納得感が持てる PRレビューに求めるポイントを考えておくたとえば・・・ ● チームメンバーの人数は？ ● チームメンバーのスキルは？ ● 担当機能のフェーズは？ ● 案件／不具合修正の数や難易度は？チームをとりまく状況を加味する＋今のチームにとって”いい塩梅”のレビューフローを考えるときは