「エンジニアとして、もっと勉強しなきゃ。」
僕が海外で働き始めた当初、頭の中はその一色でした。新しい言語、新しいフレームワーク、新しい開発環境……とにかく“知らないこと”が多すぎて、焦りの連続。
特に僕はC#とWPFをメインに設計開発をしてきたので、「この知識をベースにもっと広げなきゃ！」と信じ込んでいました。Visual Studioを立ち上げ、MVVMの設計を繰り返し、パターンを磨き上げる日々。日本にいた頃はそれでうまくいっていたんです。でも、海外の現場に飛び込むと、その“これまでの正解”が全然通じない瞬間に直面しました。
たとえば――ある時、UIの仕様変更が一気に入ったプロジェクトがありました。僕は「WPFならこういうデータバインディングで柔軟に対応できるだろう」と思い、MVVMをベースに徹底的に作り込みました。ところがレビューで出てきたのは、予想外のフィードバック。
「Why are you overcomplicating this? Just keep it simple.」
正直、面食らいました。僕としては“ベストプラクティス”を守ったつもり。でもチームメイトは「ユーザーの要望はそんな複雑な拡張性を求めてない。むしろ余計なレイヤーが保守の足かせになる」と指摘してきたんです。
その時、頭に浮かんだのは「いや、でもMVVMは……」「でも設計は将来を見据えて……」という“これまでの常識”でした。だけど、海外の現場では「過去の成功パターンが正しいとは限らない」という現実を突きつけられたんです。
振り返ると、これは僕にとって最初の「アンラーニング（Unlearning）」体験でした。
つまり、“知識を増やす”ことよりも、“過去の思考のクセを捨てる”ことのほうが大事になる場面がある、という気づきです。
もちろん、エンジニアとして勉強は欠かせません。新しい技術に追いつくために学習し続けるのは当然です。でも――それ以上に、これまでのやり方や「これが正解だ」と信じ込んでいた方法論をいったんリセットしなければならないことがある。海外に出てから、僕はその場面に何度も出会いました。
たとえば設計の段階で、僕は「まずクラス構造をきっちり固めるべき」と考えるクセがありました。でもチームによっては「最初にユーザーストーリーを動かす試作を先に作ろう」とか「完璧な設計よりもスピードを優先しよう」といった文化が根付いています。
最初は「え、そんな雑でいいの？」と感じました。でもその“雑さ”が、ユーザーに早く価値を届け、結果的にムダを減らすやり方だったんです。
つまり、僕が握りしめていた“正解”は、状況によっては足かせになっていた。
この経験が積み重なっていくうちに、「もっと学ばなきゃ」じゃなくて「一回忘れてみよう」のほうが大事だと気づき始めたんです。
「Are you an engineer feeling stuck, like your past solutions aren’t cutting it in today’s tech world?」
――この問いかけは、まさに数年前の僕自身でした。
必死に学んできた知識やスキルが、逆に新しい現場で通用しない。努力してきたからこそ、それを捨てるのは怖い。でも、本当に飛躍するためには「学ぶ」よりも「手放す」が必要なんだと実感しました。
これからお話しするのは、僕が海外でエンジニアとして働きながら、どうやって“アンラーニング”を通じて問題解決力を磨き直したか、そしてそれがキャリアをどう変えたか、という体験談です。
起の部分はここまで。次の「承」では、実際に僕が直面した“アンラーニングの壁”と、それをどう超えていったかを掘り下げていきます。
「アンラーニングの壁にぶつかる」
「捨てなきゃいけない」と頭ではわかっていても、実際にやるのは本当に難しいんですよね。
僕が海外で働き始めて1年目、最初にぶつかった壁は「自分の正しさを手放せない」というものでした。
エピソード1：レビューでの衝突
あるとき、大規模なUIリプレイス案件に参加したことがありました。僕はWPFでMVVMをきれいに構築していくのが当たり前だったので、クラス設計を緻密に整え、データバインディングを駆使して柔軟に拡張できる構造を作りました。
自信満々でレビューに出したら、返ってきたフィードバックは衝撃的。
「We don’t need this level of abstraction. It makes the code harder to maintain for the next guy.」
僕の中では“将来の保守性”を考えた設計こそ正義。でも、彼らにとっては「今すぐ動く、わかりやすいコード」の方が価値があったんです。僕は食い下がりました。
「でも、後から仕様変更が来たら対応が大変じゃないですか？」
すると、チームリードが笑いながらこう言いました。
「仕様変更？ そんなの毎回くるんだよ。そのたびにリファクタリングすればいい。無駄に完璧を目指す方が危険なんだ。」
その瞬間、頭をガツンと殴られたような感覚がありました。僕が大事にしてきた“事前に守りを固める設計思想”は、この文化では“足かせ”だったんです。
エピソード2：言葉の壁と「No」の使い方
もうひとつ大きな壁がありました。それはコミュニケーションです。
英語での議論はただでさえ緊張するのに、自分の意見を押し通せなかったり、逆に言い過ぎてしまったり。特に「No」を伝える場面は難しかった。
例えば、ある時にAPI設計で「この仕様だと将来データ量が増えた時にパフォーマンスが落ちる」と指摘したかったんですが、
僕は回りくどく「Maybe it’s not the best way…」と遠回しに言ってしまったんです。
結果、相手には「まあこのままでいいってことだよね」と受け取られてしまいました。
後からトラブルが発覚したときに、「Why didn’t you say no clearly?」とチームに言われ、ものすごく悔しい思いをしました。
そこで気づいたのは、日本流の“曖昧な表現でやんわり伝える”やり方は、この現場では通じない、むしろ害になるということ。
つまり僕にとってのアンラーニングは「文法」や「語彙」ではなく、“コミュニケーションの型”そのものを壊して作り直すことだったんです。
エピソード3：スピード vs 完璧主義
さらに僕を悩ませたのは、スピード感。
日本で働いていたときは、納得いくまで仕様を詰め、ドキュメントを書き、設計レビューを経て開発に入る――これが普通でした。
ところが海外のチームは「まず動くものを出そう」が基本。仕様がグレーでも、とにかく試作品を作ってユーザーに触ってもらい、フィードバックを得て次に進む。
僕は最初、これに全くついていけませんでした。
「え、仕様が固まってないのに作るなんてありえないでしょ！」
でも、彼らにとっては「仕様は最初から正しいはずがない。だったら早く間違えて修正した方が効率的」という考え方。
頭では理解できても、手が勝手に昔のやり方を選んでしまう。
“完璧主義を手放す”ことは、僕にとって本当に苦しいプロセスでした。
「アンラーニングを実践に移す」
壁にぶつかって、「今までのやり方が通用しない」と気づいたからといって、すぐに切り替えられるわけじゃありませんでした。長年染みついた習慣や価値観は、そう簡単には捨てられないんですよね。
そこで僕は、自分なりに小さな工夫を積み重ねて「アンラーニングの筋トレ」を始めました。
ステップ1：あえて“雑”に作ってみる
まず取り組んだのは、「雑に作る」 こと。
これ、僕にとってはめちゃくちゃ勇気のいる挑戦でした。
ある機能追加のとき、いつもならデータモデルからきれいに設計して、XAMLのバインディングを完璧に整えてから着手するところを、あえて“動くこと”だけを優先して実装してみたんです。
正直、コードの美しさはゼロ。でも、レビューに出すと意外にも評価はポジティブでした。
「Good, now we can test it quickly. We’ll clean it up later if needed.」
その瞬間、僕は「雑でもいいんだ」と初めて腹落ちしました。
つまり、完成度よりもスピードとフィードバックを重視する文化に、自分を無理やり馴染ませる練習だったわけです。
ステップ2：毎日「No」を言う練習
次に取り組んだのは、コミュニケーションのアンラーニング。
特に「No」をはっきり伝えることが課題だった僕は、あえて“毎日一回はNoを言う”という小さなルールを自分に課しました。
最初は些細なことからです。
「このミーティング、明日でもいい？」と聞かれて、いつもなら「Sure, maybe…」と流すところを、あえて「No, tomorrow I already have another task. Can we do Friday instead?」と言ってみる。
これが意外と効きました。相手は怒るどころか、「Got it, thanks for telling me clearly」とむしろ感謝されるんです。
その積み重ねで、“はっきり伝える＝衝突する”という思い込みを徐々に外すことができました。
ステップ3：学びを“捨てるノート”に書く
僕はもともと「学びノート」をつけるタイプだったんですが、アンラーニングを意識してからは「捨てるノート」を新しく作りました。
そこには、こう書きます。
- MVVMは万能じゃない → ケースによってはシンプルなコードが正解
- 曖昧な表現は安全じゃない → むしろ誤解を生む
- 完璧な設計は存在しない → まず動かしてから考える
こうやって、自分の中の「常識」をひとつずつ“棚卸し”して捨てる。
書き出すことで、頭の中でモヤモヤと残っていた古い癖を、目に見える形で手放せるようになりました。
ステップ4：仲間に「リマインダー役」を頼む
アンラーニングって、自分一人だと戻ってしまうんですよね。だから僕は、同じチームの仲間に協力をお願いしました。
「もし僕が複雑に設計しすぎてたら、指摘してほしい」
「もし僕の言い方が回りくどかったら、遠慮なく直してほしい」
すると、ある同僚は「No problem, I’ll be your coach」と言ってくれて、実際にレビューや会話の場で「Hiro, that sounds too complicated」「Just say no directly」と突っ込んでくれました。
これがものすごく効果的で、まるで“アンラーニング専属トレーナー”がついたみたいな感覚でした。
小さな成功体験
こうした工夫を続けていくと、少しずつ結果が出始めました。
ある日、短期間で試作品を出した時、ユーザーから「Exactly what we need!」とフィードバックをもらえたんです。
以前の僕なら、設計に時間をかけすぎて納期に間に合わなかったはず。でも“雑でも早く出す”というアンラーニングを実践した結果、ユーザーの喜ぶ顔を一番早く見られました。
また、ある会議で「No, this approach won’t scale. Let’s try this instead.」ときっぱり言ったら、議論が一気に建設的になったこともありました。
「You’re right, thanks for pointing that out early」と感謝され、むしろ信頼が増したのを感じました。
「アンラーニングがもたらしたもの」
「学ぶ」より「手放す」。
このシンプルな発想の転換は、僕のエンジニア人生を大きく変えました。
成果1：問題解決の幅が広がった
以前の僕は、常に「C# WPFならこうする」という“正解”を前提にしていました。
でもアンラーニングを意識してからは、「あえてそのパターンを使わないとしたら？」と考えるようになったんです。
すると不思議なことに、選択肢が一気に広がりました。
ある案件では「WPFの凝ったデータバインディング」ではなく、シンプルなJSONベースのやり取りに切り替えたことで、フロントエンドのReactチームとの連携がスムーズになりました。
「自分の得意技」に固執せず、最適解をチームで探す柔軟さ――これこそアンラーニングがくれた武器でした。
成果2：チームからの信頼が深まった
「No」を言えるようになったことは、キャリアに直結しました。
以前は「何でもYesと言ってくれる人」として扱われ、逆に大きな意思決定の場から外されることもありました。
でも今は違います。議論の中で「その方法だと将来スケールしないから、別のやり方を考えよう」と明確に伝えられる。
その結果、リスクを見抜いてくれる人として評価され、設計レビューやアーキテクチャ検討の場に呼ばれるようになりました。
つまり、アンラーニングは単なる「捨てること」ではなく、チームから信頼される立ち位置を築くための土台になったんです。
成果3：キャリア観が変わった
一番大きな変化は、キャリアへの向き合い方でした。
以前の僕は、「技術力を高めること＝キャリアのすべて」だと信じていました。だから新しい言語やフレームワークを必死に追いかけていたんです。
でも今は違います。
「古い考えを捨てる力」こそが、エンジニアとして未来を生き抜くスキルだと感じています。
技術は常に変わります。
WPFも、いまやメインストリームではないかもしれません。明日はBlazorかもしれないし、その先はまったく別のUIフレームワークかもしれない。
だからこそ、「学び続ける力」だけじゃなく「捨てて切り替える力」が必要なんです。
アンラーニングは“未来への投資”
振り返ると、アンラーニングは最初こそ痛みを伴いました。
「自分の武器を手放すのは怖い」
「せっかく積み上げてきた努力が無駄になるのでは」
――そんな不安に何度も押しつぶされそうになりました。
でも今思えば、それは“投資”だったんです。
古い考えを手放すことで、新しい可能性をつかむ。
アンラーニングは、自分の未来をアップデートするためのプロセスでした。
読者へのメッセージ
もし、この記事を読んでいるあなたが「最近、自分のやり方が通用しなくなってきた」と感じているなら――それはチャンスです。
努力が足りないわけでも、知識が不足しているわけでもありません。
もしかしたら必要なのは「もっと学ぶこと」ではなく、**「一度、忘れること」**かもしれません。
アンラーニングは簡単じゃありません。
でも、小さな実験から始めれば必ずできるようになります。
- あえて“雑”にコードを書いてみる
- 毎日一度は「No」を言ってみる
- 「捨てるノート」をつけてみる
これだけでも、あなたのエンジニアリングの景色は変わります。
最後に。
僕が海外で学んだのは、**「強さは知識量ではなく、しなやかさで決まる」**ということです。
アンラーニングは、あなたのキャリアを未来に適応させる最強の武器になります。
結び
「学び続けるエンジニア」であることはもちろん大事。
でも同じくらい、いやそれ以上に「忘れられるエンジニア」であることが、これからの時代を生き抜く鍵だと思います。
そして、その第一歩は――過去の自分を手放す勇気。
あなたが次に壁にぶつかった時、ぜひ思い出してみてください。
解決の糸口は「学ぶ」ではなく「捨てる」ことにあるかもしれません。
コメント