プルリクエストとドラフトPRの違いを初心者向けに解説｜架空チーム開発で学ぶGitの使い方
概要
今回はGitのプルリクエスト（PR）について、通常のPRとドラフトPRの違いを初心者向けに紹介していきます。
「レビューしてもらうPR」と「まだ途中経過のPR」って、名前は似ているのに役割が全然違うんですよね。
自分も新人の頃は「完璧に実装が終わるまでPRなんて出しちゃダメだろう」と思い込んでいて、1つの機能を1週間も1人で抱え込んでしまったことがあります（- -;
そうならないように、架空のWebアプリ開発チームを例に、具体的な役職名を交えながら通常PRとドラフトPRをどう使い分けるのかを見ていきます。
それではやっていきましょう！
目次
そもそもプルリクエスト（PR）とは
プルリクエスト（Pull Request、略してPR）とは、「自分が書いたコードをメインのブランチに取り込んでほしい」とチームに提案する仕組みのことです。
GitHubやGitLabのようなサービス上で使われる機能で、単にコードをマージするだけでなく、次のような役割も持っています。
- レビューの場
- 他のメンバーがコードを見て、バグや改善点を指摘してくれる
- 議論の記録
- 「なぜこう実装したのか」というやり取りがコメントとして残る
- CI（自動テスト）の実行トリガー
- PRを作ると自動でテストやビルドが走り、問題があればすぐわかる
つまりPRは、1人で黙々と書いたコードを、チームの目に触れさせる最初の入り口なんですね。
通常PRとドラフトPRの違いを一言でいうと
ここが今回の本題です。
同じ「PR」という名前でも、GitHub上では2つの状態があります。
- 通常PR（Ready for review）
- 「実装が終わったので、レビューしてマージしてください」という完成品の提出
- ドラフトPR（Draft PR）
- 「まだ途中ですが、方向性が合っているか早めに見てほしい」という下書き段階の提出
見た目上は同じPR画面ですが、GitHub上でははっきり区別されています。
ドラフトPRにはグレーのアイコンと「Draft」というラベルが表示され、マージボタンも押せない状態になります。
うっかり未完成のコードをマージしてしまう事故を防げるんですね。
通常PRの特徴
- 実装・自己確認が完了している
- 動作確認やセルフレビューを終えた状態で出す
- レビュアーに正式に通知が届く
- 「レビューお願いします」という明確な依頼になる
- マージボタンが有効になる
- 承認（Approve）が付けばそのままマージできる
ドラフトPRの特徴
- 実装途中でも作成できる
- コード1行でもコミットしてあれば作成可能
- マージを誤操作で防げる
- Draft状態のあいだはマージボタンがグレーアウトされる
- 早い段階でフィードバックがもらえる
- 「この設計方針で合っていますか？」を実装完了前に確認できる
- CIは通常どおり動く
- テストやビルドは走るので、方向性チェックだけでなく品質確認もできる
ドラフトPRの一番のメリットは、実装を最後までやり切ってから「実は方向性が違っていました」と気づく事故を防げることです。
早めに軌道修正できるので、手戻りがぐっと減ります（^^
架空のチーム開発で見る具体例：タスク管理アプリ「タスクノート」
言葉だけだとイメージしづらいと思うので、架空のWebアプリ開発チームを例に、具体的な流れを追ってみましょう。
登場人物紹介
架空のタスク管理Webアプリ「タスクノート」を開発しているチームです。
- 田中さん（プロダクトマネージャー／PdM）
- どんな機能を作るか決め、要件をまとめる役割
- 佐藤さん（テックリード／TL）
- 設計方針を決め、メンバーのPRをレビューする役割
- 鈴木さん（新人フロントエンドエンジニア）
- 今回、新機能を実装するメインの担当者
- 山田さん（バックエンドエンジニア）
- API側の実装を担当し、鈴木さんと連携する場面もある
鈴木さんが新機能に着手する
ある日、田中さんから「タスクにラベル（色分けタグ）を付けられるようにしたい」という要望が来ました。
鈴木さんはこの機能のフロントエンド実装を任されます。
新人の鈴木さんは、「ラベル選択のUIをどう作ればいいか、自信がない」という状態でした。
ドロップダウンにするか、色付きボタンを並べるか、いくつか案はあるものの、佐藤さんの意見も聞きたいところです。
ドラフトPRを出すタイミングと理由
ここで鈴木さんが取った行動が、「完成を待たずにドラフトPRを出す」ことでした。
コマンド例（ブランチ作成〜ドラフトPR作成）
1 | git checkout -b feature/task-label-ui |
このドラフトPRには、次のようなメリットがありました。
- 佐藤さんが早い段階でコードを見られる
- 「ドロップダウンよりボタン形式の方がタップしやすい」とすぐコメントできた
- 鈴木さんが安心して手を動かせる
- 「まだ完成していないのに見せるのは恥ずかしい」という心理的ハードルが下がる
- 山田さんもAPI側の仕様をすり合わせやすい
- ラベルのデータ構造をどう持つか、実装途中の段階で相談できた
もしここでドラフトPRを使わず、完成するまで1人で抱え込んでいたら、佐藤さんの「ボタン形式の方がいい」というアドバイスをもらえるのは早くても数日後です。
実装をやり直す量も増えていたはずです！
ドロップダウン案とボタン案、両方の実装を同じブランチに含めたうえで1つのドラフトPRにまとめ、佐藤さんに見比べてもらう形にしています。
案の数だけドラフトPRを分けなくても、1つのPRの中で「どちらが良さそうか」を相談すると良いかもです。
実装が固まったら「Ready for review」に切り替える
佐藤さんのフィードバックを受けて、鈴木さんはボタン形式のUIで実装を進めます。
動作確認やセルフレビューも終わり、「これでマージしてもらえる状態」まで仕上がりました。
ここで鈴木さんは、ドラフトPRを通常のPR（Ready for review）に切り替えます。
コマンド例（Ready
1 | gh pr ready |
GitHubのPR画面上部にある「Ready for review」ボタンをクリックしても同じ操作ができます。
この時点でPRのラベルが「Draft」から外れ、正式にレビュー依頼が飛ぶ状態に変わります。
ここで押さえておきたいのは、新しいPRを作り直すわけではないという点です。
ブランチもPR番号もそのまま、ドラフト中にpushしていたコミットも含めて全部同じPRに残ります。
「Ready for review」は、既存のPRの状態ラベルをDraftから通常に切り替えるだけの操作なので、鈴木さんが改めてプルリクエストを出し直す必要はありません。
佐藤さんのレビューからマージまで
通常PRに切り替わったことで、佐藤さんに正式なレビュー依頼の通知が届きます。
佐藤さんはコードを確認し、いくつか軽微な指摘（変数名の修正など）を残したうえで、最終的にApprove（承認）します。
鈴木さんが指摘を修正してpushし、佐藤さんが再度確認してマージ。
これで「タスクにラベルを付ける機能」が無事mainブランチに取り込まれました。
ドラフトPRで早めに方向性を合わせていたおかげで、通常PRになってからの手戻りはほとんどありませんでした。
使い分けフローチャート
通常PRとドラフトPRをどう使い分ければいいか、フローチャートにまとめました。
「意見がほしいだけ」ならドラフトPR、「マージしてほしい」なら通常PR、という基準で判断すると迷いにくいですよ（^^
ドラフトPRを使うメリット・デメリット
最後に、ドラフトPRを使ううえでのメリットとデメリットを整理しておきます。
- メリット：手戻りを減らせる
- 実装の早い段階で方向性を確認できるので、大きな作り直しが起きにくい
- メリット：チームの状況が見えやすくなる
- 「誰が何に着手しているか」がPR一覧から把握できる
- メリット：相談のハードルが下がる
- 「完成してから見せる」より「途中で見せる」ほうが気軽に聞きやすい
- デメリット：PRの数が増えて見づらくなることがある
- ドラフトPRを整理しないまま放置すると、一覧が煩雑になる
- デメリット：チームでの運用ルールが必要
- 「いつドラフトPRを出すか」の認識がメンバー間でズレると効果が薄れる
デメリットは、チーム内で「小さい機能でもドラフトPRを出す」というルールを決めておけば、ほとんど解消できます。
最初は照れくさく感じるかもしれませんが、慣れると通常PRよりも気軽に使えるようになりますよ（^^b
まとめ
通常PRは「レビューしてマージしてほしい完成品」、ドラフトPRは「早めに意見がほしい途中経過」という違いがあります。
新人のうちは特に、完璧に仕上げてからPRを出そうとして1人で抱え込みがちですよね。
でも実際のチーム開発では、早めに小さくドラフトPRを出して、方向性をこまめにすり合わせる方が、結果的に手戻りも少なく早く進みます。
以上となります。
何事も3割くらい出来たら相談するとスムーズに進みやすい気がします（^^
それではお疲れさまでした。
