コードレビューに関してよく受ける質問への回答

"コードレビューが良いのは分かるが、時間がない。レビュー以外にもやることが多い。"

• コードレビューの講義を行う筆者が最も多く受ける上の質問への回答を整理

1. コードレビューにかかる時間を最小限にするため、著者（PR作成者）が努力しよう
2. 毎朝10分程度のスタンドアップミーティングをするように、午前30分、昼食後30分ほどの決まったレビュー時間を持とう
3. 品質と生産性：
   初期に投資すれば後半に発生するコストを著しく下げることができ、今後の変更コストを下げて生産性向上につながる
4. その他：
   時間が足りなければ、バグや障害など致命的な部分だけでも始めて、徐々に広げていこう。
   レビューにかける努力を組織で成果として認めよう

"今すぐ私たちが実行できる成長のための共有活動、品質向上を通じて生産性を高める手段としてコードレビューを実施してほしい。"

[coremaker]

コードレビューの時間を業務時間として認める文化が必要です。

非常にタイトな日程でトップダウンに降ってくる場合は打つ手がありません。あるいは、due date を決め打ちして仕事を振るような場合もそうです。

[cbk1411]

そういう会社の場合、全体的な文化がトップダウンである可能性が高いんですよね。
一つの業務だけ調整すればいい場合は比較的変えやすいのですが、全体の雰囲気となると経営陣がその気にならないといけないので難しいです。

業務量についての議論ができないなら、（残業で説得する過程を経て）文化を変えてみつつ、
1か月たっても変わらなければ別の組織・会社・業界を探すほうが効率的ではあります。
それ以上頑張ると、内面から崩れていく自分に気づくことになるんですよね。

（業界は SI、スタートアップ、大企業を分ける意図です。やること、仕事の進め方、チームメンバーとの関係がまったく違うと感じました。）