― 海外エンジニア生活の第一歩で気づいたこと ―
海外でエンジニアとして働き始めたとき、最初に直面するのは「自分は本当にここでやっていけるのか？」という不安でした。特に僕の場合、C#とWPFを使った設計開発を主にやってきたバックグラウンドがあったので、技術的にはある程度自信があったんです。でも、いざ海外の現場に飛び込んでみると、英語力や文化的な違いが壁となって、持っている技術をそのまま活かせない場面が多々ありました。
最初の頃は、会議での発言ひとつ取っても頭の中で「これを言って大丈夫かな？」と考え込んでしまって、気づいたら会話が先に進んでいる、なんてことばかり。自分の中でのハードルを勝手に高くしていたんですね。その結果、プロジェクトに貢献できていないように感じてしまい、「自分はここにいる意味があるのか？」といわゆるインポスター症候群に陥っていきました。
ただ、この経験を通じて気づいたのは、海外で働くうえで本当に大事なのは「完璧に振る舞うこと」ではなく、自分らしさをどう保ちながら周囲に価値を提供できるかだということです。たとえば、僕がWPFでUI設計をしていたとき、日本での経験から「ユーザー操作の直感性を最優先にする」というこだわりを持っていました。海外のチームでは「まずは早く形にする」ことが重視される場面が多かったんですが、そこで「いや、ユーザーが混乱したら結局コストになる」と自分の意見を出したことで、議論が広がり、チーム全体がユーザー体験を考慮した設計にシフトしたことがありました。
このとき感じたのは、“Authentic Edge（自分らしい強み）”こそが海外の現場で武器になるということです。技術そのものは世界中のエンジニアが持っているけれど、背景や価値観の違いから来る「視点のユニークさ」は自分だけのもの。それを意識的に磨き続けることが、キャリアの中で自分を支える土台になるんです。
もちろん、口で言うほど簡単じゃありません。自分を出そうとするときに「嫌われたらどうしよう」「間違っていたらどうしよう」という不安は常について回ります。僕も最初は失敗の連続で、思い切って発言したアイデアがあっさり却下されたこともありますし、逆に相手の文化的背景を理解していなかったことで誤解を生んでしまったこともあります。
でも、それでも「自分のAuthentic Edgeをどう守り、育てていくか」を考えることが、結果的に僕を前進させてくれました。そして、この問いかけは一度で終わるものではなく、キャリア全体を通じて常に意識し続けるべきテーマだと今は感じています。
この連載では、そんな僕自身の海外エンジニアとしての体験をベースに、
- どうやって自己認識を深め続けるか
- インポスター症候群とどう向き合うか
- フィードバックをどう取り入れて「自分らしさ」を磨くか
についてお話していこうと思います。
「起」の部分としてまず伝えたいのは、海外で働き始めると誰しもが自信を失いがちだけれど、**そこで立ち返るべきなのは“完璧な自分”ではなく“自分らしい自分”**だということ。そして、それを保ち続ける努力こそが、ダイナミックに変化するプロフェッショナルの世界で生き残る鍵になるということです。
― 自分を知り続けるという戦略 ―
1. 自分の強みを“言語化”する
僕が最初にやったのは、自分の強みを紙に書き出すことでした。
例えば、僕の強みのひとつは「UI設計でユーザー目線を忘れないこと」。これは日本での案件でたくさんレビューを受けて磨かれた部分なんですが、海外に来ると「早く作って動かす」ことが優先されやすく、どうしても軽視されがちでした。だからこそ、「ここは自分が貢献できる領域だ」と言語化して、意識的に主張するようにしたんです。
これをやると、自分の立ち位置がぼやけなくなります。逆に言えば、言語化しないとすぐに「自分は何もできていない」と思い込んでしまうんですよね。
2. “小さな成功体験”を積み上げる
自己認識を深めるには、実際の行動と結果のフィードバックも必要です。
僕は海外の現場で「プレゼンは苦手だから」と避けていたんですが、あるとき思い切って自分の担当したUI改善の案をチームに発表しました。英語は完璧じゃなかったし、スライドの構成も不格好。でも、その場で一人の同僚が「君の視点はいいね」と言ってくれたんです。
それだけで一気に「自分の強みは通じるんだ」と実感できました。
この“小さな成功体験”は、自分を知るうえで大きなヒントになります。できるだけ避けずにトライして、フィードバックを受け取ることが、自分の認識を現実に近づけてくれるんです。
3. “外からの視点”を借りる
自己認識って、自分ひとりでやるとどうしても偏ります。だから僕はメンターや信頼できる同僚に定期的にフィードバックをもらうようにしていました。
例えば、ある同僚に「自分の英語が弱点で、ちゃんと伝わってない気がする」と相談したら、返ってきた言葉は「いや、言いたいことは伝わってるよ。むしろ技術的に深掘りしすぎる癖があるから、そこを意識した方がいい」でした。自分では“英語が課題”だと思い込んでいたのに、実際には“説明の仕方”が課題だったわけです。
こういう外からの気づきは、自分だけでは絶対に見つけられないものです。だから「弱みを隠す」のではなく、「自分を映す鏡」として他人の声を借りるのが、自己成長には欠かせないんだと思います。
4. ダイナミックな世界で“軸”を持つ
IT業界、とくに海外のプロジェクトは本当に動きが速いです。ツールや技術のトレンドが数か月で変わり、プロジェクトの方向性も急に切り替わることがよくあります。そんな中で「自分は何者か」を常に問い直すのは、正直しんどいです。
でも僕が学んだのは、「軸」をひとつ持っていれば、周りが変わっても自分を見失わないということ。僕の場合は「ユーザーにとってわかりやすいUIを作ること」。これを軸にすると、新しいツールを使うときも「ユーザー目線で見たらこのツールの長所はどこか」と考えられるし、チームに意見するときも「最終的にユーザーが混乱しないかどうか」で判断できる。
軸を持つことは、自分を守る意味でも大切なんです。海外で働いていると、つい「周りに合わせなきゃ」と流されがちになりますが、最後に頼れるのはやっぱり“自分の軸”なんですよね。
― インポスター症候群との付き合い方 ―
自己認識を深め、強みを言語化し、軸を持つ――ここまでは理想的な流れです。でも、現実にはその途中で必ずぶつかる壁があります。それが インポスター症候群（Imposter Syndrome） です。
「自分なんてまだまだ実力不足だ」
「周りは優秀なのに、自分だけ場違いじゃないか」
「次の失敗で、みんなに“こいつはダメだ”ってバレるかもしれない」
僕も海外に出てから何度もこの気持ちに襲われました。むしろ、キャリアを積めば積むほど強くなることすらありました。だからこそ、どう向き合うかが大きな課題になるんです。
1. 最初に襲ってきた「場違い感」
海外で働き始めて最初の半年間、僕は正直「場違い感」でいっぱいでした。周りのエンジニアは英語も堪能で、最新技術にも詳しく、会議ではどんどん意見を出していく。対して僕は、言いたいことを英語で表現するだけで精一杯。コードを書くスピードも、慣れないツールのせいで遅れがち。
そんな自分を見比べて、「やっぱり自分はここにいるべきじゃないのかも」と思うことが何度もありました。特に辛かったのは、プロジェクトレビューで他のメンバーが堂々と発表する姿を見たとき。僕が同じ場に立ったら笑われるんじゃないか、とさえ思ったんです。
2. “完璧”を求めるほど深みにはまる
今振り返ると、インポスター症候群の根っこにあったのは、**「完璧を求めすぎる気持ち」**でした。
会議で話すときも、「文法ミスをしたらどうしよう」「ネイティブっぽく聞こえなかったら恥ずかしい」と頭の中で考えすぎて、結局話せなくなる。コードレビューでも「100%の品質にしなきゃ」とプレッシャーをかけすぎて、提出が遅くなる。
その結果、自分で自分を追い込んで、さらに「やっぱり自分はダメだ」と落ち込む――完全に負のループでした。
3. 小さな“割り切り”が救ってくれた
転機になったのは、あるミーティングでの出来事です。
僕が勇気を出して英語で意見を言ったとき、途中で単語が出てこなくて「あー…えーっと…」と止まってしまったんです。顔が熱くなって「やっぱり恥ずかしい」と思ったその瞬間、同僚が「Take your time, I get what you mean」と笑顔で言ってくれました。
そのとき、ハッとしたんです。相手は僕の“完璧さ”を求めてるわけじゃなく、僕の“意見”を求めているんだって。
そこから少しずつ「文法が間違ってもいい」「スライドが不格好でもいい」「まず伝えることが大事」と割り切れるようになりました。
4. インポスター症候群を“共通体験”として捉える
もうひとつ大きな気づきは、「自分だけがインポスター症候群に悩んでるんじゃない」ということです。
ある日ランチのときに同僚と雑談していたら、彼女も「最初の頃は自分の意見を言うのが怖かった」と打ち明けてくれました。しかも彼女は僕から見ればバリバリ仕事ができる人。そんな人でも同じ気持ちを経験していたと知って、すごく救われました。
調べてみると、ハーバードの研究でも高い能力を持つ人ほどインポスター症候群に陥りやすいと言われているそうです。つまり、これはエンジニアに限らず多くの人が通る道なんですよね。
5. 自分のユニークさを“根拠”にする
じゃあどうやって自信を取り戻すか。僕の場合は、自分のユニークさを根拠にすることが大きな支えになりました。
例えば、僕のWPF経験はチーム内でも珍しかったので、「ここは自分にしか見えない視点だ」と思うようにしました。英語が不完全でも、実務で積んだ経験は誰にも否定できない。その事実を「根拠」として握ると、少しずつ「自分の存在は意味がある」と思えるようになったんです。
6. インポスター症候群との“付き合い方”
最終的に僕がたどり着いた結論は、インポスター症候群は“消す”ものじゃなく、“付き合う”ものだということです。
完全に無くすことはできません。でも、
- 「完璧じゃなくていい」と割り切る
- 「自分だけじゃない」と知る
- 「ユニークさを根拠にする」
この3つを意識するだけで、インポスター症候群は“敵”から“共存できる存在”に変わりました。むしろ「自分はまだまだ伸びたい」という成長エネルギーに変えることもできるようになったんです。
― フィードバックを力に変える ―
インポスター症候群とどう付き合うかを乗り越えたとしても、海外でエンジニアとして働く日々は決して平坦ではありません。むしろ次に待ち受けているのは、周囲からのフィードバックをどう受け止め、どう活かすかという課題です。
僕も最初の頃はフィードバックをもらうと心がざわついて仕方なかったです。ポジティブな言葉なら素直に嬉しいのに、ちょっとでも改善点を指摘されると「やっぱり自分はダメなんだ」と落ち込む。そんな繰り返しでした。
でも今振り返ると、Authentic Edgeを磨き続けるために、フィードバックほど貴重な燃料はないんです。
1. フィードバックは“評価”ではなく“材料”
最初に考え方を変えたのは、「フィードバック＝自分の価値の評価」ではない、ということでした。
以前、僕が作ったWPFのUI画面について、レビューで「操作フローが少し複雑じゃないか？」と指摘を受けたことがありました。そのときは正直ショックで、「自分の設計が否定された」と感じてしまったんです。
でも後日、その意見をベースに修正を加えたら、ユーザーからの使いやすさ評価がぐっと上がりました。その瞬間、気づいたんです。フィードバックは“ダメ出し”じゃなくて“改善の材料”なんだって。
そこからは、フィードバックを「自分を否定する言葉」ではなく、「次の一歩に必要なヒント」として受け取れるようになりました。
2. ポジティブフィードバックを“貯金”する
意外と見落としがちなのが、ポジティブなフィードバックの扱い方です。
僕は以前、「褒められても大したことじゃない」と受け流していました。でも、そうすると気づけば「改善点」ばかりが頭に残って、自己肯定感がどんどん削られていくんです。
そこで始めたのが、“ポジティブフィードバックの貯金”。
Slackで褒められたコメントや、メールでの「Good job!」といった一言を全部スクリーンショットにしてフォルダに保存しました。落ち込んだときにそれを見返すと、「あ、ちゃんと評価されてるんだ」と心が回復するんです。
小さなことですが、これが自己認識を保つ大きな支えになりました。
3. ネガティブフィードバックを“翻訳”する
建設的なフィードバックはありがたい一方で、受け取った瞬間にグサッとくることもありますよね。僕も「説明が長すぎる」「優先順位を間違えている」と言われて、心の中で凹みまくったことがあります。
そんなとき僕が意識したのは、フィードバックを“翻訳”することでした。
例えば「説明が長すぎる」というのは、「相手が理解しやすい伝え方に変えればいい」ということ。「優先順位を間違えている」というのは、「全体のゴールをもう一度確認すればいい」ということ。
つまり、表面的な言葉に感情で反応するのではなく、**“改善アクションに変換する”**ことがポイントでした。翻訳できれば、フィードバックはただの攻撃ではなく、成長の指針に変わるんです。
4. フィードバックを“会話”にする
もうひとつ大事なのは、フィードバックを一方通行で受け取らないことです。
あるとき上司から「もっと発言を増やした方がいい」と言われたことがありました。でも僕としては「英語力に不安があるし、発言してもかえって混乱させるんじゃないか」と思っていたんです。
そこで、その場で「確かに発言は少ないかもしれません。でも、どんな場面で発言した方が良いと感じますか？」と聞き返しました。すると、「技術的な細かい部分よりも、UI設計の全体方針に関する場面で意見を出してほしい」と具体的なアドバイスが返ってきたんです。
この経験から学んだのは、フィードバックは会話にしてこそ意味が深まるということ。言われっぱなしにするんじゃなく、意図や背景を掘り下げると、自分がやるべき行動がクリアになるんです。
5. Authentic Edgeを磨き続ける循環
こうしてポジティブもネガティブも含めてフィードバックを活かすと、自然と「Authentic Edge」が磨かれていきます。
僕の場合、UI設計へのこだわりを持ちつつも、説明の仕方や優先順位のつけ方をフィードバックから学びました。その結果、ただ“自分のこだわりを押し通す人”ではなく、“ユーザー視点を大切にしつつチーム全体を前に進められる人”として認識されるようになったんです。
つまり、フィードバックを取り入れることは、自分らしさを失うことではなく、自分らしさをよりシャープにしていくプロセスなんです。
コメント