強みが弱みに変わる瞬間
「エンジニア脳って便利だよな。」
これは僕が社会人になってしばらくしてから、自分でよく思っていたことです。
論理的に物事を分解する。問題を要素ごとに切り出す。最適な解決策を選び、ミスの少ないコードに落とし込む。C# WPFを使った設計や開発の現場でも、この「エンジニア脳」のおかげで、なんとか戦ってこれた気がします。
でも、海外に出てみて気づいたんです。
このエンジニア脳が、ときに自分を縛りつけていたってことに。
「正しさ」への執着が生む壁
日本にいた頃の僕は、議論でもミーティングでも「正しい答え」を出すことにすごくこだわっていました。ドキュメントを書くにしても、レビューをするにしても、「これが最適解です」と言い切れる状態にしてから発言したい。
でも、海外の現場に入るとそれが通用しないんですよね。
相手は「まだ完璧じゃないけど、とりあえずアイデアをシェアする」っていうスタンスでどんどん発言してくる。たとえ途中で間違っていても、周囲はそれを受け止めながらディスカッションを深めていく。
そのスピード感に最初は圧倒されました。僕は「ちょっと考えさせて」って黙り込んでしまう。でも、その「ちょっと」が命取りになる。議論の流れがどんどん進んで、気づいたらもう全然違う方向にいっている。
「正しさ」にこだわるあまり、僕は会話から置いていかれていたんです。
アンラーニングの必要性との出会い
ある日、同僚のエンジニアに言われた一言が今でも忘れられません。
“Hiro, sometimes you don’t need to be right, you just need to be in the conversation.”
（ヒロ、いつも正しい必要はないんだよ。ただ、その会話にいることが大事なんだ。）
その瞬間、ガツンと頭を殴られたような感覚になりました。
僕は「正しいコード」「正しい設計」「正しい発言」ばかりを求めていたけれど、海外のチームに必要だったのは「正しさ」じゃなくて「柔軟さ」だったんです。
そこから僕が意識しはじめたのが「アンラーニング」。
つまり、これまでの「こうあるべき」という思い込みやパターンを、意図的に手放していくことです。
強みが足かせになる paradox
エンジニアとしての訓練って、どうしても「正解主義」を植えつけてきます。アルゴリズムには最適解がある。コードにはバグをなくすべき。UI設計にはユーザー目線の理想形がある。
その考え方自体は間違ってないし、日本で仕事をしている間はむしろ強みとして働いていました。
でも、海外では逆にその「正解志向」が自分の弱みになったんです。
例えば、
- チームディスカッションで意見が出せない
- 新しい技術のトライに躊躇する
- ユーザーの曖昧な要望に柔軟に対応できない
要するに、僕のエンジニア脳は「正しさ」を優先するあまり、「スピード」と「柔軟さ」を犠牲にしてしまっていた。
最初の違和感が、変化のスタート地点
海外に来て最初の1年は、この「違和感」とずっと向き合っていました。
「なんで自分はこんなに発言できないんだろう？」
「なんで周りのエンジニアは失敗を恐れずに行動できるんだろう？」
「正しいことをやってるはずなのに、なんで自分は浮いてるんだろう？」
答えはシンプルで、僕が「学びすぎていた」からなんです。
正しいやり方を積み上げすぎて、逆に自分の思考が硬直していた。
つまり僕に必要だったのは、新しい知識を「学ぶ」ことじゃなくて、
古い思い込みを「手放す」こと。
これが、僕にとってのアンラーニングの始まりでした。
これからの話
これから話すのは、僕が海外の現場で「アンラーニング」とどう向き合ってきたか、です。
エンジニアとしての強みを活かしながらも、その強みが足かせになる瞬間をどう突破するのか。
そして、「正しさ」に縛られず、「柔軟さ」と「スピード」を手に入れるにはどうすればいいのか。
僕の失敗談もたくさん出てきます。
でもそれこそが、これから海外で働くエンジニアにとってヒントになると思うんです。
エンジニア脳を活かすために、あえてエンジニア脳を外す。
アンラーニングを実践する現場
「正しさ」より「速さ」を試す挑戦
海外で働き始めて数か月。僕はまだ議論のスピードに追いつけず、会話の輪に入り損ねることが多かったんです。
そんなとき、チームでUI改善プロジェクトが立ち上がりました。僕の担当はC# WPFでの画面モックをつくること。
これまでの僕なら、
- 要件を整理
- UIフローを完全に設計
- ベストプラクティスを調査
- 完璧なコードを用意
というステップを踏んでから発表していました。
でも、そのやり方だと発表のときにはもう議論が終わってしまっている。
そこで僕は思い切って「正しさ」を手放してみることにしました。
とりあえず2日で粗いモックを作って出す。 完璧じゃなくてもいい、議論のスタート地点にするんだ、というマインドに切り替えたんです。
結果はどうだったか？
コードのクオリティは低かったし、UIの配置も雑。でも、その「雑さ」が議論を引き出したんです。
「このボタン、左じゃなくて右の方がいいかも」
「この配色だとユーザーが混乱する」
「この機能は本当に必要？」
議論が盛り上がり、僕のモックがきっかけでチーム全体のアイデアが膨らんでいきました。
そのときに気づいたのは、正しいものを出すことより、早く仮説を提示する方がチームに貢献できるということ。
「失敗しても大丈夫」という文化
もうひとつのアンラーニング体験は「失敗」への向き合い方でした。
日本で仕事をしていたときは、失敗＝信用を失うことだと思っていました。バグを出したら「申し訳ありません」と謝罪、仕様の見落としがあれば「気をつけます」と反省。
でも海外の現場では、失敗に対する空気が全然違うんです。
あるとき、僕が担当したモジュールに大きな不具合が出ました。日本だったら冷や汗もの。でも、そのときリーダーが言ったのはこうでした。
“Great, now we know what doesn’t work. Let’s fix it.”
（いいね、これで“うまくいかない方法”が分かった。じゃあ直そう。）
驚きました。怒られるどころか、失敗が前進の証拠として扱われていたんです。
そこで僕は「失敗＝マイナス」という思い込みをアンラーニングしました。
失敗はチーム全体で学びに変える。むしろ失敗を共有しないことの方が罪になる。そう考え方を切り替えた瞬間、行動の幅が一気に広がりました。
会議で「黙らない」訓練
海外の会議では、とにかく発言しないと存在感が消えてしまいます。
最初は「完璧な意見じゃないと発言できない」というブレーキが働いていました。
でもある日、先輩にアドバイスをもらいました。
“Hiro, just say something, anything. Even if it’s just ‘I agree’ or ‘Can you explain more?’”
（ヒロ、何でもいいからとにかく発言してみろよ。“賛成です”でも“もっと説明して”でもいいんだ。）
そこで僕は「黙らない訓練」をはじめました。
会議では必ず最低3回は発言する、と自分に課したんです。
最初はぎこちなくてもいい。たとえば：
- 「Interesting, can we test this idea quickly?」
- 「I see, but what if the user doesn’t understand this step?」
- 「I agree with that approach, maybe we can combine it with…」
小さな一言でも、積み重ねることで「発言するのが当たり前」という習慣に変わっていきました。
これはまさにアンラーニング。
「正解じゃないと発言できない」という古い思い込みを壊して、「発言すること自体が価値」という新しいルールに書き換えたんです。
「アンラーニング＝無駄にすること」ではない
ここで強調したいのは、アンラーニングは「今まで学んだことを全部捨てる」って意味じゃない、ということです。
むしろ大事なのは、必要なときに古い知識を“外せる柔軟さ”を持つこと。
エンジニア脳が役立つ場面ももちろんあります。
要件を整理するとき、バグを潰すとき、最適化を考えるとき――そこでは論理的思考や正しさが強みになる。
でも、アイデアを出す場面や、スピード重視のプロトタイピング、ユーザーの曖昧な要望に応えるときは、「正しさ」より「柔軟さ」が武器になる。
僕が学んだのは、このスイッチの切り替え方でした。
つまり、**アンラーニングは“選択的に使い分ける力”**なんです。
少しずつ変わる自己イメージ
アンラーニングを意識してから、僕自身の自己イメージも少しずつ変わっていきました。
以前は「正確で慎重なエンジニア」だった僕が、今は「スピード感を持って議論を動かせるエンジニア」に近づいている。
もちろんまだ完璧じゃないし、時々また「正しさ」に縛られてしまう瞬間もあります。
でも、そのたびに「あ、これまたエンジニア脳の罠にハマってるな」と気づけるようになった。
そして、その気づきこそがアンラーニングの第一歩なんだと実感しています。
アンラーニングが生んだブレイクスルー
「正しさ」より「共創」で成果を出す
アンラーニングを意識し始めて半年ほど経った頃、僕は大きなプロジェクトに参加することになりました。
ある金融系のクライアント向けに、C# WPFを使った業務アプリの新UIを設計する案件。
当初のクライアント要望はかなり曖昧で、
- 「もっと直感的に使いやすくしてほしい」
- 「ユーザーが迷わないように」
といった抽象的な言葉ばかり。
以前の僕なら、「具体的な要件が固まっていないと進められない」とフリーズしていたはずです。
でもそのときは違いました。
「完璧な仕様を求めるより、とりあえず仮説を投げる」
そう割り切って、僕はシンプルな画面遷移モックをチームに提示しました。
すると、クライアントは「なるほど、こういう形もあるのか」と目を輝かせ、そこから具体的な要望がどんどん出てきたんです。
結果的に、僕の“雑な仮説”が議論の起爆剤となり、プロジェクトが一気に動き出した。
このとき初めて「正しさ」に縛られないことが成果につながる瞬間を体感しました。
「失敗」を共有したら、信頼が深まった
もうひとつ大きな転機になったのは、僕が大きな設計ミスをしたときのことです。
あるモジュールのUIフローに抜けがあり、ユーザーが操作を完了できない致命的な問題が発覚しました。
日本にいた頃の僕なら、まずは「バレないように必死に修正」していたと思います。
でもそのときは、あえてSlackにこう投稿しました。
“I found a serious mistake in the UI flow I designed. Here’s what happened, and here’s my idea to fix it. Any thoughts?”
（自分が設計したUIフローに重大なミスを見つけました。状況はこうで、修正案はこう考えています。意見をもらえますか？）
すると、意外なことに誰も僕を責めませんでした。
むしろ、他のメンバーが次々と「この改善案いいね」「こうすればもっとシンプルになるよ」と建設的なフィードバックをくれたんです。
結果的に、以前よりも使いやすいUIに仕上がり、クライアントから高評価を得られました。
ここで気づいたのは、失敗を隠すよりも、共有した方が信頼が深まるという逆説。
これもまさにアンラーニングの成果でした。
「会議での存在感」が変わった瞬間
会議で「最低3回発言する」という自分ルールを続けていたら、次第に周囲からの反応も変わってきました。
以前は、僕が黙って座っていると「この人は意見がないのかな？」と誤解されていたと思います。
でも今は、たとえシンプルな発言でも積み重ねたことで、次第に「Hiroの意見を聞きたい」という場面が増えていったんです。
あるとき、UIの大幅変更を検討する会議で、僕が出した提案が議論の軸になりました。
内容自体は特別なものじゃなく、単に「ユーザーがこの画面で迷ったら、次のステップに進めなくなるんじゃない？」という指摘。
でも、それをきっかけに全員が「確かに！」「じゃあどうすればいい？」と話し合い、結果的に操作フローが大幅に改善されました。
このとき、「正解を出す」ことより「議論を動かす」ことが自分の役割なんだと実感したんです。
自分の弱点が武器に変わる
アンラーニングを進める中で面白かったのは、「弱点」が逆に武器になった瞬間でした。
僕は英語が母語じゃないので、どうしても発言がシンプルになりがちです。
最初はそれをコンプレックスに感じていました。ネイティブの同僚みたいに流暢に意見を展開できない。
でも、ある日同僚にこう言われたんです。
“I like how your points are always clear and straight to the point.”
（ヒロの発言っていつもシンプルで分かりやすいんだよね。）
つまり、僕が「弱み」だと思っていたものは、実は「強み」としてチームに受け入れられていたんです。
アンラーニングのおかげで、「流暢じゃない自分を隠す」のではなく、「シンプルさを武器にする」と発想を切り替えられました。
アンラーニングがもたらした3つの成果
こうして振り返ると、アンラーニングがもたらした成果は大きく3つあります。
- スピードが上がった
- 完璧を目指さずにアイデアを出せるようになり、議論や開発のスピードが格段に上がった。
- 信頼が深まった
- 失敗を共有することで、隠すよりもむしろチームからの信頼を得られるようになった。
- 存在感が増した
- 会議で発言を重ねることで、意見を求められる存在になり、チーム内での立ち位置が強くなった。
これは単に「技術が伸びた」とか「英語が上達した」といった話じゃありません。
「古い思い込みを手放す」ことで、自分の強みを引き出せるようになったということなんです。
そして、次の課題へ
もちろん、アンラーニングを一度やったら終わり、ではありません。
プロジェクトごとに新しい壁が出てきて、そのたびに「また古い習慣に縛られてないか？」と自問する必要がある。
でも、このサイクルこそが僕の成長エンジンになっている気がします。
エンジニア脳は便利です。でも、その便利さに甘えていると柔軟さを失う。
だからこそ「学ぶ」だけでなく「手放す」ことが、これからのキャリアに欠かせないんだと確信しています。
アンラーニングが未来を切り拓く
学ぶより、手放す勇気
エンジニアという仕事をしていると、「学び続けろ」という言葉をよく耳にします。
新しいフレームワーク、新しいライブラリ、新しい開発手法――テックの世界は進化が早く、学びを止めたらすぐに取り残されてしまう。
確かにそれは事実です。でも、僕は海外で働いて初めて気づきました。
「学ぶ」だけでは不十分だということに。
学びを積み重ねれば積み重ねるほど、「こうあるべき」「これが正しい」という自分ルールが増えていく。
そのルールが知らず知らずのうちに思考を縛り、新しい発想やスピードを妨げる。
だからこそ、これからのエンジニアに必要なのは、**「手放す勇気」**なんです。
アンラーニングが教えてくれた3つの真実
海外での経験を通じて、僕がアンラーニングから学んだのは次の3つの真実でした。
- 正しさよりも、会話にいることが大事
- 議論の場では「正解を出す」より「一緒に考える」ことが価値になる。
- 失敗は隠すものじゃなく、シェアするもの
- 失敗は信頼を壊すんじゃなく、むしろ信頼を深めるきっかけになる。
- 弱点は武器に変えられる
- 英語が流暢じゃなくてもいい。シンプルさや違和感こそが強みになる。
この3つは、どれも「過去の思い込み」をアンラーニングしたからこそ得られた気づきです。
海外で働くあなたへ
これから海外で働こうと考えているエンジニアに伝えたいのは、準備は完璧じゃなくていいということです。
もちろん技術力や英語力は必要です。でも、それ以上に大事なのは「自分の固定観念を手放せるかどうか」。
例えば、
- 「間違えたら恥ずかしい」という思い込みを手放す
- 「正解があるはず」という前提を手放す
- 「弱点は隠さないといけない」という考えを手放す
そうやってアンラーニングを積み重ねることで、海外の現場でもっと自由に、自分らしく働けるようになります。
アンラーニングは終わらない
アンラーニングは一度きりのイベントじゃありません。
キャリアのステージが変わるたびに、新しい学びと同時に古い思い込みを脱ぎ捨てていく必要がある。
僕自身も、まだまだ道の途中です。
プロジェクトごとに新しい壁にぶつかるたび、「これは学ぶべきなのか、それとも手放すべきなのか？」と問い直しています。
でも、その問いを持ち続けることこそが、エンジニアとして、そして人としての成長につながるんだと思っています。
最後に
あなたのエンジニア脳は強力な武器です。
でも、ときにその武器があなた自身を縛ることもある。
だからこそ、あえてその武器を手放し、新しいやり方を受け入れてみてください。
「正しさ」に縛られない柔軟さが、海外でのキャリアを切り拓く最大の力になります。
僕が経験したアンラーニングの旅は、まだ始まったばかり。
そして、あなたの旅もまた、これから始まろうとしています。
Don’t just learn. Unlearn. And then, relearn.
（ただ学ぶだけじゃない。手放し、そして再び学ぶんです。）
未来を変えるのは、そのサイクルを回せるエンジニアだけです。
コメント