※本記事は、AIは責任を取らない、最後に決めるのは人間だ。今こそ本気で鍛える「責任移譲」としてのコードレビュー術 の対となる「レビューイ（実装者）編」です。
はじめに：なぜ「レビューお願いします」と送るのが怖いのか？
プルリクエスト（PR）を作成し、レビューを依頼するとき、あなたはどんな気持ちですか？
「何か言われませんように」
「怒られませんように」
そう祈っていませんか？
その「怯え」の原因は明白です。
「自分の成果物に自信がない（やりきっていない）」 からです。
多くの人がPRを「間違っていたら直します」という 「添削依頼」 だと勘違いしています。違います。
PRとは、プロとしての 「納品（完了報告）」 です。
未完成のものを「とりあえず見てください」と出すのは、レビュアーを「デバッグ係」として扱っているのと同じであり、非常に失礼な行為です。
この記事では、レビュアーの負担を極限まで減らし、 「堂々と、自信を持って」 成果物を提出するための、プロとしての作法をお伝えします。
なお、前回の記事では「楽にLGTMを出したい人は、ブラウザバックを推奨します。」と言いましたが、今回は 「楽にLGTMを出したい人は、ブラウザバックを非推奨とします。」
1. 【品質】テストコードは「実装への責任」である
まず前提として、UnitTestやFeatureTestのないコードは、品質が担保されていない「野良コード」です。
テストは「とりあえずカバレッジを通せばいい」という 形だけの通過儀礼 ではありません。
将来の自分とレビュアーに対し、
「この変更は既存機能を破壊せず、仕様通り動くことを私が確認し、責任を持ちます」
という意思表示です。
この責任をテストコードという形で明示するからこそ、我々は怯えずにコードを変更でき、レビュアーも安心してコードを読むことができるのです。
テストを書く時間はコストではなく、実装への責任を果たすための必須工程です。
2. 【自律】自己レビューは「最低3回」やれ
「タイポ」「不要なログの消し忘れ」「フォーマット崩れ」。
こうしたしょうもないミスでレビュアーの思考を中断させるのは、プロとして恥ずべきことです。
私は、難易度にもよりますが 最低3回 は自己レビューを行います。（平均5回）
-
1回目（正確性）：
不要な処理が残っていないか、ロジックが間違っていないか。指摘されたら恥ずかしい実装の排除です。 -
2回目（自信）：
「これで自信を持てるか？」「これが自分のベストなアウトプットか？」という観点で、自分のために見直します。 -
3回目（レビュアー視点）：
レビュアーになったつもりで確認します。レビュアーが読んだ時につまづきやすいポイントはないかを確認します。
あなたはブログやSNSに投稿する際、誤字脱字や伝わり方をチェックせずに世に出しませんよね？（あ、SNSはちょっと甘いので気をつけます...）
コードも同じです。「どう相手に捉えられるか」 まで考えて初めて、レビューに出せる状態になります。
3. 【配慮】PR記述は「見る人」のためにある
PRのDescription（説明）は誰のために書くのでしょうか？
そうですね。「見る人（レビュアー）」のためです。見る人がいなければ書く必要はありませんが、見る人がいる以上、その人のために書くのが道理です。
レビュアーに正しく意図を伝えるために、以下のポイントを押さえます。
1. チケットリンク
これはルールです。ブランチ名にIDが含まれていても、クリック一発でチケットを参照できるようにするための配慮です。
2. 対応内容（やったこと）
このPRの実装を端的に表す重要情報です。
ここの記述と実際の実装内容がズレていると、レビュアーは大いに混乱します。「何をしたか」を正確に言語化してください。
3. 動作確認結果（テスト観点とエビデンス）
「問題なし」という言葉だけで済ませていませんか？
これではレビュアーは、あなたの言葉を信じるかどうかの判断しかできません。
- テスト観点: 「どういう観点で確認したか」を明記する。
- エビデンス: その結果どうなったか、スクショや動画などの「工作しようがない（しにくい）情報」を提示する。
これにより、レビュアーは「信頼」ではなく「事実」に基づいてレビューできるようになります。
4. 【先手】コメントで「思考」を残す
コードだけで意図を100%伝えるのが理想ですが、現実には補足が必要な場面があります。
そこで、レビュアーが「ん？」と手が止まりそうな箇所には、あらかじめコメントを残し、疑問を先回りして解消します。
コメントには2種類あります。
-
コードに残すコメント:
「ここは〇〇という理由であえてこうしています」など、実装の経緯やロジックの理由として、永続的にコードに残すべき情報。 -
PRに残すコメント:
「ここは既にマージ済みの〇〇の処理と同じです」など、レビュー時に伝えたい文脈情報。これはGitHub等のコメント機能を使います。
大切なのは、「なぜ？」 と思わせる時間 を減らしてあげる ことです。
5. 【作法】依頼は「優先度」を明確に
準備が整ったら、Slack等でレビュー依頼を出します。
「レビューお願いします」だけ送っていませんか？
相手は忙しいです。自分のタスクが相手にとってどれくらいの優先度なのか、実装者視点での情報を添えてください。
- 必須: PRのリンク
- 必須: チケットのタイトル
-
推奨: 状況の補足
- 「〇〇の実装のブロッカーになるので、優先で見てもらえると助かります」
- 「急ぎではないので、お手隙の際にお願いします」
遅らせる判断はタスクを管理する側が行いますが、情報がなければ判断もできません。勝手に優先度を下げられないためにも、状況を伝えるのは重要です。
おわりに：自身の成果物に最大限の責任を持つ
これら全ての工程に共通するのは、「自信を持つために、レビューイとしてできることを最大限やる」 という姿勢です。
「信用されたからレビューが甘くなる」ことなど望んでいません。
私たちが目指すのは、レビュアーの負荷を下げ、指摘されるだけの怖い場から 「より良い設計を議論する場」 へと昇華させることです。
ここまでやったら、もう不安はないはずです。
きっと良いレビューになることを応援しています。