はじめに

テキストレビューでは落ち着いて説明できていたはずの内容が、通話ではうまく言葉にできなくなることがある。
ドキュメント上では通ると思っていた設計も、口頭で説明しようとすると不安になってくる。
レビュー担当の一言に詰まってしまい、以降の会話がぎこちなくなる──。

リモート開発が一般化した今でも、リアルタイムで行われるレビューは少なくありません。
特に「常駐メンバーと顧客担当者」という関係では、
レビューは通話・画面共有による実質的な“対面”の場として頻繁に行われています。

この「対面レビュー」には、コードそのものよりも強く影響する空気や圧力があります。

想定されるレビューシーン

• ZoomやTeamsなどでの画面共有＋音声通話によるレビュー
• 社内や客先での対面でのレビューMTG
• コード設計の理由や背景をその場で問われるリアルタイムな応答シーン

こうした場では、チャットやPull Request上での指摘とは異なり、
表情・声のトーン・間（ま）・沈黙といった非言語の要素が強く作用します。
そのため、同じ言葉でも受け手への影響がまったく違うことがあります。

登場人物と立場

この2名のやりとりをベースに、レビューの場で実際に起きがちな失敗を描き出します。
批判や断罪を目的とせず、あくまでレビュー文化の健全なあり方を模索するための材料として扱います。

Case 1： どうしてですか？なんでですか？の弾丸詰問

会話：詰問から始まる対面レビューの萎縮

詰問さん「なんでこの書き方にしたんですか？なんですかこれ？こんな設計ありましたっけ？」  
実装くん「えっと……あの、今回は再利用の想定があったので、そのために…」  
--
詰問さん「ちょっ・・と再利用？どこで再利用する話なんてありましたっけ」  
実装くん「いえ、仕様上の記載はないんですが、前回のレビューで似た対・・」
--
詰問さん「今回の設計の話してるんですけど」
実装くん「・・応の汎用化が必要という話があったかと思いまして」  
--
詰問さん「それを踏まえての判断なら、ちゃんと記載すべきじゃないですか？ そもそも、どういう理屈でこれに至ったのか、きちんと説明できます？」  
実装くん「・・・えっ・・・と。。汗」

表面上は「質問」に見えても、そこに返答を引き出す“余白”がなければ、それはもはや対話ではありません。
詰問さんは明らかに説明を求めていますが、実装くんの応答はどんどん短くなり、視線はコードから外れていきます。

なぜ「詰問」になってしまうのか？

レビューアーにとっては、“確認のための質問”のつもりであっても、
相手にとっては“判断を否定された”ように聞こえることがあります。 特に以下のような要因が重なると、詰問に変質しやすくなります：

• レビュー時間が限られていて急いでいる
• コードの意図がすぐに読み取れずイラついている
• 以前の指摘が反映されていないと感じた
• 「なんとなく違和感」があるが理由を言語化できない

このような状態で出る「なんでこうしたんですか？」「どういう理屈ですか？」は、
質問というより“糾弾”に近くなるという点を理解する必要があります。

構造的な問題：意図の言語化が阻害される

詰問がもたらす最大の弊害は、実装者が言葉にすることを避け始めることです。

• 「どうせ説明しても聞いてもらえない」
• 「意図があっても、それを言語化するのが面倒になった」
• 「最終的に“正しい”形だけ提示されるなら、最初から従った方が楽だ」

こうした心理が積み重なると、表面的にはレビューで修正が進んでいるように見えても、
本来見えていたはずの「設計判断のプロセス」が共有されなくなっていきます。

「なんで？」の問い自体が悪いわけではない

設計の理由を問うこと自体は、レビューにおいて最も重要な観点のひとつです。
問題はその聞き方・切り出し方に、受け手が“裁かれている”と感じてしまう要素が含まれているかどうかです。

• 「意図を確認する」
• 「判断の根拠を聞く」
• 「他案との比較を依頼する」

これらはすべて“なぜ”を内包しますが、詰問になるとそれらを飛び越えて
「答えを探られる尋問」のような形になってしまいます。

詰問は、言葉ではなく態度として現れることが多いです。
自覚がないまま使ってしまうケースが非常に多いため、
録音やフィードバックによる振り返りが有効です。

レビューとは説明を引き出す場である

レビューの目的は「意図を暴く」ことではなく、「意図を共有する」ことです。
その第一歩は、相手が話しやすい空気を作ることに他なりません。

「なんで？」の一言を投げる前に、「何か背景があるのでは」と想像する。
その一呼吸が、レビューの対話構造を大きく変えます。

Case 2：意図的な「沈黙圧」

会話：何も言わず、しかし“圧”は放たれている

実装くん「あの、ここはAPIの戻り値の構造が少し特殊でして……そのまま扱うと画面側の表示と噛み合わないところがあったので、前処理を一段挟むようにしました」
詰問さん「……」
--
実装くん「……えっと、その、設計ドキュメント上は明記してなかったので、現物見てから調整した、という流れになります」
詰問さん「……」
--
実装くん「……（な、なにかまずかっただろうか……）」

沈黙は言葉ではありません。しかし、対話の流れの中に現れる沈黙は、非常に強い意味を持ちます。

この例では、詰問さんは何も言っていません。
でも、実装くんの側には「責められている感覚」や「不正解を出したような不安」が生まれています。

なぜ「沈黙」はこんなに怖いのか？

沈黙そのものは悪ではありません。
考えるための余白としての沈黙や、相手の話を待つための静寂は必要なものです。
しかしレビューの文脈では、「意見を返さない」ことが否定の合図と取られやすい構造になっています。 とくに以下のような状況が重なると、沈黙は「圧」として認識されます：

• 相手が顧客や上位の立場である（反論しづらい構造）
• 問題提起の直後に沈黙する（返答を試されている空気になる）
• 表情やジェスチャーが一切なく、ただ黙っている（感情が読めない）
• 通話・画面共有など対話の逃げ場がないリアルタイム状況である

「間」と「圧」は紙一重

実装くんのような立場から見ると、「自分が間違っていたのでは」という不安が沈黙中に膨らんでいきます。
そして沈黙のあとにコメントがあったとしても、すでに心理的には「防御モード」に入ってしまっている。

レビューの意図が改善提案であっても、相手が「否定されている」と感じた時点で、それは圧です。

::tip 自分が沈黙している時間、相手はどう感じているか。
「何かを引き出そうとしてるだけ」という認識で止まっていないか、振り返ってください。 :::

沈黙が積み重ねる設計への不信

実装くんのような立場で、何度も「沈黙されるレビュー」を経験すると、以下のような行動変化が起きやすくなります：

• 説明より先に謝るようになる（反射的防御）
• 言われそうな選択肢だけ選ぶようになる（本来の設計意図が失われる）
• 「正解を探す設計」になりやすくなる（問いへの備えが優先される）

このような変化は、個人の成長だけでなく、設計判断力を持った人材の定着や信頼形成を阻害することになります。

無意識のうちに“場を支配している”ことがある

レビューにおける発言力は、単に発言数や声の大きさで決まるわけではありません。
言葉を使わない沈黙や視線すらも「力」になります。

そしてそれが意図せず「支配的」に働くと、対話の対称性は失われ、
レビューが単なる確認作業や指導の場へと変質していきます。

レビューとは、設計上の判断と意図を相互にすり合わせていく作業です。
黙っている側が無意識のうちに“正解の審判”の位置に立っていないか、常に問い直す必要があります。

黙るなら、安心させて黙ろう

レビューで黙るとき、意識してほしいのは「黙ること」ではなく、その沈黙が相手にどう届いているかです。

• 考えている最中なら、それを一言添える
• 伝えるべきことがまとまらないなら、「後でコメントします」と言う
• 相手に話させたいなら、「お考えがあれば聞きたいです」と明示する

黙る自由はあります。しかし、黙る責任もあります。
その静けさが、委縮を生まない余白として機能するように、レビューの設計を見直していきましょう。

Case 3：「わかってるけど聞く」 - 理解度テストはレビューに不要

会話：質問ではなく、“試されている”と感じる瞬間

実装くん「ここは、条件ごとにAPIを分けずに、共通の引数を渡して切り替えるようにしています」
詰問さん「それってHTTPメソッドに対して動的に処理分岐する意図ですか？」
--
実装くん「はい、そうです。PATCHとPUTの両対応を一つにまとめてます」
詰問さん「確認ですけど、RESTの設計原則的に許容されると思ってます？」
--
実装くん「……一応、冪等性の担保と目的の明確化は意識したつもりです」
詰問さん「理解できてます？」

この会話のポイントは、詰問さんは既にその意図を理解しているという点です。
にもかかわらず「確認ですけど」と言いながら、“その意図を実装くんがちゃんと分かってやってるか”を探るような言い方をしています。

なぜ「わかってるけど聞く」が信頼を削るのか？

レビューアー自身がすでに理解している内容を、あえて確認の名目で質問するのは、
「ちゃんとわかってるかどうか、説明してごらん？」というトーンになりやすく、説明の中身より“説明させる構造”が主語になってしまいます。

これにより、実装側は次のような反応になりやすくなります：

• 「ちゃんと答えなきゃ」モードに入り、判断意図の本質より説明の正しさに意識が向く
• 「わかってるくせに聞いてるな…」と感じ、心理的な距離が生まれる
• 「ミスではなく説明の浅さで評価されている」感覚が残る

「確認なんですけど」が持つ評価性

「確認させてください」は丁寧な言葉ですが、
レビューの立場でこれを多用すると、“試験官の確認”に聞こえやすい点に注意が必要です。

特に、自分が質問の意図や正解をすでに持っている状態で使うと、

• 質問自体が“答え合わせ”の空気になる
• 相手が正しく答えるまで黙る構図になりやすい
• 正答しても「じゃあ最初からそう言えばいいのに」と評価が生まれにくい

という流れになりやすく、結果的に相手にとっては「試された場」として記憶に残ります。

実装くんは、ちゃんと分かってる前提で話を始める

レビューで最初に意識したいのは、相手はちゃんと考えて設計しているという前提に立つことです。

実装が荒い場合や、意図が読み取りにくい構造になっていたとしても、
それはコードやドキュメントの問題であって、本人の理解を試す構造で補うべきではありません。

確認が必要な場合も、それがレビューアー側の理解補完のためであることを明示すれば、
相手の反応も自然な対話になります。

レビューは対話であって、試験ではない

レビュー中、「この人、ちゃんとわかってやってるのかな？」と思うことは当然あります。
でもそのときこそ、レビューアーとしての問いの設計力が問われます。

「わかってるけど聞く」という行動の裏には、
「本当は自分も少し不安」「説明を受けて安心したい」というレビューアー側の心理があることもあります。

その不安を、相手を試す形ではなく、自分の理解補完として素直に聞ける構造をつくる。
それが、“相手を信じる前提の対話”にする第一歩です。

あとがき

「なんでそうしたの？」「（沈黙）」「……え、それって昔の仕様無視してません？」
こんなやり取り、思い当たる節がある方、いらっしゃったりしませんか？

レビューで何気なくやってることでも、受け手の立場になると実はまあまあ圧が強いというケース、案外多いんですよね。
詰問する気はなかったのに、ただちょっと気になって聞いただけのはずが、なぜか空気が重くなってしまう──
あれ、自分だけじゃなかったんだ…と感じていただけたら、この記事の役割はほぼ果たせたと思っています。

今回取り上げた内容は「レビューの技術」ではなく「レビューの態度」の話でした。
設計指摘の正しさや設計方針の合意以前に、
場の空気や聞き方ひとつで、コードの説明ってめちゃくちゃ難しくなるんですよね。

まだ「沈黙圧なんて知らんし、普通に考える時間でしょ」という方は、
次のレビューでぜひ3秒以上の沈黙を入れて相手の目の動きを観察してみてください。
びっくりするほどそわそわします。たぶん。

今後も「レビューの場で地味にやりがちなこと」を取り上げていく予定ですので、
「これは自分のことかも？」と思いながら軽く読んでいただけたら嬉しいです。

コードレビュー、するのもされるのも、ほんと気を使いますね。