「コードレビューも通ったし、マージもされた。なのに本番でバグが出た。」
この状況、チーム開発をしていると一度は経験があるのではないでしょうか。
そして必ず浮かぶこの疑問。
これ、誰のせい？
書いた人？ レビューした人？
現場でよくあるこのモヤっとした話を整理してみます。
よくある「責任の押し付け合い」構図
バグが見つかった瞬間、チームの空気はだいたいこうなります。
-
実装者
「レビュー通ってますよね？」
-
レビュアー
「仕様通りに見えたんだけど…」
-
マネージャー
「なんで防げなかったの？」
ここで 「誰のせいか」 にフォーカスし始めると、だいたい不毛です。
なぜなら、コードレビューは“バグをゼロにする魔法”ではない からです。
コードレビューで見ているもの・見ていないもの
多くのチームで、レビュー時に見ているのは主に以下です。
- 可読性
- コーディング規約
- 明らかなロジックミス
- 既存仕様との整合性
- セキュリティ上の致命的な問題
逆に、見落とされやすいもの はこうです。
- 境界値・レアケース
- 実データ量での挙動
- 仕様書に書かれていない暗黙ルール
- 将来の変更を前提にした影響範囲
つまり、
レビューを通った = 正しい動作が保証された
ではない、という前提を
チーム全体が持っているかどうかが重要です。
「誰のせい？」ではなく「どこで防げたか」
個人的におすすめしたい考え方はこれです。
誰のせいかではなく、どこで防げたか
例えば：
- 実装時
- テストケースが足りなかった？
- レビュー時
- 観点が属人化していた？
- 設計時
- 仕様が曖昧だった？
- プロセス
- レビュー時間が足りなかった？
こう整理すると、
次に同じバグを減らす行動につながります。
CodeRabbitのようなAIレビューは「補助輪」
最近は CodeRabbit のような
AIコードレビューを導入するチームも増えています。
AIレビューの強みは、
- レビュー観点の抜け漏れを減らす
- 指摘のばらつきを抑える
- 人が疲れていても一定品質を保てる
一方で、AIにもできないことがあります。
- ビジネス仕様の意図理解
- チーム独自の暗黙知
- 「この変更、将来つらくならない？」という勘
だからこそ、
AIレビュー = 人の代わり
ではなく
AIレビュー = 人を助ける補助輪
として使うのが現実的だと感じています。
結論：バグは「チームの成果物」
コードレビューを通った改修でバグが出た場合、
- 実装者だけの責任でもない
- レビュアーだけの責任でもない
- ツールだけの責任でもない
チームのプロセス全体の結果 です。
そして一番大事なのは、
「じゃあ次はどうする？」
を冷静に話せる空気を作ること。
コードレビューは、犯人探しの場ではなく、学習装置。
そう捉えられるチームほど、結果的にバグは減っていくと感じています。