“聞き返されるたびに、少しずつ自信が削られていった”
“Sorry, can you repeat that?”
“Wait, what do you mean exactly?”
毎日英語で仕事をしていれば、こんな返しに出会うのは当たり前。
だけど、何度も聞き返されるたびに、心の中で小さな棘が刺さっていく。
「ちゃんと伝えたつもりなのに」
「説明力が足りないのか？ 英語が下手だから？」
Slackやミーティングでそう感じたのは、一度や二度じゃなかった。
海外のIT企業にジョインしてから数ヶ月。
技術的には通用している実感があった。WPFでのアーキテクチャ設計も、MVVMの構成も、CI/CDへの組み込みも順調。
でも、会話になった途端に、自分の価値が小さくなるような感覚があった。
特に辛かったのは、「レビューの場」だった。
🔍 コードは伝わっても、“意図”が伝わらない
レビューである修正を提案したときのこと。
“Can we consider separating this logic from the ViewModel? It might reduce side effects in future changes.”
自分では丁寧に書いたつもりだった。でも、返ってきたのは冷たい返事。
“Is this really necessary? Looks fine to me.”
それを見ていた他のメンバーは、僕のメッセージに何も反応しなかった。
Slackではよくある「既読スルー」に近い空気。
その瞬間、言葉の力不足が、自分の技術力をかき消していくような気がした。
🇯🇵非ネイティブが直面する「評価されにくさ」
ここで初めて、自分が抱えていた前提に気づいた。
「評価は“実力”でされるもの」
日本では、この価値観がある意味“安心感”として機能していた。
でも、海外ではどうか？
- 実力があっても、それが伝わらなければ評価されない
- 意図が見えなければ、信頼される判断材料がない
- 「言い方」や「表現力」が、判断基準の一部になる
これが現実だった。
📌 技術 × 言語力 × 信頼
海外では、仕事に必要な“3つの柱”のうち、言語は避けて通れないファクターになる。
だけど、非ネイティブが“英語での弱さ”を背負ってしまったとき、
そこをカバーする手段は「話す力」だけじゃなかった。
自分にできるのは、“言葉”を磨くことだけじゃない。
“言葉がいらないくらいの設計”を磨くことだ。
そう思ったのが、僕のキャリアの転換点だった。
🧩 英語力がなくても伝わる“設計図”はある
きっかけは、ある日レビューで提出したXAML画面の構成図だった。
レイアウト案をFigmaで共有し、UI要素の関係性を補足するために、
「ユーザー視点での操作フロー」まで図示してみた。
すると、それを見たリードがこう言った。
“Now this is crystal clear. Honestly, the diagram says it better than any explanation would.”
英語で説明する前に、“視覚設計”で納得させてしまったのだ。
その日以来、「この人は言葉じゃなく、UIの設計で伝えてくれる人」という認識が広がっていった。
🧠 言葉に頼らない“設計の説得力”とは？
UI設計者として働いているなら、意識したい問いがある。
- 伝えたいことは、図やUIで説明できるか？
- ユーザーの行動が、設計意図そのものになっているか？
- 他人が見て「理由」を感じ取れるレベルに落とし込めているか？
これらを意識しはじめてから、Slackでも、レビューでも、英語のやり取りのハードルが一段下がった。
なぜなら、「伝えたいことの90%が設計に込められている」状態を作れていたから。
つまり、「言葉足らず」でも、「設計が語ってくれる」状況が作れるということ。
🎯 “黙っていても伝わる設計”は、非ネイティブにとって最大の武器になる
言葉で補うことが難しいなら、
設計で“先回りして伝える”ことができる。
それは、
- わかりやすいUIのラベリング
- フローの一貫性
- 意図が見える命名やコンポーネントの分割
- コメントより、構造そのもので語るデザイン
など、「読む」ではなく「感じ取れる」UIを目指す姿勢に通じていた。
“図で語る設計”が、言語の壁を超えた日
英語に自信がない。
けれど、僕にはWPFで培ったUI設計力がある。
この2つをどう組み合わせて“非ネイティブなりの戦い方”をするか——。
それを形にしたのが、**「図で語るレビュー術」**だった。
💡Case1：「このUI、なぜこうなってるの？」への無言の回答
レビュー中、アメリカ人リードエンジニアからこんなコメントが入った。
“Not sure about this tab order. Any particular reason?”
いつもの僕なら、英語で理由を説明しようとして詰まるところだ。
でもその日は違った。
提出していたFigmaモックに、あらかじめこうした補足を入れておいたのだ。
📝**[注釈] Tab order follows user’s natural data entry flow: left to right → top to bottom.**
💬**[Icon flow arrows] Indicate typical user action sequence based on usability test feedback.**
これが功を奏した。
“Ahh, got it. Thanks for the annotation. Makes total sense.”
まさに、“言わずとも伝わる設計”が成立した瞬間だった。
📊Case2：Slackの投票機能で「UI案の比較」を視覚的に共有
別のプロジェクトで、2つのUIレイアウト案（A案・B案）を提案したときのこと。
Slackにこう投稿した：
“Hey team, I’d love your thoughts on these two layout directions!
I made this quick side-by-side view with interaction flows.”
[添付画像：A/B UI比較図＋ユーザーフローのGIF]
さらに、Slackの投票リアクション機能を使って、「A 👍 or B 👏」でリアルタイムに集計。
結果、たった2時間で15人中13人が反応し、全員が納得感を持って意思決定できた。
重要なのは、文章で細かく説明しなくても、視覚で納得してもらえたことだった。
「ネイティブのように話せなくても、合意形成はできる」と感じた瞬間だった。
🧰僕が使った“言葉いらずのレビュー支援ツール”
ここで、実際に僕が使った“英語に頼らずに設計意図を伝える道具”を紹介したい。
| ツール・技法 | 用途・効果 |
|---|---|
| Figma (with comments) | UI構成の意図をコメントや矢印で補足。視覚で「なぜこうしたか」が伝わる。 |
| Slack Poll | 英語長文を書く代わりに、リアクションだけで意思決定。敷居を下げる。 |
| Loom (短い動画解説) | 英語に自信がなくても、図とジェスチャーで解説できる。繰り返し見てもらえる。 |
| カスタムUIガイド | チーム用の“操作意図ドキュメント”。「設計の背景」を英語ではなく図解メインで伝える。 |
言語で伝えきれない“意図”を、構造・動き・フローで伝えるという考え方がすべての軸になっていた。
🤝視覚情報が“信頼のショートカット”になる
「発言の多さ」ではなく、「伝え方の工夫」がチームでの信頼を左右する。
これはSlack上のやりとりでも顕著だった。
Slackで議論が白熱していたある日、あるメンバーが投稿した技術案が難解すぎて議論が迷走。
そのとき僕は、あえて発言はせず、簡単なUIフロー図を5分で描いて投稿した。
“Here’s how I understand the flow — just to help us align.”
この投稿だけで、議論が整理され、他のメンバーがそれをベースにコメントをし始めた。
そしてリードがこう言った。
“Thanks, Hiro. That made everything way easier to follow.”
このとき初めて、「発言しなくても場を整える」ことができるポジションを得たと感じた。
🧭“話す力”ではなく“整理する力”で貢献する道
ネイティブのようにスラスラ話すことは難しい。
でも、それがすべてではない。
- 議論が迷走していたら、図にして整理する
- 設計意図が見えにくい部分は、レイアウトに込めておく
- 自分の代わりに“UIが語ってくれる”状況をつくる
これは、非ネイティブが「口数では勝てない場」で勝つための、静かなアプローチだった。
🇯🇵日本人エンジニアの“空気を読む力”は、視覚に変換できる
特に印象深かったのは、アメリカ人リードが僕にこう言ったときだった。
“You often draw what others are trying to say. That’s incredibly helpful.”
「話す」ではなく「可視化する」。
日本人特有の“場の空気を読む力”は、言葉の代わりに「視覚言語」として表現することができる。
- 「何が起きているか」を察知して図にする
- 「誰が詰まっているか」を察してSlackでそっと補助する
- 「今このタイミングで話さない方がいい」と判断して見守る
これらはすべて、**英語のうまさとは無関係な“設計的貢献”**だった。
「あの時、言葉で伝えられていたら」——失敗が教えてくれた“視覚設計の限界と進化”
英語が苦手でも伝わる「視覚による設計」。
その有効性を何度も体感した僕だったが、ある時期に**“それだけでは足りない”壁**にぶつかることになる。
🔥Case1：設計レビューで“納得されない”という初の違和感
ある日、WPFアプリのアラート画面のデザイン改善を提案したときのことだった。
ユーザーから「エラーが目立たない」とのフィードバックを受け、僕は以下のような設計を用意した：
- 背景に薄い赤のグラデーション
- アイコンとエラーメッセージの一体化
- 音と振動による視覚＋触覚の補強（将来的に対応予定）
これをSlack上でFigmaモックとして共有し、補足説明も図解で丁寧に添えた。
反応は、静かだった。
“Hmm. Visually, it looks okay. But I don’t really get the rationale for the color changes.”
“Is this backed by data, or just a preference?”
普段なら視覚ベースで伝わる内容が、今回は“踏み込みが足りない”という扱いを受けた。
理由は明確だった。
「設計意図の背景」が伝わっていなかったのだ。
🧠 視覚ではカバーしきれない“なぜそうするのか”の説明
Slackでのやり取りは短文化される。
図だけでは、「なぜそのUI設計が今必要なのか」「ユーザーの文脈にどう合っているのか」までは届きにくい。
それを言語で補わないと、“なんとなく良さそう”レベルにしか届かない。
このとき、リードにこう言われたのが忘れられない。
“Design is not just about looking good. It’s about making users feel understood.”
英語がうまく話せなくても、「ユーザー理解」という意図をどう伝えるか。
視覚だけでは不十分な領域が、確かに存在していた。
📈Case2：「資料を褒められたのに、会議で空気が止まった」事件
ある英語会議で、自分がメインで説明するUI改善案のプレゼンがあった。
事前に共有した資料は、図も多く、反応もよかった。
「資料は最高だ」とまで言ってくれたチームメンバーもいた。
でも、本番のZoomミーティング。
僕がプレゼンを始めて1分後、空気が止まった。
“Umm… sorry, I didn’t quite follow that part.”
“Can you repeat the flow again?”
スライドはしっかり作った。
UIフローの図も、遷移例も入れた。
でも、話す英語に詰まった瞬間、“プレゼン全体が止まってしまう”のだ。
その後、上手く説明できない自分に焦り、声も小さくなり、
最後は他のメンバーが代わりに進行してくれた。
終了後のSlackには、気まずい沈黙が残っていた。
💬言葉で詰まっても、伝え方を“設計”すればいい
その夜、落ち込んだ僕にメッセージをくれたのは、UXライターのMさんだった。
“You have really strong design instincts. Maybe structure your speaking like your UI — one screen, one message.”
この一言でハッとした。
UIを作るときは、画面ごとにメッセージを整理しているのに、
自分の話し方はそれと全く逆で、詰め込みすぎていたのだ。
「英語をうまく話そう」とするのではなく、
「UI設計のように話を設計すればいい」。
その発想が、僕をもう一段階、次のフェーズへ押し上げてくれた。
🛠非ネイティブのための“話し方UI設計術”
そこから僕が取り入れたのは、UI設計的プレゼン法。
つまり、“会話や説明の流れそのものを設計する”というアプローチ。
✅ステップ化された説明構成（例：レビュー会議での提案時）
Step 1：問題の再確認（例：「現在の画面では通知が目立たない」）
Step 2：改善方針（例：「視覚的強調を増やし、入力エラーを即座に認知させる」）
Step 3：設計案の提示（図解＋説明は1文で）
Step 4：意図の背景（UX観点、ユーザーフィードバックなど）
Step 5：次のアクション案（導入の影響、代替案の提示など）
これをFigmaだけでなく英語スクリプトにも落とし込み、
自分用の“話すためのUI設計台本”を作って練習するようにした。
💬Case3：「プレゼンは短く、質問は長く」戦略
プレゼンの構成も大きく変えた。
- 話す時間は最小限（3分以内）
- 質問に時間を割く設計
- Slackで“補足図”を同時投稿しておく
結果、発言が短くても、“内容が明確で整理されている”という印象を持ってもらえ、
質問タイムではむしろ自分がリードできるようになっていった。
✨評価されるのは「英語力」ではなく「伝達設計力」
この転換を通じて、ようやく気づいた。
海外で評価されるのは、英語のうまさではない。
“伝えること”をどう設計し、どう相手に届く形に仕上げるか。
まさにそれがUI設計者にとっての「共通言語」だったのだ。
ある日、アメリカ人マネージャーが僕のプレゼンについてこう言ってくれた。
“Your English may be simple, but your communication is strong.
You make it easy for everyone to understand — that’s leadership.”
“英語が苦手”はハンデじゃない。「伝え方を設計する力」があれば、信頼される
海外エンジニアとして働き始めた頃、
Slackで聞き返されるたびに、「英語が下手だから仕方ない」と、自分を責めていた。
けれど今では、「伝わらなかった理由は“構造にない説明を言葉で補っていたから”」と、冷静に見つめ直せるようになった。
そして、非ネイティブの自分だからこそ身につけた「伝達設計力」は、やがてキャリアの武器へと変わっていった。
🎯“黙って伝える”力が、チームにポジションを生んだ
ある週次レビューで、チーム全体が新しいUIのワイヤーフレームを巡って議論していたときのこと。
- Aさん：「このフローでユーザーが混乱しないかな？」
- Bさん：「ここ、ステップが多すぎるかも」
Slackでやり取りされる会話は、あちこちに飛び火していた。
その時、僕は黙ってFigmaで1枚の画面フロー図を作り、こう投稿した。
“Hey team, here’s a visual breakdown of what I understood so far. Let me know if I missed anything!”
その投稿は、10分後にはスレッドの中心になっていた。
いつのまにか、「議論の全体像を掴む図を描ける人」として、場の交通整理役を任されるようになっていた。
言葉ではなく、構造と視覚で信頼されていたのだ。
🔁失敗経験が“伝達設計力”を磨くエンジンだった
思い返せば、英語が不自由だったからこそ、何度も“失敗の記録”を残してきた。
- Slackでの「通じなかった投稿」
- プレゼンで詰まった台本
- レビューでスルーされたフィードバック
それらすべてを振り返っては、「なぜ伝わらなかったのか」をUI設計の視点で見直すようにしてきた。
- 順番がおかしかった？
- 論理の導線が切れていた？
- 図の“前提知識”が抜けていた？
まさに、UIのフィードバックループと同じだった。
🌍非ネイティブだからこそできる“多国籍設計支援”
この伝達設計スキルは、他の非ネイティブ同僚たちのサポートにも活きていった。
例えば、スペイン出身のフロントエンドエンジニアがレビューで苦戦していた時、
「英語じゃなくて、図にしてみようか？」と提案。
一緒にフロー図を描いて投稿すると、次の日にはリードから「Great work, team!」のメッセージ。
誰かの“伝えることの壁”を、図で橋渡しする。
それは、言葉が完璧でない自分だからこそ気づけたことだった。
🧭 キャリアの“次の扉”は、伝達力が開けた
数ヶ月後、ある中規模プロジェクトのUI全体設計のリードポジションを打診された。
英語ネイティブでもなければ、チームで最も年数が長いわけでもない僕が、なぜ？と思った。
するとマネージャーがこう言った。
“Because when people don’t understand, you make it visible.
That’s what good architects do.”
それはつまり、「言語ではなく、設計でチームをつなげる人」という評価だった。
英語の上手さではない。
**“誰もが理解できる構造を用意できる力”**が、UI設計リーダーとしての扉を開いたのだ。
🇯🇵“空気を読む”を“構造にする”という、日本人エンジニアの可能性
ここまで来て、ようやく気づいた。
日本で培ってきた“気配り”や“察する力”は、海外では言語化されなければ伝わらない。
でも、UIという「構造」を通せば、それは言語を超えて通じる力になる。
- 空気を読む → ユーザーの心理を想像してUIに込める
- 雰囲気を察する → チームの温度を見てSlackで補助する
- 話しすぎず、伝える → 一枚の画面で、全員の理解をそろえる
日本人エンジニアが本来持つ“非言語的な感性”は、構造化すれば海外でも武器になる。
💡最後に：英語が苦手でも、伝え方は自分で設計できる
“英語力”という言葉に縛られた過去の自分に、こう伝えたい。
「伝える」という行為は、話すことではない。設計することだ。
UIを設計するように、Slackのやり取りも、プレゼンも、レビューコメントも、
全部“伝達のUI”として捉えることができる。
そして、それを自分の強みとして磨いた先に、ネイティブではたどり着けない立ち位置がある。
コメント