レビューツールの活用

ストーリー

「レビューのコメントは上手く書けるようになってきたか？」

松本先輩がGitHub の画面を開きながら聞いた。

「はい、少しずつ慣れてきました。 でも、ファイル数が多いPRだと追いきれなくて......」

「ツールを上手く使えば効率が全然違う。 GitHub PRの機能やVS Codeの拡張機能を使いこなすことで、 レビューの質とスピードの両方を上げられるんだ」

GitHub Pull Request のレビュー機能

PRの基本的な画面構成

┌──────────────────────────────────────────┐
│  PR #123: ユーザー登録バリデーション追加  │
├──────────────────────────────────────────┤
│                                          │
│  [Conversation] [Commits] [Checks]       │
│  [Files changed (8)]                     │
│                                          │
│  ← この4つのタブを使い分ける             │
│                                          │
└──────────────────────────────────────────┘

差分の表示モード

Unified（統合表示）:
  変更前の行が赤（-）、変更後の行が緑（+）で表示
  → 小さな変更の確認に適している

Split（分割表示）:
  左側に変更前、右側に変更後を並べて表示
  → 大きなリファクタリングの確認に適している

レビューコメントの種類

1. 行コメント（Single Comment）
   → 特定の行に対するコメント。即座に投稿される。

2. レビューコメント（Review Comment）
   → Start a review で複数のコメントをまとめて投稿。
   → レビュイーへの通知が1回で済むため、推奨。

3. ファイルコメント
   → ファイル全体に対するコメント。

レビューの提出オプション

Suggested Changes（提案変更）

GitHub では、コードの修正案を直接提案できます。

```suggestion
function calculateTotal(items: OrderItem[]): number {
  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}
```

レビュイーは「Apply suggestion」ボタンで提案をそのまま適用できます。小さな修正に特に有効です。

GitHub PR のレビュー効率化機能

ファイルフィルタ

Files changed 画面で使えるフィルタ:

1. ファイル種別でフィルタ
   → .ts, .test.ts, .css などで絞り込み

2. Viewed チェックボックス
   → 確認済みのファイルをマークして折りたたみ
   → 大量のファイルがあるPRで特に有効

3. ファイルツリー表示
   → 左サイドバーでディレクトリ構造を表示

CODEOWNERS ファイル

リポジトリに CODEOWNERS を設定すると、特定のファイルやディレクトリの変更に対して自動的にレビュアーがアサインされます。

# .github/CODEOWNERS

# フロントエンドチームがフロントのコードをレビュー
/src/components/   @frontend-team
/src/pages/        @frontend-team

# バックエンドチームがAPIをレビュー
/src/api/          @backend-team
/src/services/     @backend-team

# セキュリティチームが認証関連をレビュー
/src/auth/         @security-team

# 全員がインフラ設定の変更を確認
/terraform/        @devops-team @tech-leads

PR テンプレート

.github/pull_request_template.md を作成しておくと、PRの品質が向上します。

## 変更の概要
<!-- この PR で何を変更したか、簡潔に説明 -->

## 関連 Issue
<!-- closes #123 -->

## 変更の種類
- [ ] 新機能
- [ ] バグ修正
- [ ] リファクタリング
- [ ] テスト追加
- [ ] ドキュメント更新

## テスト方法
<!-- レビュアーがどう検証すればよいか -->

## スクリーンショット（UI変更の場合）

## チェックリスト
- [ ] テストを追加・更新した
- [ ] ドキュメントを更新した
- [ ] 破壊的変更はない

VS Code でのレビュー

GitHub Pull Requests 拡張機能

VS Code 上で直接 PR のレビューが行えます。

主な機能:
├── PR一覧の表示とチェックアウト
├── 差分のインラインプレビュー
├── コメントの投稿・返信
├── Approve / Request Changes の実行
└── Suggested Changes の適用

GitLens 拡張機能

コードの変更履歴を可視化し、レビューの理解を深めます。

主な機能:
├── 行単位の blame 表示（誰がいつ変更したか）
├── コミット履歴のグラフ表示
├── ファイルの変更履歴
└── ブランチ間の比較

自動化ツールとの連携

リンターと整形ツール

スタイルに関する指摘はツールに任せましょう。

# .github/workflows/lint.yml
name: Lint
on: [pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint
      - run: npm run format:check

人間がレビューすべきこと vs 自動化すべきこと

自動化すべき（ツールに任せる）    人間がレビューすべき
├── コードスタイル               ├── ビジネスロジックの正確性
├── フォーマット                 ├── 設計の妥当性
├── 型チェック                   ├── 可読性と命名
├── リント警告                   ├── セキュリティの考慮
├── テスト実行                   ├── パフォーマンスの判断
└── 依存関係の脆弱性チェック     └── テストの十分性

まとめ

チェックリスト

• GitHub PR のレビュー機能（Comment/Approve/Request Changes）を使い分けられる
• Suggested Changes を活用できる
• CODEOWNERS の設定を理解した
• PRテンプレートの目的と書き方を理解した
• 自動化すべき項目と人間がレビューすべき項目を区別できる

次のステップへ

ツールの使い方を学んだら、次はチーム全体でのレビュー文化の構築について考えましょう。個人のスキルだけでなく、組織としてレビューを機能させる方法を学びます。

推定読了時間: 20分