レビューで「ここは直した方がよさそうです」と届いた。直すべきか、理由を聞いてよいか、今回は対象外だと伝えてよいか。コードより返答に時間がかかることがあります。
先に結論
- まず指摘の意図を確かめる。必須の修正か、改善提案か、質問かを揃える。
- 修正・質問・見送りの相談を分ける。判断が残る点を「対応しました」で閉じない。
- 変更箇所と確認結果、残る判断を返す。未確認は未確認として伝える。
以下は、件名が必須・1〜100文字の問い合わせ管理を改修する架空の会話例です。実際のレビューや実行済みのテスト結果ではありません。
最初に、何を求める指摘かを確かめる
保存してはいけない値が保存される問題と、名前を読みやすくする提案では扱いが違います。チームに必須・提案・質問などのラベルがあれば、その意味を使います。ラベルや意図が分からなければ聞いて構いません。
質問例｜仕様違反か、改善提案か
空白だけの件名を保存できる点が、仕様に合っていないという指摘でしょうか。それとも、入力を整える改善提案でしょうか。今回合意した必須条件と照らして確認したいです。
相手の立場だけで即座に変更せず、仕様と提案を区別します。意図が分かると、直す場所や必要な確認を決めやすくなります。
Googleのガイドも、指摘を理解できているか確かめ、不明なら明確化を求める考え方を示しています。会話例はそれを参考にした独自の例で、分類や解決手順は職場の運用に合わせてください。Google Engineering Practices
返答を三つに分ける
- 理解できたので直す：何をどう変えたか、変更箇所と確認結果を残す。
- 意味が分からない：理解できた範囲と疑問、確認したい理由や具体例を伝える。
- 今回は見送りたい：理由・影響・代案を示し、誰が判断し、どこで追うかを相談する。
目的は相手を説得して会話を終えることではなく、変更をどう扱うか決めることです。短く返しても、判断が残る点は見えるようにします。
修正したら、場所と確認結果を返す
「空の件名を保存できています。必須条件を満たすよう修正してください」という指摘を受けたとします。
「修正しました」だけでは、画面だけか、保存処理も直したかが分かりません。次は、該当の確認まで終わっている場合の返信例です。
返信例｜修正・確認が終わった場合
保存を受け付ける処理に、空の件名を受け付けない条件を追加しました。画面側の案内も合わせています。
空欄では保存されず、1文字と100文字は保存されることを手元の開発環境で確認しました。修正箇所と確認記録を添えたので、再確認をお願いします。
未確認なら：「修正を入れたので、これから空欄と有効な件名を確認します」と返します。編集した時点と、動作を確かめた時点を混ぜないようにします。
単純な誤字修正に長いテスト報告は不要でも、条件分岐や保存処理を変えたなら影響に応じた確認が必要です。返信の長さは、変更量だけでなく、相手の判断に必要な情報で決めます。
分からないときは、理解できたところから聞く
「この処理の責務を整理してください」と言われて、何をどこへ移すのか分からない場合があります。「勉強不足ですみません」だけでは、疑問の場所が伝わりません。
質問例｜理解を仮置きして、分かれ道を示す
入力形式の確認と、状態に応じた変更可否の判断が同じ場所にある点が気になっている、と理解しました。
件名の必須チェックも移す提案でしょうか。それとも、受付済みの問い合わせを変更できるかという判断を分ける意図でしょうか。既存の参考実装があれば合わせて確認したいです。
まったく理解できていないなら、「責務という言葉が、ここではどの処理の違いを指すか分かっていません。対象の処理を一つ示してもらえますか」で構いません。
納得できたら、必要に応じてコードやコメントにも意図を残し、将来の読み手へ理由を伝えます。説明の残し方はコードコメントの書き方、構造の例はServiceのクラス分割を参照できます。
見送りたいときは、理由と次の扱いを相談する
件名追加のPRで「問い合わせ全体の状態管理も共通化できそう」と提案されたとします。有用な提案でも、一緒に進めると確認範囲が広がるかもしれません。
相談例｜独立した改善を別課題にしたい場合
状態管理が複数箇所に分かれている懸念は理解しました。共通化すると、受付済み・対応中・完了の変更処理まで確認が必要になりそうです。
今回は件名追加に必要な変更までにとどめ、共通化は対象と確認範囲を整理する別の課題にしたいと考えています。この分け方で問題ないでしょうか。
「範囲外なのでやりません」だけでなく、安全に受け入れるための問題か、独立した改善かを話します。機能の誤りや必要な確認を、納期だけを理由に見送ったことにしません。
別課題への移動に合意したら、内容・理由・担当者・見直す時点を記録します。担当が決まらなければ未決と書き、課題名だけ作って放置しないよう、次の扱いを揃えます。
話が長引いたら、伝え方を変える
同じ説明が続くときは、双方の前提が違う可能性があります。短い通話や画面共有で入力・動作を確かめ、結論と理由はPRへ戻します。口頭で話した人だけが分かる状態にしないためです。
人格を否定する表現や威圧が続く場合まで、一人で引き受ける必要はありません。具体的なコメントを残し、リーダーやチームの相談先へ進め方を相談してください。技術上の指摘への対応と、不適切な扱いの受け入れは別です。
再レビュー前に、残る判断を確認する
返信前のチェック
- 変更箇所・確認結果・まだ決めたいことを分けたか。
- 修正が増えた場合、PRの説明も現在の範囲に合わせたか。
- コメントを解決済みにする人と、承認を依頼する時点はチームの運用に合っているか。
相手の再確認が必要な指摘を、自分だけで終わったことにしないようにします。返答に詰まったら「ここまで理解しています。そのうえで、ここを確認したいです」から始めてみてください。
