【コードレビュー】指摘を減らす提出前の確認｜SEのセルフチェック5観点

レビュー依頼を送った直後に、修正漏れや説明不足に気づくと、レビュアーへ連絡し直す手間が増えます。コードの品質だけでなく、レビューに必要な情報を整えて出すことも、手戻りを減らすための準備です。

結論として、提出前の基本確認は5つの観点から始められます。変更の範囲、仕様との一致、異常系、テスト、説明文。この5観点を自分のdiffで確認すれば、提出前に見つけられる漏れや説明不足を減らしやすくなります。変更の大きさは100行前後が1つの目安で、1000行近い変更は分ける側に倒します（Googleのコードレビュー著者向けガイドに記載された一般的な例です。厳密な上限ではありません）。

チェック項目を増やす前に、仕事全体の進め方を整理したい場合は30代サラリーマンの仕事の進め方も参考になります。

レビューで戻ってくる変更に共通すること

差し戻しの理由は、コードの書き方だけではありません。変更に無関係なファイルが混ざっている、説明がなくて変更の意図が読めない、テストを動かした形跡がない。このあたりは、レビュアーが中身を判断する前に引っかかる場所です。

逆に言えば、判断の前に引っかかる場所は、出す側が先に潰せます。レビュアーの時間を「意図の確認」ではなく「設計と仕様の判断」に使ってもらうための準備だと思っています。

提出前のセルフチェックは基本の5観点から

提出する前に、自分の変更をdiffの先頭から最後まで1回読み直します。そのときに見る観点は次の5つです。

この表で大事なのは、観点ごとに「直すか、説明に書くか」を決めてから出すことです。異常系に対応しないなら、対応しない理由を説明文に残す。それだけで、レビュアーは同じ疑問を持っても回答を先に読めます。

読み直しは、書いた本人には甘くなりがちです。セルフチェックを効率化する一案は、変更量の大きいファイルから読み、次に関連する小さな差分を確認する順序です。最初に変更の全体像をつかむことで、目的に関係ない修正が混ざっていないか判断しやすくなります。

変更が大きいと、指摘の前に読んでもらえない

Googleの著者向けガイドでは、変更の目安を「100行は通常適切、1000行は大きすぎる場合が多い」としています。数字そのものより、考え方が使えます。1つの変更には自己完結した1つの目的だけを入れ、関連するテストは同じ変更に含める。リファクタリングは機能変更と分ける。

大きな変更は、レビュアーが読む時間を確保できず、結果として往復も増えます。分ける作業は提出直前だと面倒なので、実装を始める時点で「この変更は2つに割れるか」を先に考えておく方が楽です。レビューしやすい単位を実装前に設計しておくと、提出直前の分割や説明の書き直しを減らせます。

向いていない分け方もあります。途中の変更だけでは動かない状態になる分割は、レビュアーを余計に迷わせます。分けた単位ごとに動作が説明できることが前提です。

説明文は「何を」と「なぜ」を軸にする

同じガイドでは、変更の説明文に求めるものを「何を変更するか」と「なぜ変更するか」の2点に絞っています。1行目には変更内容の短い要約を置き、本文には解く問題や背景、選んだ方法の理由を書く形です。

提出前の説明文では、次の3点も確認すると実務で役立ちます。対象のチケットや仕様への参照があるか。確認したテストと結果が書いてあるか。そして、レビュアーに特に見てほしい場所を1か所挙げてあるか。3点目があると、レビュアーは迷わず判断の中心に入れます。

仕様との一致を確認する際は、SEが仕様を理解するための確認の進め方も参考になります。

緊急修正では組織の障害対応手順を優先する

本番障害の緊急修正では、所属組織の障害対応・変更管理手順に従い、必要な承認、影響範囲、最低限必要なテスト、切り戻し方法を確認します。通常手順からの例外が認められる場合も、責任者の判断と未実施項目を記録し、復旧後に追加確認や事後レビューを行います。緊急であることだけを理由に独断で確認を省略しないでください。

逆に、通常の変更で「急いでいるから」を理由にチェックを飛ばすのは割に合いません。レビューの往復が増えると、待ち時間も含めて総作業時間が長くなる場合があります。通常の変更では、時間不足を理由に確認を省略せず、作業範囲に応じてチェックの粒度を調整する方が安全です。

実務例｜提出前に確認する順序を固定する

例えば業務システムの小改修をレビューに出す場面を考えます。レビュアーは実装の意図や確認範囲を最初から知っているとは限りません。変更の説明がない、範囲が広すぎる、テストの記録がないといった状況では、設計の適否を判断する前に質問が増えます。

そこで、①「何を・なぜ変更するか」を先に下書きし、②diffを先頭から確認し、③説明文を実際の変更・テスト結果に合わせて修正する、という順序を例として推奨します。説明文を先に書くことで、当初の目的から外れた変更が見つかりやすくなります。

チェック項目を細かく増やしすぎると、確認が形式的になりがちです。基本の5観点を使い、セキュリティや性能など変更の性質に応じて追加する方法が現実的です。

まとめ｜最初にやることは、出す前にdiffを1回通して読むこと

• 提出前の基本確認は、範囲・仕様との一致・異常系・テスト・説明文の5観点で始めます
• 変更は自己完結した1つの目的に絞り、100行前後を目安に、大きければ先に分けます
• 説明文には「何を変えたか」と「なぜか」を書き、見てほしい場所を1か所挙げます
• 緊急修正では組織の障害対応手順と承認を優先し、影響確認・必要なテスト・切り戻し方法を確認します

最初にやることは、次に出す変更で、依頼ボタンを押す前にdiffを先頭から1回通して読むことです。そこで修正漏れを見つけられれば、レビュー後の手戻りを減らせる可能性があります。

情報時点: 2026年11月13日時点の公式ガイドに基づきます。所属組織のレビュー規程がある場合は、その規程を優先してください。

参考資料

Google Engineering Practices：Small CLs、Google Engineering Practices：CL Descriptions（2026年11月14日確認）。