これは思想の話ではありません。
私自身が複数の現場で何度も失敗を見てきた事実です。
この記事は「設計の話をやめろ」ではなく「設計をちゃんとやるために、レビューから切り離せ」というものです。設計について議論することはチーム開発においてとても重要なものです。
実体験：レビューが機能しなくなった瞬間
以前いたチームで、こんな流れがありました。
- 機能追加のPR（変更はそこそこ大きいが、仕様は単純）
- 実装者は事前に要件を確認し、期限内に実装
- レビュー開始
最初の指摘は妥当でした。
- 命名の微修正
- 条件分岐の簡略化
ところが、途中から流れが変わります。
「このクラス、そもそも責務分け間違ってません？」
「この設計だと、将来〇〇が入ったときに辛そう」
「レイヤー構造から考え直した方がいい気がします」
ここからPRは3日止まりました。
そのレビューで実際に起きたこと
- 実装者は設計を説明し始める
- レビューアは「理想の設計」を提示し始める
- 誰も「このPRをどうするか」を決めない
結果はこうです。
- 一部だけ直してマージ
- 「本当は良くないよね」という空気だけが残る
- 次のPRでも同じ議論が再発
設計も、レビューも、どちらも良くならなかった。
問題は設計ではなく「レビューに持ち込んだこと」
この経験で気づいたのは、設計の良し悪しではありません。
「レビューで設計を扱うと、必ず中途半端になる」
これが問題でした。
理由は明確です。
1. 実装コストはすでに発生している
コードを書いたあとに設計を否定されると、
議論は必ず「今さら戻れるか」という話になります。
結果、
本来やるべき設計改善は見送られ、妥協案だけが残る。
2. 設計議論は結論が出にくい
レビューは本来、Yes/Noを早く決める場です。
設計はそうではありません。
両者の性質が根本的に違います。
3. 心理的安全性が壊れる
この現場では、次第にこうなりました。
- 実装者は最小限しか書かなくなる
- レビューアは強い指摘を避ける
- 誰も設計の話をしたがらなくなる
一番まずい状態です。
「レビューで気づいたから仕方ない」への実体験からの答え
もちろん、実装を見て初めて問題に気づくことはあります。
私自身、何度もありました。
ただ、そのとき取るべきだった行動は、当時の自分がやっていたこととは違いました。
正解はどちらかです。
- この設計は致命的なので、このPRは止める
- 今回は割り切って通し、設計改善を別チケットに切る
レビューで設計の理想論を語ることではありません。
その後、このチームで変えたこと
同じ失敗を繰り返さないために、次のルールを決めました。
-
設計に関わる指摘は
- 「PRを止めるかどうか」まで言語化する
-
止めない場合、レビューではそれ以上設計を深掘りしない
-
設計の話は、実装前か振り返りでやる
これだけで、
- PRの滞留時間が減り
- レビューが短くなり
- 設計の話がむしろ前向きにできるようになりました
「それでも設計を指摘しないと腐る」
これはもっともです。
ただ、私の経験上、腐る原因は別にありました。
- 設計レビューの場が存在しない
- 実装前に相談する文化がない
- 設計の責任者が曖昧
これらを放置したままレビューで設計を殴ると、腐敗を遅らせるどころか、見えなくするだけでした。
例外について
以下は、レビューで止めるべきです。
- 明確な破綻構造
- セキュリティや安全性に直結する設計ミス
- 将来ではなく「今」壊れる設計
重要なのは、「設計が微妙」では止めないこと。
まとめ
この話は、設計を軽視したいわけではありません。
むしろ逆で、
- 設計をちゃんと扱いたいなら
- レビューという場から切り離すべき
という、かなり実務的な結論です。
コードレビューで設計の話が始まったら、
一度立ち止まって考えてみてください。
それ、本当に“今ここ”でやるべき議論でしょうか。
よい記事と思ったら、ぜひいいね、ストック、フォローをお願いします！
おすすめ記事