Ever wonder why some technical explanations just click, while others leave you completely lost?
僕自身、海外でエンジニアとして働き始めた頃、これを痛いほど実感しました。コードが書けるだけじゃダメ。設計図を完璧に仕上げるだけでも足りない。なぜなら、「それをどう説明するか」で仕事の評価がガラッと変わるからです。
日本で働いていた時は、正直そこまで「説明力」を意識したことはありませんでした。ドキュメントは丁寧に作っていたし、レビューの場では質問に答えられる程度の準備をしていた。でも、海外に出ると状況が全然違うんです。
会議の空気はスピード勝負。長い前置きや回りくどい説明をしていると、すぐに「So what’s the point?（で、要点は？）」と遮られる。僕にとっては衝撃でした。せっかく時間をかけて作った説明資料も、要点がぼやけていると一瞬でスルーされてしまうんです。
そして何より、自分の英語力の限界も痛感しました。
「文法を間違えずに話さなきゃ」「ネイティブみたいに言えなきゃ」と思えば思うほど、言葉が出てこなくなる。気づけば、言いたいことの半分も伝えられないまま会議が終わってしまう。そんなことが何度もありました。
そこで僕がたどり着いたのが、**「コードを物語に変える」**という発想です。
たとえば、あるWPFアプリのUI設計をレビューする場面を思い出します。
日本的なやり方だと、まず「仕様」「画面遷移」「データバインディングの流れ」を順番に説明することが多いですよね。でも海外では、それだけだと相手の頭に残らない。会議が終わった後に「あの設計ってどういう狙いだったっけ？」と聞かれてしまう。
じゃあ、どうすれば覚えてもらえるのか？
僕が学んだのは、「ストーリーで語ること」でした。
つまり、
- このアプリは誰のためにあるのか
- ユーザーはどんな課題を抱えているのか
- その課題を、僕たちの設計がどう解決するのか
これを冒頭で語るだけで、聞き手の理解度と集中力がまったく変わるんです。
僕はある時から、コードやUIを「キャンバスに描く絵」に例えるようにしました。
「この画面の役割はこうで、ここがメインのストローク。この部分は背景のように支えている。だから見た目以上に重要なんだ」
そんな風に説明すると、チームメイトの表情が一気に変わるんです。
「なるほど、だからこのデザインなんだ」
「それなら、この部分をもっと強調したほうがいいかもしれない」
議論が“生きたもの”になる瞬間でした。
もちろん、最初からうまくいったわけじゃありません。
英語でストーリーを語るのはハードルが高い。単語が出てこなくて「えーっと」を繰り返すこともしょっちゅうでした。だけど、気づいたんです。完璧な文法よりも、伝わるイメージのほうが強いってことに。
例えば、
「This function is like the backbone of our app. Without it, nothing stands.」
と比喩を入れるだけで、相手の理解度が跳ね上がる。
僕の拙い英語でも、例え話を交えると「あぁ、そういうことね！」と笑いながら理解してくれる。そこから議論が広がっていく。
つまり、「コードからキャンバスへ」発想をシフトすることが、海外で戦うエンジニアとしての僕の武器になったんです。
この経験から学んだのは、
- コードは単なるロジックの集合じゃない
- 説明はストーリー化することで相手の心に届く
- 英語力よりも、伝える工夫が勝負を分ける
ということ。
そして、この「伝える技術」はエンジニアリングスキルと同じくらい大切だと実感しました。
「失敗から学んだ、“伝える力”の磨き方」
「コードをストーリーに変える」と気づいた僕ですが、当然、最初からうまくできたわけではありません。
むしろ失敗だらけ。そこからどうやって改善していったかが、僕にとって大きな学びのステップになりました。
英語力の壁よりも大きなもの
最初の頃、僕は「伝わらない理由＝英語力不足」だと思い込んでいました。だから語彙を増やそうと必死で勉強したし、ネイティブっぽい表現を真似しようと努力もしました。
でも現実は違ったんです。
あるUIレビュー会議でのこと。僕は事前にスクリプトを準備して、ほぼ暗記して挑みました。緊張しながらも、用意した説明を一通り言えたときは「よし、やっと伝えられた！」と安堵したのを覚えています。
ところが会議後、同僚がこう言ったんです。
「Your explanation was clear, but I couldn’t really see why this design matters.」
つまり、文法的に正しくても、内容が“刺さらなかった”んです。
その瞬間、僕は痛感しました。問題は言語そのものじゃなく、“物語をどう組み立てるか”にあるんだと。
「聞き手の視点」に立つ練習
そこで僕が次に試したのは、**「聞き手ファースト」**の説明法。
つまり、自分が言いたいことから入るのではなく、相手が知りたいこと、気になることからスタートするやり方です。
たとえば、ある機能の実装について説明するとき。
以前の僕なら、
「We used MVVM pattern here, with data binding to handle the view updates…」
と、いきなり技術的な話に突入していました。
でも聞き手の多くは、非エンジニアや別分野の開発者。そんな専門用語を最初から並べられても、理解が追いつかないんです。
そこで発想を変えて、まずこう言うようにしました。
「ユーザーは画面の操作をなるべくシンプルにしたい。でも従来の仕組みだと複雑な更新処理が必要になる。そこで僕らはMVVMパターンを使って、その煩雑さを裏側で吸収したんです。」
同じ内容でも、「課題 → 解決策 → 技術」という流れで話すと、みんなの表情が変わるんです。うなずきながら聞いてくれるし、そのあとで細かい技術に踏み込んでもちゃんとついてきてくれる。
このとき僕は、説明はコードを書くのと同じで「相手が読みやすい順番」に整理することが大事なんだと気づきました。
例え話の威力
次に試したのが、比喩やアナロジーです。
英語が完璧じゃなくても、例え話を入れると相手の理解度が一気に上がる。
あるとき、データフローの複雑さを説明する必要がありました。言葉だけで説明するとどうしてもややこしい。そこで僕はこう言ったんです。
「Think of it like a train station. Each module is a platform, and data is like the train. It arrives, stops, and then departs to the next platform. If one platform is blocked, the whole flow is delayed.」
その瞬間、会議室に「あぁ〜！」という声が広がったんです。
誰もが駅のイメージを知っているから、一発で腑に落ちる。
そのあとで、「具体的にどのモジュールがボトルネックか」という話に入ったら、議論がスムーズに進みました。
つまり、テクニカルな説明に“身近なイメージ”を差し込むことで、理解のハードルを一気に下げられるんです。
小さな改善の積み重ね
もちろん、毎回うまくいったわけではありません。
例え話が伝わらず「それ、逆にわかりにくい」と笑われたこともあります。説明の順序を工夫したつもりが、話が長くなって結局「So, what’s the point?」と突っ込まれたこともありました。
でも、その失敗の一つひとつが「改善のネタ」になったんです。
- 会議後に同僚へ「どの部分がわかりやすかった？」とフィードバックをもらう
- 自分の説明を録音して、テンポや単語の使い方を振り返る
- TED TalkやYouTubeの技術解説を見て、構成の真似をしてみる
そうやって試行錯誤するうちに、少しずつ「伝わる説明」が板についてきました。
「文化の壁にぶつかった、“伝わらない説明”」
ここまでの話だと、なんとなく「説明力は工夫すれば改善できる」という前向きなムードに聞こえるかもしれません。
でも、実際にはもう一段深い壁がありました。
それが、**文化や価値観の違いが生む“伝わらなさ”**です。
技術は正しい。でも納得されない。
ある大規模なプロジェクトで、WPFを使った業務アプリのUI設計を担当していたときのこと。
僕は「ユーザー操作を最小化する」という観点で、画面遷移を大胆に省略した設計を提案しました。
日本でなら「効率的ですね」と素直に受け入れられそうな内容。実際、内部のテストでもかなり操作性が向上することが確認できていました。
ところがレビュー会議では、思いもよらぬ反応が返ってきたんです。
「But isn’t this too simple? Users might get confused without clear steps.」
僕にとっては「シンプル = 良い」だったのに、相手にとっては「シンプルすぎる = 不安」という評価だったんです。
僕は思わず、「でも操作数が減りますし、効率も良くなるんですよ」と強調しました。
しかし相手は首を横に振るばかり。最後には「I don’t feel comfortable with this approach」とまで言われてしまいました。
論理的には正しいはずの説明が、文化や感覚の違いでまったく響かない。
このとき初めて、「伝える」には技術や言語以上に文化の読み解きが必要なんだと痛感しました。
「安心感」を重視する文化とのズレ
僕がいたチームはヨーロッパ出身のメンバーが多かったのですが、彼らのユーザー体験に対する価値観は「明示性」や「予測可能性」を重んじるものでした。
- 日本的な発想 → 「使えば慣れるから、シンプルさ優先」
- 彼らの発想 → 「誰でも迷わないように、ステップは多少冗長でも明示する」
この違いを理解していなかった僕は、いくら「効率」を説いても納得されないわけです。
つまり、「どんなに論理的でも、相手の文化的背景に沿っていなければ伝わらない」。
これが僕にとっての大きな転機になりました。
説明を「翻訳」するという発想
その後、僕は自分の説明を単なる英語への翻訳ではなく、文化的な翻訳に切り替えるようにしました。
同じ設計を説明するときでも、
- 日本的な価値観の人に対しては「無駄を削って効率的に」
- ヨーロッパ的な価値観の人に対しては「ユーザーの安心感を優先しながら効率も確保」
という切り口で語るようにしたんです。
実際に会議でこんな説明をしました。
「Yes, this design reduces steps, but more importantly, it guides the user with clear signals at each point. That way, they don’t feel lost, even though the process is shorter.」
同じUIでも、「効率化」より「安心感」を前面に出すと、みんなが納得してくれる。
つまり、相手の価値観に合わせてストーリーを語り直すことが、文化をまたいで働くエンジニアには不可欠だったんです。
衝突から共創へ
この文化的なズレは、ときに衝突を生みました。
ある会議では、僕が「とにかくステップを減らしたい」と主張し、相手が「とにかく明示性を高めたい」と譲らず、30分以上平行線をたどったこともあります。
そのとき、マネージャーがこう言いました。
「We’re not here to win arguments. We’re here to build something together.」
その言葉でハッとしました。
僕は「正しい説明をすること」に必死になりすぎて、「相手と共に作り上げる」視点を忘れていたんです。
それからは、議論のゴールを「自分の案を通すこと」から「みんなが納得できる解に近づくこと」へと切り替えるようにしました。
たとえば、
- まず相手の価値観を繰り返し言葉にして確認する
- その上で「じゃあ、その安心感を保ちつつ効率を高める方法はないか」と投げかける
こうすることで、議論が「対立」から「共創」に変わっていったんです。
「伝える力は、エンジニアの武器になる」
ここまで振り返ると、僕が海外で学んだのは単なる「英語で説明する方法」ではありませんでした。
むしろ、どうすれば相手と共に未来を描けるかという、もっと根源的なスキルだったんです。
説明は「プロジェクトの推進力」
以前の僕は、「説明＝自分の案を正しく理解してもらうこと」だと思っていました。
でも海外で働くうちに、それだけでは足りないことに気づいたんです。
あるプロジェクトで、期限が迫る中、チームの方向性がバラバラになってしまったことがありました。
- UIの分かりやすさを最優先したいメンバー
- パフォーマンス重視で妥協したくないメンバー
- とにかく納期に間に合わせたいマネージャー
会議は平行線で、誰も譲らない。空気はどんよりして、時間だけが過ぎていきました。
そこで僕は、いつものように「課題 → 解決策 → 技術」のフレームをベースに、ストーリー仕立てで状況を整理してみたんです。
「今、僕らのユーザーは“スピード”を求めている。でもスピードは二つある。ひとつは画面のレスポンスの速さ。もうひとつは、アプリを理解して操作できるまでの速さ。
パフォーマンスを重視する人も、UIの明快さを重視する人も、実は同じ“スピード”を違う角度から見ているんじゃないかな。」
そう語った瞬間、議論の雰囲気が変わりました。
「確かに、同じゴールを見てるのかも」
「じゃあ両立できる部分を探そう」
結果的に、UIを段階的にロードする設計で妥協点を見つけ、無事に期限に間に合いました。
このとき僕は強く実感しました。
説明は単に理解を得るためじゃない。プロジェクトを前に進めるエンジンなんだ。
完璧じゃなくても「伝わる」
もうひとつ大きな気づきがあります。
僕の英語はいまだに完璧じゃありません。発音で笑われることもあるし、会議で言い淀むこともあります。
でも、完璧じゃなくても「伝わる」んです。
なぜなら、相手が受け取るのは「言葉」そのものじゃなくて、そこに込められた意図やストーリーだから。
たとえば、あるプレゼンで僕は緊張して「user experience」を「user experiment」と言い間違えました。会場が一瞬ざわっとしましたが、すぐに笑いに変わりました。
「Well, sometimes experiments lead to better experiences, right?」と冗談めかして返したら、むしろ場が和んで議論が活発になったんです。
この経験から、僕は「正確さ」より「伝える姿勢」のほうがずっと大事だと確信しました。
伝えることは、自分を成長させること
振り返ってみると、僕が「伝える力」を磨く過程は、そのまま僕自身の成長の過程でした。
- 起：英語の壁と「説明が通じない」挫折
- 承：構成や比喩を工夫して「伝わる実感」を得る
- 転：文化の違いに直面し、「共創」の視点を学ぶ
- 結：説明がプロジェクトを前進させ、自分をも成長させる
こうして見ると、説明力は単なるスキルではなく、僕にとってのエンジニアとしての武器になったと言えます。
これから海外で働くエンジニアへ
最後に、これを読んでくれている「これから海外で働くエンジニア」に伝えたいことがあります。
- 完璧な英語は必要ない
- 大事なのは「伝える工夫」。
- 単語が出てこなくても、例え話や図解で補える。
- ストーリーで語れ
- コードや設計は、ただのロジックの集まりじゃない。
- 「誰の課題を、どう解決するのか」という物語にすると一気に伝わる。
- 文化を読み解け
- 自分の常識は相手の常識じゃない。
- 相手の価値観に合わせて説明を「翻訳」することで、本当に理解が得られる。
- 説明はプロジェクトの推進力
- ゴールは「自分の案を通すこと」じゃない。
- 「相手と一緒に前進すること」が最終目的。
終わりに
僕は今でも、毎日のように「伝える難しさ」と格闘しています。
でも同時に、伝える楽しさも感じています。
コードをキャンバスに描き、物語として語り、文化を超えて共有する。
そのプロセスの中で、自分も相手も成長し、プロジェクトも前に進んでいく。
これこそが、僕が海外で学んだ「Code to Canvas」の真髄です。
もし今、あなたが「英語に自信がない」「説明が苦手」と感じているなら、心配はいりません。
大事なのは「伝えようとする姿勢」と「工夫する意識」。
その一歩を踏み出せば、必ず道は開けます。
そしてその道は、あなたをただのエンジニアではなく、仲間を動かし、未来を描けるエンジニアへと成長させてくれるはずです。
コメント