   伝わるコードレビュー チーム開発を加速させる5つのルールと33のTIPS 開発チームの生産性を高める「上手な伝え方」の教科書 VUCA Labo（テック分科会） 

 バグの混入防止 第三者視点での客観的評価  バグの混入防止 第三者視点での客観的評価  コード品質向上 メンテナンス性・保守性の確保  コード品質向上 メンテナンス性・保守性の確保  知識の共有 チーム内でのノウハウ・経験の伝達  知識の共有 チーム内でのノウハウ・経験の伝達  チーム文化醸成 共通の価値観と規範の形成  チーム文化醸成 共通の価値観と規範の形成 コードレビューの利点 コードレビューが本質的に「批評」である コードの不備を指摘し、改善を要求する行為は、受け取り方によっては自分自身への批 判と捉えられることがある レビュイー側の問題 ž 過剰に防衛的な態度 ž 過剰に受動的な態度 レビュアー側の問題 ž 独善的な指摘 ž 持って回った表現 ž 人格の攻撃 コードレビューの難しさ コードレビューはコミュニケーションの問題  成功の鍵は伝え方  意図が正確に伝わるかが技術的正確さより重要  レビュアーとレビュイーの対話が「二人三脚」の関係性を構築  「あなたvs私」ではなく 「私たちvs問題」という姿勢 コードレビューはコミュニケーションの問題  成功の鍵は伝え方  意図が正確に伝わるかが技術的正確さより重要  レビュアーとレビュイーの対話が「二人三脚」の関係性を構築  「あなたvs私」ではなく という姿勢 「私たちvs問題」 コミュニケーションとしてのコードレビュー PART 1 心構え編 コードレビューにおける5つの基本ルール、心構えを紹介 PART 2 実践編 架空の開発チームを舞台に19の具体的ケースで学ぶ PART 3 TIPS編 すぐに使える33の具体的なテクニックを紹介 PART 1 心構え編 コードレビューにおける5つの基本ルール、心構えを紹介 PART 2 実践編 架空の開発チームを舞台に19の具体的ケースで学ぶ PART 3 TIPS編 すぐに使える33の具体的なテクニックを紹介 本書の構成 コードレビューの重要性と難しさ 伝わるコードレビュー 2/10 コードレビューの重要性と難しさ 伝わるコードレビュー 2/10 

伝わるコードレビューの5大ルール 伝わるコードレビュー 3/10 伝わるコードレビューの5大ルール 伝わるコードレビュー 3/10 コードレビューを円滑に進め、効果を最大化するための基本原則 1  決めつけない 相手の行動や意図を悪意や怠惰によるものと決め つけず、確認や対話を通じて理解を深める姿勢を 持つ。 実践のポイント:  「ハンロンの剃刀」を意識する  想像で補わず、確認する 1  決めつけない 相手の行動や意図を悪意や怠惰によるものと決め つけず、確認や対話を通じて理解を深める姿勢を 持つ。 実践のポイント:  「ハンロンの剃刀」を意識する  想像で補わず、確認する 2  客観的な根拠に基づく 事実と想像を明確に区別し、指摘や提案には具体 的な根拠を添える。エビデンスを示すことで、相 互理解を促進する。 実践のポイント:  事実と推論を分けて伝える  エビデンスを必ず添える 2  客観的な根拠に基づく 事実と想像を明確に区別し、指摘や提案には具体 的な根拠を添える。エビデンスを示すことで、相 互理解を促進する。 実践のポイント:  事実と推論を分けて伝える  エビデンスを必ず添える 3  お互いの前提知識を揃える 用語や概念の理解度、仕様の背景など、コミュニ ケーションの土台となる情報を積極的に共有す る。 実践のポイント:  用語や概念の意味を確認する  前提条件が異なることに気づいたら指摘 3  お互いの前提知識を揃える 用語や概念の理解度、仕様の背景など、コミュニ ケーションの土台となる情報を積極的に共有す る。 実践のポイント:  用語や概念の意味を確認する  前提条件が異なることに気づいたら指摘 4  チームで仕組みを作る 個人の心がけだけに依存せず、自然に正しい行動 を促すプロセスやツールを導入する。チーム全体 の効率化を図る。 実践のポイント:  PRテンプレートの活用  Lintツールの導入 4  チームで仕組みを作る 個人の心がけだけに依存せず、自然に正しい行動 を促すプロセスやツールを導入する。チーム全体 の効率化を図る。 実践のポイント:  PRテンプレートの活用  Lintツールの導入 5  率直さを心がける 相手を尊重しつつも、遠回しな表現を避け、要点 を明確に伝える。率直さは双方に求められる姿 勢。 実践のポイント:  相手を尊重した言葉で率直に伝える  感情的にならず冷静に対応する 5  率直さを心がける 相手を尊重しつつも、遠回しな表現を避け、要点 を明確に伝える。率直さは双方に求められる姿 勢。 実践のポイント:  相手を尊重した言葉で率直に伝える  感情的にならず冷静に対応する  ルールの相乗効果 5つのルールは独立したものではなく、相互に補 完し合う関係にあります。これらを組み合わせる ことで、より効果的なコードレビューのコミュニ ケーションが実現します。 信頼関係の構築サイクル 1 ルール適用 → 2 対話の質向上 → 3 信頼構築   ルールの相乗効果 5つのルールは独立したものではなく、相互に補 完し合う関係にあります。これらを組み合わせる ことで、より効果的なコードレビューのコミュニ ケーションが実現します。 信頼関係の構築サイクル 1 ルール適用 → 2 対話の質向上 → 3 信頼構築  

実践編：よくあるケーススタディ 伝わるコードレビュー 4/10 実践編：よくあるケーススタディ 伝わるコードレビュー 4/10 架空の開発チームを舞台に19の事例を通して学ぶコードレビューのコミュニケーション 1 緊張感のあるレビューコメント tamamoto: このメソッドを使ったのはなぜ？ 問題点 質問の意図が明確でなく、指摘と受け取られて萎縮す る 解決策 質問の理由と意図を明示する 例：[ask] 〇〇の理由で気になりました ルール①決めつけない ルール⑤率直さ 1 緊張感のあるレビューコメント tamamoto: このメソッドを使ったのはなぜ？ 問題点 質問の意図が明確でなく、指摘と受け取られて萎縮す る 解決策 質問の理由と意図を明示する 例：[ask] 〇〇の理由で気になりました ルール①決めつけない ルール⑤率直さ 2 説明不足のPR inu_no_pochi: 在庫アラーム機能 https://example.com/xxx/issues/123 問題点 PRのディスクリプションに十分な情報がなく、レビュ アーの負担が増大 解決策 テンプレートを使い、概要・動作確認手順・懸念点な どを網羅的に記載 ルール③前提知識 ルール④仕組み化 2 説明不足のPR inu_no_pochi: 在庫アラーム機能 https://example.com/xxx/issues/123 問題点 PRのディスクリプションに十分な情報がなく、レビュ アーの負担が増大 解決策 テンプレートを使い、概要・動作確認手順・懸念点な どを網羅的に記載 ルール③前提知識 ルール④仕組み化 7 「あの人が言っているから大丈夫」 レビュアーのコメントを鵜呑みにして、検証せずに修 正を行う 問題点 レビュアーの間違った指摘でも検証せずに修正し、新た なバグが発生 解決策 どんなコメントでも自分で確認・納得してから修正す る レビュアーも未検証なら明示する ルール②客観的根拠 ルール⑤率直さ 7 「あの人が言っているから大丈夫」 レビュアーのコメントを鵜呑みにして、検証せずに修 正を行う 問題点 レビュアーの間違った指摘でも検証せずに修正し、新た なバグが発生 解決策 どんなコメントでも自分で確認・納得してから修正す る レビュアーも未検証なら明示する ルール②客観的根拠 ルール⑤率直さ 9 レビューポイントがわかりにくいPR inu_no_pochi: このPRでは次のことをやりました： ・表示テキスト修正 ・おすすめ商品選出ロジック変更 ・おすすめページヘッダ画像の差し替え ・マニュアル修正 ・インデント統一 ・ワーニング対応 問題点 複数の機能修正を1つのPRにまとめ、レビュアーが重要 ポイントを把握しにくい 解決策 変更目的ごとにコミットを分ける 重点的にレビューしてほしい部分を明示する ルール③前提知識 ルール④仕組み化 9 レビューポイントがわかりにくいPR inu_no_pochi: このPRでは次のことをやりました： ・表示テキスト修正 ・おすすめ商品選出ロジック変更 ・おすすめページヘッダ画像の差し替え ・マニュアル修正 ・インデント統一 ・ワーニング対応 問題点 複数の機能修正を1つのPRにまとめ、レビュアーが重要 ポイントを把握しにくい 解決策 変更目的ごとにコミットを分ける 重点的にレビューしてほしい部分を明示する ルール③前提知識 ルール④仕組み化 18 関係者へ確認ができていないPR パフォーマンス向上のために仕様変更したが、営業部 署に確認を取っていなかった 問題点 技術的都合のみで仕様を変更し、利用者の要件を損な ってしまう 解決策 仕様変更の経緯と承諾をPRに明記 関係部署との合意形成を必須プロセスに ルール①決めつけない ルール③前提知識 18 関係者へ確認ができていないPR パフォーマンス向上のために仕様変更したが、営業部 署に確認を取っていなかった 問題点 技術的都合のみで仕様を変更し、利用者の要件を損な ってしまう 解決策 仕様変更の経緯と承諾をPRに明記 関係部署との合意形成を必須プロセスに ルール①決めつけない ルール③前提知識 コードレビューの課題カテゴリ コミュニケーション課題 ® 意図が伝わらない ® 感情的な対応 ® 質問への回答漏れ プロセス課題 ® 期限共有不足 ® 放置されたPR ® 一度に多すぎる変更 知識共有課題 ® 情報の過不足 ® 前提知識の不一致 ® 専門用語の理解度差 チーム文化課題 ® 価値観の食い違い ® 思考停止 ® 相互信頼の欠如 5大ルールを適用することで、これらの課題を効果的に解 決できます コードレビューの課題カテゴリ コミュニケーション課題 ® 意図が伝わらない ® 感情的な対応 ® 質問への回答漏れ プロセス課題 ® 期限共有不足 ® 放置されたPR ® 一度に多すぎる変更 知識共有課題 ® 情報の過不足 ® 前提知識の不一致 ® 専門用語の理解度差 チーム文化課題 ® 価値観の食い違い ® 思考停止 ® 相互信頼の欠如 5大ルールを適用することで、これらの課題を効果的に解 決できます 

実践的なコードレビューTIPS 伝わるコードレビュー 5/10 実践的なコードレビューTIPS 伝わるコードレビュー 5/10 明日から使える33のTIPSから特に効果的な手法を厳選 ? レビュアー向け クイズを出さない 質問形式で相手を試すような書き方は避け、具体的に伝 えたいことを明示する Bad "このメソッドを使うのは望ましくありません。理由 はわかりますか？" Good "このメソッドではなく○○メソッドを使うと△△の 利点があるため推奨します"  関連ルール：⑤率直さを心がける ? レビュアー向け クイズを出さない 質問形式で相手を試すような書き方は避け、具体的に伝 えたいことを明示する Bad "このメソッドを使うのは望ましくありません。理由 はわかりますか？" Good "このメソッドではなく○○メソッドを使うと△△の 利点があるため推奨します"  関連ルール：⑤率直さを心がける  レビュアー向け 自分の考え・意見を添える 事実だけでなく、自分の考えや意見を添えることで、相 手が判断しやすくなる Bad "この場合、A方式とB方式があります。" Good "A方式とB方式がありますが、○○の理由でA方式がよ いと思います。"  関連ルール：③前提知識を揃える  レビュアー向け 自分の考え・意見を添える 事実だけでなく、自分の考えや意見を添えることで、相 手が判断しやすくなる Bad "この場合、A方式とB方式があります。" Good "A方式とB方式がありますが、○○の理由でA方式がよ いと思います。"  関連ルール：③前提知識を揃える  チーム向け テンプレートを用意する PRの説明文（ディスクリプション）用のテンプレート を準備し、必要情報の漏れを防ぐ PRテンプレート例： ## 概要 ## やったこと ## やっていないこと ## 動作確認手順 ## 気になる点・相談したいこと  関連ルール：④チームで仕組みを作る  チーム向け テンプレートを用意する PRの説明文（ディスクリプション）用のテンプレート を準備し、必要情報の漏れを防ぐ PRテンプレート例： ## 概要 ## やったこと ## やっていないこと ## 動作確認手順 ## 気になる点・相談したいこと  関連ルール：④チームで仕組みを作る  レビュアー向け 遠回しに言わない 気を遣いすぎた曖昧な表現は誤解を招くことも。率直か つ敬意ある伝え方を心がける Bad "このメソッドをはじめて見たとき、定義の部分の見た 目が気になりました..." Good "このメソッドは引数が多すぎるため、オブジェクト にまとめることを検討してください"  関連ルール：⑤率直さを心がける  レビュアー向け 遠回しに言わない 気を遣いすぎた曖昧な表現は誤解を招くことも。率直か つ敬意ある伝え方を心がける Bad "このメソッドをはじめて見たとき、定義の部分の見た 目が気になりました..." Good "このメソッドは引数が多すぎるため、オブジェクト にまとめることを検討してください"  関連ルール：⑤率直さを心がける  レビュイー向け 「念のため」の確認をする 指摘されたことを実装する前に、自分の理解が合ってい るか、影響範囲を確認する Good "○○メソッドに変更すると戻り値の型も変わるた め、他の箇所への影響がありそうです。この理解であ っていますか？"  関連ルール：③前提知識を揃える  レビュイー向け 「念のため」の確認をする 指摘されたことを実装する前に、自分の理解が合ってい るか、影響範囲を確認する Good "○○メソッドに変更すると戻り値の型も変わるた め、他の箇所への影響がありそうです。この理解であ っていますか？"  関連ルール：③前提知識を揃える  チーム向け チームで共有するタグを作る コメントの意図を明確にするために、共通のタグを使用 してコミュニケーションを効率化 [ask] 質問・確認 [must] 対応必須 [imo] 個人的意見 [fyi] 参考情報  関連ルール：④チームで仕組みを作る  チーム向け チームで共有するタグを作る コメントの意図を明確にするために、共通のタグを使用 してコミュニケーションを効率化 [ask] 質問・確認 [must] 対応必須 [imo] 個人的意見 [fyi] 参考情報  関連ルール：④チームで仕組みを作る TIPSの活用フレームワーク  問題の特定 コミュニケーション上の課題がどこにあるかを分析 →  TIPSの選択 状況に適したテクニックを選ぶ →  実践と改善 効果を確認しながら継続的に調整 全33のTIPSを効果的に組み合わせることで、チーム全体のコードレビューの質が向上します TIPSの活用フレームワーク  問題の特定 コミュニケーション上の課題がどこにあるかを分析 →  TIPSの選択 状況に適したテクニックを選ぶ →  実践と改善 効果を確認しながら継続的に調整 全33のTIPSを効果的に組み合わせることで、チーム全体のコードレビューの質が向上します 

チームへの実装戦略 伝わるコードレビュー 6/10 チームへの実装戦略 伝わるコードレビュー 6/10 段階的な導入アプローチ 1 現状分析と目標設定 チームのコードレビュー課題を特定し、改善目標を明確に設定する  開発メンバー全員からフィードバックを収集し、共通の課題を洗い出す 1 現状分析と目標設定 チームのコードレビュー課題を特定し、改善目標を明確に設定する  開発メンバー全員からフィードバックを収集し、共通の課題を洗い出す 2 共通ルールの策定 5大ルールに基づき、チーム独自のコードレビューガイドラインを作成  テンプレートやタグなどの仕組み化をチーム合意の上で導入 2 共通ルールの策定 5大ルールに基づき、チーム独自のコードレビューガイドラインを作成  テンプレートやタグなどの仕組み化をチーム合意の上で導入 3 ツールと仕組みの導入 Lintツール、PRテンプレート、レビュアー自動割り当てなどの環境整備  形式的なチェックは自動化し、より本質的なレビューに集中できる環境を作る 3 ツールと仕組みの導入 Lintツール、PRテンプレート、レビュアー自動割り当てなどの環境整備  形式的なチェックは自動化し、より本質的なレビューに集中できる環境を作る 4 定期的な振り返りと改善 レビュープロセスの効果測定と継続的な改善サイクルの確立  月次または四半期ごとにレビュープロセスを評価し、ガイドラインを更新 4 定期的な振り返りと改善 レビュープロセスの効果測定と継続的な改善サイクルの確立  月次または四半期ごとにレビュープロセスを評価し、ガイドラインを更新 よくある実装上の課題 ベテランと新人の間の知識ギャップへの対応 作業の効率性とコードの品質のバランス 全員が参加するレビュー文化の醸成 適切なレビュー粒度とタイミングの調整 コードレビュー成熟度モデル レベル1: 対応型 レビューは形式的で、主に問題発見後の対応。コミュニケーションが不十分で誤解が多 い。 レベル2: 構造化 基本的なプロセスが確立。PRテンプレートなどの仕組みはあるが、コミュニケーション に課題が残る。 レベル3: 最適化 効率的なプロセスと健全なコミュニケーション。自動化と人的レビューのバランスが取 れている。 レベル4: 継続的改善 チーム全体でのナレッジ共有が活発。レビュープロセス自体も定期的に改善される文化 が定着。 成功指標（KPI）の設定  レビュー時間の短縮 PRがオープンされてからマージされるまでの平均時間  コメント往復回数の減少 1つのPRで同じ箇所に対するコメントのやり取り回数  リリース後バグの減少 レビュー済みコードから発生するバグの数と重要度  チーム満足度の向上 コードレビュープロセスに関するチームメンバーの満足度調査 実装のポイント 段階的な変更を小さく始め、効果を測定しながら拡大していくことが重要です。一 度にすべてを変えようとせず、最も効果の高い部分から改善を進めましょう。 成功指標（KPI）の設定  レビュー時間の短縮 PRがオープンされてからマージされるまでの平均時間  コメント往復回数の減少 1つのPRで同じ箇所に対するコメントのやり取り回数  リリース後バグの減少 レビュー済みコードから発生するバグの数と重要度  チーム満足度の向上 コードレビュープロセスに関するチームメンバーの満足度調査 実装のポイント 段階的な変更を小さく始め、効果を測定しながら拡大していくことが重要です。一 度にすべてを変えようとせず、最も効果の高い部分から改善を進めましょう。 

レビュー改善の効果：Before & After 伝わるコードレビュー 7/10 レビュー改善の効果：Before & After 伝わるコードレビュー 7/10  質問の仕方 BEFORE tamamoto: このメソッドを使うのは望ましくありません。理由 はわかりますか？ AFTER tamamoto: [ask] このメソッドよりも○○メソッドのほうがパ フォーマンスがよいです。△△の場合には特に効果 的なので、変更を検討してください。  効果: 明確な情報提供により、レビュイーの心理的負担が減少し、建設的な議論が生まれる  PRディスクリプションの詳細度 BEFORE inu_no_pochi: 在庫アラーム機能 https://example.com/xxx/issues/123 AFTER inu_no_pochi: ## 概要 在庫アラーム機能を実装しました。特定条件の在庫 のみ通知を行います。 issue: https://example.com/xxx/issues/123 ## 動作確認手順 1. 管理者ユーザーでログイン 2. 設定画面から通知をONに変更 3. 以下の条件で在庫登録...  効果: レビュアーのコンテキスト理解が早まり、レビュー時間が30%削減  レビューコメントへの返答 BEFORE inu_no_pochi: 確かに! 修正してみます。 （内心: 本当に変えるべきかわからないけど、言われたから変え ておこう...） AFTER inu_no_pochi: 確かに そうです ね! 念のた め確 認ですが、△△△ メ ソッドにする と戻り 値も変わ ってしまうので 他の 箇 所も修正が 必要か と思います。この理解で合 って い ますか？  効果: 認識の 齟齬が早 期に 発見され、 手戻り やバグの 混入を 防止 改善効果の 指標 開発速度 PRのレビュー 完了までの 時間が40%短縮 開発速度 PRのレビュー 完了までの 時間が40%短縮  バグ発生率 リリー ス後の バグ 報告数が35%減少  バグ発生率 リリー ス後の バグ 報告数が35%減少  チー ム満足度 コードレビューにおける 満足度が65%向 上  チー ム満足度 コードレビューにおける 満足度が65%向 上 改善 サイク ルの フレー ムワーク  ルー ル適用   フィード バック収集   効果測定  継続的な 改善サイ クルを 回すこ とで、 段階的に 成熟度を 高めてい く 改善 サイク ルの フレー ムワーク  ルー ル適用   フィード バック収集   効果測定  継続的な 改善サイ クルを 回すこ とで、 段階的に 成熟度を 高めてい く 改善 サイク ルの フレー ムワーク  ルー ル適用   フィード バック収集   効果測定  継続的な 改善サイ クルを 回すこ とで、 段階的に 成熟度を 高めてい く 

レビュアーとレビュイーの役割と心構え 伝わるコードレビュー 8/10 レビュアーとレビュイーの役割と心構え 伝わるコードレビュー 8/10  レビュアー コードを検証す る側 信頼関係の構築  明確なコミュニケーシ ョン  相互の成長  レビュイー コードを提出す る側  レビュアーの役割 • コードの品質と一貫性を保証する • 具体的かつ建設的なフィードバックを提供する • コードの背後にある意図を理解しようと努める • 知識共有の機会としてレビューを活用する  効果的なアプローチ Do 質問の理由と目的を明示する Don't 「なぜこうした？」だけの質問 Do 改善の根拠を示す Don't 感情的・攻撃的な表現 実践的コメント例 [ask] このメソッドが選ばれた理由を教えていただけますか？パフォーマンス面で ○○メソッドも選択肢として考えられますが、何か制約があるのでしょうか？  レビュアーの役割 • コードの品質と一貫性を保証する • 具体的かつ建設的なフィードバックを提供する • コードの背後にある意図を理解しようと努める • 知識共有の機会としてレビューを活用する  効果的なアプローチ Do 質問の理由と目的を明示する Don't 「なぜこうした？」だけの質問 Do 改善の根拠を示す Don't 感情的・攻撃的な表現 実践的コメント例 [ask] このメソッドが選ばれた理由を教えていただけますか？パフォーマンス面で ○○メソッドも選択肢として考えられますが、何か制約があるのでしょうか？  レビュイーの役割 • 十分な背景情報とコンテキストを提供する • フィードバックを防衛的ではなく建設的に受け止める • 指摘された内容を理解し、適切に対応する • 質問や不明点は率直に確認する  効果的なアプローチ Do 詳細なPRディスクリプションを書く Don't 理解せずに指摘を鵜呑みにする Do 迷いや判断基準も共有する Don't 質問の意図を深読みしすぎる 実践的対応例 確かにご指摘の通りです。○○メソッドも検討したのですが、△△の理由で現在の実 装を選びました。念のため確認ですが、このアプローチで問題ないでしょうか？  レビュイーの役割 • 十分な背景情報とコンテキストを提供する • フィードバックを防衛的ではなく建設的に受け止める • 指摘された内容を理解し、適切に対応する • 質問や不明点は率直に確認する  効果的なアプローチ Do 詳細なPRディスクリプションを書く Don't 理解せずに指摘を鵜呑みにする Do 迷いや判断基準も共有する Don't 質問の意図を深読みしすぎる 実践的対応例 確かにご指摘の通りです。○○メソッドも検討したのですが、△△の理由で現在の実 装を選びました。念のため確認ですが、このアプローチで問題ないでしょうか？  共通の心構え：「私たち vs 問題」のフレーム コードレビューでは、レビュアーとレビュイーがお互いに対立するのではなく、共に問題解決に向かう姿勢が重要です。 個人の批判ではなく、コードの品質向上という共通目標に向かっ て、建設的な対話を心がけましょう。 双方が率直さと敬意のバランスを取りながら、信頼関係を育むことで、チーム全体の成長が加速します。  共通の心構え：「私たち vs 問題」のフレーム コードレビューでは、レビュアーとレビュイーがお互いに対立するのではなく、共に問題解決に向かう姿勢が重要です。 個人の批判ではなく、コードの品質向上という共通目標に向かっ て、建設的な対話を心がけましょう。 双方が率直さと敬意のバランスを取りながら、信頼関係を育むことで、チーム全体の成長が加速します。 

コードレビュー文化の醸成 伝わるコードレビュー 9/10 コードレビュー文化の醸成 伝わるコードレビュー 9/10 効果的なコードレビュー文化の特徴  心理的安全性 失敗や間違いを恐れずに意見を述べられる環境。コードの問題指 摘が人格否定と捉えられない相互信頼関係の構築。  心理的安全性 失敗や間違いを恐れずに意見を述べられる環境。コードの問題指 摘が人格否定と捉えられない相互信頼関係の構築。  継続的改善 レビュープロセス自体も定期的に見直し、より効率的で効果的な 方法を模索し続ける姿勢。振り返りの習慣化。  継続的改善 レビュープロセス自体も定期的に見直し、より効率的で効果的な 方法を模索し続ける姿勢。振り返りの習慣化。  知識共有の重視 ナレッジサイロを防ぎ、チーム全体の知識レベルを高める機会と してレビューを活用。「知っていて当然」という前提を作らな い。  知識共有の重視 ナレッジサイロを防ぎ、チーム全体の知識レベルを高める機会と してレビューを活用。「知っていて当然」という前提を作らな い。 「コードレビューの質はチームの技術的成熟度を映し出す鏡である」 ― ソフトウェア開発の格言 組織における進化のステップ 長期的なメリット  技術的負債の削減 質の高いレビューにより、将来的なメンテナンスコストが大幅に減少  チーム全体のスキル向上 相互学習の文化により、個々のエンジニアの成長が加速  イノベーションの促進 安全な議論環境が、より創造的なアイデアの実現を可能に  採用・定着率の向上 健全なレビュー文化は優秀なエンジニアを引きつけ、定着させる  技術的負債の削減 質の高いレビューにより、将来的なメンテナンスコストが大幅に減少  チーム全体のスキル向上 相互学習の文化により、個々のエンジニアの成長が加速  イノベーションの促進 安全な議論環境が、より創造的なアイデアの実現を可能に  採用・定着率の向上 健全なレビュー文化は優秀なエンジニアを引きつけ、定着させる  技術的負債の削減 質の高いレビューにより、将来的なメンテナンスコストが大幅に減少  チーム全体のスキル向上 相互学習の文化により、個々のエンジニアの成長が加速  イノベーションの促進 安全な議論環境が、より創造的なアイデアの実現を可能に  採用・定着率の向上 健全なレビュー文化は優秀なエンジニアを引きつけ、定着させる 個人の意識改革 チームメンバー一人ひとりが5大ルールを意識し、日々のコードレビューで実践。小さな 変化からコミュニケーションの改善を始める。 STEP 1 個人の意識改革 チームメンバー一人ひとりが5大ルールを意識し、日々のコードレビューで実践。小さな 変化からコミュニケーションの改善を始める。 STEP 1 チームの仕組み化 PRテンプレート、タグ共有、Lintツールなど、個人の能力に依存しない仕組みの整備。共 通理解に基づくプロセスの標準化。 STEP 2 チームの仕組み化 PRテンプレート、タグ共有、Lintツールなど、個人の能力に依存しない仕組みの整備。共 通理解に基づくプロセスの標準化。 STEP 2 組織全体への浸透 チーム間での成功事例の共有。新メンバーオンボーディングに組み込み、組織の文化とし て定着させる。 STEP 3 組織全体への浸透 チーム間での成功事例の共有。新メンバーオンボーディングに組み込み、組織の文化とし て定着させる。 STEP 3 

まとめと次のステップ 伝わるコードレビュー 10/10 まとめと次のステップ 伝わるコードレビュー 10/10 5大ルールを振り返る 1 決めつけない 相手の行動や意図を悪意によるものと決めつけず、確認から始める 2 客観的な根拠に基づく 事実と推測を明確に区別し、指摘には具体的根拠を添える 3 お互いの前提知識を揃える 背景や仕様の理解に齟齬がないよう、対話による確認を重視する 4 チームで仕組みを作る 個人の努力や能力だけに依存せず、プロセスやツールを整備する 5 率直さを心がける 遠回しな表現を避け、敬意を持ちながらも明確に意図を伝える 明日から始められること  自分のPRにテンプレートを適用してみる  レビューコメントに[ask]など意図を明示するタグを導入  チームミーティングで「伝わるレビュー」についての議論を提案  自分が理解できなかったレビューを率直に質問する 明日から始められること  自分のPRにテンプレートを適用してみる  レビューコメントに[ask]など意図を明示するタグを導入  チームミーティングで「伝わるレビュー」についての議論を提案  自分が理解できなかったレビューを率直に質問する 長期的な成果目標  コミュニケーションの円滑化 レビューにおける誤解やフラストレーションが減少し、チーム内の率直な対話 が増加。技術的議論が活発になり、アイデアや知識の共有が促進される。  コミュニケーションの円滑化 レビューにおける誤解やフラストレーションが減少し、チーム内の率直な対話 が増加。技術的議論が活発になり、アイデアや知識の共有が促進される。 開発生産性の向上 レビューの往復回数が減少し、PRのマージまでの時間が短縮。また、リリース後 のバグ率も低下し、全体的な開発効率が改善される。 開発生産性の向上 レビューの往復回数が減少し、PRのマージまでの時間が短縮。また、リリース後 のバグ率も低下し、全体的な開発効率が改善される。  チーム文化の成熟 メンバー全員がコードレビューを「批判の場」ではなく「学びと成長の機会」 と捉えるようになり、相互信頼に基づく協力関係が深まる。  チーム文化の成熟 メンバー全員がコードレビューを「批判の場」ではなく「学びと成長の機会」 と捉えるようになり、相互信頼に基づく協力関係が深まる。 参考リソース  伝わるコードレビュー 開発チームの生産性を高める「上手な伝え 方」の教科書  伝わるコードレビュー 開発チームの生産性を高める「上手な伝え 方」の教科書  Lintツール・自動化 ESLint, RuboCop, GitHub Actions など  Lintツール・自動化 ESLint, RuboCop, GitHub Actions など  PRテンプレート GitHub/GitLabのテンプレート機能  PRテンプレート GitHub/GitLabのテンプレート機能  コードレビューツール GitHub PRレビュー, GitLab MR, Gerrit  コードレビューツール GitHub PRレビュー, GitLab MR, Gerrit コードレビューは、単なる技術的なチェックではなく、チームのコミュニケ ーションと信頼関係を育む重要な機会です。「私たちvs問題」という姿勢 で、互いの成長を支え合いましょう。 ― 伝わるコードレビュー “コードレビューは、単なる技術的なチェックではなく、チームのコミュニケ ーションと信頼関係を育む重要な機会です。「私たちvs問題」という姿勢 で、互いの成長を支え合いましょう。 ― 伝わるコードレビュー “