背景
PMとしてコードレビューも担当しています。開発はオフショアで、レビューのやり取りがあまりにも多くなっていました。
そこで、細かいところは指摘しないことにしました。必要になったときに、AIですぐ直せるからです。結果、ラリーは10回から4回ほどに減りました。あとから直さなくても、意外と問題はありませんでした。
指摘しないこと
- 変数名や関数名の細かい好み
- 関数の分け方の粒度
- 小さな重複コードの共通化
ビジネスインパクトの小さい書き方の改善は任意にして、デリバリースピードを優先しています。テストコードは、テスト観点を満たしていればOKです。TODOコメントなども、基本的には書きません。
これらは、Claudeに持たせているレビュー観点に、除外項目として書いています。
必ず指摘すること
- テスト工数に影響するもの
- 意味なく既存の書き方から外れているもの
- セキュリティに関わるもの
- 意図が残っていない実装
意図は、コメントかPRに残します。
指摘の重要度を4段階に分ける
| 重要度 | 対応 |
|---|---|
| クリティカル | 必ず直す |
| ハイ | 必ず直す |
| ミディアム | 任意 |
| ロー | 任意 |
クリティカルとハイを直さないと、テスト環境に上げられる状態になりません。エンジニアには、ミディアムやローの修正に時間をかけず、こちらを優先してもらっています。修正の優先度を伝える手段としても役立っています。
まとめ
AIでリファクタリングのコストが下がったので、細かいところはレビューで捨てています。押さえるのは、テスト工数、既存の書き方、セキュリティ、意図の4つです。