第6回となる今回は、いよいよGitHub開発サイクルの花形である 「Pull Request（プルリクエスト、通称PR）」 と 「コードレビュー」 について解説します。
なぜ直接マージせずに、わざわざ「レビュー」を挟むのでしょうか？それは、バグを未然に防ぎ、チーム全体の技術力を底上げする最大のチャンスだからです。

GitHub入門シリーズ全10回本記事は「GitHub入門」全10回のNo.6です。

No.1：Git/GitHubの基本概念とGitHub導入による投資対効果(ROI)
No.2：リポジトリとREADMEから始める
No.3：変更を確定！コミット実行とコミットメッセージの書き方
No.4：VS CodeでGitを使いこなすマージ・コンフリクト・便利機能
No.5：Issue（イシュー）でタスク管理
No.6：Pull Request（PR）とコードレビュー
No.7：ブランチ戦略の比較 Git Flow、GitHub Flow、GitLab Flow
No.8：GitHub Actions CI/CDで自動化
No.9：Code Scanning・Dependabot セキュリティの自動化
No.10：なぜGitHubが高パフォーマンスチームを作るのか

今回のゴール

良いPRを作成し、スムーズにレビュー依頼ができる
Draft PRとテンプレートを活用して手戻りを減らす
レビュー段階での修正により、後工程と比較して手戻りコストを1/10以下に抑える
心理的安全性を高めるレビューコメントの作法（must/imo/nits）を知る

Pull Request（PR）とは？

Pull Requestとは、自分のブランチで行った変更を、メインのブランチ（main）に 「取り込んで（Pull）ください」とリクエストする機能です。
この段階で他のメンバーがコードを確認（レビュー）し、問題なければマージ（統合）されます。

なぜレビューが必要なのか？（シフトレフトとROI）

第1回の記事（GitHub導入によるROI）でも解説した通り、バグ修正のコストは後工程になればなるほど指数関数的に増大します。これを防ぐために、品質管理を工程の「左側（上流）」へ寄せる考え方をシフトレフトと呼びます。

一般的に、バグ修正にかかるコストは以下のような「1:10:100の法則」に従うと言われています（出典：IBM Systems Sciences Institute等）。

設計・実装段階: コスト 1
テスト段階: コスト 10
リリース後: コスト 100（顧客対応、緊急パッチ開発、機会損失など）

リリース後の障害対応に比べ、PRでのコードレビュー（実装・テスト段階）でバグを発見できれば、修正コストを 1/10〜1/100 に圧縮できる計算になります。レビューは単なる品質チェックではなく、開発コストを劇的に下げるための投資なのです。

実践：良いPRを作成しよう

コードを書き、コミットし、GitHubへプッシュしたら、PRを作成します。
ただし、作成前に必ずやるべきことがあります。

1. 機械で分かることは「機械」に任せる

レビューは人間の時間を使う高コストな作業です。「インデントがずれている」「使っていない変数が残っている」といった指摘で時間を浪費するのは非常にもったいないです。

Linter（リンター）やFormatter（フォーマッター）といったツールを使い、静的解析で分かる指摘はPR作成前に排除しておきましょう。
レビュアーが「設計」や「ロジック」といった本質的な議論に集中できる環境を作ることが、良いPRの第一歩です。

2. PRの作成と「Draft PR」

GitHubのリポジトリページを開き、「Compare & pull request」ボタンの横にある ▼ を押し、「Create draft pull request」を選びましょう。

Draft PR（下書きPR）:
「まだ作業中ですが、方向性は合ってますか？」と早めに共有するための状態です。マージできない状態なので、安心して作りかけのコードを見せることができます。

3. PRの内容を書く（テンプレート活用）

レビュアーに「何を見てほしいか」を伝えるために、以下の機能を活用しましょう。

魔法の言葉「Closes #Issue番号」

PRの本文に Closes #1 や Fixes #5 と書くと、このPRがマージされた瞬間に、リンクされたIssueが自動的に完了（Close） します。

PRテンプレートの導入

Issueと同様、PRにもテンプレートを設定できます。
.github/pull_request_template.md というファイルを作成すると、PR作成時に自動で読み込まれます。

## 概要
Closes # 

## 変更内容

## レビューしてほしい点

## 動作確認

4. 依頼前の「セルフレビュー」が品質を決める

PRができたらすぐにレビュー依頼（Review Request）を出していませんか？
その前に一度、自分で自分のコードをレビュー（セルフレビュー） しましょう。

ケアレスミスの排除:
誤字脱字や、消し忘れたデバッグ用のコード（console.logなど）がないか確認します。これらを事前に直しておくだけで、レビュアーはノイズに邪魔されず、ロジックの確認に集中できます。
意図を伝えるコメント:
コードだけでは意図が伝わりづらい箇所（例：あえて複雑な処理をしている部分など）には、自分のPRに自分でコメントを入れておきましょう。
「ここは〇〇という理由で、あえてこう実装しています」と先回りして書いておくと、レビュアーの疑問が解消され、非常に親切です。
※レビュー時だけではなく恒久的に補足した方が良いものはコード上にコメントを残しましょう。

レビューにおけるコミュニケーション

レビュアー（見る側）も、レビューイー（見られる側）も、お互いに気持ちよく開発するための「作法」があります。

1. ラベル（Prefix）で温度感を伝える

コメントの冒頭に「ラベル」をつけることで、修正の強制力を明確にします。

must: 「必須」修正しないとマージできません。バグや重大な規約違反
- 例：「must: パスワードがログに出力されています。削除してください。」
imo: 「私の意見 (In My Opinion)」修正するかは任せます。提案や別案
- 例：「imo: この変数名は user_list の方が分かりやすいかも？」
nits: 「些細な点 (Nitpick)」修正不要ですが、気になった点。
- 例：「nits: ここの空行は不要かも。」
ask: 「質問」意図を確認したいとき。
- 例：「ask: なぜこのライブラリを選定したのですか？」

【Point: nitsへの対応】
nits や imo で修正不要と判断した場合でも、無視するのはNGです。
「今回は既存の実装に合わせます」「後ほど別PRで対応します」といったコメントを返すか、スタンプ（👍など）を押して、「読みました」という意思を伝えましょう。

2. 「なぜ？」を聞くチャンスにする

レビューは「指摘を受ける場」であると同時に、「先輩の技を盗む場」でもあります。
特に経験の浅いエンジニアは、ベテランの書いたコードに対して積極的にPRのレビューに参加しましょう。

「なぜここでこのパターンを使ったんですか？」
「もっとパフォーマンスが良い方法はありますか？」

単にバグを探すだけでなく、設計の意図や背景を聞くことで、育成スピードが飛躍的に向上します。

3. Suggested changes（修正提案）機能

「ここのコード、こう直して」と言葉で説明するのは大変です。
GitHubには、コメント欄で直接コードを書き換え、「提案（Suggest）」 する機能があります。

レビュアーが提案したコードを、実装者は ボタン一つでコミット（適用） できます。
お互いの手間が減る、非常に強力な機能です。

まとめ

今回は、開発プロセスの要であるPRとコードレビューについて解説しました。

静的解析: 人間にしかできないレビューに集中するため、Linter等は事前に済ませる
Draft PR & セルフレビュー: 未完成の状態から共有し、意図を補足して手戻りを防ぐ
シフトレフト: レビュー段階での修正により、手戻りコストを1/10以下に抑える
レビュー作法: must/imo/nits を使い分け、学習の場として活用する

次回は、チーム開発で避けては通れない 「ブランチ戦略（Branching Strategy）」 について解説します。
「Git Flow」「GitHub Flow」...いろいろあるけど、結局どれを使えばいいの？という疑問に答えます。