- 黙ってコード書いてた自分が、ある日突然“通訳役”になった話
- 言葉が足りないなら、“訳す力”で勝負するしかなかった
- 1. デザイナーの「意図」を引き出す英語フレーズ
- 2. PMの「ゴール」を確認する時の言い回し
- 3. 技術的制約を“かみ砕いて”伝えるとき
- 4. UIの微妙なニュアンスをどう説明する？
- 5. UIの仕様がふわっとしてるときの質問
- 6. “話しすぎ防止”のひと言：聞き役に回る技術
- 7. 自分の英語に自信がないときはこう逃げる
- 8. “異文化の沈黙”にやられないコツ
- 9. 技術者同士の“翻訳者”になった感覚
- 譲れないのは技術？それともUX？対立を“合意”に変える話し方
- 「話し合い＝勝ち負け」じゃない世界
- 対立が起きたときの「3ステップ会話術」
- 一番ムズいのは「話が平行線になった時」
- “日本人であること”が武器になる瞬間もある
- チームで“正解”をつくる時代へ
- 会話力は“実装スキル”の外にある武器だった
- 自分で気づく前に、評価されていたスキル
- UI会話力は、“キャリアの幅”を広げる
- レジュメやポートフォリオにも“会話力”は書ける
- 英語が完璧じゃなくても、“つなぐ人”にはなれる
- UI設計の現場で“通訳できる技術者”は、まだまだ足りていない
- 最後に：あなたが“話せるエンジニア”になるための一歩
黙ってコード書いてた自分が、ある日突然“通訳役”になった話
「Hey, can you quickly explain to the PM why that dropdown needs to stay in the top right corner?」
ある日、Slackにこうメッセージが飛んできた。
「え、俺が？ っていうか”quickly explain”って、どのくらいのテンション？てかPMってあのアメリカ東海岸の人だよね…？」
そんな戸惑いから始まった、“UI設計現場での会話力”の必要性に気づいた瞬間だった。
海外に出て初めて痛感した「コードは通じても、考え方は通じない」
WPFメインの設計開発者として、日本国内でそこそこ経験を積んでから、英語圏のリモート案件に挑戦したのが始まりだった。
技術的なやりとりはSlack＋Pull Requestのレビューで問題なし。「Your PR looks good!」と言われれば、ひとまず安心していた。
でも、ある日から妙な違和感が出てきた。
「フィードバックがふわっとしてる」「UIの修正が頻繁すぎる」「決まったはずのレイアウトがまた変わる」──なんで？
気づけば、自分の周りだけ“会話”が不足していた。
コードで説明することはできる。でも、なぜその設計にしたのか、なぜそれがユーザーにとってベストなのか、英語で説明できていなかったのだ。
UI設計の現場は“仕様書のない戦場”
特にUI設計の現場では、WPFでどれだけMVVMをしっかり書こうが、画面遷移を正確に組もうが、
「ユーザーがどう操作するか」をチーム全員が想像しながら会話することが設計そのものだった。
ここで必要なのは、いわゆる英語力ではなかった。
必要なのは、「なぜこのUIが必要か」を相手の言葉で訳してあげるスキルだった。
- デザイナーが求める視覚的な一貫性
- PMが求めるビジネス側の優先順位
- エンジニア視点の実装コストとパフォーマンス考慮
この三者の間に立って、「このボタン、いま動かせないんですよ」だけじゃなく、
「なぜそれがUX的に問題になるか」「PMのKPIにどう影響するか」までを言語化してつなぐ力。
最初はまったくできなかった。いや、正確には「できてるつもり」だった。
でも実際には、自分が説明を怠ったせいで、デザイナーとPMの間にズレが生まれてた──それに気づくまで、時間がかかった。
「橋渡し役」としてのエンジニアって、けっこう必要とされてる
そのうち、こう言われるようになった。
“You explain things really clearly between tech and design. That’s super helpful.”
え、自分が英語で説明できてた？
そう思って振り返ると、別に完璧な文法や難しい単語を使ってたわけじゃなかった。
やっていたのは、「誰が何を気にしているか」を意識して、相手に合わせて訳すことだけだった。
たとえば、
- デザイナーには「この実装で視覚的バランスが崩れるかもって心配してる？」と確認し、
- PMには「この変更は予定より1.5倍くらいの工数がかかるけど、本当にやるべき優先度か？」と問いかける。
そのうえで、自分はWPFの制約や構造をわかりやすく伝える。
そうすると、議論の論点がクリアになって、話し合いのスピードも設計の質も一気に上がる。
“英語力”の前に、“意図を聞く力”を育てる
「英語が苦手でも、設計会話に参加できますか？」という質問をよくもらう。
その答えはYES。というか、**「英語力」より「聞く力」**が先。
実際、ネイティブじゃない仲間たちはみんな「わからないから聞く」「自分の考えを相手の視点で言い換える」ことに慣れてる。
それがチーム全体のUI設計の前提になってる。
だから逆に、“黙ってわかったふり”をする人が一番ズレるし、最も危険。
言葉が足りないなら、“訳す力”で勝負するしかなかった
前回の「起」では、UI設計の現場で、ただ英語ができるだけじゃ通用しないって話をしました。
デザイナーとPMとエンジニア──この三者の“頭の中”をつなぐ「橋渡し役」が必要だったって話です。
でもさ、じゃあどうやって？
通訳でもない自分が、どうやってそんな会話できるようになったのか？
今回は、実際に使った“翻訳フレーズ”や状況別の工夫を、恥ずかしさも含めてリアルにお届けします。
英語が得意じゃなくても、**ちゃんと伝わる“技術者の言い回し”**は、確かにある！
1. デザイナーの「意図」を引き出す英語フレーズ
WPFなどのUI実装って、デザイナーの理想を現実に落とし込む作業でもあります。
でもFigmaを見ても、「これ何がポイントなんだろう？」って思うとき、ありません？
そんな時、僕がよく使っていたのがこのフレーズ：
💬 “What’s the most important thing you want users to notice here?”
（ここでユーザーに一番気づいてほしいポイントってどこ？）
この一言で、「ボタンの色より、配置の流れが大事」とか「視線誘導を意識してる」とか、
**“コードには書かれてない意図”**が出てくる。ここがUIの本質だなって、ほんと何度も思った。
2. PMの「ゴール」を確認する時の言い回し
PMとの会話では、「この仕様、なんで急に変わったの？」とか「これって絶対Must？」みたいなモヤモヤがつきもの。
でもそれをただ聞くと、角が立つ場合もある。
そんな時、やさしく“ゴール”を確認する言い回しがこれ：
💬 “Just to align expectations — is this change aiming to improve conversion, usability, or something else?”
（認識合わせのために聞くんだけど、この変更ってコンバージョン改善？それともユーザビリティ？それ以外？）
この“Just to align expectations”って前置きが超便利。
「責めてるわけじゃなくて、共通認識のために聞いてます」ってニュアンスが伝わる。これは神フレーズ。
3. 技術的制約を“かみ砕いて”伝えるとき
「技術的に難しい」って言いたい時、そのまま “It’s difficult” って言ってませんか？
でもそれ、PMには伝わらない（むしろ「じゃあ頑張って」ってなる危険）。
僕はこう言い換えてました：
💬 “To make that work, we’d need to refactor the whole binding structure. That might delay the release by X days.”
（それを実現するには、バインディング構造全体をリファクタする必要があって、リリースがX日遅れそう）
“やるならどうなるか”まで具体的に話すと、説得力が爆上がり。
実装の苦労を“予算とスケジュールの言葉”に訳す。それだけで信頼される度が変わる。
4. UIの微妙なニュアンスをどう説明する？
デザイナーから「もうちょっと軽く見せたい」と言われた時、どのプロパティをどう変えるか迷いますよね。
そんな時は、デザイン意図を言語化してあげるのも橋渡しのひとつ。
💬 “Do you mean lighter in terms of spacing, color tone, or overall visual weight?”
（“軽く”っていうのは、スペースの話？色味？それとも見た目のボリューム感？）
この「3択質問」、めちゃくちゃ使える。
会話が具体化して、議論の方向性がぐっと定まるんです。
5. UIの仕様がふわっとしてるときの質問
Figmaに載ってない動作仕様、ありますよね。
「このモーダル、閉じる条件どうするの？」みたいなやつ。
そんな時の一言：
💬 “How should this component behave when the user presses Esc or clicks outside?”
（ユーザーがEsc押すか、外をクリックしたときの挙動ってどうする？）
当たり前と思われてる部分をあえて聞くと、実はみんな想定してなかったりします。
“その場しのぎの実装”を減らす、会話の力。
6. “話しすぎ防止”のひと言：聞き役に回る技術
自分ばかり説明してて、相手が口数減ってきたなって時は、こう切り返してました：
💬 “Does that make sense from your side, or would you suggest a different approach?”
（今の話って、そっちの視点からすると納得感ある？それとも違う案あるかな？）
英語が拙くても、“対話”をしようとしてる姿勢が伝われば、それだけで空気が和らぐ。
7. 自分の英語に自信がないときはこう逃げる
技術英語はまあまあ話せるけど、雑談っぽいニュアンスはまだ苦手…ってときは、
💬 “Sorry if I’m overexplaining — just trying to make sure I got your point right.”
（ちょっと説明くどくなってたらごめん、ちゃんと理解できてるか確認したくて）
この“Just trying to…”は万能です。
「完璧じゃないけど、ベストを尽くしてる」感が出せて、ネイティブも笑ってくれる。
8. “異文化の沈黙”にやられないコツ
会議中に急に沈黙が訪れると、つい不安になりますよね。でも文化によっては、「考えてる時間」だったりします。
そんなとき、僕はこう言って時間を稼ぎます：
💬 “I’ll give everyone a sec to think about this — no rush.”
（みんな少し考える時間取りましょう、急がないので）
これで空気がふわっとやわらかくなる。文化的な間を読むことも、会話力の一部。
9. 技術者同士の“翻訳者”になった感覚
気づけば、コード書く時間よりも、人の話を聞いて訳す時間の方が長くなってたこともある。
でもそれが、結果的に「UIの質」に直結するんです。**共通言語は、技術じゃなくて“意図”**だった。
💬 “I’m happy to translate between what design wants and what’s technically feasible — that’s part of the fun!”
（デザインの理想と実装の現実をつなぐのが自分の役目。むしろそれが楽しい）
そう思えたとき、初めて「海外チームの一員になれた」って実感が湧きました。
譲れないのは技術？それともUX？対立を“合意”に変える話し方
「No, I really think this layout won’t work for our users.」
英語でこんな言葉を言われると、思わず一瞬ひるむ。
しかも相手はUXリード。自分はWPFエンジニア。そう、完全に立場が違う。
海外で開発していると、意見がぶつかることは日常茶飯事です。特にUIまわりは、
「技術的に無理」vs「ユーザー体験的に必要」というぶつかり方が多い。
でもその時、「技術者として正しいこと」を言うだけでは、相手は納得しない。
むしろ、「技術に閉じこもってる人」って思われて終わることもある。
今回は、そんな場面でどう**“折れずに伝え、でもチームで着地するか”**を掘り下げます。
「話し合い＝勝ち負け」じゃない世界
正直、最初の頃は「この仕様じゃバグ出る」と思ったら、ハッキリ言ってました。
「この設計はバッドUX」「このUIは冗長」みたいに。でも、これ逆効果でした。
あるUXリードから言われたひと言が忘れられません。
“We’re not trying to win an argument here. We’re trying to find what works best — for everyone.”
（ここは議論に勝つ場所じゃないよ。みんなにとって一番いい方法を探してるんだよ）
そうか。会話の目的は“勝ち負け”じゃなくて“合意形成”なんだ。
このマインドセットを変えただけで、議論の場の空気がまったく違うものに見えてきました。
対立が起きたときの「3ステップ会話術」
WPFでの設計で、パフォーマンスやアクセシビリティを考えると「それ実装したくない…」って時、ありますよね。
でも、それをそのまま「やりたくない」と言うと印象が悪い。
そこで自分が使っていた**“ぶつかりそうな時の3ステップ”**がこれです：
ステップ①：まず「理解を示す」
たとえば、こんな感じで話し始める：
💬 “I see what you’re aiming for. A cleaner visual flow would definitely help the user.”
（なるほど、見た目の流れをスッキリさせたいって意図はよくわかる）
まず「敵じゃないよ」という姿勢を見せることが重要。
共感から入ることで、議論の空気が一気に穏やかになります。
ステップ②：リスクを客観的に提示する
共感したうえで、技術的な懸念を伝える：
💬 “My only concern is performance — the animation you’re suggesting might cause a lag on lower-end devices.”
（1点だけ懸念があるんだけど、そのアニメーションだとスペックの低い端末でラグが出るかも）
ここで大事なのは、“I’m concerned”とか“Just a thought”といったやわらかい前置き。
強く言うより、冷静に事実を共有する方が説得力があります。
ステップ③：代替案を出して、一緒に考える
ただ否定するのではなく、「代案」を出す：
💬 “What if we simplify the animation or only trigger it under certain conditions?”
（代案として、アニメーションを簡略化するか、特定の条件下だけにするっていうのはどう？）
これが一番大事。代替案があることで、“建設的な人”として信頼されるようになります。
一番ムズいのは「話が平行線になった時」
でも、現実はそんなきれいにいかないこともあります。
議論がかみ合わず、「いや、やっぱこっちがいい」と押し切られそうになる。
そんな時、僕がやってたのは──
💬 “Let’s test both options in the next sprint and gather feedback. That way we can make a data-informed decision.”
（次のスプリントで両方試して、ユーザーの反応見て決めるっていうのはどう？）
そう、「議論じゃなく、検証に持ち込む」作戦です。
PMもUXも納得しやすいし、実際ユーザビリティテストで明確に結果が出ると、言い合いの必要がなくなるんです。
“日本人であること”が武器になる瞬間もある
海外のチームで働くと、「自己主張しなきゃ」「アピールしなきゃ」と思いがちです。
でも、丁寧に対話する姿勢とか、空気を読む力って、実は評価されます。
「あなたの質問って、考えさせてくれるから助かる」と言われたことがあります。
それって、“日本人っぽさ”の強みじゃないかと。
言葉が完璧じゃなくても、相手を立てながら、本質を突くような質問ができる。
その姿勢は、多国籍のチームでも好印象になるんです。
チームで“正解”をつくる時代へ
昔は「仕様に書かれた通りに作る」ことが正義でした。
でも今は、チームで正解を探す時代です。
- ユーザーにとっての価値は何か
- 実装可能なラインはどこか
- デザインの狙いはどこにあるか
この3つの軸の**“交差点”を探す会話こそがUI設計**。
だから、技術だけじゃなく、“聞く力・訳す力・問い返す力”が求められるんだと思います。
会話力は“実装スキル”の外にある武器だった
コードが書けること。
WPFでMVVMを正しく使えること。
非同期処理をきれいに扱えること。
それらは、当然「技術者として必要な力」。
でも、海外で実際に評価された力は、もう一段“外側”にあった。
それが、**「会話で信頼をつなぐ力」**だった。
ここでは、WPFエンジニアとしての自分が、どんなふうに会話力を評価され、キャリアに反映されたかを、赤裸々に共有します。
自分で気づく前に、評価されていたスキル
あるプロジェクトの終了時、チームマネージャーがくれたフィードバックに、こんな一文がありました：
“You were more than a developer — you made communication between design and engineering effortless.”
（あなたは単なる開発者じゃなかった。デザインと開発の会話をスムーズにしてくれた）
…え、それってそんなに大事だったの？
自分では「Slackで地味に聞き返してただけ」「言い回しをちょっと工夫しただけ」だったけど、
チームにとってはそれが摩擦のない開発環境を生み出していたらしい。
UI会話力は、“キャリアの幅”を広げる
面白いのは、そのプロジェクトが終わったあと。
僕はWPFのスペシャリストとして紹介されていたのに、
次に紹介されたポジションは「UIコーディネーター／アーキテクト寄り」だった。
そこでは、こんな業務を期待された：
- 複数のUIエンジニアの設計レビュー
- デザイナーとの仕様調整
- PMとの画面要件すり合わせ
- 実装者が迷わないためのUIガイドライン整備
つまり、「自分ひとりで手を動かす人」じゃなくて、「UIチームをつなげる役」だった。
しかもこれ、英語ネイティブじゃない自分が選ばれたっていうのがミソ。
理由を聞くと、
“You listen more carefully. And that’s rare.”
（あなたは丁寧に話を聞く。それって案外、希少なんだ）
とのこと。なんだそれ、泣けるじゃん。
レジュメやポートフォリオにも“会話力”は書ける
この「会話で価値を出した体験」は、レジュメにもちゃんと書けます。
たとえば、僕が実際に使っていたフレーズがこちら：
📄 Resume（英語）
Role: WPF UI Developer
Key Contribution:
- Acted as a communication bridge between designers, product managers, and developers to align UI expectations across stakeholders.
- Reduced rework on UI implementations by 40% by clarifying design intentions and addressing technical constraints early in the process.
📁 Portfolio（UI実装例）
Project: Medical Dashboard UI
My Role:
- Translated Figma prototypes into WPF UI with high fidelity
- Initiated clarification meetings with UX designers to confirm user goals
- Proposed alternative layouts when WPF limitations surfaced, ensuring both design intent and implementation feasibility
これ、単に「XAML書きました」「DataTemplate設計しました」よりも、はるかに“チームに貢献した感”が出るんです。
そしてこれが、グローバル転職市場では強い。
英語が完璧じゃなくても、“つなぐ人”にはなれる
もちろん、僕の英語はネイティブレベルなんかじゃない。
Zoomで何度も言い直したし、SlackではDeepLに助けられたし、
「もうちょっと英語でうまく言えたらな」って悔しい思いも山ほどした。
でも、**“意図を正確に伝えようとする姿勢”**があれば、信頼される。
それに気づけたのは、海外で実際に働いてみたからこそ。
「言葉が完璧じゃなくても、対話の価値は出せる」
これは、これから海外に出るすべてのエンジニアに伝えたい真実です。
UI設計の現場で“通訳できる技術者”は、まだまだ足りていない
ここまで読んでくれたあなたに、最後に伝えたいことがあります。
UI設計の橋渡し役は、まだ圧倒的に不足しています。
特に、技術者でありながら相手の視点で考え、言葉を訳して伝えられる人は少ない。
だからこそ、このスキルは希少で、これからのエンジニアの価値を大きく高めてくれます。
最後に：あなたが“話せるエンジニア”になるための一歩
難しく考える必要はありません。
- 「なぜ？」を聞く勇気
- 「相手がどう考えているか」に興味を持つこと
- 「技術の話を、相手の言葉で伝える」意識
この3つだけでも、UI設計現場でのあなたの存在感は確実に変わります。
WPFで得た経験も無駄にならない。むしろ、その深さがあるからこそ、“会話力”が活きる。
あなたがもしこれから海外で働こうとしているなら、
「英語が通じるか」じゃなくて、「会話で価値を出せるか」にぜひ目を向けてほしい。
コメント