ぼくらは“普通”が違う世界にいる
「レビューでそんな言い方されたら、そりゃカチンと来るよね」
「いやいや、あれ向こうでは普通だよ。怒ってるわけじゃない」
こんなやり取り、海外チームとの仕事では一度や二度じゃありません。特に、C#×WPFでプロダクトの設計・UIアーキテクチャを任されるような立場になると、レビューコメントを書く側になることも増えてきます。ぼく自身、日本からフルリモートでオーストラリア・ドイツ・インド・アメリカのエンジニアと仕事する中で、レビューをめぐる文化差で何度もヒヤッとしたことがありました。
このブログでは「文化差を理解したうえで、グローバルなチームでも嫌われず、むしろ信頼されるレビューコメントを書くには？」というテーマで、ぼくの実体験や失敗談をもとに具体的なノウハウを共有していきます。今回はその第一章、“起”の部分として、「なぜ、レビューコメントひとつで誤解や軋轢が起こるのか？」という土台の話を掘り下げていきます。
◆ レビューで起きた小さな炎上
はじめてグローバルチームでPull Requestレビューをしたときのこと。ぼくは、日本で慣れた文脈で、「この変数名、ちょっと意味がわかりづらいですね。こうしたらどうでしょうか？」と軽い気持ちでコメントを書きました。
でも、それに対する返信はこうでした：
“Please explain why this name is unclear. This naming follows the XYZ convention.”
明らかにカチンと来てる感じ。チーム全体にも妙な空気が流れました。「しまった…」と感じたけど、なぜ怒られたのか最初は正直ピンと来なかったんです。
その後、別の先輩エンジニア（イギリス人）にこっそり聞いてみたらこう言われました：
“Your comment sounds indirect and subjective. In English-speaking cultures, it’s better to be concrete. Otherwise, it sounds like you’re doubting the author’s logic without offering facts.”
日本では「ちょっと○○かもですね〜」というのが柔らかい言い方。でも英語だとその“ぼかし”が逆に攻撃的に感じられるんだとか。レビューコメントひとつで、こんなにも解釈が変わるなんて、まさに文化の違いが出る場面だなと実感しました。
◆ なぜレビューで文化の違いが出やすいのか？
コードレビューって、実は**「フィードバック文化」そのもの**なんですよね。そして、この“フィードバック”という行為には、その国・その人の「コミュニケーションの前提」がモロに表れます。
例えば──
| 文化圏 | フィードバックの傾向 |
|---|---|
| 日本 | 空気を読む、間接的、否定より肯定重視 |
| アメリカ | 明確・直接的、意見の違いは歓迎される |
| ドイツ | 論理に厳密、結論から話す、妥協より正しさ |
| インド | 相手の上下関係を意識しながら調整的に対応 |
こうした背景がレビューコメントに滲むわけです。日本式で「ちょっと気になるかも」と書くと、「遠回しにダメって言ってるの？じゃあちゃんと理由を言ってよ」となる。逆に欧米式の「これは良くない。こうすべきだ。」という言い方は、日本人からすると「そんなに断定する？冷たくない？」と感じてしまう。
コードはグローバルだけど、フィードバックの作法はローカル。この矛盾が、グローバルチームのレビューで誤解が生まれやすい理由です。
◆ ぼくらが身につけるべき“翻訳スキル”
じゃあ、どうすればいいのか？
ぼくがたどり着いた答えは、「レビュー言語の文化翻訳者になる」ということです。
レビューでは、
- 書く側（＝自分）の文化的な癖を意識する
- 読む側（＝相手）の文化に合わせて調整する
この2つをセットで意識するだけでも、ずいぶんと空気が変わります。
例えば：
- ✖「ちょっと気になるかもですね」→ ✔「To improve clarity, I suggest renaming this to XXX because…」
- ✖「変数名が微妙」→ ✔「The current name might be misleading because it could imply YYY. How about ZZZ instead?」
どちらも同じことを言ってるけど、言い方が違う。それだけで相手の受け取り方がまるで変わるんです。
◆ “嫌われない”は“イエスマン”ではない
注意したいのは、「嫌われないレビュー術＝何でもYesと言うこと」ではないという点です。むしろ、信頼されるエンジニアはきちんと反対意見も言う。でも、それを「どう伝えるか？」が鍵。
つまり、コードの良し悪しではなく、“対話の土台”の作り方が重要なんです。
レビューは批判じゃない。共に良いプロダクトを作るための“対話”なんだ、と自分のマインドセットを変えた瞬間から、相手との関係も変わってきました。
レビューが“文化の橋”になる瞬間
◆ 文化差は「問題」じゃなくて「設計要件」
グローバルチームで働いてしばらくして、ぼくの中で大きな認識の変化がありました。それは：
文化差は「障害」じゃなくて「仕様」だ
ということ。
たとえばUIデザインでは、ユーザーの利用環境や習慣に応じて設計を変えますよね？ヨーロッパでは24時間表記を好むけど、アメリカではAM/PMのほうが親しまれている。だから「どっちが正しい？」ではなく、「どっちに合わせて設計する？」という発想になります。
レビューも同じ。相手の文化や言語に合わせて“設計”すればいい。そう思ったとき、レビューがストレスではなく、文化の橋渡しをするクリエイティブな作業に変わったんです。
◆ レビューで信頼される書き方５選
それでは、実際にぼくが使ってみて効果的だった**“文化の橋をかけるレビューコメント”の書き方５選**をご紹介します。すべてC#×WPFの開発現場で使った実例に基づいています。
① 「Why」から入ることで、感情より論理を共有する
✖ Bad
I think this needs to be changed.
✔ Good
Would you consider changing this logic? Here’s why: [理由]
It might cause issues in scenarios where the binding context is null.
Whyがないコメントは、「気分で反対してる」ように受け取られがちです。理由が書かれていれば、「この人はプロダクトのために言ってるんだ」と受け取ってもらえます。
② “I-message”で意見をパーソナルに伝える
✖ Bad
This is wrong.
✔ Good
I’m a bit confused by this implementation. Maybe I’m missing something—could you explain the intent?
英語圏では「断定」はとても強く響くので、“I think”や“I noticed”など、自分の立場から語るフレーズを入れるだけで、柔らかくなります。それでいて逃げている感じはなく、誠実な印象に。
③ 提案＋理由＋代案で、ネガティブ印象を減らす
✖ Bad
This naming doesn’t make sense.
✔ Good
I found the name slightly ambiguous. What do you think about
CustomerListViewModelinstead? It might better represent the data source here.
**“Not just criticism, but contribution”**が鍵です。代案を出せば、相手は「ダメ出しされた」ではなく「助けられた」と感じてくれます。
④ ポジティブなフィードバックを惜しまない
✖ Bad
（良い点には触れず、指摘だけ）
✔ Good
This overall structure is really clean and easy to follow. One minor suggestion regarding this section…
グローバルチームでは**“ポジティブなフィードバック”は貴重な通貨**。どれだけ忙しくても、良い点には一言触れるようにしています。それだけで、「この人は公平に見てくれている」と信頼を得られる。
⑤ 疑問形で“会話モード”を作る
✖ Bad
Use DataTriggers instead of code-behind.
✔ Good
Would it be possible to use DataTriggers here instead? It might help separate logic from the view more cleanly.
疑問形にするだけで、コメントが命令→提案に変わります。これは日本語でも同じですが、英語圏ではとくにこの「トーンの調整」が重要視されます。
◆ それでも、伝わらないときの“奥の手”
どれだけ工夫しても、うまく伝わらないときがあります。そんなときにぼくが最後の手段として使っているのが、「相手に任せる」スタイルのコメントです。
たとえば：
This is just a suggestion—feel free to ignore if it doesn’t fit your approach.
Up to you. I trust your judgement here.
これは、「ぼくの意見も一応置いておくけど、決定はあなたに任せます」というメッセージ。こういう余白があると、相手も構えずに受け取ってくれます。
◆ レビューは信頼を積み上げる行為
レビューで嫌われたくない…という気持ちは、多くの人が持っています。でも、本当に大切なのは「嫌われないこと」じゃなくて、「信頼されること」なんですよね。
そして、信頼は一夜では生まれない。毎回のレビューコメントが、信頼を積み上げるブロックになります。
ぼくが実感しているのは、
- 相手をリスペクトし
- 自分の文化のフィルターを通しすぎず
- 相手の文化を読み取って歩み寄る
という３つの姿勢があるだけで、レビューの空気がまるで違ってくる、ということ。
レビュー炎上の裏にある“言葉にならない摩擦”
◆ 言葉は丁寧だった。それでも、レビューが炎上した
レビューコメントをどれだけ丁寧に書いても、空気が悪くなることがある。それは、言葉の内容以外の部分＝非言語的な要素が影響しているからです。
たとえば以下のようなこと、心当たりありませんか？
- PRを出してすぐにレビューされず、何日も無視される
- チームによってレビューコメントがやたら短い or 長い
- Slackで「ちょっとこのコメント、きつくない？」と陰で言われる
- コメントに即レスしたのに「not responsive」と言われた
これらはどれも、文化差と非言語コミュニケーションのズレが引き起こしている“レビュー摩擦”です。
実はぼくも、この「非言語の地雷」を踏んで、レビュー炎上を経験しました。
◆ 実録：レビューが引き金になったチーム内“微ギス”事件
ある日、ぼくが提出したWPFのUIコンポーネントのリファクタPRに対して、イギリス人の同僚から即座に10件以上のレビューコメントが入りました。
それに対して、ぼくはすぐに対応・修正し、コメントにもすべて返答をつけてプッシュし直しました。
すると、その人からSlackでひとこと：
“It feels like you’re rushing changes without proper discussion.”
（なんか、議論せずに勝手に進めてる感じがする）
え？何がいけなかった？と思ったぼくは、逆にこう思いました：
「ちゃんと返事したし、変更理由も説明したし、全部改善したはずなのに…？」
その後、別のチームメンバーから「君のやり方、ちょっと急ぎすぎに見えるよ。彼は話し合いを大事にする人だから」と言われて、やっと気づいたんです。
“レビューは対話の始まり”と考える文化と、
“レビューは改善リストへの対応”と捉える文化の違いがあるということに。
ぼくの感覚では、「レビューコメントに対応したら、すぐに反映して次へ」が正義。
でも彼の感覚では、「ちゃんと会話してからマージに進む」ことが重要。
このズレが“勝手に直して強行した”という印象を生んでしまっていたのです。
◆ 非言語のレビュー文化の落とし穴
以下に、実際の現場でよく見られる**“非言語文化の違い”とその影響例**をまとめてみます。
| 項目 | 日本的な感覚 | 欧米的な感覚 | ズレによる摩擦例 |
|---|---|---|---|
| レビュータイミング | すぐレビュー・即対応＝誠意 | すぐレビュー＝せっかち／強引 | 「急かされた」と思われる |
| コメント量 | 細かく丁寧に＝思いやり | 長すぎ＝passive-aggressive | 「面倒くさい人だ」と思われる |
| 返信の頻度 | 1日1回まとめて返す | コメントごとに即レス | 「放置された」と感じられる |
| GitHubの👍 | 押さない（無言） | 押すことで合意・OK表現 | 無言だと「不満があるのか？」と誤解 |
| Slackでの確認 | DMは控えめ／全体チャンネルで質問 | DMで早めに聞いてくれた方が良い | 遠慮が“不透明”に感じられる |
こうしたズレは、どれも誰かが悪いわけじゃないんです。
ただ、認識のベースが違うから起こる。それを理解しておくだけで、レビュー摩擦はぐっと減ります。
◆ ズレを防ぐ「レビューの作法」４つの工夫
では、ぼくがその後実際に取り入れて効果があったレビュー・非言語コミュニケーションの改善策を４つ紹介します。
①「レビューは会話のスタート」マインドで臨む
コメントへの即対応ではなく、まずはコメントを一度まとめて読み込む→返事だけして、修正は次のフェーズに分ける。
これを意識するだけで「議論を経て進めてくれてる感」が出ます。
例：
Thanks for the feedback! Let me go through your suggestions and reply in detail before pushing any changes.
②「合意形成」のサインを意識して残す
欧米では「レビューはプロフェッショナルな議論」なので、合意や感謝のサインをきちんと残すと安心されます。
例：
Great point. I’ve applied the change as you suggested. Thanks!
👍
たったこれだけで、「あ、この人ちゃんと向き合ってる」と伝わる。
③ コメント・修正・Slackの“3点セット”で動く
コードレビューだけでやり取りせず、SlackやTeamsと合わせ技にする。たとえば：
- 「ちょっと意図が読み切れなかったんだけど、5分だけ会話できる？」
- 「今PRにコメントしたよ、時間あるときチェックお願い！」
といった軽いトリガー的なコミュニケーションが入ると、距離が縮まります。
④ ルールではなく「個別の習慣」を把握する
大事なのは、“文化圏”ではなく**“個人の習慣”**に注目すること。
たとえば：
- Aさんは通知を全部Slackで見る
- BさんはPRにラベルが付いてからしかレビューしない
- Cさんは午前中にしかレビューしない習慣がある
など、人ごとの“流儀”を観察しておくとレビューでスムーズに協働できます。
◆ グローバルレビューは“空気”じゃなく“信号”を読む
日本ではレビューも含めて“空気を読む”ことが多いですが、
グローバルチームでは空気ではなく“信号（signal）”を出す・読むことが大切です。
- コメントを書いたら、なぜそれを書いたか明確にする
- 変更を加えたら、合意形成のための一言を添える
- 忙しいときでも、短くてもいいからレスポンスを返す
こうした小さな“信号”の積み重ねが、相手との信頼を築いてくれるのです。
レビューは「信用を稼ぐ技術」
◆ “レビューのうまさ”が評価される時代へ
海外のIT現場で働いてみて実感したのは、コードを書く力と同じくらい、レビューする力が評価されるということでした。
コードレビューは、単なるチェック作業ではなく、チームの技術品質・雰囲気・スピード感を左右する“文化設計”の一部。
特にリモートやタイムゾーンが違うメンバーがいる場合、**レビューこそが「信頼の可視化ツール」**なんです。
では、海外で働く日本人エンジニアとして、どんな「レビューキャラ」を設計していけばよいのでしょうか？
この章では、ぼく自身が海外のプロジェクトを通じて編み出した「グローバルで信頼されるレビューキャラの作り方」をシェアします。
◆ キャラ設計1：あなたは「どのタイプ」のレビュアーでいたいか？
まず、レビューで“好かれる人”にはいくつかタイプがあります。
ざっくり分類すると、以下のようなキャラが国境を超えて信頼されやすいです。
| タイプ名 | 特徴 | 向いている人 |
|---|---|---|
| 🧠 ロジカル・タイプ | 論点を構造化して丁寧に伝える | 技術仕様や設計が得意な人 |
| 🌱 メンタリング・タイプ | 初学者にもわかりやすく教える | 優しさ・教育的視点がある人 |
| ⚙ プロダクト・タイプ | 技術だけでなくUXやビジネス視点を補完 | UI/UXや要件視点が得意な人 |
| 🔍 クオリティ・タイプ | 細部に厳しいが筋が通っている | テストや安定性に強い人 |
| 🔗 バランス・タイプ | どの視点も少しずつ押さえた全方位型 | チーム全体を見たい人 |
自分のスキルや性格に合わせて、“目指すキャラ”を意識するだけで、レビューの書き方や発言の仕方が定まり、「らしさ」が伝わるレビュー担当になっていきます。
ぼくはWPF UIアーキテクトという背景もあり、レビューでは**UI・UXと設計視点を絡めた“プロダクトタイプ”＋“ロジカルタイプ”**を意識してきました。
◆ キャラ設計2：「人のコードを見る姿勢」で信頼が決まる
レビューは、コードの良し悪しだけでなく、「人のコードにどう向き合っているか」が透けて見える行為です。
信頼されるレビュアーは、
- 「ちゃんと読んでくれてる」
- 「感情ではなく、目的のために見てくれてる」
- 「この人のコメントなら納得できる」
という印象を与えています。
そのために意識したいのは、レビューに“人格”を持ち込まない、でも“思いやり”は持ち込むということ。
たとえば：
This logic might be improved by extracting it into a helper method. What do you think?
I really like how you handled the binding here — super clean.
このように、意見と賞賛、提案と感謝をセットで出すことで、「この人は対立ではなく、協力の立場にいる」と自然に伝えることができます。
◆ キャラ設計3：時間差・言語差を超える“レビュー習慣”を作る
グローバルレビューにおいて、あなたの誠実さや配慮がちゃんと伝わるとは限りません。だからこそ、“伝わる設計”が必要です。
以下は、ぼくが実践しているレビュー習慣の一例です。
✅ PRレビュー時の習慣
- PR全体を一度通読し、「全体感コメント」を最初に置く
- テクニカル指摘 → 質問 → 提案 → 賞賛 の順にコメント
- 変更が微妙な場合は “just a suggestion” でやんわり提案
- 終わったら “Thanks again for the great work!” と一言つける
✅ PR作成者側の習慣
- Descriptionに「意図・背景・範囲外事項」を明記
- Draft状態で早めに出して“早期対話”を促す
- コメントをもらったら “👍 + 簡単な反応”でリアクション
- 最後に “Merged with all suggestions applied. Appreciate your input!” など締めの言葉を添える
こうした地味な習慣の積み重ねが、言語差・文化差・タイムゾーン差を超えて**“この人は信頼できる”**という評価を生んでいきます。
◆ 最後に：レビューは“翻訳”と“設計”の技術だった
「レビューがうまい」とは、技術に詳しいとか、英語が堪能だとか、それだけではありません。
ぼくがグローバルチームで学んだのは──
レビューとは、文化を翻訳し、信頼を設計する行為
だということです。
- 自分の文化を意識して
- 相手の文化を受け入れて
- 建設的で具体的に
- そして、誠実に
この４つをベースにすれば、あなたのレビューはただの“指摘”から、“対話”に変わります。
そしてその対話の積み重ねが、海外の現場であなたを“頼られる人”にしてくれるはずです。
✍️まとめ：海外レビューで嫌われずに信頼されるために
| ポイント | 実践例 |
|---|---|
| 文化差を理解する | 英語圏では「ぼかし」が攻撃的になることも |
| 内容だけでなく非言語面に注意 | レスポンスのタイミング・リアクションも信頼を左右 |
| 合意と貢献のサインを示す | 👍 や「Thanks!」を意識的に活用 |
| 自分のレビューキャラを設計する | “提案型” “賞賛型”など、自分のスタイルを持つ |
| 信頼は日々の習慣から生まれる | 「読んでいる」「考えている」を言葉で見せる |
次の一歩へ：あなたのレビュー文化を言語化しよう
最後に、おすすめのアクションがあります。
それは、「自分のレビューの指針（Review Philosophy）」を1枚にまとめておくこと。
たとえば：
- How I give feedback
- How I want to receive feedback
- My focus when reviewing
- My habits when responding
これがあると、転職・異動・グローバルチーム参加時に自己紹介代わりにもなりますし、自分自身の軸にもなります。
コメント