── 海外チームで信頼を築くコミュニケーション設計の極意
「英語ができないから、会話に入れないんです」
僕が海外チームに入ったばかりの頃、同じような日本人エンジニアからよく聞かれたセリフだ。
英語が不安、文化が違う、雑談が通じない、設計の相談をしづらい——
そうやって、黙って黙って、気づけば“言われたことだけをやる人”になっていく。
…それ、すごくもったいない。
なぜなら、設計職ほど“対話力”が価値になる職種はないからだ。
そして、“英語力”と“対話力”は、まったくの別物だということを、僕は海外チームで痛感した。
🤝 設計者に必要な「会話力」は、言語力ではない
これは実際のエピソードだ。
ある日、海外のプロジェクトでUIの構成を見直すことになった。
そのとき、リードのUXデザイナー（オランダ人）から言われた一言がある。
“Don’t just say yes. Tell me what you see.”
つまり、「わかった」で終わらず、ちゃんと“あなたの視点”を聞かせてほしいということだった。
この一言で、僕のスイッチが入った。
言われた通りに作るだけじゃ、設計者としての価値はない。
むしろ、“あなたはどう見る？”を語れることこそが、信頼の入り口になる。
🧭 対話とは、「設計する行為」そのもの
UI設計とは、「ユーザーの行動をどう導くか？」を考えること。
そしてチームで働くということは、「相手の思考をどう汲み取り、伝えるか？」を設計することでもある。
言い換えれば、
- ユーザーのためにUIを設計する
- チームのためにコミュニケーションを設計する
この2つは、同じ設計スキルの延長線にある。
海外チームで価値を出せる設計者になるためには、
“伝わる設計図”だけでなく、“伝えるプロセス”そのものを設計する視点が必要なのだ。
🌏 文化が違うと、前提がまるで違う
日本では当たり前に通じることが、海外ではまったく通じない。
たとえば、
- 「仕様書が足りないですね」→ 海外では“仕様を待つ人”と思われる
- 「今、忙しそうなので後にします」→ “発言しない＝関心がない”と解釈される
- 「すみませんが…」→ “Sorry”を多用すると、自信がない人と思われる
こうした文化の“ズレ”を放置していると、
**「技術はあるのに信頼されない設計者」**になってしまう。
でも逆に、このズレに気づき、翻訳し、橋渡しできると——
“文化をつなげる設計者”としての新しい価値が生まれる。
💬 英語の「型」を知っていれば、対話は設計できる
英語が苦手でも大丈夫。
僕が実際に使っている、**「設計対話」に効くフレーズテンプレート」をいくつか紹介する。
✅ 提案時の型
“From the user’s perspective, would it be better if we…?”
（ユーザーの視点で見たとき、こうした方がよいのでは？）
✅ 選択肢を提示するとき
“I see two options here: A focuses on speed, B on clarity. What do you think?”
（スピード重視のA案と、分かりやすさ重視のB案、どう思いますか？）
✅ 相手の意図を汲むとき
“Just to clarify, are you aiming for…?”
（確認ですが、目的は…ということで合ってますか？）
✅ 自分の考えを伝えるとき
“My thinking is based on the assumption that users tend to…”
（私の考えは、ユーザーが〜しがちだという仮定に基づいています）
こうしたフレーズを「部品」として覚えておくと、まさに“英語でUI設計する”感覚で会話が組み立てられる。
✨ 対話を設計できる人が、チームのハブになる
僕があるプロジェクトで「UIリード」のようなポジションを任されたとき、
実は、技術力以上に評価されたのが、**“チームの会話をつなげる力”**だった。
- 開発とデザインの視点を翻訳してつなぐ
- 英語が得意じゃないメンバーの意図を代弁する
- 意見が対立したとき、背景を整理して合意に導く
こうした役割ができると、自然と「信頼できる設計者」として認識される。
それは、コードの腕前以上に、会話を設計する力＝職能のひとつとして扱われる。
🎯 今回のまとめ：グローバル設計者の“対話力”とは
| 要素 | 解説 |
|---|---|
| 英語力より大事なこと | 自分の視点・設計意図を“相手が理解できる構造”で話すこと |
| 文化翻訳力 | 相手の前提と自分の常識のギャップを察知して、翻訳・調整できる力 |
| フレーズ設計力 | 自分の考えを伝えるための言語テンプレートを事前に持っておくこと |
| 対話＝設計行為 | 会話の目的を定義し、相手の理解フローを設計しながらやりとりする技術 |
設計者の声をどう通すか——言葉と構造で“説得力のある設計”をつくる技術
海外チームの一員として、初めて「自分のUI提案が通った日」。
それは、ちょっとした“勝利”だった。
しかもそのとき、僕の英語はまだ流暢とは言えなかったし、
「ネイティブ級に話せる人」に比べれば、決して聞きやすいスピーカーではなかったと思う。
でも、その提案が採用された理由は、英語の流暢さではなかった。
それは、“設計としての説得力”があったからだった。
🧭 言葉ではなく、「構造」で相手を納得させる
海外の設計レビューや議論で最も大切なのは、話の“構造”。
“英語を正しく話す”よりも、**「論点が整理されているか」**のほうが遥かに重視される。
あるとき僕は、次のような新しい入力フォームの提案をした。
🌐 提案内容（Before → After）
- Before: 一画面にすべての入力項目を並べる縦長フォーム（15項目以上）
- After: 3ステップのウィザード形式に変更。ユーザーの状況に応じて動的に項目を絞る。
🧩 僕が提示した構成
- 現状の課題：ユーザー離脱率が高く、誤入力も多発していた
- ユーザーの状況モデル：現場のオペレーターは、日常的に同じタイプの入力を繰り返す
- 提案の意図：認知負荷を減らし、入力内容に集中できる構造へと再設計
- 技術面の影響：バリデーションロジックとMVVM構造は既存のものを再利用可能
🔄 使った英語フレーズの工夫
“This redesign is not about reducing clicks — it’s about reducing hesitation.”
（この再設計は、クリック数を減らす話ではなく、“迷い”を減らすためのものです）
この一言が、チーム内のUXデザイナーやPMの心に刺さったらしい。
「数ではなく行動に着目している」という点が、
“UIではなくUXを考えている設計者”という印象につながった。
✍️ 文書でも“設計の構造”を伝える技術
SlackやGitHubのコメントでも、構造的に伝える力は重宝される。
僕がよく使うテンプレートはこんな形：
✉️ GitHubのUI改善提案コメント例：
### Problem:
Users often miss required fields when filling out the form.
### Observed Behavior:
Based on usability testing, 3 out of 5 users skipped over Section C entirely.
### Proposal:
- Break form into 3 steps
- Use visual indicators to show required fields
- Auto-scroll to the next step upon completion
### Impact:
- Reduced user confusion
- Clearer validation process
- Increased task completion rate (hypothesis)
Let me know what you think.
こうした「問題 → 観察 → 提案 → 期待される効果」の構成にすることで、
英語がネイティブでなくても、論理の構造が補ってくれる。
実際、この形式でSlackに投稿した提案がそのまま会議のアジェンダに採用されることも増えた。
🔍「主張が通る人」は、聞かせ方をデザインしている
海外チームでは、静かにしている＝意見がないと思われがちだ。
逆に、自信満々で話している人が必ずしも正しいわけでもない。
違いは、「聞かせ方を設計しているかどうか」。
あるとき、議論が割れたことがあった。
チャートの並び順について、
- デザイナーは「ブランドカラーに近い順に並べたい」
- 僕は「ユーザーの使用頻度に合わせて並べたほうがいい」と主張
僕はここで、ある図を1枚用意した。
📊 提示した図：ヒートマップによるクリック頻度の比較
- Before: 色優先の配置 → 上位3つのクリック率 52%
- After: 使用頻度優先の配置 → 上位3つのクリック率 73%
そしてSlackに一言だけ添えた：
“I tested this with a small group. Users reacted faster when the order matched their daily usage. Just wanted to share this.”
強く主張しなくても、事実と構造があれば、言葉数は少なくて済む。
🧩 UI設計と同じように、対話も“UI”である
このとき感じたのは、コミュニケーションもまた“ユーザー体験”であるということ。
- 相手が読みやすいように構成する（UX）
- 複雑な内容を視覚化する（UI）
- 選択肢を提示し、自律的に判断できるようにする（情報設計）
つまり、設計者としてやってきたことをそのまま**“対話”にも応用できる**。
✅ 海外チームで「説得力のある設計者」になるための要素
| 要素 | 技術としての説明 | 英語としての工夫 |
|---|---|---|
| 構造 | 問題 → 観察 → 提案 → 効果 | セクション化、箇条書き |
| 視点 | ユーザー目線、データ根拠 | “from the user’s perspective” |
| 可視化 | スライド、図、テスト動画 | OBS＋字幕、軽量GIF |
| 謙虚な主張 | 強制でなく提案 | “Just an idea to consider…” |
対話が噛み合わないとき、どうするか？信頼を失わずに文化の壁を超えるヒント
英語でのやり取りも慣れてきたある日、プロジェクトレビューで**大きな“すれ違い”**が起きた。
WPFを使って実装していたUI構成に対して、ヨーロッパのプロダクトオーナーから突然のコメント。
“This feels too rigid. Can we make it more fluid like a mobile flow?”
つまり、「この画面遷移、固すぎる。スマホっぽくもっと柔軟にしてほしい」と言うのだ。
でも、その画面は「業務端末＋デスクトップ環境」で、入力デバイスはキーボード＋マウス。
業務効率を重視して、意図的に“定型フロー”にしていた。
僕は内心、「それは無理だよ…」と思った。
でも、そこでストレートに否定すれば、相手を潰してしまう。
かといって、黙ってしまえば、「やる気がない」と思われる。
🌀 否定せずに、背景を掘る。「NO」の代わりに「WHY？」を返す
そこで、僕が最初に返したのは、反論ではなく、問いかけだった。
“Just to understand better — do you mean the current flow feels slow, or not intuitive enough?”
（確認なのですが、「今の構成は遅いと感じるのか、それとも直感的じゃないと感じるのか」どちらでしょうか？）
この問いが功を奏した。
相手は「感覚的にそう言っていた」だけだったことがわかり、
実は**“モバイルっぽさ”が欲しいのではなく、“画面遷移の流れが見えにくい”**という不満だったのだ。
🧠「主張の奥にある本音」を掘り出せる設計者が、対話のバグを修正する
このときのように、海外チームでは**表面的な要求の裏にある“真の意図”**を読み解く力が特に求められる。
なぜなら、以下のような背景があるからだ：
| 問題の表現 | 実際の意図（例） |
|---|---|
| “This doesn’t look modern.” | → 情報が詰まりすぎて読みにくい |
| “Can we make this simpler?” | → 操作ミスが多くてストレスになっている |
| “Feels not user-friendly.” | → フィードバックやガイドが足りないと感じている |
つまり、“対話のバグ”を修正できる設計者は、プロジェクトの中で非常に重宝される。
🔄 文化の“違和感”を「敵」ではなく「設計課題」として扱う
このプロジェクトでは、さらに難しい場面もあった。
ある東南アジアの開発者が、コードレビューで僕の提案をすべて「非効率的」とコメントしたとき。
しかもSlack上で、かなりストレートに。
正直、「あ、これちょっと空気悪くなるな」と思った。
でも、ここでも“感情”より“構造”にフォーカスするようにした。
🎤 僕の返信（英語）
“Thanks for pointing that out. Just curious — what metric are you using to define ‘efficient’ here?
Are you focusing on rendering speed, or implementation effort?”
→ “ご指摘ありがとうございます。『効率的』という言葉の基準を確認したいのですが、描画速度のことでしょうか？ それとも実装負荷のことでしょうか？”
この問いに対し、相手は「描画速度」を重視していたと答えた。
でも、僕は「ユーザーの目線の移動量と操作回数」をベースに設計していた。
🧩「評価軸の違い」は、文化差ではなく“設計観の違い”
ここで改めて気づいたのは、
“文化”という言葉で片づけると、設計の議論が止まってしまうということ。
大切なのは、“その人の評価軸は何か？”を設計のフレームワークとして共有すること。
このとき、Notionで「UI設計における優先軸」を可視化した以下のようなドキュメントを作成した。
📄 設計評価軸ドキュメント（抜粋）
| 評価軸 | 優先度 | 説明 |
|---|---|---|
| 操作ミスの少なさ | High | 一日数十回操作する現場向けUIのため |
| 初回ユーザーの理解性 | Medium | トレーニングがある前提なので高くない |
| 描画スピード | Medium | 遅延が出る場面は限られている |
| 実装負荷 | Low | コンポーネント再利用で解決済み |
これを共有してから、議論のすれ違いが一気に減った。
**“設計とは、判断の優先順位を言語化・共有する行為”**でもある。
そう言えるようになったのは、この“衝突”がきっかけだった。
🤝 信頼は、「正解」よりも「整合性」に宿る
グローバルチームでは、「意見の正しさ」よりも「判断の整合性」が信頼につながることが多い。
つまり、「その設計、筋が通ってるね」と思ってもらえるかどうか。
- なぜそのUI構成にしたのか？
- 他の案との比較はどうだったか？
- ユーザーのどんな行動変化を想定しているのか？
この一貫性を持って話せるようになってから、意見の通り方が劇的に変わった。
🎯 今回のまとめ：文化の違いを“設計に活かす”3つの力
| 力 | 内容 | 実践のヒント |
|---|---|---|
| 🔍 意図を掘る力 | 相手の言葉の背後にある“本当の課題”を引き出す | “Do you mean…?”で真意を問う |
| 📐 評価軸の翻訳力 | 自分と相手の“何を重視するか”を可視化する | 優先順位のドキュメントを共有 |
| 🔄 感情から構造へ | 衝突が起きても、構造で話すことで感情を抜く | “What’s your assumption?”と返す |
設計は言葉を超える——信頼される設計者の“対話設計フレームワーク”
エンジニアである前に、「設計者」として海外で働いて感じたことがある。
それは——
言葉が通じなくても、設計は通じる。
逆に、言葉が通じていても、設計思想が共有されていなければ、信頼は生まれない。
そして、最も大切なのはその“間”をつなぐ存在になること。
つまり、「設計の意図を翻訳し、伝わる形に変える設計者」になることだった。
🧭 “話す”より、“設計して伝える”という意識
日本では「ちゃんと説明する」ことが美徳とされる場面が多い。
しかし、海外チームでは**「簡潔に、構造的に伝える」ことが信頼につながる**。
例えば、SlackやNotionのやりとり、Figmaコメント、スタンドアップでの報告。
- 長文で正確な説明 → 🙅♂️ 「読みにくい」「結論がわからない」
- 3〜4行で構造的に要点提示 → 🙆♀️ 「OK、納得」「いいね、それ進めよう」
これはまさに、UI設計と同じ発想。
ユーザーに「何を、どう操作してほしいか」を明快にするように、
チームにも「何を、どう考えてほしいか」を伝える必要がある。
つまり、設計者の言葉は“インターフェース”であり、“ナビゲーション”でもあるのだ。
✍️ 僕が使っている「対話設計フレームワーク」
対話やレビュー、プレゼン、チャットで設計の意図を伝えるとき、僕は以下の3ステップで組み立てている。
🧩 対話設計フレームワーク（3ステップ）
- 観察（Observation）
現場で起きている事象や背景を簡潔に共有
例：“Users seem to hesitate at the second step of the form.” - 解釈（Interpretation）
なぜそうなっているのか、自分なりの仮説を提示
例：“I assume it’s because the required fields aren’t visually distinguished.” - 提案（Suggestion）
具体的なアクションまたは改善案
例：“We can highlight them using a light red border and a tooltip.”
この流れにすることで、英語がネイティブでなくても「考え方が整理されていてわかりやすい」と言ってもらえるようになった。
特にプレゼンやレビューではこの構成が効く。
事実→仮説→提案。この“構造の強さ”が、言語の弱さを補ってくれる。
🧠「設計思想」を共有できるチームは、強い
実際に働いていて痛感するのは、**信頼される設計者とは、“判断の基準を言語化できる人”**だということ。
僕はポートフォリオの中でも「設計原則（Design Principles）」を必ず明文化している。
たとえば：
| 原則 | 説明 |
|---|---|
| 1. ユーザーの“迷い”をゼロにする設計 | 操作の順序や状態遷移を常に可視化する |
| 2. ミスは“予防”より“リカバリーしやすさ”で対応 | Undoや警告表示の最適化 |
| 3. 知識がなくても使える構造を優先 | 操作説明よりも導線の直感性を重視 |
これをNotionやGitHub READMEに載せておくと、海外の同僚から「これがあるからレビューしやすい」と言われる。
🌏 信頼は“積み上げる”ものではなく、“設計する”もの
日本では「経験年数」や「勤続年数」で信頼を得る文化が根強い。
でも、海外ではもっとシンプルに、**「この人と話すとわかりやすい」「筋が通ってる」**と感じてもらえるかどうかがすべて。
つまり、信頼とは「設計された経験」であり、以下の積み重ねで形成される：
| 小さな信頼の積み重ね | 結果 |
|---|---|
| Slackでの質問に対して毎回論点が明確 | → 「いつも話が早い人」 |
| レビューコメントに感謝を添えて返す | → 「オープンで協調的な人」 |
| 提案に軽いプロトタイプを添えて提示 | → 「自走力がある人」 |
こうした“マイクロコミュニケーション”が積もって、
やがて「任せたい人」「一緒に考えてくれる人」になる。
🚀 最後に：設計者の「対話力」は、国境を越えるスキル
言語、文化、ツール、リモート——
海外で働く設計者は、あらゆる“ノイズ”とともに設計していくことになる。
でもだからこそ、「伝え方を設計できる人」には唯一無二の価値がある。
言い換えれば、
- UIを通じて、ユーザーと“対話”できる設計者
- 言葉を通じて、チームと“共創”できる設計者
この両方を持った人は、世界中どこでも必要とされる。
✅ まとめ：文化を越えて信頼される“対話設計者”になるために
| 項目 | ポイント |
|---|---|
| 🎯 フレームワーク | 観察 → 解釈 → 提案 で思考を構造化 |
| 📘 設計原則の可視化 | 「判断の基準」をチームで共有できるようにする |
| 🧠 整合性重視 | 英語力より、考え方が筋通っていることが信頼につながる |
| 🤝 マイクロ信頼の積み重ね | 毎回のやりとりに「聞きやすさ」「伝えやすさ」を設計する |
コメント