レビューアーが考える「差し戻し」判断の設計と伝え方
レビューアーが考える「差し戻し」判断の設計と伝え方
レビューアーとして「差し戻す」という判断は、コードを読む行為以上に重い責任を伴います。
その一方で、差し戻しを避け続ければコード品質は低下し、チームに曖昧な基準がはびこってしまいます。
本マニュアルでは、レビューアーがどのように「差し戻す／通す」を判断し、それを論理的・建設的・相手の負担を最小限に抑えて伝えるかを扱います。
「差し戻し」とは何か
プルリクエスト（PR）を受け取ったレビューアーが、修正や再検討を必要と判断し、「このままマージすることはできない」と返すことを指します。
多くの場合は「Approveせず、コメントで修正依頼」「Change requested」などの手段で行います。
差し戻しの判断が難しい3つの理由
レビューアーが差し戻しを躊躇するのには理由があります。
-
明確な基準が共有されていない
- 曖昧な感覚でしか差し戻し可否を判断できず、基準が属人化する
-
指摘による人間関係の悪化を懸念
- 「空気を悪くしたくない」「ネガティブに思われたくない」といった心理が働く
-
指摘が伝わらず、堂々巡りになる懸念
- 再修正が曖昧になり、何を直すべきかの認識が共有されないまま繰り返しになる
差し戻し判断を支える3層構造の設計基準
レビューアーの判断を再現可能にするには、「何を軸に判断すべきか」を構造化する必要があります。
1. 技術基準（コードに内在する問題）
最優先されるのが、以下に該当するコード自体の致命的な問題です。
| 技術的問題 | 判断観点 |
|---|---|
| コンパイルエラー・ビルド失敗 | CIで検出されるが、ローカルで未確認など |
| 仕様逸脱（明示的バグ） | 要件に対する誤解・取り違え |
| 設計違反（責務不一致、密結合） | モジュールの独立性を著しく損ねている |
| 例外処理・ロギング漏れ | エラー発生時のトレース不可 |
@Reviewer: この処理はエラー発生時にログ出力がなく、リリース後の調査困難を引き起こします。ハンドリング方法を含めた再設計をお願いしたく、差し戻させていただきます。2. 運用基準（ルール・規約の逸脱）
コードの絶対的な誤りではないが、チーム内のガイドラインやレビュー方針に反しているケースです。
| 運用的問題 | 例 |
|---|---|
| 命名規約の逸脱 | userInfo2 や doSomething() など曖昧な命名 |
| PR粒度違反 | 1000行を超える巨大な差分 |
| コメント・説明不足 | PRの背景がわからず判断不能 |
| テスト方針との齟齬 | 境界条件・失敗系のテストが欠如 |
「修正してもしなくても影響は限定的」「次回以降改善すればよい」が成立するなら、差し戻しは回避し、コメント指摘にとどめてもよい。
3. 影響度とリスク（文脈の中での判断）
コードが明らかに間違っているわけではないが、他のモジュールへの影響や将来的なメンテナンスリスクが大きいと判断される場合。
| 状況 | 判断軸 |
|---|---|
| 影響範囲が大きい | 共有ユーティリティやグローバル変数への変更 |
| 複雑化・技術的負債の蓄積 | 処理がif/elseやネストで複雑すぎる |
| 再利用性の低下 | 一時的にしか使えないような設計 |
@Reviewer: 現時点では動作しますが、この構造では将来的に複数のユースケースに対応できなくなる懸念があります。修正を前提に一度差し戻しとさせてください。差し戻しを伝えるときの「NG表現」と「改善例」
| NG例 | 改善例 |
|---|---|
| 「これ、ひどいです」 | 「現在の実装だと意図が伝わりづらいように感じました」 |
| 「ちゃんと考えてください」 | 「設計意図をもう少しコメントなどで補足いただけると助かります」 |
| 「無理です、やり直してください」 | 「このままでは判断が難しく、目的ごとにPRを分けていただけるとレビューしやすくなります」 |
- 開発者の自尊心を傷つける
- レビューコメントの内容より「言い方」に意識が向く
- 防衛的姿勢を生み、建設的対話にならない
差し戻しを納得してもらうための構成的伝え方
差し戻しコメントは、次の3ステップで構成することで、論理的かつ穏当な伝え方になります。
-
状況の認識合わせ
- 「〇〇の処理を確認しました」「〜のように読み取りました」
-
判断理由の説明
- 「ただ、このままだと〜のリスクがあると考えています」
-
修正案 or 次にすべきアクションの提示
- 「この処理を切り出す、もしくは事前の共通化をご検討ください」
@Reviewer: この処理全体を確認しました。現在の構成だと、エラーケースでの挙動がテストされていないため、想定外の障害時に挙動が把握できない懸念があります。
一度テスト観点を整理のうえ、必要なケースを追加した上で再レビューとさせてください。ケーススタディ：実際の差し戻し例と改善コミュニケーション
function updateUserProfile(data) {
if (data.age > 18) {
@Reviewer将来的な年齢制限ルール変更に対応しにくい構造です。 一度この条件分岐を外部関数化し、ユースケースの拡張に備える構造に修正いただけると幸いです。差し戻しにて対応をお願いできればと思います。 log.info('adult');
}
db.update(data);
}このように、将来リスク・構造的問題・改善案提示の3要素を入れたコメントは、建設的に受け止められやすくなります。
差し戻し判断をレビューアー間で統一するには？
チームで「どこまでを差し戻し対象とするか」のブレを防ぐには、レビュー運用ポリシーの整備が必要です。
差し戻し判断基準の例
| 判断基準 | 差し戻し | コメントのみ |
|---|---|---|
| CI失敗 | ✅ | ❌ |
| 明示的なバグ | ✅ | ❌ |
| 命名の改善余地 | ❌ | ✅ |
| PR粒度オーバー | ✅（原則） | ⭕（軽度な場合） |
| 説明不足 | ⭕（内容次第） | ✅ |
差し戻しは「人」ではなく「構造」へのフィードバックである
差し戻すことは人格の否定ではなく、構造的な改善要求です。
- この実装はセンスがない
+ この構造だと責務が分散していて保守性が低下する懸念があります
差し戻しをためらう理由の多くは、言葉の選び方にあります。
レビューアー自身が冷静な構造分析者であるという立ち位置を保つことで、開発者との信頼関係も損なわずに質の高いレビューが可能になります。
まとめ：レビューアーの差し戻し力を高める3原則
- 判断を再現可能な構造で行う（技術・運用・リスク）
- 伝えるときは3ステップ構成（認識合わせ → 理由提示 → 修正案）
- 人格でなく構造にフォーカスする表現を徹底する