学習2026年3月20日
コードレビューが怖い？チェックリストで自信を持とう
ゆめさくコードレビューが怖い？チェックリストで自信を持とう
エンジニアとして
チェックリストを
PRを出す前に自分でチェックする10項目
1. 不要なコードが残っていないか
console.logやデバッグ用のコードが 残っていないか - コメントアウトした
コードが 残っていないか - 使っていない
import文がないか - 未使用の
変数・関数がないか
これは
2. 命名は適切か
- 変数名・関数名・
コンポーネント名が、 内容を 正確に 表しているか - プロジェクトの
命名規則 （camelCase、PascalCase等）に 従っているか - 略語を
使いすぎて いないか（ usr→user、btn→button）
| チェック項目 | 悪い例 | 良い例 |
|---|---|---|
| 意味が | d | daysUntilExpiry |
| 真偽値か | check | isValid |
| 動詞で | userData | fetchUserData |
3. 関数の責務は1つか
1つの
- データの
取得と 表示を 1つの 関数でやって いないか - バリデーションと
ビジネスロジックが 混在して いないか - 50行を
超える 関数は、 分割を 検討する
4. エラーハンドリングは適切か
- API呼び出しに
try-catchが 書かれているか - エラー時に
ユーザーへの フィードバックがあるか - エラーを
握りつぶして いないか （catchブロックが 空でないか）
5. エッジケースを考慮しているか
- データが
空の 場合の 処理はあるか - nullや
undefinedの 可能性を 考慮しているか - 配列が
0件の 場合の 表示はどうなるか - 文字列が
極端に 長い 場合に UIが 崩れないか
レビュー文化のある
6. セキュリティ上の問題はないか
- ユーザー入力をそのまま
HTMLに 埋め込んでいないか （XSS対策） - APIキーや
パスワードが ハードコードされて いないか - 認証・認可の
チェックが 適切に 行われているか
7. パフォーマンスに問題はないか
- 不要な
再レンダリングが 発生して いないか （React） - N+1クエリ問題が
発生して いないか （バックエンド） - 大量の
データを 一度に 取得して いないか （ページネーション）
8. テストは書かれているか
- 新しい
機能に ユニットテストが 追加されて いるか - 既存の
テストが 壊れていないか - テストケースが
正常系と 異常系を カバーして いるか
9. UIは仕様通りか
- デザインカンプ
（Figma等）と 一致しているか - レスポンシブ対応ができて
いるか - ローディング状態、
エラー状態の 表示があるか - アクセシビリティ
（alt属性、aria属性等）が 考慮されて いるか
10. PRの説明は十分か
- 変更の
目的と 概要が 書かれているか - 動作確認の
手順が 書かれているか - スクリーンショットがあるか
（UIの 変更時） - 関連する
チケット/Issueへの リンクがあるか
レビューコメントの書き方
レビューする側のマナー
- 指摘ではなく
提案の — 「こう形で 書く すべきです」→「こうするとより 良くなると 思います」 - 理由を
添える — 「この書き方は 避けて ください」→「この 書き方だと XXXの 理由で 問題が 起きる 可能性があります」 - 良い
点も — 改善点だけでなく、「この伝える 設計は 良いですね」と 伝える ことも 大切 - 重要度を
示す —[nit]（些細な指摘）、 [must]（必ず修正）などのプレフィックスを 使う
レビューを受ける側のマナー
- 指摘を
個人攻撃と 捉えない - わからない
指摘は 質問する（ 「なぜそう すべきなのですか？」） - 修正したら、
何をどう 修正したか コメントで 伝える - 意見が
異なる 場合は、 根拠を 示して 議論する
チェックリストは「成長のツール」
この
最初は
ゆめさくエンジニアの
プロの
読みやすい
コードレビューで
チーム開発の
Git/PR/レビューの
エラーハンドリングの
本番環境で
ゆめさくエンジニアの
18ヶ月で
