「話せるようになった」その先にある壁
海外チームの会議に慣れてきた頃、不意に感じる違和感がある。
「発言はできるようになった。でも、評価にはつながってない気がする」
――これ、実はすごくよくあることです。
最初のステージは、「話せるようになること」でした。
英語という言語にビビらず、何かしらの発言をできるようになる。それだけでも大きな一歩。実際、僕も最初は、Zoom越しの沈黙にどう割って入るかで精一杯で、話の内容よりも「話した」という事実に満足していました。
でも、次の壁はそこで終わらない。
「この人の発言は価値がある」
「このエンジニアのコメントはプロダクトに貢献してる」
と、チームから**“信頼と評価”を獲得する発言力**が求められてくるんです。
なぜ、話してるのに評価されないのか？
「ちゃんと発言してるのに、なんか評価に反映されてない」
この原因、多くの場合は**“内容”ではなく、“伝え方”**にあります。
たとえば──
- 質問に答えただけで、議論が深まっていない
- 仕様確認はできても、改善提案につながっていない
- 話す内容に“Why”がなくて、判断材料にならない
英語で話すハードルは越えたけど、「この人の話が有益だ」「次のアクションが見える」と思わせる力が足りていない。
つまり、“話せる”と“伝わる”は別物なんです。
評価される発言には「戦略」がある
ここで、英語力とは別の武器が必要になってきます。
それが、**「設計された伝え方」**です。
英語ネイティブに比べて、私たちノンネイティブは語彙や言い回しの幅では勝てません。でも、構造的に「伝える内容を整理する技術」なら、むしろ鍛えられる。
実際、英語が第二言語であるドイツ人やインド人エンジニアが、明快に論点を整理してチームの議論を前進させているのを、何度も見てきました。
彼らは、言語より**“伝え方の設計”**に長けているんです。
これは、C#やWPFで設計パターンを使いこなしてきたエンジニアにとって、親和性が高いスキルです。言語力で勝負しない。「構造」と「目的」で勝負する。
僕の失敗例：「話したのに、誰にも刺さらなかった」案件
ある国際案件で、UIの設計方針について質問され、僕はこう答えました。
“We chose a tab-based layout because it’s easier for users to navigate.”
間違ってはいない。でも、その瞬間、誰もリアクションせず、次の話題に移っていきました。
「あれ…ちゃんと答えたよね？」と思いながらモヤモヤ。
その後、同僚が同じ質問にこう答えたんです：
“We selected a tab-based layout based on user testing data. Over 70% of our test users were able to find key features within 3 clicks, compared to 45% with the previous list layout. It also reduced bounce rate by 18%.”
すると、マネージャーが即座に「Great insight!」と反応し、チャットにも “👍”が飛び交った。
どちらも“正しい”ことを言っている。でも、“説得力と影響力”がまったく違う。
この経験から僕は、「話すこと」から「伝えること」にシフトしなければと痛感しました。
次に必要なのは、“内容の設計力”
じゃあ、何をどう変えていけばいいのか？
答えはシンプルで、こうです：
✅「結論 → 理由 → 根拠や数字 → 提案」
この順番で、“話す内容を設計”すること。
英語が流暢じゃなくてもいい。文法が多少怪しくてもいい。
でも、この構造があるだけで、相手の理解度・納得度・信頼度がグッと上がる。
実は、WPFアプリのUI設計とまったく同じ。
どんなデータをどんな順序で提示すれば、ユーザーが迷わずアクションできるか？
それと同じように、**「相手がアクションを取りやすい説明」**を組み立てるんです。
まとめ｜話す力に“設計力”を掛け算する
評価される発言は、英語のうまさじゃない。
“設計された伝え方”が、成果と信頼を生む。
そしてそれは、英語ネイティブではないからこそ、身につけられる武器です。
次回の会議では、「何を話すか」だけでなく、「どう話すか」を意識してみてください。
評価される発言には“型”がある：伝え方テンプレート大全
前回、「話す」から「伝える」へと視点を切り替えることの重要性についてお話しました。
今回からはいよいよ実践編です。
非ネイティブでも、いや、**非ネイティブだからこそ使える“構造化された発言の型”**を紹介します。
これは、僕自身が海外の技術会議で信頼を得るまでに磨いてきた武器であり、日英問わず「伝え方で損をしない」ための技術です。
型①｜PREP法：最もシンプルで即効性のある型
PREPは、以下の4つの要素で構成されるシンプルな型です。
- P（Point）：結論を先に言う
- R（Reason）：理由を述べる
- E（Example）：具体例・証拠・データを示す
- P（Point）：もう一度結論で締める
たとえば、UI設計の方針について問われた時、こう答えます：
Point（結論）：I think we should go with the collapsible sidebar design.
Reason（理由）：Because it gives users more screen space and works better on smaller resolutions.
Example（例）：In our last A/B test, the collapsible layout increased task completion by 25% on 13-inch laptops.
Point（再主張）：So overall, the collapsible sidebar will improve both usability and responsiveness.
これだけで、内容が一気に「議論に使える情報」になります。
PREPは、設計レビュー・議事録・プレゼンのどんな場面でも使えます。
型②｜“So What?”を起点にする
これは特にグローバル環境において、評価される発言に欠かせない思考です。
結論を述べたあとに、「で？それって何に効くの？」と突っ込まれたとき、“So What?”に答えられるかどうかで、発言の価値が決まります。
たとえば：
“We changed the component size from 32px to 24px.” → So what?
“It saves 20% vertical space, allowing more information above the fold, improving scanability.” → 評価される発言！
この“意図や影響まで含めて話す力”は、非ネイティブでも十分に鍛えられます。
逆に、これがないと「細かい話ばかりで目的が見えない」と扱われることも。
英語の語彙より、“文脈の設計”が評価されるポイントなんです。
型③｜MECE（モレなくダブりなく）で整理する
「この案の選択肢は何があるか？」「どのくらいリスクがあるか？」という話題になるとき、役立つのが**MECE（Mutually Exclusive, Collectively Exhaustive）**の発想です。
例：新しいUI設計のアプローチとして3案を比較する時：
“We considered three mutually exclusive layout options:
(1) a tab-based layout,
(2) an accordion layout, and
(3) a single-scroll page.
Each has pros and cons in terms of user discoverability, responsiveness, and content density.”
ここで重要なのは「網羅感」と「分類の明確さ」。
MECEを意識するだけで、あなたの発言が**「整理されている」「設計者視点がある」**と高く評価されるようになります。
これはまさに、WPFのUI構成をViewModel単位でモジュール化してきた経験が活きる部分。技術の整理力＝発言の説得力に変換できるのです。
型④｜KPT法で振り返り発言を整理する
チームの振り返り（Retrospective）や定例会議での発言には、KPT（Keep/Problem/Try）のフレームワークが使えます。
- Keep：What worked well
- Problem：What didn’t go well
- Try：Suggestions for improvement
例えば：
“Keep: The new release process reduced downtime by 50%.
Problem: But we still had confusion over branch naming.
Try: Let’s introduce a clear branch-naming convention and add it to our checklist.”
この形式で発言するだけで、「この人は構造的に考えられる」「改善の視点がある」と感じてもらえます。
型⑤｜“インサイト型”コメントで差をつける
最後に、もっとも評価される発言の型。それが**“洞察（Insight）”を提供する型**です。
例：
“I noticed that most users don’t interact with the right-hand panel unless there’s a visual cue. Maybe we can test highlighting the icon or using a subtle animation?”
これは、「何が起きたか（事実）」だけでなく、「なぜ起きているか（仮説）」を添えて話す技術。
ここまで来ると、あなたの発言は単なる情報共有を超え、プロダクトに価値を生む発言として認識されます。
伝え方の型は、“武器”として身につけられる
これらの発言テンプレートは、英語力とは別軸の「戦術」です。
そして、WPFでのUI設計に構造化の発想が求められるように、会議でも構造がある発言は信用を生む。
今日からすぐできることは、この3つ：
- 結論から話す（PREPのP）
- “So What?”を意識する
- 発言の前に、5秒だけ構造を考える
あなたの中にあるアイデアや経験は、必ず評価される価値があります。
あとは、それを「伝わる形」に変換するだけです。
ノンネイティブの“弱み”を“強み”に変える：話せないことを恐れない技術
「発言の“型”はわかった。…でも、それを瞬時に英語で話すのが難しいんだよ」
そんな声が聞こえてきそうです。
わかります。僕自身も、PREPだのMECEだの、理屈では理解していても、実践となると頭が真っ白になることが何度もありました。
でも、ここで大事なのは、**「完璧に言うこと」ではなく、「伝わる形を意識していること」**です。
そして、その“意識の差”こそが、ノンネイティブでも評価される会議発言を生むんです。
ネイティブじゃないからこそ、「構造」で勝てる
英語ネイティブの会話は、時に雑談のように流れていきます。
でも実は、非ネイティブが同じテンポで話そうとすると、情報が曖昧になって伝わらないことが多い。
たとえば、ネイティブがこんなふうに話していたとします：
“Yeah, I was just thinking maybe like, we could go with a more flexible layout. You know, just to give users a bit more room or something…”
聞き取れたとしても、「結局何が言いたいのか」がわかりにくいですよね。
でも、同じ意図をノンネイティブがシンプルで構造的に言えば、むしろチームにとっては“明快な意見”になるんです。
“I suggest using a flexible layout. It would give users more space, especially on smaller screens.”
英語力の差を“構造の明確さ”で埋める。
これが、ノンネイティブにできる最大の強みです。
「沈黙」も、戦略になる
もうひとつ、意外に見落とされがちなのが、“沈黙”の使い方。
日本人はよく「黙ってると評価されない」と思いがちですが、無理に話して曖昧になるより、考えてから話す方が圧倒的に信頼されるのが海外会議です。
僕の実体験ですが、ある設計会議で急にアイコンの意味について意見を求められたとき、焦って中途半端な英語で答えかけたのを、グッと止めて、こう言いました：
“Let me take 10 seconds to organize my thoughts.”
（ちょっと考えをまとめさせてください）
そして、15秒後にこう続けました：
“The icon looks intuitive at first, but we may need a tooltip because some test users thought it was a button.”
結果、議論は深まり、「そうだね、それ重要だ」と賛同が得られました。
焦って話すより、沈黙を挟んで整理するほうが、ずっと“聞かれる発言”になる。
これは、ノンネイティブだからこそ使える「間の技術」なんです。
「短く話す」ことが、むしろ評価される
ネイティブでも話が長い人は多いです。
でも実は、短く、構造的に話せる人ほど、グローバル会議では“プロフェッショナル”扱いされやすい。
特に海外のマネージャーたちは、「判断材料になる情報」を短く明快に提示することを評価します。
例：会議で進捗を聞かれた時──
×
“Umm, so I’ve been working on the new feature… and it’s kind of going okay, but I faced some bugs…”
◎
“Feature X is 70% complete. Found two bugs. Will fix by tomorrow noon.”
この「情報 → 状況 → 対応策」のような**“報告フォーマット”の習慣化**は、技術的に冷静な印象を与えます。
**英語で話す量を増やすことより、内容を磨くことの方が、遥かに“評価される”**という逆転現象が、ここにあります。
「完璧じゃない英語」の方が、伝わることがある
もう一つ、大切な真実があります。
それは、完璧な英語より、「あなたの視点」が伝わる方が大切だということ。
あるとき、僕は英語が堪能な現地メンバーにこう言われました。
“I really like how you explain things. It’s always clear, and I don’t need to guess what you mean.”
僕はネイティブのように流暢じゃない。でも、PREPで話すようにしていたから、構造がわかりやすかったらしい。
「英語が上手いかどうか」ではなく、「相手が理解できるかどうか」が本質なんです。
発音や文法に自信がなくても、構造と意図が伝わる発言をすれば、それだけで十分武器になります。
まとめ｜“伝え方”は、非ネイティブの逆転スキル
「話すのが苦手だから評価されない」は、思い込みです。
むしろ僕たちノンネイティブは、“話しすぎないこと”“構造的に伝えること”で、会議の中で信頼を勝ち取ることができます。
✅ あえて黙る勇気を持つ
✅ 話す前に10秒、構造を考える
✅ 短く明快に話すスタイルを貫く
✅ “完璧な英語”より、“伝わる意図”を優先する
これだけで、あなたの発言力は格段に評価されるようになります。
英語がハンデにならない。むしろ、“設計思考”をもつエンジニアとしての強みに変えられるんです。
“発言力”がキャリアを変える：会議で信頼される人になるロードマップ
ここまで、英語会議で評価される発言の「型」や「意識の切り替え」、そしてノンネイティブとしての“逆転戦略”を紹介してきました。
最終パートでは、「それがキャリアにどう影響するのか？」という問いに向き合います。
実は、“発言力”はただの会議スキルではありません。
グローバルなキャリアで“抜擢される人”と“そうでない人”を分ける、決定的な力です。
“技術があるのに目立たない”という落とし穴
多国籍チームに入って驚くのは、技術スキルだけでは評価されにくいという現実でした。
あるプロジェクトで、僕はWPFのカスタムテンプレートを使った柔軟なUI構成を一人で黙々と構築していました。
技術的にはかなり評価される内容だったし、動作も安定していた。
でも、会議ではその詳細にあまり触れられることはなく、リーダーからも「Good job」の一言だけ。
一方で、プロジェクトの中で常に簡潔に進捗を報告し、設計方針の意図を明確に説明していた別のメンバーが、次期リーダーに選ばれました。
このとき初めて、**「成果は“伝えて初めて評価される”」**という現実を、痛感しました。
会議で“信頼が残る人”の発言習慣
信頼される発言には、共通点があります。
1. 結論から話す人
→ 聞き手の思考負荷を減らす
→ どんな会議でも“話がわかりやすい人”として認知される
2. 自分の意図・背景を添える人
→ “この人の発言には考えがある”と思われる
→ 意見が通りやすくなる、議論に重みが出る
3. 質問やツッコミを歓迎する姿勢がある人
→ 対話的な空気を生み、チームへの安心感を与える
→ リーダー候補として見られやすくなる
4. 常に「なぜこの発言をするのか」を意識している人
→ 発言が“ノイズ”ではなく“判断材料”になる
→ 評価者からの信頼度が上がる
つまり、発言の内容そのものより、「どう話すか」「なぜ話すか」の視点を持っている人が、最終的に信頼されるんです。
海外チームで“引き上げられる”人の特徴とは？
僕の周囲では、同じスキルレベルでも、**「発言がチームの意思決定に影響を与えているかどうか」**がキャリアの分かれ目になっていました。
たとえば、あるインド出身のエンジニアは、英語は比較的訛りが強く、話すスピードもゆっくりでした。
でも彼は常に「誰が次に何をすべきか」「なぜそうすべきか」を構造的に説明していました。
結果、チームの中で「この人が言うならやろう」と自然に信頼が集まり、2年後にはテックリードに昇進。
彼が話していたのは、**“完璧な英語”ではなく、“整理された意見”と“行動を促すメッセージ”**だったんです。
“設計力”を武器にすれば、話し方はキャリアに変わる
ここで、WPFやC#でUI設計をしてきたエンジニアの皆さんに伝えたいのは、
「話す」ことも、UI設計と同じく“設計できるスキル”だということ。
- どんな順番で情報を提示すれば理解されやすいか？
- どこに論理の支柱（＝根拠や意図）を入れれば、相手の判断が加速するか？
- どういう見せ方にすれば、ユーザー（＝聞き手）のアクションが起きるか？
そう、これはまさに「UIアーキテクト」が日々考えていることと一緒です。
あなたが画面の中で実践してきたその思考、会議という“対話のUI”の中でも、存分に活かせます。
“設計者の言葉”が、世界で求められている
最後に。
グローバルチームでは、求められるのは「よく喋る人」ではありません。
考え抜かれた設計を、必要な人に、わかりやすく伝えられる人です。
あなたが黙って築いてきた設計力には、世界で通用する説得力があります。
あとは、それを**相手に届く“形”にすること。**それだけで、評価は一変します。
発言力の育て方：ロードマップまとめ
🔧 ステップ1｜話す前に構造を意識する
PREP・MECE・So What構造で、頭の中を一瞬で整理。
🧠 ステップ2｜短くてもいいから意図を込めて話す
完璧を目指さず、「何を伝えたいか」に集中。
🧱 ステップ3｜フィードバックをもらい、型を磨く
1on1やレビュー会議で、伝え方について相談してみる。
🚀 ステップ4｜“発言”を成果として記録する
会議の議事録・要約・チャットへのフォローアップで発言の影響力を可視化する。
この積み重ねが、「評価される人」の土台をつくります。
コメント