レビューは「指摘」ではなく「お互いの考えを共有する場」だと思った話

現場では、設計やコードのレビューが日常的に行われています。
品質を高めるはずが、実際の現場では「通すため」に形式を整えたり、「指摘するため」に細部を突いたりして、「これがレビュー…？」と思う瞬間がありました。
目的が共有されないまま始まるレビューや、背景を理解せずに指摘だけが並ぶレビュー。
声の大きい人の意見が通りやすく、他の意見が埋もれることもありました。
結果、作業者のストレスが増え、レビューの本来の意味とかけ離れていように思えたことが多かったように思います。
こうした経験を通じて気づいたのは、
レビューの本質は単に正誤を競うことではなく、
設計書をお互いに俯瞰しながらチーム全体で考えを共有し、品質を高める時間なのだということです。

レビューする側になって意識していること

現在はレビューする立場としてお仕事に関わっております。
過去の経験や書籍から学んだことも踏まえ、私は次の点を意識しています。

1. 背景や制約を確認する

レビューは間違い探しではなく、考え方の共有です。

• 「この構成を選んだ理由は何ですか？」
• 「この仕様はどの制約を前提にしていますか？」

背景を理解することで、意見のズレが自然に減り、単なる指摘ではなく建設的な議論が生まれます。

2. 仕様を理解してからレビューする

レビュー前に次の3点を確認しています。

a. 何を実現するための設計か
b. 想定ユーザー／利用シーン
c. 制約や背景（コスト・納期・運用など）

こうした準備を怠ると、レビューはその人の都合の良い好みの話になってしまいます。
準備をすることで、レビューは「通すため」ではなくチームの理解を深める場になります。

3. 目的とゴールを明確にする

レビューする側も準備は必要です。
何を見たいのか、どんな視点でレビューするのかを事前に共有するだけで、レビューの質は大きく変わります。

• 「今日は主に構成の妥当性と運用性を中心に見ます」
• 「目的は設計の方向性を確認することで、正誤判断ではありません」

こうして目的と視点を明示することで、上下関係や威圧的な雰囲気を避け、建設的な対話が生まれます。

4. 「どうすべき」ではなく「どう考えたか」を話す

「自分ならこう考えるかもしれませんが、どう思いますか？」
この一言で、相手の思考を閉ざさず、レビューが“指摘”ではなく“対話”に変わります。
書籍『なぜ重大な問題を見逃すのか？ 間違いだらけの設計レビュー』(参考URL)でも、

• 指摘は設計や判断に対して行い、人格を否定しないこと
• 目的とゴールの共有が重要であること
• 上下関係や威圧的な態度は自由な議論を阻害すること
  が述べられています。

私の経験とも重なりますが、本質は経験と学びを組み合わせてレビューを“意味ある時間”にすることだと感じています。

まとめ

過去にレビューを受ける側で感じた息苦しさを、今はレビューする側として少しずつ変えていきたいと思っています。

レビューは通過儀礼でも単なる指摘の場でもなく、お互いの考え・判断・背景をすり合わせる場です。

• 人格を否定せず
• 威圧的にならず
• 目的・ゴール・準備を明確にし
• 上下関係による圧力を避ける

こうした意識で臨むことで、レビューは「通すため」ではなく、チームの設計力とコミュニケーション力を高める時間に変わります。