おおいし (@bicstone) 2024/06/19 CHUO_Tech #3 開発生産性について語ろう！ もうブロッカーにしない！ コードレビューを爆速にする 組織づくり 🚀 (C) 2024 Oishi Takanori

Certified ScrumMaster® is a certification mark of Scrum Alliance, Inc. Any unauthorized use is strictly prohibited. 自己紹介 大石貴則 (@bicstone) SaaS大好きプロダクトエンジニア

課題 実装 レビュー待ち 修正 実装 レビュー待ち 修正 実装① レビュー待ち A機能 B機能 C機能 🚀 🚀 実装② レビュー待ち レビュ… とあるエンジニアの1週間の作業

実装 レビュー待ち 修正 実装 レビュー待ち 修正 実装 レビュー待ち A機能 B機能 C機能 実装 レビュー待ち レビュ… 🚀 課題 🚀 A機能のみに着目してみる

課題 リードタイムが伸び、価値提供が遅れていることが わかる 実装 レビュー待ち 修正 レビュー待ち 🚀 A機能 → リソース効率は高いがフロー効率が低い A機能のみに着目してみる

実装 レビュー待ち 修正 レビュー待ち 実装 修正 レ レ 目標設定 🚀 現状 目標 🚀 レビュー待ちと並行タスクで中断され非効率 → ブロッカーを減らし爆速な価値提供を目指す

目標設定 個人の効率に最適化され品質やコラボーレーション などに悪影響が出る 品質やコラボーレーションを維持しながら フロー効率を上げるという意識が重要！！ ※ 私はまだフレームワークを完全に理解できていないので、違ったらツッコミください 🙏 (参考) リードタイムを最小化する指標 Four Keys: “Lead time for changes” SPACE: “Efficiency and flow” 効率の向上のみを目的にしてしまうと…

① 優先順位の認識を揃える ② 開発単位を小さく ③ プロジェクト並列数を減らす ① 優先順位の認識を揃える ② 開発単位を小さくする ③ プロジェクト並列数を減らす コードレビューを爆速にする組織づくり

① 優先順位の認識を揃える Working Agreementでレビュー・修正 を最優先することを明文化 → 優先順位の認識を揃え、爆速なレビュー文化を醸成 Scheduled remindersの活用 モブプロ・ペアレビューの推奨 コメントにラベルを付けて重み付け 【MUST】必須・【NITS】無視してもよい など コードレビューにラベルを付けるだけで チームの心理的安全性を高めた話 https://zenn.dev/hacobell_dev/ articles/code-review-comment-prefix

② プルリクエストを小さくする PRを小さくしレビュアー、レビュイー共に 負担を軽減 変更行数に応じてラベルを付け可視化 Git Feature Flowを採用 GitFlowは使わない！シンプルな 「GitFeatureFlow」を紹介します https://developers.gnavi.co.jp/ entry/GitFeatureFlow/koyama → レビューのコストを下げ、 品質を維持しながら効率が向上 GitHub Apps - Pull Request Size https://github.com/apps/pull- request-size 非破壊変更はmainにどんどんマージする 破壊的変更はfeatureにどんどんマージする

③ プロジェクトの並行数を減らす レビュアーを整理し仕組み化することで 余分なコストを削減する EM主導の元、レビュー担当を整理 Code Ownersを活用し自動アサイン Slackの通知も活用し主体性も向上 → レビュアーの主体性が向上し、 レビューの品質が向上 (c) aoi1 CC-BY 4.0

まとめ レビューを優先することを明文化 PRを小さくしてレビューコストを削減 並行数を減らしてレビュー品質を向上 品質やコラボーレーションを維持しながら フロー効率を上げるという意識が重要！！ 文化づくりと仕組みづくり両面からの取り組みを行った