「小さいPRだし、サクッと送っちゃえばいいか」と思ったこと、ありませんか？😅
でも実は、小さなPRほど「なぜその変更が必要なのか」が伝わりにくい落とし穴があります。差分（diff）が数行でも、メンテナー（プロジェクトの管理者）がレビューしやすいかどうかは、まったく別の話なんですよね。
今回は、OSSへのPR（プルリクエスト）を送る前に使えるチェックリストをご紹介します。初めてOSSコントリビューションに挑戦する方にも、ぜひ参考にしてほしい内容です！
📋 なぜチェックリストが必要なのか
PRの「差分」はあくまで作業の結果に過ぎません。本当の作業は、メンテナーが「何を変えたのか」「なぜ安全なのか」「余計な変更が混じっていないか」を推測しなくて済む状態にすることです。
つまり、レビュアーの認知負荷を下げることが最大のゴールです。これを意識するだけで、PRの通過率がぐっと上がります。
✅ PR送信前のチェックリスト7選
1. コードを変える前にバグを再現する
まず「本当にバグが存在するか」を確認しましょう。再現できないまま修正しても、的外れな変更になりがちです。修正前の挙動を最小スクリプトで確認し、メモしておくのがおすすめです。
# バグ再現用の最小スクリプト例（Python）
# 修正前の挙動を先にメモしておく
def buggy_function(items):
# 空リストを渡すとIndexErrorが起きる（再現確認済み）
return items[0]["key"]
# 再現コード
buggy_function([]) # <-- IndexError: list index out of rangeこの「再現スクリプト」をPRの説明文に貼るだけで、メンテナーの理解速度が格段に上がります。
2. 変更範囲を最小限に絞る
「ついでにリファクタリングも…」はNG！バグ修正ならバグ修正だけ、typo修正ならtypoだけを変更しましょう。複数の目的が混在すると、レビュアーはどこに注目すべきかわからなくなります。
# ❌ NG：バグ修正のつもりが余計な変更が混入
def process(items):
result = [] # ← バグ修正と無関係なリファクタリング
for i in items:
result.append(i) # ← これも無関係
return result[0] if result else None # ← これが本来の修正
# ✅ OK：バグ修正だけに集中
def process(items):
if not items:
return None # ← この1行だけ追加するのが正解
return items[0]3. コーディング規約・スタイルガイドに従う
OSSプロジェクトには独自のコーディングスタイルがあります。PEP 8やBlack、flake8など、プロジェクトが採用しているツールを必ず確認しましょう。CONTRIBUTING.mdがあれば最初に読むのが鉄則です。
# よく使われるPythonのスタイルチェックツール
# flake8でスタイルチェック
# pip install flake8
# flake8 your_file.py
# blackで自動フォーマット
# pip install black
# black your_file.py
# isortでimport順を整理
# pip install isort
# isort your_file.pyツールを使えば機械的に統一できるので、スタイル違反のまま送ってしまうミスを防げます。
4. テストを追加・実行する
バグを修正したなら、そのバグが再発しないことを証明するテストを一緒に追加しましょう。「テストが通っていれば安心」という状態にすることで、メンテナーが変更を承認しやすくなります。
import pytest
from your_module import process
# バグ修正前は失敗していたテスト（回帰テスト）
def test_process_empty_list():
# 空リストを渡してもエラーにならないことを確認
result = process([])
assert result is None
def test_process_with_items():
# 通常ケースも壊れていないことを確認
result = process(["hello", "world"])
assert result == "hello"
# 実行方法: pytest test_your_module.py -v既存のテストも全部通っているか確認することを忘れずに！
5. コミットメッセージを丁寧に書く
コミットメッセージは「何をしたか」より「なぜしたか」を書くと格段に伝わりやすくなります。プロジェクトによってはConventional Commitsなどの規約を採用していることもあるので要確認です。
# ❌ NG：何をしたか「だけ」しか書いていない
git commit -m "fix bug"
git commit -m "update process function"
# ✅ OK：なぜ変更したのかが伝わる
git commit -m "fix: handle empty list in process() to avoid IndexError
Previously, passing an empty list caused an IndexError.
Added an early return of None when the list is empty.
Fixes #42"Issue番号（例: Fixes #42）を入れると、PRとIssueが自動でリンクされて便利です。
6. PRの説明文を充実させる
差分コードだけ送るのはNG。PRの説明文（description）には以下の情報を含めましょう。多くのプロジェクトにはPRテンプレートが用意されているので、それに従うだけでOKです。
## 変更の概要
空リストを渡した際のIndexErrorを修正しました。
## 変更の背景・理由
`process()`に空リストを渡すと`IndexError`が発生する問題がありました。
Fixes #42
## 変更内容
- `process()`に空リストチェックを追加
- 空リストの場合は`None`を返すように変更
## 動作確認
- [ ] 既存テストがすべてパスすること
- [ ] 新規テスト `test_process_empty_list` が追加・パスすること
## 再現手順（修正前）
```python
process([]) # IndexError: list index out of range
```「このPRを見た人が5分で全体を理解できるか？」を基準に書くと良いですよ。
7. ブランチとベースブランチを確認する
意外と見落としがちなのがどのブランチに向けてPRを出すかです。mainではなくdevelopやnextブランチに送るべきプロジェクトも多いです。また、自分のブランチ名がわかりやすい名前になっているかも確認しましょう。
# ❌ NG：ブランチ名がわかりにくい
git checkout -b fix
git checkout -b my-changes
# ✅ OK：何の修正かひと目でわかる
git checkout -b fix/process-empty-list-index-error
git checkout -b feat/add-retry-logic
git checkout -b docs/update-contributing-guide
# PRを送る前にベースブランチを確認
git log --oneline origin/main..HEAD # mainとの差分コミットを確認誤ったブランチにPRを送ると、クローズされてしまうこともあります。CONTRIBUTING.mdでターゲットブランチを必ず確認してください。
📝 チェックリストをまとめて使おう
7つのチェック項目をまとめると、以下のようになります。PR送信前にコピーして使ってみてください！
## PR送信前チェックリスト
- [ ] 1. バグを最小スクリプトで再現確認済み
- [ ] 2. 変更範囲が1つの目的に絞られている
- [ ] 3. コーディング規約・lintチェックをパス済み
- [ ] 4. テストを追加・既存テストもすべてパス済み
- [ ] 5. コミットメッセージに「なぜ」が書かれている
- [ ] 6. PRの説明文に背景・変更内容・確認手順を記載
- [ ] 7. 正しいベースブランチに向けてPRを送っている🚀 まとめ：小さなPRでも「丁寧さ」が信頼につながる
OSSコントリビューションは、コードの品質だけでなくコミュニケーションの質も問われます。1行の修正でも、このチェックリストを通すことで「このコントリビューターは信頼できる」という印象をメンテナーに与えられます。
最初は時間がかかっても、習慣にしてしまえばむしろ手戻りが減ってトータルの時間は短くなります。ぜひ次のPRから実践してみてください！💪
「初めてのOSSコントリビューションで何から始めればいい？」という方は、まずGitHubのIssueで「good first issue」タグを検索するのがおすすめですよ。
こちらも読まれています
📚 関連商品・おすすめ書籍
※本記事にはアフィリエイトリンクが含まれます。
PR
