Slackの雑談から始まった信頼の種
海外で働きはじめて半年くらい経った頃、Slackの画面を開くのが少しだけ怖くなくなってきた。
最初の数カ月は、通知がピコンと鳴るたびに心臓がドクンと反応してたんですよ。英語のスレッドを開くと、文字がビッシリ並んでて、「これ…今すぐ返事できるやつ？」と一瞬固まる。でも慣れってすごいもので、相変わらず速読は苦手でも、「とりあえず開こう」というメンタルにはなってきた。
そんなある日、Slackの雑談チャンネルで誰かがランチの写真を上げたんです。
カレーの写真。コメントは “Too spicy for me! 🌶️” 。
僕、つい「I like spicy!」って返したんですよ。いつもなら業務連絡以外はROM専（読むだけ）だったのに、その日はなぜか気が緩んでた。すると、別の同僚から「Oh, you should try the Indian place next to the office!」っておすすめが飛んできた。そこから「いや、辛すぎるのは無理」とか、「でも日本のカレーは甘いんだよ」みたいな会話が3〜4人で展開。英語はめちゃくちゃだったと思うけど、意外なほど盛り上がった。
その小さなやり取りが、のちに設計レビューで僕の発言を受け止めてもらえる空気づくりにつながるなんて、そのときは思いもしなかった。
英語が苦手でも、雑談はできる？
海外で働きはじめたばかりの頃、「英語の壁」って9割は業務英語のことだと思ってたんですよ。
でも実際は、仕事の英語以上に、雑談とかちょっとしたツッコミのほうがハードルが高かった。なぜなら、雑談ってスピードが速いし、予想できない話題がポンポン飛んでくる。専門用語は辞書で引けるけど、突然「昨日の試合見た？」とか「そのTシャツどこで買ったの？」って言われたら、頭の中が真っ白になる。
僕がいたチームは、エンジニア8人中5人が英語ネイティブ。あとの3人は僕を含めて非ネイティブだけど、みんな英語力は僕より全然高かった。
だから最初の頃は、Slackで雑談スレッドを見つけても「見なかったことにしよう」とスルーしてたんです。だって、入ってもついていけないし、無理にコメントして変な空気になるのも怖いから。
でも雑談が「信頼の入り口」だった
転機になったのは、さっき話したカレーの写真事件。
あの時、思い切って「I like spicy!」って一言打ったのは、英語的に正しいかどうかを考える前に、とにかく反応したくなったからだった。
結果として、それがきっかけで「この人、冗談も言えるんだな」みたいな印象を持ってもらえたらしい。
数日後、コードレビューのときに、ある同僚が僕の提案を真剣に聞いてくれたんですよ。
以前なら、僕が意見を出すと「Hmm… maybe later.」で終わることも多かったのに、その日は「Tell me more about this design choice.」と深掘りしてくれた。
正直、その提案が受け入れられた理由は技術的な部分だけじゃなく、「あのカレー好きの人」というちょっとした親近感もあったんじゃないかと思う。
信頼は英語力だけで築けない
この経験から学んだのは、
信頼って、英語の流暢さだけで決まらない ということ。
もちろん、スムーズに会話できるに越したことはない。でも、チームメイトが「この人と話しやすい」と感じれば、英語が完璧じゃなくても話を聞いてくれる土台は作れる。
しかもこれは、非ネイティブだからこそ使える武器でもある。
僕がカレーの話で笑いを取ったように、文化や食べ物の違い、ちょっとした日常ネタを武器にすれば、むしろ「面白い視点を持ってる人」として覚えてもらえる。
英語をペラペラにするよりも、こうした「言葉以外の要素」で信頼を作るほうが、実は即効性があるんじゃないかと感じた。
このあと、英語の壁をどう超えたのか？
雑談で生まれた小さな信頼は、その後の設計レビューやチーム内のディスカッションで大きな効果を発揮する。
でも、それだけじゃ「壁」は越えられない。
僕にはまだ、「レビューの場で正しく意図を伝えられない」という大きな課題が残っていた。
次のステップは――
言葉に頼らないコミュニケーション設計。
英語力で勝負するのではなく、UIや図、プロトタイプを使って相手に「見える形」で伝える方法を編み出すことになる。
言葉じゃなく“見える形”で勝負するレビュー戦術
Slackの雑談でちょっとした信頼の土台ができたとはいえ、
レビュー会議の場に座ると、やっぱり英語の壁は立ちはだかってきた。
会議の形式はだいたいこんな感じだ。
- 僕が新しい設計や機能案を説明する
- チーム全員が質問や懸念点を投げる
- 最終的に「OK」か「修正」かが決まる
問題は、2 の部分だった。
ネイティブ勢の質問は容赦ない。しかも一度に2つ3つと飛んでくることもある。
こっちは一つ目の質問の意味を理解しようと必死になっているのに、二つ目の質問はもう次の議題に進んでいる。
で、結局「Sorry, could you repeat that?」と2回くらい聞き返す。すると場がちょっと止まってしまって、なんとなく気まずい空気になる。
言葉で戦うのは限界だ
何回かそんなことを繰り返して、僕はハッキリ悟った。
「この戦場で、言葉だけで勝負するのは無理だ」
もちろん英語力を上げる努力は続けていたけど、同時に別の武器が必要だった。
相手の質問の意図を100%聞き取れなくても、こちらの考えを確実に届けられる方法。
それが―― “見える形で伝える” ことだった。
WPFエンジニアの特権を活かす
僕はC# WPFを使って設計開発をしている。
これ、UIのモックアップや簡単なプロトタイプをすぐに作れるのが強みなんですよ。
ある日、レビューに臨む前に、説明用のスライドだけじゃなくて、2パターンのUIモックを準備してみた。
1つ目は「今まで通りの設計案」。
2つ目は「今回提案する新しい設計案」。
それぞれスクリーンショットにアニメーションGIFをつけて、ボタンを押したときの動きや画面遷移が一目で分かるようにした。
“見せる”レビューの威力
当日、レビューが始まると、案の定ネイティブ勢が質問を投げてきた。
でも今回は、口で説明する前に、モックのGIFをSlackのスレッドにポンッと貼った。
すると「ああ、なるほどね」と一瞬で理解してくれる。
そのあとは「じゃあこの部分のデータバインドはどうなってる？」みたいに、話が具体的になった。
このやり方の良いところは、
- 英語での説明が多少ぎこちなくても、UIを見れば意図が伝わる
- 相手も質問しやすくなる
- 会議の流れが止まらない
という点だ。
まさに**“言葉以外のUI”**でコミュニケーションを補った瞬間だった。
“質問を予測して潰す”設計ドキュメント
さらに慣れてくると、僕は「質問を予測して先回りで答える」というスタイルに進化した。
レビュー前にSlackで「Design Preview」というスレッドを作り、そこに図やGIFを貼っておく。
添える文章は短くてOK。
例：
Here are two design options for the new filtering feature.
Option A: keeps the current search UI, Option B: adds real-time filter.
Looking forward to your feedback in tomorrow’s review.
これをやると、会議当日にはすでに何人かがコメントを入れてくれている。
質問の半分くらいは事前に解決しているので、当日の議論は核心部分だけに集中できる。
「英語がうまい人」より「設計が伝わる人」に
この方法を続けているうちに、ある変化が起きた。
レビューの場で僕が英語をつっかえても、誰も気にしなくなったんです。
なぜなら、設計意図はドキュメントやモックでクリアに伝わっているから。
逆に、英語は流暢でも準備が甘い人は、質問の嵐で時間を取られることもあった。
僕はこのとき初めて、
「あ、英語力よりも“設計をどう伝えるか”のほうが重要なんだ」
という実感を持った。
信頼が「発言の後押し」に変わる
さらに、雑談で築いた親近感と、この“見える化レビュー術”が組み合わさることで、もう一段階状況が良くなった。
会議中、僕がまだ説明し終わってないのに「Wait, let him finish.」と同僚がフォローしてくれるようになったんです。
以前の僕なら想像もできなかった光景。
信頼が「遠慮なく発言できる空気」に変わっていった瞬間だった。
次は“非ネイティブならではの強み”へ
言葉に頼らず設計意図を届ける方法は、僕にとって大きな武器になった。
でも、それはあくまで“防御”の側面が強い。
次は、非ネイティブだからこそ持っている視点や発想を“攻め”に変えていくステージに進むことになる。
非ネイティブ視点を“武器”に変える瞬間
設計レビューで「言葉に頼らず伝える」戦術を使いはじめて数カ月。
会議でつっかえても笑って流してくれる空気ができ、レビューも通りやすくなった。
正直、この時点で僕はかなり満足してたんですよ。
「英語が苦手でもやっていける」っていう安心感があったし、精神的にも余裕が出てきた。
でも、ある日ふと気づいたんです。
このままだと、僕は**“英語が苦手だけど頑張ってる人”**で止まってしまう。
チームにとって「必要不可欠な人」になるには、もっと違う武器が要る。
きっかけはUIの違和感
あるプロジェクトで、新しいフィルター機能のUIを作ることになった。
最初の設計はネイティブの同僚が担当。レビュー用に出てきたモックを見て、僕は即座に違和感を覚えた。
「これ、日本のユーザーなら絶対迷うやつだ…」って。
理由は単純で、フィルターボタンの位置とラベルの表現が、アジア圏のUI慣習とズレていた。
例えば、日本や中国では検索バーの横にある小さいアイコンで条件を開くUIが多いけど、その案では画面の右下に大きく配置されていた。
これだと、ユーザーは「ここにフィルター機能がある」と直感的に思えない。
「それは文化的なUI差だよ」
そのレビューで僕は、英語の文章を一度頭の中で組み立てながら、思い切って言った。
“I think Japanese users might not recognize this as a filter button. The position and size are very different from what they usually see.”
一瞬、沈黙。
あ、やばい、空気止まった？と思ったら、リードデザイナーが興味深そうに聞き返してきた。
“Oh, that’s interesting. Can you show an example?”
すぐに、日本のECサイトやアプリのスクショを3枚Slackに貼った。
比較すると一目瞭然。
「おお〜」と何人かが声を上げた。
その場でUIの位置変更が即決され、「これはローカライズに役立つ視点だね」と評価された。
「当たり前」は武器になる
このとき初めて気づいた。
僕にとって“当たり前”のUIや操作感は、ネイティブの同僚にとっては新鮮な情報だった。
英語では彼らに敵わないけど、ユーザー文化や慣習の知識では勝てるフィールドがある。
それからというもの、レビューや設計ディスカッションで「非ネイティブならではの気づき」を意識的に探すようになった。
- 日付や時間のフォーマット（YYYY/MM/DD vs MM/DD/YYYY）
- ボタンの色が持つ意味（赤は警告？承認？）
- アイコンの形（チェックマークの文化差）
- フォントサイズと行間（漢字が詰まりすぎないか）
こうした細かい指摘は、機能仕様の議論では見落とされがちだけど、ユーザー体験に直結する。
僕が口を開くたびに、「また面白い視点が出てきた」とチームが反応してくれるようになった。
非ネイティブ視点を仕組みにする
せっかく見えてきた強みは、仕組みに落とし込まなきゃもったいない。
そこで僕は、社内のデザインガイドラインに**“Localization Tips”** というセクションを追加する提案をした。
- UI配置の文化差
- 色やアイコンの意味の違い
- 言語ごとの文字量とレイアウト調整ポイント
このガイドを作る過程で、インド、ドイツ、ブラジル出身の同僚も参加してくれた。
結果、ただの「英語が苦手な人」だった僕が、「グローバルUIの相談役」みたいなポジションになった。
攻めに転じた実感
この頃になると、僕の英語力は相変わらず完璧じゃないけど、会議での発言の重みが変わった。
以前は「意見を通すために頑張る」感じだったのが、今は「意見を聞かれる」立場になっていた。
雑談で築いた親近感、見える化レビュー術、そして非ネイティブ視点――
この3つが合わさって、やっと**“防御だけじゃない、自分の攻め筋”**が見えてきた。
でも、その次の壁は…
そんな中で迎えたのが、最大規模のプロジェクト。
機能数も関係者も桁違いで、世界中の拠点からエンジニアが参加する。
この場でのレビューは、もはや英語力だけじゃなく、政治力・調整力も試される。
そして僕は、このプロジェクトで“ある大きな決断”を迫られることになる。
最大規模プロジェクトで得た“信頼の座”
「じゃあ、この新機能のUIレビューはhiroにリードしてもらおう。」
ある日、プロジェクトマネージャーがそう言った瞬間、僕は「聞き間違いじゃないか？」と思った。
チーム史上最大規模のプロジェクト。関わるエンジニアは30人以上、拠点は5か国にまたがる。
そのレビューリードを――非ネイティブで、数年前は英語にビビってSlackすら開けなかった僕がやるなんて。
英語よりも“準備”が勝負
正直、英語力ではまだネイティブ勢に敵わない。
だからこそ、今回も僕の武器は同じだ。
- UIモック＆GIFでの視覚化
- 事前にSlackで質問を回収するプレビュー投稿
- 文化差に基づく改善提案
さらに今回は、タイムゾーンが異なるメンバーも多かったので、全員が会議に参加できるわけではなかった。
そこで僕は、レビュー資料を英語のテキストだけじゃなく、スクリーンショットと簡単な図解でまとめ、時差組が見てもすぐ理解できるように作り込んだ。
会議当日、想定外の展開
レビュー当日。
各国からZoomに集まったメンバーの画面がズラリと並ぶ。
まずはUIモックのGIFを共有しながら説明。
英語の説明文は短く、ポイントごとに切って話すようにした。
そして各案ごとに「メリット／デメリット」を図で示し、質問を促す。
すると、ある米国拠点のエンジニアが手を挙げた。
“I didn’t realize the color red could mean ‘confirmation’ in Japan. That’s super interesting.”
これは以前の「転」パートで話した文化差の話を応用した場面だった。
僕が事前に「色の意味」について資料に入れておいたのが、海外メンバーにも刺さったらしい。
この一言から議論が広がり、結果としてUIの配色はグローバル基準に沿いつつも、日本向けには微調整する方向で決まった。
信頼のバトン
会議が終わった後、PMからSlackでメッセージが来た。
“Great job leading the discussion today. You made it easy for everyone to understand, no matter the language.”
その言葉でハッとした。
僕がやってきたことは、結局「非ネイティブでも理解できるレビュー環境」を作ることだった。
それは僕自身のためだけじゃなく、他の国や言語背景のメンバーにも役立っていたのだ。
その後、このやり方はチーム内の“レビュー標準”になり、別のプロジェクトでも採用されるようになった。
そして、次のレビューリードには、ブラジル出身の同僚が任命された。
僕のやり方を参考にすると言ってくれたとき、ちょっと誇らしかった。
「英語が苦手」からの卒業
この経験を経て、僕は自分の中でひとつの線を引けた。
“英語が苦手”はもう自分の肩書きじゃない。
今の肩書きは、“グローバルUIの設計をリードできるエンジニア”だ。
もちろん、英語力はまだ伸ばし続けるし、会議で聞き返すこともある。
でもそれは恥じゃない。
だって僕は、英語の壁を“別の強み”で超えられる方法を手に入れたからだ。
読者へのメッセージ
もし今、あなたが海外で働くことに不安を感じているなら――
特に「英語が流暢じゃない」という理由で躊躇しているなら――
僕から言えるのはこれだけだ。
- 信頼は雑談からでも生まれる
- 言葉以外の武器を持てば、英語力の差を埋められる
- 非ネイティブ視点は、チームの強みにできる
英語はツールのひとつに過ぎない。
大事なのは「どうやって相手に伝えるか」と「自分だけの視点をどう活かすか」。
この2つを磨けば、言葉の壁は“通過点”になる。
コメント