その話、本当にレビュー中にすることですか？

設計レビューやコードレビューが、気づけば講義や雑談になっていることはありませんか？

レビューは、品質を守り、リードタイムを短縮するための意思決定プロセスです。
一方で、教育はスキルを高めるための投資活動です。

目的も、成果物も、使う時間も異なります。
この2つを明確に分けることで、レビューの質も、教育の効果も、チーム全体のスピードも高まります。

よくある“レビューのすり替え”アンチパターン

ケース1：講義が始まる

「このfor文はビッグオーがね……」
「DDDの文脈で言うと……」
「ユニットテストとはまず……」
「このアノテーションはSpringの……」

→ 講義は別の時間に切り出し、レビューでは“差分に関わるリスクと修正案”に集中しましょう。必要があればリンクや補足資料を添えましょう。

ケース2：昔話が長い

「このコードは3年前の案件で……」
「昔このあたりでバグが……」
「この命名は当時の仕様で……」

→ 背景の説明はIssueに3行でまとめ、PRコメントには“今必要な情報”だけを残しましょう。

ケース3：ペアプロが始まる

「画面共有して一緒に直そう」
「今から手を動かしてもらって……」

→ 別途時間を確保し、レビューは“判断と記録”に集中しましょう。

ケース4：設計全体に話が広がる

「ついでにこの部分も直そう」
「設計から見直した方が……」
「この構成おかしくない？」

→ スコープ外のリファクタや設計改善は別Issueとして切り出しましょう。

ケース5：態度や姿勢への言及

「やる気が感じられない」
「真面目にやった？」
「ちゃんと考えてる？」

→ 態度や評価についての指摘は1on1で行い、レビューでは事実ベースの内容に徹しましょう。

ケース6：質問攻め・詰問モード

「なぜ？ それは？ 他の方法は？」
「どこで知識を得たの？」
「この選択肢のメリデメは？」

→ Yes／Noで答えられる確認質問に絞り、結論と修正案を明確に伝えましょう。

ケース7：命名やスタイルの好み論争

「普通こう書くよね？」
「こっちの方がキレイ」
「俺ならこう書く」

→ 個人の好みではなく、チームのルールやリンターに基づいて判断しましょう。

正しいレビューの進め方（グッドパターン）

ケースA：観点を宣言する

「今回は正確性とパフォーマンスだけ確認。スタイルは対象外です」

→ レビューの観点を最初に明言し、スコープを明確にしましょう。

ケースB：差分に関わる指摘だけ伝える

「このクエリはN+1が発生。UserRepo.findAll()をページングAPIに変えましょう」
「例外処理が漏れています。try-catchを追加しましょう」

→ 「どこ × なぜ × どう直す」のセットで、1点ずつ具体的に指摘しましょう。

ケースC：根拠を添える

「項目Xが未検証で要件違反です（仕様書P.12）」
「この関数は非同期で副作用があります。静的チェックでは検出できません」

→ 主張には、仕様・コード・規約などの根拠を添えましょう。

ケースD：Must／Should／Nitを明示する

「この2件はMust。他はShouldとNitなので任意対応で大丈夫です」

→ 優先度を示して、判断と対応のスピードを上げましょう。

ケースE：教育事項は別チケットへ

「この共通処理の分離は学習コストが高いので、別Issueに切り出しましょう」
「このパターンは勉強会で扱う予定です」

→ 教育はレビューとは分けて、継続的に計画しましょう。

ケースF：時間を区切る

「レビューは25分で区切り、残りはコメントで対応しましょう」

→ 時間を明示して、過集中やダラダラ進行を防ぎましょう。

ケースG：受け手が結論を要約する

「Mustは即修正、Shouldは別PR、Nitは対応見送り。完了予定は金曜中です」

→ 対応方針をレビューイ自身に要約してもらい、認識のズレを防ぎましょう。

ケースH：自動化できる指摘はツールに任せる

「このスタイルの指摘は、次回からフォーマッタとリンターに任せましょう」

→ 人間のレビューは“価値ある判断”に集中し、単純作業は自動化しましょう。

ケースI：リスクベースで判断する

「P95で+2msの性能影響。許容範囲なのでApproveしましょう」
「エラー時の挙動が変わりますが、ユーザー影響なしと判断します」

→ 影響とリスクを明示し、レビュー可否を判断しましょう。

ケースJ：合意を記録に残す

「設計改善はタスク#123で対応することで合意しました」
「この仕様変更は次スプリントで対応予定です」

→ 合意事項はIssueやPRコメントに残し、共有しましょう。

まとめ

レビューと教育を混同すると、品質は上がらず、進捗は遅れ、学びも定着しません。
一方で、両者を明確に分けて運用できれば、レビューは速く・厳密に、教育は計画的かつ楽しく進められます。
「今やっているのは、レビューか？ 教育か？」
この問いを常に意識し、チーム全体の成長とスピードの両立を目指しましょう。