なぜあなたの設計レビューは紛糾するのか

よくある光景

設計レビューで「こっちの方が良い」「いや、パフォーマンスが」「でも保守性が」と議論が迷走し、気づけば 1 時間が過ぎていた——多くの SE が経験するシーンです。

なぜこうなるのか。その構造的原因を理解すれば、対処できます。

原因 1：評価軸が共有されていない

「良い設計」には複数の軸があります。

• パフォーマンス
• 保守性・可読性
• 拡張性
• 開発コスト
• 運用コスト
• セキュリティ

参加者それぞれが別の軸を最重要視していると、同じ設計を見ても評価が正反対になります。

対処法：レビュー開始時に「今回は何を最優先するか」を明示する。「今フェーズは保守性と開発速度を最優先。パフォーマンスは現時点で非機能要件を満たせれば十分」のように。

原因 2：問題と解決策を混同している

「この設計にしたい」という提案者が解決策（How）から説明すると、聴衆は問題（What）を理解しないまま代替案を出し始めます。

NG の流れ：

1. 「キャッシュ層を追加する提案です」
2. 「Redis よりも Memcached の方がよいのでは？」
3. 「いや Nginx のキャッシュでいいのでは？」
4. …（元の問題が忘れ去られる）

OK の流れ：

1. 「現状：DBへの問い合わせが毎秒1000件を超え、レイテンシが劣化している（問題）」
2. 「解決策の選択肢は 3 つあります…」
3. 「今回は〇〇の理由でキャッシュ層追加を推奨します（根拠）」

問題を先に共有することで、「そもそも問題の捉え方が違う」という上流の食い違いを先に解決できます。

原因 3：意見と事実が混在している

「この設計は複雑すぎる」——これは事実か意見か。意見です。「100行のクラスが 3 つある」は事実です。

意見ベースの議論は水掛け論になりやすい。事実に変換する習慣をつけましょう。

対処法のまとめ

1. 評価軸の合意：レビュー前に優先軸を 1〜3 つ明示する
2. 問題先行：解決策より先に「何が問題か」を共有する
3. 事実と意見の分離：意見は「〇〇だと思う理由は△△（事実）」の形で表現する
4. 時間制御：「この論点には 10 分」と決め、ファシリテータが管理する

紛糾するレビューのほとんどは、これらのどれかが欠けています。構造を意識するだけで、同じメンバーでも議論の質は変わります。