はじめに

コードレビューで、同僚が何か説明しようとしたとき「いや、それは違って」と口を挟んでしまったことはありませんか？

私も昔はやってました。「話が長そうだな」と思うと、つい「要するにこういうことでしょ？」と先回りしてしまう。でも、それって相手からすると結構キツいんですよね。

今回は、レビューで「話を遮る」ことの弊害について書いてみます。特に、無意識にやってしまいがちな「遮り」がチームの信頼関係に与える影響を考えてみました。

ありがちな光景：それ、先に言ってくださいよ

よくある会話パターン

実装くん「ここの分岐ですが、データの取得元が複数あるので、それぞれの型を一度…」

詰問さん「それなら、共通化すればよくないですか？わざわざ分けて書く意味あります？」

実装くん「（あ、でも、共通化すると逆にAPIの補完で…）いえ、それはその、補完の挙動が…」

詰問さん「いや、でも共通で型定義すれば済む話ですよね？それに、以前もそうしてたと思いますけど？」

実装くん「……はい……そうですね……」

この会話、何が問題かわかりますか？

実装くんは最初から「複数の取得元があるから型を分けた」という説明をしようとしていたのに、詰問さんが話の途中で「共通化すればいい」と結論を押し付けています。

なぜ遮ってしまうのか

私の経験では、話を遮る理由って大体こんな感じです：

時間がもったいない

• 「この人の説明、長そうだな」
• 「見ればわかることをわざわざ説明されても」

自分の方が正しいと思っている

• 「明らかに間違った方向に向かってる」
• 「こうすればいいのに、なんで気づかないんだろう」

効率を重視している

• 「議論するより先に解決策を示した方が早い」
• 「黙っている時間がもったいない」

でも、これって全部「自分目線」なんですよね。相手がどう感じるかを考えていない。

遮られた側の気持ち

私も遮られた経験があるのでわかるんですが、話を途中で止められると：

• 「自分の意見は聞く価値がないんだな」と感じる
• 次から説明するのが嫌になる
• 「どうせ最後まで聞いてくれないし」と諦める

特にジュニアメンバーだと、「また遮られるかも」という恐怖で萎縮しちゃうんですよね。

遮らないレビューのコツ

まずは最後まで聞く

当たり前のことですが、これが一番大事。相手が話し終わるまで待つ。

言いたいことがあっても、メモしておいて後で話す。「途中ですが」って割り込むのは、結局遮ってるのと同じです。

質問で理解を深める

いきなり否定するのではなく、まず相手の考えを理解する：

• 「なるほど、その判断の理由を教えてください」
• 「他の選択肢も検討されましたか？」
• 「このアプローチのメリットはどこにありそうですか？」

沈黙を恐れない

レビュー中の沈黙って、実は悪いものじゃありません。相手が考えをまとめる時間だったり、次の説明を準備している時間だったり。

「間を埋めなきゃ」という焦りが、遮る原因になることも多いです。

実際にやってみた結果

私も意識して「最後まで聞く」を実践してみたところ、こんな変化がありました：

チームメンバーから

• より詳細な設計背景を話してくれるようになった
• 「実はこんな懸念もあって」という本音を聞けるようになった
• レビューの時間は少し長くなったけど、手戻りは減った

自分自身も

• 見落としていた観点に気づくことが増えた
• 「なんでこう書いたんだろう」という疑問が解消されやすくなった
• レビュー後の関係がギスギスしなくなった

遮ってしまったときは

それでも、つい遮ってしまうことってありますよね。そんなときは素直に：

「すみません、続きをお聞かせください。ちゃんと最後まで聞きたいです」

この一言があるだけで、雰囲気が全然変わります。

まとめ

レビューって、コードの品質を上げることが目的ですが、それ以前に「お互いの考えを共有する場」でもあります。

話を遮ってしまうと、技術的には正しいアドバイスをしていても、相手との信頼関係を壊してしまう可能性がある。

次回のレビューでは、「最後まで聞く」を意識してみてください。きっと、今まで見えなかった相手の考えが見えてくるはずです。