March 18, 2026

朝、コーヒーを淹れながら昨日のプルリクエストを見返していたら、同じような指摘を何度も繰り返していることに気づいた。「また変数名か」と思わず呟いてしまった。これは仕組みで解決すべきだと思い、今日は自分のコードレビュープロセスを見直すことにした。

まず最初にやったのは、レビュー観点の明文化だ。頭の中にあるチェックポイントを書き出してみると、意外と整理されていないことが分かる。僕の場合、こんな3段階に分けられた。

1. 機械的チェック（5分以内）

• [ ] CI/CDが通っているか
• [ ] テストカバレッジは基準を満たしているか（80%以上）
• [ ] Lintエラーはゼロか
• [ ] コミットメッセージは規約に従っているか

2. ロジックチェック（15分程度）

• [ ] エッジケースは考慮されているか
• [ ] エラーハンドリングは適切か
• [ ] パフォーマンス上の問題はないか
• [ ] セキュリティリスクはないか（SQL injection、XSSなど）

3. 設計チェック（必要に応じて）

• [ ] 既存のパターンと一貫性があるか
• [ ] 将来の拡張性は考慮されているか
• [ ] 責務の分離は適切か

午後、このチェックリストを実際に使ってみた。すると、以前は20分以上かかっていたレビューが12分で終わった。頭の中で「次は何を見るんだっけ」と迷う時間がなくなったからだ。

ここで一つ、よくある失敗について。僕も以前やっていたのだが、すべてのPRに対して同じ深さでレビューしてしまうことだ。typo修正に30分かけても意味がない。上記の3段階を、PR の影響範囲に応じて使い分けるのがコツだ。軽微な修正なら1だけ、機能追加なら1と2、アーキテクチャ変更なら全部、という具合だ。

夕方、チームメンバーに「こんなチェックリスト作ったんだけど」と見せたら、「これ、テンプレート化してPRコメントに使えそうですね」と言われた。確かに、GitHub のコメントテンプレートに入れておけば、レビュアー全員が同じ観点で見られる。早速 .github/PULL_REQUEST_TEMPLATE.md に追加しておいた。

今日あなたができる小さなタスク：
自分のレビュー時に毎回チェックしている項目を3つ書き出してみよう。それだけで、次回から少し迷いが減るはずだ。

チェックリストは一度作って終わりではなく、レビューを重ねるごとに更新していくものだと思う。「あ、これ毎回見てるな」と気づいたら追加し、使わない項目は削る。そうやって自分専用の道具に育てていくのが、長く使えるコツだと感じた。

#ハウツー #コードレビュー #開発効率 #チェックリスト #プログラミング