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