Imagine presenting your technical work not just as data, but as a gripping narrative that enthralls your audience.
最初にこの言葉を聞いたとき、正直「いやいや、コードはコードでしょ。物語なんて大げさだな」って思ったんです。C# WPFの画面設計をしていた僕にとって、コードはいつも「正確さ」と「効率」がすべてでした。バグがなくて動けば、それでよし。デザインパターンやアーキテクチャの正しさが担保されていれば、なおさらよし。そこに「物語性」なんて必要なのか？ っていうのが正直な気持ちでした。
でも海外に出て仕事を始めてみたら、その考えはガラッと変わりました。
プレゼンテーション、チームミーティング、レビュー…どんな場面でも「ただ説明する」だけじゃ相手の心に残らないんです。日本で働いていたときは、「細かく仕様を説明できる」ことが評価されることが多かったけど、海外だとそれだけじゃ足りない。むしろ「どうしてそれが必要なのか」「その設計がどんな未来を描いているのか」まで話せないと、相手は興味を持ってくれません。
最初の衝撃は、入社して数ヶ月たったある日のこと。
僕は新しく導入するWPFベースのUIフレームワークについて、チームに説明する役を任されました。スライドにはきっちり図を入れて、コード例も載せて、「これなら伝わるだろう」と思って挑みました。ところが、プレゼンが終わったあと、上司からこんなフィードバックをもらったんです。
“Your explanation is technically correct, but I can’t see the story. Why should we care about this change?”
直訳すれば「説明は正しいけど、物語が見えない。この変更がなぜ大事なのかが分からない」ってこと。
正直、心にグサッと刺さりました。「え、正しく説明したのに、なんで伝わらないんだ？」って。日本なら「仕様通りで問題なし」と評価されて終わりだったはず。でも海外では、「正しい」だけじゃ通じない。そこに“ストーリー”がなきゃいけないんです。
それ以来、僕は「どうすればコードや設計をストーリーとして語れるのか？」を意識するようになりました。最初は難しかったです。だって、エンジニアってどうしてもロジック優先で話してしまうから。「このアルゴリズムを使えば処理が早くなる」「このUI設計ならバグが減る」っていう説明はできても、「それがチームにどんなインパクトを与えるか」「ユーザーにどう貢献するか」を語るのは苦手なんですよね。
でも、そこで役に立ったのが「自分自身の海外での苦労」そのものだったんです。
例えば「英語が聞き取れない日々をどうやって乗り越えたか」とか、「Yesしか言えなかった自分がどうNoを言えるようになったか」とか。そういう個人的な物語を交えて話すと、相手の目が変わる。エンジニアリングの話でも同じで、「ただ速くなったコード」じゃなく「これでユーザーが待たされずに済む」「サポート担当が夜中に呼び出されなくなる」っていうストーリーを添えるだけで、ぐっと相手に届くようになるんです。
つまり、技術を物語にするってのは「数字やコードに血を通わせること」なんだと気づきました。
僕にとっての「起」は、この気づきから始まりました。海外に出て、ただ正しいだけじゃ通じない現実にぶつかって、「どう伝えるか」が武器になるんだと理解した瞬間です。この“伝える技術”に目覚めたことで、僕のエンジニアとしてのキャリアは大きく変わり始めました。
物語の力に気づいた僕は、「じゃあどうやって技術をストーリーに変えるんだ？」という壁に直面しました。
正直、最初は試行錯誤の連続でした。
日本で働いていた頃は、レビュー会議やプレゼンといえば「正しい設計かどうか」を確認するのが主な目的。だから、コードやアーキテクチャの正当性を説明できれば十分だったんです。でも海外では、会議の空気がまったく違う。
ミーティングの最初から「Why?（なぜ？）」が飛んでくる。
「なぜこのフレームワークを選んだの？」
「なぜこのUI構造にしたの？」
「なぜ今それが必要なの？」
僕は最初、この「Why?攻撃」にボロボロにされました。だって、僕の説明はいつも「技術的に正しいから」ですべて片づけようとしていたから。効率的だから、パフォーマンスがいいから、メンテナンス性が高いから…。でも、それでは相手は納得しない。
あるとき先輩エンジニアに言われました。
“You are explaining the what and the how, but you are missing the why. Without the why, it’s just numbers and code.”
（君は「何を」「どうやって」は説明できているけど、「なぜ」が抜けているんだよ。「なぜ」がなければ、それはただの数字とコードだ。）
その言葉が僕を突き動かしました。
“Why”を語る練習
僕はまず、自分の提案を「物語」として組み立てる練習を始めました。
例えば、あるとき担当したWPFのダッシュボード画面の改善プロジェクト。
従来のダッシュボードは表示が重くて、ユーザーから「読み込みが遅い」と不満が出ていました。日本にいた頃なら「非同期処理に切り替えたので表示速度が改善しました」で終わっていたと思います。
でも海外での僕は、こう言い換えるようにしました。
- Before: 「ユーザーは朝イチでダッシュボードを開くと、毎回10秒待たされていました」
- Change: 「新しい設計で待ち時間が2秒に短縮されました」
- After: 「これでユーザーは朝のコーヒーを取りに行かなくても、すぐに仕事を始められるようになりました」
数字（10秒→2秒）だけじゃなく、その変化がユーザーの生活や気分にどう影響するのかを語るようにしたんです。
そうしたら、チームの反応がまったく違いました。みんな笑いながら「なるほど、コーヒーいらずか！」と盛り上がる。これまでの「静かなレビュー」とは雰囲気がガラッと変わった瞬間でした。
“Story”の型を見つける
そこから僕は、自分なりの「技術ストーリーの型」を見つけようとしました。試行錯誤の末に落ち着いたのが、次の3ステップです。
- Before（課題）
まずは「困っている人の姿」を描く。ユーザーがどんな不便をしているのか、チームがどんなストレスを抱えているのか。 - Change（解決策）
次に「自分の技術的アプローチ」を提示する。アルゴリズムや設計の工夫をシンプルに説明する。 - After（未来）
そして「その解決で誰がどう幸せになるのか」を描く。数値改善だけじゃなく、感情や行動の変化まで伝える。
この型に当てはめると、たとえばデータベースの最適化でも、バグ修正でも、単なる技術説明を「ストーリー」に変えられることに気づきました。
小さな成功体験
このアプローチを続けていくうちに、少しずつ成果が出てきました。
特に印象的だったのは、社内の全体ミーティングで自分のチームの成果を発表したときのこと。
それまでは「開発部の発表」は正直つまらない時間と見られていました。数字やグラフばかりで、エンジニア以外には退屈だったんです。でも僕は、あえて「ユーザーの一日の流れ」をスライドの冒頭に入れました。
「朝、営業担当が外出先でアプリを開いたとき、以前はロードが遅くてイライラしていました。でも新しい仕組みで、そのイライラは解消されました。これで彼らはもっと早く顧客対応を始められるんです。」
シンプルな話でしたが、会場の雰囲気が変わったんです。営業部の人たちが笑顔でうなずいてくれて、後から「やっと技術の成果が自分たちの仕事につながっていると実感できたよ」と言われました。
その瞬間、僕は確信しました。
ストーリーは、技術を「誰かのためのもの」として可視化してくれる。
ただ正しいコードを書くだけじゃなく、誰かの生活や仕事を変える力があるんだと。
こうして僕は「物語として語る力」を少しずつ身につけていきました。
でも、それはまだ序章に過ぎませんでした。次に待っていたのは、“文化の違い”からくるさらなる試練。そして、その壁を越えることで、ストーリーテリングはさらに大きな意味を持つようになっていったのです。
物語として語る技術を少しずつ掴み始めた僕でしたが、次に待っていたのは「文化の壁」でした。
エンジニアリングの世界はグローバルです。コードは世界中どこでも動くし、アルゴリズムに国境はありません。でも「伝える」という行為は、相手の文化に強く影響されます。日本では効果的だった説明方法が、海外ではまったく響かない。逆に、海外で盛り上がった話が、日本人チームにはピンと来ないこともある。
このギャップに気づいたとき、僕はもう一度「正しい説明をしているのに伝わらない」というジレンマに直面しました。
エピソード1: ユーモアが伝わらない
ある日、国際チームで成果発表をすることになりました。参加者はアメリカ、ヨーロッパ、アジアと多国籍。僕は「ストーリー」で語ることを意識して、ちょっとユーモアを交えて説明しました。
「旧システムはまるで渋滞中の高速道路みたいでした。でも新しい設計は、ようやくETCレーンを作ったようなものです。」
日本人やアメリカ人メンバーは笑ってくれました。ところが、ヨーロッパのメンバーの一部は無反応。後で聞いたら、「高速道路の渋滞」という比喩自体がピンとこなかったらしいんです。国によっては車を日常的に使わない人が多くて、僕の例えはむしろ理解を妨げていたんですね。
このとき痛感しました。
**「ストーリーは文化に依存する」**ということを。
エピソード2: 直接的 vs. 間接的
さらに苦労したのが「どれくらい直接的に伝えるか」のバランスでした。
日本では、あまりにストレートに「ここが問題だ」と言うと角が立つので、柔らかい表現を選ぶことが多いですよね。僕も長年そのスタイルで話してきました。ところが、アメリカの同僚からはこう言われました。
“Your story is good, but you are too vague. What’s the problem exactly?”
（君の話はいいけど、曖昧すぎる。結局、具体的な問題は何なんだ？）
逆にヨーロッパの同僚にアメリカ流でズバッと言ったら、「ちょっと攻撃的だね」と受け取られたこともありました。
つまり、文化によって「ちょうどいい伝え方」が違うんです。
エピソード3: データの扱い方
さらに驚いたのは「データをどう語るか」にも文化差があることでした。
ある会議で、僕は「ユーザー満足度が20%改善した」と誇らしげに話しました。日本の感覚なら「20%」って結構大きな数字ですよね。でもアメリカ人のマネージャーから返ってきたのは、
「So what?（で？）」
の一言。
彼にとって大事なのは「20%がどんな意味を持つのか」でした。例えば「解約率が下がった」「新規契約が増えた」など、ビジネスへの影響に直結する話を求めていたんです。僕が示した「20%」は、彼らにとっては単なる統計に過ぎなかったんですね。
この経験から学んだのは、
- 日本では「数字そのもの」に価値を置く傾向がある
- アメリカでは「数字の意味」を語らないと響かない
という違いでした。
壁をどう乗り越えたか
こうした文化の壁にぶつかって、僕は最初かなり落ち込みました。「せっかくストーリーで語れるようになったのに、国が違えばまた通じないのか」と。
でも、ここで諦めなかったのは良かったと思います。
僕が取ったアプローチは大きく3つです。
- 相手の文化をリサーチする
会議前に、相手がどんなバックグラウンドを持っているか調べました。車に馴染みのない国の人には別の比喩を選ぶ。アメリカ人には「ビジネス的な意味」を先に示す。ヨーロッパの人には「チーム全体への貢献」を強調する。 - 多層的なストーリーを準備する
ひとつの説明に「感情」「数字」「未来像」の3要素を盛り込みました。感情的に響かなくても、数字で響く人がいる。数字に冷淡でも、未来像でワクワクする人がいる。複数の角度を準備しておくことで、文化差をカバーしました。 - フィードバックを即座に吸収する
伝わらなかったときは必ず「どこが分かりにくかった？」と質問しました。最初は勇気がいりましたが、この習慣のおかげで次第に「相手に響くストーリー」の引き出しが増えていきました。
気づいたこと
こうした経験を通して、僕はひとつの真実にたどり着きました。
「ストーリーは普遍ではない。でも、“相手に合わせて編み直す”ことこそがプロフェッショナルのスキルだ」
つまり、技術を物語に変える力は、単なるプレゼンスキルじゃなくて、異文化で橋をかけるための武器なんです。コードを共通言語にしているはずのエンジニアの世界でも、最後に人を動かすのは「伝え方」。そしてそれは、国や文化ごとにアレンジが必要になる。
これは僕にとって、海外で働くことの本当の難しさであり、同時に面白さでもありました。
海外で働き始めた当初、僕にとっての武器は「正しいコード」でした。
C# WPFでのUI設計、堅牢なアーキテクチャ、効率的な非同期処理。それらを積み上げれば評価されると信じていました。
でも実際に海外に出て分かったのは、「正しい」だけでは評価されないという現実でした。
その後、「物語」として語る力に目覚め、さらに文化ごとにストーリーを編み直す術を学ぶことで、僕のエンジニア人生は大きく変わっていきました。
変わった評価
以前の僕は、レビュー会議ではいつも緊張していました。「コードの細かい部分を突っ込まれたらどうしよう」と。ところが、ストーリーテリングを意識し始めてから、会議の雰囲気そのものが変わりました。
コードレビューで「この非同期処理は〇〇を防ぐためです」と説明するだけでなく、
「これでユーザーは“画面が固まる”ストレスから解放されます」と加える。
すると、マネージャーや非エンジニアのメンバーまで「それは助かる！」とリアクションしてくれるんです。
単なる「技術者の成果」だったものが、**「チーム全体の成果」**として認識されるようになった瞬間でした。
新しい役割の獲得
この変化は、僕に新しい役割をもたらしました。
以前は「実装担当」止まりだった僕に、やがて「プレゼン役」「チームの代表」として声がかかるようになったんです。
国際会議で自分のチームの成果を紹介したり、新しいフレームワーク導入を社内に提案したり。そういう「人前で語る役割」を任されるようになったのは、間違いなくストーリーテリングを磨いたからだと思います。
正直に言うと、エンジニアとしては自分より優秀な人は山ほどいます。でも「技術を物語にして相手に届ける」スキルを持っている人は意外と少ない。だからこそ、僕はチームの中でユニークなポジションを確立できたんです。
キャリアの広がり
さらに、このスキルはキャリアの可能性そのものを広げてくれました。
たとえば、異なる部署とのコラボレーション。以前なら「専門外の人には分からないだろう」と思って避けていた話し合いも、今ではむしろ楽しみになっています。営業部やサポート部に「エンジニアリングの成果があなたたちの仕事にどう役立つか」をストーリーで伝えると、彼らは一気に協力的になるんです。
その結果、プロジェクトがスムーズに進んだり、リソースが増えたりする。これって、単なる「コードを書く力」だけでは得られなかった成果です。
海外に挑戦するエンジニアへのメッセージ
ここまでの経験から、これから海外で働こうとしているエンジニアに伝えたいことがあります。
- 「正しさ」だけでは足りない
コードが動くのは当たり前。その上で「なぜそれが大事なのか」を語れることが、海外では評価につながります。 - ストーリーは相手のために編む
同じ成果でも、エンジニアには「技術的な工夫」を、マネージャーには「ビジネス効果」を、ユーザーには「体験の変化」を伝える。相手ごとにストーリーを変える意識が必要です。 - 文化をリスペクトする
日本的な「謙遜」や「間接的な言い方」が通じない場面もあれば、逆に直接すぎて誤解を生む場面もある。文化ごとに響く言葉や例えを調整するのも、エンジニアに求められるスキルのひとつです。 - 物語はあなたの武器になる
語る力があれば、チームの代表として発言の場を得られる。キャリアのチャンスも広がる。これは間違いなく、海外で戦う上でのアドバンテージです。
最後に
冒頭のフックに戻ります。
「Imagine presenting your technical work not just as data, but as a gripping narrative…」
最初は半信半疑だったこの言葉が、今では僕自身のキャリアを象徴するものになりました。
エンジニアリングはもちろん数字やコードの世界です。でも、その背後には必ず「人」がいます。ユーザーがいて、チームがいて、ビジネスがある。その「人」を動かすのは、正しいコードだけではなく、コードに血を通わせる物語なんです。
これから海外に挑戦するエンジニアのみなさん。
もしあなたが「英語に自信がない」「説明が苦手」と感じていても、大丈夫です。僕も最初はYesしか言えなかった。でも、「ストーリーで語る」ことを意識するだけで、伝わり方は劇的に変わります。
あなたのコードは、ただの数字や記号の集まりじゃない。
そこには必ず「誰かを助ける物語」が隠れています。
それをどう引き出して語るか――それこそが、海外で戦うエンジニアに必要なスキルだと僕は信じています。
コメント