request-changes｜コードレビューにおける変更要求の意図と運用

概要

request-changes は、GitHubなどのコードレビューシステムで、レビューアーが修正を要求し、マージを一時停止するための公式な意思表示です。
ただの指摘コメントとは異なり、明確な拒否の意図を伴います。

使用される状況

• 明らかなバグ・誤動作・テスト未通過
• 仕様との不整合
• セキュリティ・パフォーマンス上のリスク
• ドキュメント・コメントの重大な欠落

request-changes: 入力値のバリデーションが不足しており、不正アクセスが可能な状態です。

操作方法（GitHubの場合）

1. PR画面の「Files changed」タブでコメントを記述
2. 「Review changes」ボタンをクリック
3. 「Request changes」を選択してSubmit

request-changesの心理的影響

配慮した書き方の工夫

• must + request-changes は最小限に抑える（必須修正のみ）
• 指摘理由を論理的に示す（主観や好みではなく）
• トーンを柔らかく：「ここは修正必須ですが、意図は理解できます」など

request-changes: ロジック自体は良さそうですが、この処理が現在の仕様と一致しないため修正が必要です。

会話例：request-changesが必要な場面

Reviewer: このままマージすると他のAPIとの整合性が崩れるので、request-changes入れました。
Author: 承知しました。設計意図にズレがあったようなので修正します。

Reviewer: 修正必須ではありませんが、設計的に重大な懸念があります。
Author: 話し合いの上、別案を採用することにします。

チーム運用での注意点とルール化

• request-changes は「意見」ではなく「判断」として扱う
• 一人だけの判断で保留が続く状態を避ける（チーム合意で解除）
• 「何を直せばApproveされるか」を明確に記載する

Team policy:
- request-changesを出す際は、必ず「マージ可能条件」をコメントに含める
- 2人以上のApproveがあれば、片方のrequest-changesは議論で解除可能

関連用語

• must：修正必須のレビューコメント表現
• status-check：マージ可否を決めるCIチェック
• reviewer-assignment：責任あるレビュアーの割り当てと判断基準

実務視点まとめ