■ 1. 問題提起と背景
- コードレビューにおいて素通しでApproveしてしまう状況が多く発生している
- 思考停止でのApprove実施はレビュープロセスの形骸化を招く
- 主な要因として理解不足・権威への盲従・時間不足の3つが存在する
■ 2. ケース別対処法
- 正直理解できない場合:
- スキルセット不足による理解不能:
- 素直に質問コメントを残す
- 勉強不足を恥じる必要はない
- 質問により自身の知識増加と実装者の見直し機会創出という2つのメリットが得られる
- シニアエンジニアのコメントを観察し新たな視点を取り入れる
- PRの目的理解不能:
- 実装者の説明不足である可能性が高い
- チケットリンクや背景説明の追記を依頼し差し戻す
- 変更量過多による本質的変更の理解不能:
- PR分割を指摘することで適切なレビューを実現する
- 無理に全部読まずPR粒度の改善を求める
- 自分より知識がある人が実装している場合:
- 権威バイアスは即座に捨てるべきである
- 凄腕エンジニアでもタイポや削除漏れは発生する
- 高度すぎる複雑さは運用負債となる可能性がある
- 難しいと感じた場合は可読性向上を提案する
- レビュー時間を取ることができない場合:
- コードレビューは品質担保のための正式な業務である
- コンテキストスイッチコスト削減のためレビュー時間を固定化する
- 急ぎでなければ朝一番での実施が効果的である
■ 3. レビュー依頼側の心がけ
- タスク・実装の細分化:
- PR変更行数の最小化がレビュアーの心理的ハードル低下につながる
- 小さなPR複数回の方がトータルマージ時間は短縮される
- 機能追加とリファクタリングの分離など工夫が重要である
- 自己レビューの徹底:
- Files changedタブでの変更内容確認によりデバッグコード残存等を発見できる
- 実装時の判断理由をコメントとして事前記載する
- レビュアーの納得感向上と前提勘違いの早期発見につながる
- Descriptionに背景・目的・テスト結果等の証跡を明記する
- 実装者としての責任意識:
- 一番理解しているのは実装している自分であるという矜持を持つ
- レビュアー頼みではなく自信を持ってPRを出す
- 実装の端々に責任感の有無が現れる
■ 4. 現代のレビュー環境
- ツール活用による負担軽減:
- LinterのCI実行による文法チェック自動化
- PolicyAgentによる組織ルール遵守の自動化
- AIレビュー導入によるコスト削減
- ツールでコスト低減可能だが人間レビューで担保できる品質は必ず存在する
- AI進歩に伴う課題:
- 大規模PR増加による確認負荷上昇
- 意図不明のままPR提出されるケース発生
- AI盲信による品質低下リスク
- 人間レビュー対象と自動チェック対象の分離が必要
- 実装前の設計・方針レビューの重要性増大
- 思考履歴の言語化と記録が重要
■ 5. 結論
- わからないことを質問するのは恥ではない
- 間違いを指摘するのは失礼ではない
- 思考停止Approveを止め一言でもコメントを入れることから開始する
- 小さな一歩が自身とチームの成長につながる