海外エンジニアとしての第一歩：技術を超えて「伝わる」設計を作るまで

はじめに

こんな挑発的な言葉を聞いたら、きっと「いやいや、そんな世界あるわけないでしょ」とツッコミを入れたくなるはずです。僕も最初はそうでした。

僕は日本でC# WPFを使って設計開発をしていたエンジニアです。国内での開発経験を重ね、それなりに自分の設計やコードに自信を持つようになっていた頃、思い切って海外の現場に飛び込むことにしました。そこには「技術力があれば、きっと世界中どこに行っても通じるはずだ」という淡い期待もあったんです。

でも現実は甘くありませんでした。

海外に出て最初にぶつかった壁は、「自分の設計が相手に理解されない」 ということでした。設計レビューで画面レイアウトやアーキテクチャの説明をしても、相手が首をかしげている。
「いやいや、このフローを見れば一目瞭然でしょ？」と思うんです。でも、実際には一目瞭然どころか、相手の頭の中にクエスチョンマークが浮かんでいるのが手に取るようにわかる。

もちろん英語の問題もありました。自分の説明がシンプルに伝わっていないのかもしれない。でも、それだけじゃなかったんです。
同じコード、同じUI設計を見ているのに、文化やバックグラウンドが違うと、解釈の仕方が全く違う。日本では常識と思っていた「UIの並び順」や「例外処理の書き方」も、海外チームからすると「なんでそんなやり方を？」となる。

最初は正直、めちゃくちゃ挫けました。
「自分の設計力って、実は全然通用しないんじゃないか？」
「英語だけじゃなくて、技術的な根本の部分も伝わってないんじゃ？」

会議のあと、自分のノートには「Not clear」「Need to explain again」と赤字でメモが残る。設計ドキュメントを出したのに、結局はもう一度ホワイトボードの前でゼロから説明させられる。そういう日々が続きました。

でも、ある瞬間に気づいたんです。
「理解されないのは、英語力が足りないからじゃなくて、相手の頭の中にある“当たり前”と、自分の“当たり前”がズレているからだ」 って。

例えば、日本の現場だと「UIは左から右へ情報が流れる」っていう感覚がありますよね。でも、ある国のメンバーにとっては「重要なボタンは画面の中央か右下に置くのが当然」だったりする。
僕が「直感的にわかるでしょ？」と思って置いたボタン配置は、彼らからすると「なんでこんなに分かりにくいの？」になるわけです。

この「当たり前のズレ」が、チーム全体の理解を難しくしていた。

――つまり、問題は英語力やコードの質ではなく、**技術を越えた“認識の橋渡し”**ができていないことだったんです。

ここから僕の奮闘が始まりました。
最初は悔しさと戸惑いからでしたが、次第に「どうすれば自分の設計が“伝わる”のか？」というテーマに挑戦するようになったんです。

この挑戦は、ただの技術スキルを磨く話ではありませんでした。
それは、「相手の文化や考え方に一歩踏み込み、技術を相手の視点で説明する力」を身につける旅でもあったんです。

――そして、その一歩が僕にとって海外エンジニアとしての“本当のスタートライン”だったのです。

伝わらない設計からの逆転 ― 僕が試した具体的アプローチ

「自分の設計が理解されないのは、英語が下手だからじゃない。文化や“当たり前”が違うからだ。」
そう気づいた瞬間、僕の視点は大きく変わりました。

それまでは「どうやって英語をもっと正しく話せばいいか？」ばかりを考えていました。でも、もし相手の前提が違うなら、いくら正しい英語を話しても伝わらないのは当然。むしろ 「どうやって相手の頭の中にある地図に合わせて説明するか」 が勝負なんだと気づいたんです。

1. 設計レビューで「絵」を先に出す

最初にやったのは、文章よりも図を先に出すことでした。
日本では「設計書を書いて、そこに図を添付する」という流れが一般的でしたが、海外チームとやりとりしてみると、文章を読んでくれる人が圧倒的に少ない。レビューの場で「ドキュメントの2ページ目を見て」と言っても、みんなすでに別のことを考えている（笑）。

そこで逆に、最初に絵を見せて、それを軸に話すスタイルに切り替えました。

例えば、WPFの画面フローを説明するとき、

  • 文章：画面Aから画面Bへ遷移し、条件によって画面Cに進む
  • 図：矢印でつながったスクリーンショットやワイヤーフレーム

この二つを比べると、図のほうが圧倒的に早く理解されました。
しかも、絵をベースに話すと、相手からのフィードバックも具体的になるんです。
「この矢印の方向が逆じゃない？」とか「ここにCancelボタンはないの？」みたいに。

文章では抽象的に流れてしまう議論が、図を使うだけで一気に“同じ地面に立てる”感じがしました。

2. 「Why」を最初に話す

もう一つ大きく変えたのは、説明の順序です。
日本の現場だと「仕様を細かく積み上げていき、最後に全体像を示す」という説明が多かった気がします。でも、海外のエンジニアはその逆。

彼らがまず知りたいのは「なぜこの設計が必要なのか？」という背景でした。
「この画面はユーザーが初回ログイン時に必ず通る。だからシンプルさを最優先した」
「このクラス構造は、将来的に拡張しやすいようにした」

こういう「Why」を先に伝えると、その後の細かい設計がスムーズに理解されました。
逆にWhyを言わずにHowだけ話すと、相手は「で、なんでその方法なの？」と途中で止まってしまうんです。

これは僕にとって大きな学びでした。設計はHowの積み重ねじゃなく、Whyを軸に説明しないと国境を超えて伝わらない。

3. 「Yes/No」をはっきり言う練習

さらに僕が苦労したのは、意思表示の明確さです。
日本の現場だと「まぁ大丈夫だと思います」とか「検討してみます」という曖昧な言葉が許される場面が多いですよね。ところが海外だと、それは「YesなのかNoなのか結局わからない」と受け取られる。

設計のレビュー中に「This logic is fine?」と聞かれて、「I think so… maybe」と答えると、一気に場の空気が微妙になるんです。相手からすると「どっちなんだよ！」ってなるわけです（笑）。

そこで意識的に、Yes/Noをはっきり言う練習をしました。
「Yes, but we need to adjust one point.」
「No, because this logic will break in case of X.」

最初は勇気がいりました。でも、言い切ったほうが議論が早く進むし、相手も安心してくれることに気づいたんです。

4. 「小さな成功体験」で自信を積み上げる

こうした工夫を少しずつ試すうちに、徐々にチームの反応が変わっていきました。
以前は「Not clear」「Explain again」と言われていたレビューが、今度は「Got it」「That makes sense」と返ってくる。

小さな一歩ですが、この積み重ねが僕にとって大きな自信になりました。
「自分の設計は、ちゃんと国を越えて伝わるんだ」
そう思えるようになったことで、次の挑戦に踏み出す勇気も出てきました。

5. 技術だけじゃない「共感力」

特に大きかったのは、相手の立場を想像する力が少しずつ鍛えられていったことです。
「この人はバックエンド寄りのエンジニアだから、UIの細かい話は退屈に感じるかもしれない」
「この人は新人だから、抽象的な説明よりもコード例を見たいはず」

そうやって相手の頭の中に寄り添って話すと、設計が伝わるスピードも精度も全然違う。

気づけば僕は「設計を作ること」と同じくらい「設計を伝えること」にエネルギーを注ぐようになっていました。

この頃から、僕の中にひとつの疑問が生まれました。

「もし技術力と同じくらい“伝える力”を鍛えたら、エンジニアとしてどこまで成長できるんだろう？」

その答えを探すように、僕はさらに工夫を重ねていくことになります。
そしてその過程で、“技術を超えたコミュニケーションの武器”を少しずつ手に入れていったのです。

最大の挫折と、突破口となった“逆転の一手”

ここまで順調に見えるかもしれませんが、正直に言うと僕は一度、大きく挫けています。
「Whyを先に伝える」「Yes/Noを明確にする」「図を使う」――こうした工夫でだいぶ改善したと思っていたんですが、ある日、それが完全に通じなくなった瞬間がありました。

1. 大規模プロジェクトでの衝突

その頃、僕は海外の大手クライアント向けに、新しい業務システムのUI設計を任されていました。
C# WPFを使った大規模アプリケーションで、要件も複雑。しかも期限はタイトで、レビューの場には海外拠点のPMやアーキテクトが勢揃い。いわば「この場で設計が認められなければ、全部やり直し」という緊張の場でした。

僕は準備に準備を重ねました。

  • 画面フローの図を用意する
  • 「Why」を先に説明するスクリプトを作る
  • 英語での質疑を想定して答えを用意しておく

万全だと思って挑んだんです。

しかし、会議は最初から空気が悪かった。

「This layout looks confusing.」
「Why are you using this control here?」
「I don’t think this is user-friendly at all.」

次から次へと厳しい指摘が飛び、僕の説明はことごとく遮られました。
「Wait, can you clarify?」「That doesn’t make sense.」

気づけば僕は防戦一方。
頭の中では「いや、ちゃんと理由はあるのに！」と叫んでいるのに、言葉にすると「I mean… because…」としどろもどろ。
最終的にPMからは「We need a redesign.」と冷たく言い渡され、会議は終了しました。

あのときの絶望感は今でも覚えています。
「こんなに準備したのに、全然伝わらない。やっぱり自分には無理なんじゃないか。」

2. 言葉じゃなく「視点」が違った

その日の帰り道、僕は自分のノートを見返しました。そこには無数のメモと矢印、図、理由の書き込み…。
「伝える努力は確かにした。でも、なぜここまで響かなかったのか？」

悶々と考えているうちに、ふと気づいたんです。
僕は“自分が考えた設計を正しく理解させよう”としていただけで、相手が欲しい視点に立っていなかったんじゃないか？

相手が求めていたのは「僕の設計の正しさ」じゃなく、

  • ビジネス側の人が「ユーザーが迷わないか」を知りたい
  • アーキテクトが「パフォーマンスや拡張性は大丈夫か」を確認したい
  • PMが「スケジュール内に収まるのか」を把握したい

――つまり、聞き手ごとに“見たい世界”が違ったんです。

僕はそれを全部ひとまとめに「これが正しい設計です！」と押し込んでいた。
だからどの立場の人にも中途半端にしか届かず、結果として「Not clear」になったんだと。

3. 突破口 ―「相手の言葉で語る」

この気づきから僕が試したのは、説明を相手の視点に合わせて切り替えることでした。

次のレビューでは、まずPMに向けて「スケジュール上、どの部分がリスクか」をシンプルに説明。
次にアーキテクトには「処理の並列化を想定して、この構造にした」と技術的な根拠を示す。
そしてビジネス側には「初回ログイン時にユーザーが3クリック以内で操作を完了できる」とユーザー体験の言葉で話す。

同じ設計でも、相手ごとに“翻訳”して話すんです。

すると驚くほど反応が変わりました。
PMは「That’s clear. Thanks.」と頷き、アーキテクトは「Good, performance seems fine.」と納得し、ビジネス側も「ユーザー目線でいい」と評価してくれた。

このとき、僕は心の底から実感しました。

**「設計はコードや画面そのものじゃなく、“相手の理解”の中に完成する」**って。

4. 技術を超えた武器 ―「テクニカル・エンパシー」

僕が見つけた突破口は、一言でいうと Technical Empathy（技術的共感力） でした。
これは「自分の技術を相手に押し付ける」のではなく、相手の立場や文脈を理解し、その視点で技術を説明する力です。

  • コードレビューなら、相手が新人かベテランかで説明の深さを変える
  • UI設計なら、相手がユーザー視点かアーキ視点かで強調点を変える
  • スケジュール調整なら、技術的な難しさを「日数」という数字で伝える

こうした工夫を積み重ねることで、会議は驚くほどスムーズになっていきました。
以前なら「Not clear」で終わっていたやりとりが、今では「Got it」「That works」と前に進む。

もちろん、全てが完璧に伝わるわけではありません。でも、少なくとも「伝わらない苛立ち」や「同じ説明を繰り返す無駄」は劇的に減ったんです。

5. 挫折が残したもの

振り返ると、あの大規模プロジェクトでの挫折は、僕にとって転機でした。
「自分の設計を守る」ことばかり考えていた僕が、「相手の視点で語る」ことを学んだからです。

あのとき痛い思いをしたからこそ、“伝える”を技術と同じくらい重視するエンジニアになれた。
もしあの失敗がなかったら、僕はいまだに「Not clear」と言われ続けていたかもしれません。

海外で戦うエンジニアへのメッセージ ― 「伝える力」が未来を変える

大規模プロジェクトでの挫折を経て、僕は「Technical Empathy（技術的共感力）」の重要性に気づきました。
そして、その学びを日々の仕事に活かしていくうちに、少しずつですが確かな変化が現れ始めました。

1. チームの空気が変わる

以前はレビュー会議のたびに、
「Not clear」「Explain again」
と突っ込まれ、何度も同じ説明を繰り返すのが当たり前でした。

でも今では、レビューの場で僕が話し始めると、相手の反応が前向きになっているのを感じます。

  • PMは「この設計ならスケジュールに収まる」と安心する
  • アーキテクトは「この構造なら将来の拡張に耐えられる」と納得する
  • ビジネス側は「ユーザーにとってわかりやすい」と評価する

同じ設計を説明しているのに、相手ごとに響き方が違う。
それを意識して言葉を選ぶだけで、場の雰囲気が驚くほど変わったんです。

何より大きかったのは、会議が「防戦」ではなく「共創」の場に変わったこと。
以前は「自分の設計を守らなきゃ」という気持ちで必死でしたが、今は「一緒により良いものを作ろう」という空気に変わっています。

2. 信頼される存在になる

「この人の設計はわかりやすい」「説明がクリアだ」
そう言われるようになってから、僕への期待も変わりました。

ある日、上司からこんな言葉をもらいました。
「君は単にコードを書く人じゃなくて、チームをつなぐ“橋渡し”になっている」

その瞬間、胸の奥が熱くなりました。
かつて「Not clear」と言われ続け、自信を失いかけた自分が、今ではチームの中で「伝わる人」として見られている。

これは技術力だけでは得られない信頼です。
むしろ、伝える力があるからこそ、技術力が活きる。
それを実感したとき、海外で働くエンジニアとしての自分の立ち位置が、ようやく定まった気がしました。

3. 自分自身の成長

もちろん、僕は今でも完璧ではありません。
言葉が出てこなくて詰まることもあるし、相手の意図を誤解することもある。

でも以前と違うのは、失敗を恐れなくなったことです。
「伝わらなかったらどうしよう」ではなく、
「伝わらなかったら別の角度で説明すればいい」
と思えるようになったんです。

これは小さなことのようでいて、実は大きな違いです。
恐怖ではなく挑戦の気持ちで会議に臨めるようになったことで、僕は一段と仕事を楽しめるようになりました。

4. これから海外を目指すエンジニアへ

最後に、これを読んでくれている「これから海外で働こう」と考えているエンジニアのあなたに、僕から伝えたいことがあります。

  • 英語が完璧じゃなくても大丈夫です。
  • コードが100%正しくても、それだけでは伝わらないことがあります。
  • 大事なのは「相手の視点に立って話す」ことです。

つまり、技術を翻訳する力です。
それは辞書的な翻訳ではなく、相手の文化・立場・役割に合わせて言葉を変えること。
そしてその結果、設計やコードが「相手の頭の中で意味を持つ」瞬間が生まれる。

その力を僕は「Technical Empathy」と呼んでいます。

海外で働くと、必ず壁にぶつかります。
「伝わらない」「理解されない」「誤解される」――そんな経験は避けられません。
でも、それは決してあなたの能力が足りないからではなく、文化や前提の違いがあるだけです。

その違いを越えるために必要なのは、完璧な英語でも、天才的なアルゴリズムでもありません。
必要なのは、相手の頭の中に入り込む勇気と、共感する力です。

5. 未来を切り拓くために

僕が学んだのは、エンジニアという職業が単なる「技術を作る人」ではないということです。
エンジニアは、文化を越えて人をつなぐ橋になれる。
設計図を通して、世界中の人たちと未来を形にできる。

それは決して特別な才能ではなく、誰にでもできること。
「伝わる」ことにこだわり、小さな工夫を積み重ねれば、必ず到達できる場所です。

だから僕は声を大にして言いたい。

👉 Imagine a world where your technical designs are understood without a hitch, and cross-cultural tech teams operate like a single mind. Sound impossible? It’s not.

僕はその世界を、ほんの少しだけど体験しました。
そしてあなたも、きっとそこにたどり着けます。

コメント

タイトルとURLをコピーしました