GIT PRレビュー観点チェック表(現場用)

 いいね、レベル4=「レビューできる・守れる」段階に入ってる 👍

ここでは**実務でそのまま使える「PRレビュー観点チェック表」**を渡すね。


PRレビュー観点チェック表(現場用)

※ 上から順に見ればOK
※ ★は特に重要(まずここだけ見てもレビューになる)


① 目的・前提(★最重要)

「このPRは何を解決するのか」

  • PRタイトルが作業内容を表している

  • PR概要に「なぜやるか」が書かれている

  • 影響範囲(どのページ / 機能 / 環境)が分かる

  • チケット・課題・要望と紐づいている

👉 ここが曖昧なら、コードを見なくていい

「このPRのゴールを一言で教えてください」


② 差分の粒度・構成(★)

「このPRは大きすぎないか?」

  • 1つの目的に対して1つのPRになっている

  • 無関係な修正(空白・整形・別機能)が混ざっていない

  • ファイル数・行数が妥当

  • レビュー可能な量か(5〜15分で読める)

👉 NG例

  • 機能追加 + デザイン修正 + リファクタ

  • 「ついでに直しました」


③ 影響範囲・壊れやすさ(★)

「戻せるか?壊れないか?」

  • 既存機能への影響が想定されている

  • 共通JS / 共通CSS / 共通コンポーネントを触っていないか

  • 既存の挙動が変わる点が明記されている

  • rollback(戻す)手段がある

👉 ディレクター視点の質問

「このPRをrevertしたら何が起きますか?」


④ コード・実装の妥当性

「今じゃなくて未来の人が困らないか」

  • 命名が意図を表している

  • 魔法の数値・ハードコードがない

  • 同じ処理をコピペしていない

  • コメントが「なぜ」を説明している

※ 書き方の好みではなく
**「保守性・再利用性・理解コスト」**で見る


⑤ 可読性・レビューしやすさ

「読む側への配慮があるか」

  • 不要な差分が含まれていない

  • フォーマットが崩れていない

  • PR内コメントで補足がある

  • レビュアーが迷わない構成

👉 良いPRの特徴

  • 「ここが一番見てほしいです」

  • 「この判断は○○の理由です」


⑥ 動作確認・検証

「本当に動くか」

  • ローカル / 検証環境での確認内容が書いてある

  • 確認URL・操作手順がある

  • edgeケース(スマホ / 古いブラウザ等)を考慮

  • 未確認点・不安点が明示されている

👉 完璧より正直さが大事


⑦ マージ判断(★)

「今マージしていいか?」

  • mainに入っても事故らない

  • 他PRと競合しにくい

  • 緊急度とリスクが釣り合っている

  • 必要なら「条件付きOK」にしている

よくある判断パターン

  • ✅ LGTM(問題なし)

  • ⚠️ 条件付きOK(後続PR前提)

  • ❌ 差し戻し(粒度 or 目的)


レベル4の人がよく使うレビューコメント例

  • 「目的は理解できました。影響範囲だけもう少し明記ください」

  • 「この修正、別PRに分けた方が安全そうです」

  • 「rollback時の影響を教えてもらえますか?」

  • 「急ぎ対応としてはOKですが、後続で整理PRを切りましょう」

👉 技術マウントはしない/判断軸を言語化する

コメント

このブログの人気の投稿

既存のページから逆算してみる「企画意図」「主要施策」「ビジネスゴール」「KPI(想定される)」

優秀なwebディレクターがgoogle analyticsでよく使う、使える機能、チェックする項目

既存のページから逆算してみる共通の「構成」「目的」「技術ポイント」