1. 導入：なぜDraft PRが必要なのか
開発現場において、機能実装が完了してからPull Request（PR）を作成していませんか？実装が終わってからのレビューでは、設計方針の根本的なズレが発覚した際に多大な手戻りが発生します。Draft PR（WIP PR）を活用することで、実装の初期段階からチームのフィードバックを得る「シフトレフト」の考え方を実践でき、手戻りを最小限に抑え、チーム開発のスピードと品質を劇的に向上させることが可能です。
2. 基礎知識：Draft PRとは
Draft PRとは、GitHubなどのプラットフォームで提供されている「作業中」であることを明示するための機能です。通常、PRを作成すると即座にレビュー依頼が飛ぶ状態になりますが、Draftモードで作成することで、以下のメリットが得られます。
・マージの誤操作防止：Draft状態の間はマージボタンが無効化されるため、未完成のコードが本番環境へ混入するリスクを物理的に防げます。
・早期フィードバック：コード全体が完成していなくても、実装方針やディレクトリ構成、API設計などを早い段階で共有し、レビューを依頼できます。
・CIの検証：Draft状態であってもCI（自動テストやリンター）は実行されるため、早い段階でコードの不備やビルドエラーを検知できます。
3. 実装/解決策：GitHub CLIを用いたDraft PRの作成
GUIから作成するのも手ですが、DevOpsエンジニアとしてはCLIでの操作を推奨します。GitHub CLI（gh）を使用すれば、ターミナルから素早くDraft PRを作成できます。
4. サンプルプログラム：GitHub CLIによるDraft PR作成コマンド
以下のコマンドは、作業中のブランチからDraft PRを作成するための実用的な例です。
作業ブランチをプッシュし、Draft PRを作成するコマンド
–draft オプションを付けることで、Draft状態として作成されます
gh pr create –title “WIP: 新機能のAPI実装” –body “設計方針の確認をお願いします。まだ未実装部分が多いです。” –draft
準備が整い、正式なレビュー依頼に切り替えるコマンド
PR番号（ここでは123）を指定して、Draftを解除します
gh pr ready 123
5. 応用・注意点：現場で陥りやすい罠と対策
Draft PR運用を成功させるためには、いくつか注意点があります。
・「Draft」のまま放置しない：Draft PRは「レビュー待ち」ではないため、レビュアーが気づかないことがあります。方針の相談が必要な場合は、チャットツール（Slackなど）で「この機能の設計について相談させてください」と明示的に通知しましょう。
・CIの過剰実行に注意：頻繁にDraft PRを更新するとCIが回り続け、コストやリソースを消費します。重要な変更のタイミングでプッシュするなどの工夫が必要です。
・マージ可能状態にするタイミングを明確に：Draftを解除（Ready for Review）する際は、必ず自分が意図した「レビュー可能な状態」になっていることを確認してください。
Draft PRは単なるステータス管理ではありません。チームの心理的安全性を高め、コミュニケーションを活性化させるための強力なツールです。ぜひ明日の開発から意識的に取り入れてみてください。
コメント