■ 1. レビュー疲れの背景と課題
- レビュー時間の急増: LLMの普及により、コードやドキュメントのアウトプット量と速度が大幅に増加した。しかし、必ずしも質が向上しているわけではなく、レビューに要する時間と疲労が増加している。
- 「他人を経由したプロンプティング」: 知識がないままLLMに生成を任せ、その結果をレビュー側に丸投げするケースが多い。レビュー側は、生成側より知識をつけた上でレビューする必要があり、非効率である。
- 自己レビューの欠如: 生成されたものを自己レビューしない、あるいはレビューしても見落とすケースが多発している。これは、自分の手で書いたコードではないため脳内キャッシュに乗らず、理解が追いつかないことが原因である。
- クソデカコミットの問題: LLMが試行錯誤を繰り返し、大きな単位でコードを上書きするため、既存の設計を無視した巨大なコミットが生まれやすい。適切なタスク単位への切り出しが困難である。
- インセンティブ構造の不一致: 生成側はLLMの利用でスループットを最大化しようとするが、レビュー側は質を担保する必要があり、レビューの速度は向上していない。このインセンティブ構造の違いが、レビュー疲れの主原因である。
■ 2. 対策と試行錯誤
- コーディングレビューでの対策:
- 1. 自己レビューの徹底: 生成したコードをGitHub上で他人のコードとしてレビューし、レビュアーとしてのマインドセットに切り替える。
- 2. ドキュメントドリブン開発: 要件定義、外部設計、作業計画書などをドキュメントとして実装と一緒にコミットする。これにより、コミットが大きくても意図が理解しやすくなり、不毛な議論を回避できる。
- 文章レビューでの対策:
- LLMが生成した文章をそのまま提出する人に対しては、LLMにエスカレーションの文言を作成させ、適宜マネージャーに報告することが有効である。
■ 3. 結論
- LLMの限界は人間の限界: LLMの能力はそれを使う人間の能力に規定される。
- 今後の展望: LLMを最大限に活用するためには、人間が主導してワークフローを構築し、LLMの限界を補完していく必要がある。現状はまだ手探りの状態が続いている。