海外エンジニアの幻想と、僕がエナドリを手放すまで
どうも、こんにちは！海外（今はヨーロッパの某国です）でITエンジニアとして働いています。メインの技術スタックはC#とWPF。クライアント向けのデスクトップアプリケーションの設計と開発をゴリゴリやっています。
「海外で働くエンジニア」って聞くと、どんなイメージがありますか？
フレックスタイムでゆったり出社して、多国籍な同僚とスマートに英語でディスカッション。週末はカフェで読書したり、ふらっと隣国に旅行したり…。うん、そういうキラキラした側面がゼロとは言いません。
でも、これから海外で働こうと思っている、あるいは働き始めたばかりのエンジニアの皆さんに、まず声を大にして言いたいことがあります。
「技術力さえあれば、どこでもやっていける」――これは、半分ホントで、半分は危険な幻想です。
僕もそう思っていました。C#の言語仕様は熟知してるし、WPFのXAML（ザムルって読みます）を使ったMVVM（Model-View-ViewModel）パターンの設計も得意。非同期処理（async/await）だって使いこなせる。技術的な引き出しさえ多ければ、環境が変わったって大丈夫だろう、と。
でも、現実はそんなに甘くなかった。
海外で働くってことは、自分の「OS」が動く「ハードウェア」ごと、まったく違う環境に持っていくようなものなんです。電圧も違えば、ネットワークのレイテンシも違う。頼れるドキュメント（＝日本の常識）も通じない。
僕の場合、最初の3ヶ月が地獄でした。
まず、時差ボケが抜けない。日本とのミーティングが変な時間に入ったりして、生活リズムがガタガタ。慣れない食事で胃腸も安定しない。スーパーで買う食材ひとつとっても、「これ、なんだ？」の連続。
そして、何より「認知コスト」の爆増です。
朝起きてから寝るまで、すべてが「非ネイティブ」なんです。同僚のジョークに愛想笑いするのも、ランチの注文をするのも、送られてくるチャットのスラングをこっそりググるのも、全部、脳のメモリとCPUを消費していく。
日本のオフィスにいれば、無意識にできていたことが、全部「意識的なタスク」に変わる。
この状態で、WPFの複雑な設計と向き合うのがどれだけしんどいか。
WPF開発って、結構「脳みそに汗をかく」タイプの仕事なんですよね。ユーザーコントロールの依存関係プロパティ（DependencyProperty）がどう連携するか、ViewModelのロジックがViewにどう影響するか、膨大なXAMLの中からパフォーマンスのボトルネックを見つけ出すか…。
ロジックとUIが密結合しやすいWPFを、いかに疎結合（そけつごう）に、テスト可能に、そして高速に保つか。これって、ものすごく高い集中力と、クリアな思考力が要求されるんです。
でも、当時の僕はどうだったか。
脳が常に「霧がかかった」状態。時差ボケと疲労で、簡単なロジックさえ思いつかない。コードレビューでは、普段なら絶対に見逃さないような凡ミスを連発。「あれ、俺、こんなに仕事できなかったっけ？」と、自信を失う日々。
その時、僕が頼ったもの。それが、皆さんお馴染みの**「エナジードリンクと大量のコーヒー」**です。
朝、霧のかかった頭を叩き起こすために1本。昼食後、猛烈な睡魔と戦うためにコーヒーを2杯。そして、夕方。集中力が切れてきたところで、ダメ押しのエナジードリンクをもう1本。
カフェインの力で、無理やり脳を「オーバークロック」させて、その場しのぎのパフォーマンスをひねり出す。まさに「睡眠負債」を「カフェイン」という高金利のローンで返済しているような状態でした。
もちろん、そんなものが長続きするわけがない。
夜はカフェインのせいで眠りが浅くなり、翌朝はさらにひどい疲労感で目覚める。パフォーマンスは日に日に落ちていく。そして、ついに「事件」は起きました。
ある重要なリリースの直前。僕が担当していたのは、WPFアプリケーションのコア機能の一つで、非同期処理を多用してバックグラウンドで重いデータを処理し、その進捗をUIにリアルタイムで反映させる、という割と複雑な画面でした。
寝不足とストレスで判断力が鈍っていた僕は、async/awaitのコンテキスト（お作法みたいなもの）を一部で見誤りました。結果、特定の操作をするとUIスレッドがデッドロックを起こし、アプリが完全にフリーズする、という致命的なバグを埋め込んでしまったんです。
リリース前の最終テストでそれが発覚し、チームは大騒ぎ。
その時、リードエンジニア（オランダ人のおじさん）に言われた一言が、僕の目を覚まさせました。
「君、最近ちゃんと寝てるか？ 君のコードは技術的に間違ってるんじゃない。ただ、すごく『疲れてる』コードだ」
ハンマーで頭を殴られたような衝撃でした。
問題は、C#の知識が足りないことでも、WPFの経験が浅いことでもなかった。
僕が管理すべきだったのは、コードの品質（Quality）である前に、僕自身の「認知機能（Cognitive Function）」の品質だったんです。
アスリートが最高のパフォーマンスを出すために、練習（技術）だけでなく、睡眠、栄養、メンタルケアを徹底するのと同じです。僕たちエンジニアも、複雑な設計を考え、バグのないコードを書くという「知的パフォーマンス」を発揮するために、自分の脳と体を最高のコンディションに保つ義務がある。
特に、僕のように環境ストレスの多い「海外」で戦うなら、それは「できればやること」じゃなくて、「絶対にやるべき最重要スキル」なんだと痛感しました。
そこから僕は、「技術書」を読むのと同じ熱量で、「人間のパフォーマンス」について学び始めました。
どうすれば脳の疲労を回復できるのか？
どうすればプレッシャーやストレスと上手く付き合えるのか？
どうすれば失敗を「学習」に変えられるのか？
そして行き着いたのが、今回のブログのテーマでもある**「The Mindful Engineer（マインドフルなエンジニア）」**という考え方です。
これは、「禅」とか「精神論」みたいなフワフワした話じゃありません。
- 睡眠と栄養を最適化し、脳の「ハードウェア」を最高の状態に保つ。
- マインドフルネスで、マルチタスクの誘惑や「今ここ」にない不安から脳を守り、集中力をハックする。
- グロースマインドセット（成長マインドセット）で、失敗やバグを「脅威」ではなく「フィードバック」として受け入れるメンタルを構築する。
これらはすべて、持続的に高いパフォーマンスを発揮するための、超具体的な「技術スタック」です。
このブログでは、僕がエナジードリンクを手放し、燃え尽き寸前からどうやってV字回復したのか。そして、C#やWPFの技術と同じくらい、いや、それ以上に重要だと気づいた「サステナブル（持続可能）なパフォーマンス術」について、実体験ベースで余すところなくお話ししていこうと思います。
もしあなたが「技術力には自信があるけど、最近どうもパフォーマンスが出ない」とか、「これから海外に行くけど、環境の変化が不安だ」と感じているなら、きっと役に立つヒントがあるはずです。
コードは「脳」で書く。睡眠と栄養がWPFの設計をどう変えたか
（起からのつづき）
さて、「君のコードは疲れてる」という、あのグサリとくる一言。
あれから僕は、技術書をいったん脇に置き、代わりに「睡眠」と「栄養」に関する本や記事を読み漁りました。
正直、ナメてましたね。「寝る間も惜しんでコード書くのが美徳」みたいな、昭和のスポ根ドラマみたいな価値観が、僕のどこかにまだ残ってたんです。
でも、海外のトップエンジニアたちの話を聞くと、みんな口を揃えて言うんですよ。「睡眠はコストじゃない、投資だ」と。
僕たちエンジニアの仕事道具って、なんだと思いますか？
もちろん、ハイスペックなPCや、使いやすいキーボードも大事です。でも、一番大事な、そして替えが効かない道具は、僕たちの**「脳」**ですよね。
WPFで「なんでこのBindingがうまく動かないんだ？」とか、「このDataGridのパフォーマンスが最悪だ。UI仮想化は効いてるはずなのに…」とか、そういう複雑な問題をデバッグする時。あるいは、新しい機能のために、「このViewModelの責務はどこまでだ？」「このロジックはService層に切り出すべきか？」みたいな、拡張性の高い設計（アーキテクチャ）を考える時。
これ、全部「脳」がやってる高負荷な知的作業です。
その「脳」が、寝不足や栄養不足で「低スペックモード」になっていたら？
そりゃあ、バグも埋め込むし、フリーズするアプリも作っちゃいますよね。リードエンジニアの言う通り、僕は「疲れたコード」を量産していたわけです。
僕がまずやったこと。それは「睡眠時間の絶対確保」です。
それまでの僕はひどかった。夜中までダラダラとコーディングしたり、ネットを見たり。カフェインで無理やり起きてるから、ベッドに入ってもなかなか寝付けない。
これを全部変えました。
まず、「夜12時以降はPCを開かない」という鉄のルールを決めました。
そして、「最低7時間半はベッドにいる」とカレンダーに予定としてブロックする。もう、クライアントとの最重要ミーティングと同じ扱いです。
最初はソワソワしましたよ。「あ、あの機能の実装、夜中にやろうと思ってたのに…」って。
でも、強制的にPCを閉じて、ベッドで（技術書じゃない）普通の小説とかを読むようにしたら、驚くほどスッと眠れるようになったんです。
そして、翌朝。違いは明らかでした。
比喩じゃなく、本当に「視界がクリア」なんです。頭にかかっていた霧が、サーッと晴れていく感じ。
そのクリアな頭で、昨日まで悩んでいたWPFの設計図を見直してみたんです。
それは、複数のユーザーコントロールが協調して動く、ちょっと複雑な画面でした。以前の僕なら、ViewModel同士を無理やりMessenger（イベントバスみたいなやつ）でつないで、スパゲッティコード一歩手前のものを作っていたかもしれません。
でも、その朝の僕は違った。
「あ、これ、共通の親ViewModelにDependency Injection（依存性の注入）でSharedService（共有サービス）を一個挟めば、全部そいつ経由でキレイに状態管理できるじゃん」
…と、ものの10分でスッキリした設計が頭に浮かんだんです。昨日まであんなに悩んでいたのが嘘みたいに。
これ、別に僕のC#やWPFのスキルが急に上がったわけじゃない。
単に「脳」が、本来のパフォーマンスを取り戻しただけなんです。
寝不足の脳って、いわば「メモリリーク」を起こしてる状態。ガベージコレクション（GC）がうまく働いてなくて、思考のゴミが溜まってる。だから新しいアイデアを入れるスペースがないし、処理も遅い。
しっかり寝ることで、この「脳のGC」がちゃんと動いて、メモリが解放される。当たり前のことでした。
次に手を出したのは「栄養」、特に「カフェインと糖質」です。
海外のオフィスって、エナジードリンクやスナック菓子が、福利厚生で「取り放題」みたいなところ、結構あるんですよ。僕のいたところもそうでした。
そりゃ、飲みますよね。午後3時、ちょっと集中力が切れてきたな…って時に、エナドリをプシュッ。小腹が空いたら、クッキーやチョコレートをつまむ。
これが最悪のループでした。
血糖値が急上昇して一時的に元気（になったフリ）をして、その直後に急降下。猛烈な眠気とダルさに襲われる。そして、そのダルさを解消するために、またエナドリかコーヒーを飲む…。
まさに「負債」を「高金利ローン」で返してる状態。
僕は、まず「午後3時以降のカフェイン」を一切断ちました。
そして、デスクに常備していたエナドリと甘いお菓子を撤去。代わりに置いたのが、**「ナッツ類（無塩）」と「ダークチョコレート（カカオ70%以上）」、そして大量の「水」**です。
ランチも変えました。以前はパスタとかピザとか、手っ取り早い炭水化物で済ませがちだったんですが、野菜や鶏肉、魚（タンパク質）をメインにするように意識しました。
効果はテキメンでした。
何より変わったのは、**「集中力の持続時間」**です。
以前は、午前中は調子が良い（カフェインのおかげで）けど、昼食後は必ずパフォーマンスがガタ落ちしていた。
それが、血糖値の乱高下を抑える食事に変えたことで、午後も安定して集中力が続くようになったんです。
WPFのデバッグって、本当に地道で集中力がいる作業なんです。
Snoop（スヌープ：WPFのデバッグツール）とかVisual Studioの「ライブビジュアルツリー」を睨みつけながら、「なぜこのButtonのIsEnabledがFalseになってるんだ？」「どのStyleがこのMargin（余白）を上書きしてるんだ？」って、UI要素のツリーを延々と追いかけないといけない。
以前は、こういう作業が午後になると苦痛で仕方なかった。集中力が続かないから、すぐ他の作業に逃げちゃってたんです。
でも、食生活を改善してからは、そういう「地味だけど重要なタスク」にも、しっかり腰を据えて取り組めるようになりました。結果、バグの発見も早くなったし、何より仕事のストレスが激減しました。
まとめると、僕がやったのは以下の2つだけ。
- 睡眠を「最優先タスク」としてスケジュールする。（脳のGCを回すため）
- エナドリと砂糖をやめ、血糖値を安定させる食事に変える。（脳のCPUを安定稼働させるため）
キーボードを叩くのは「指」かもしれないけど、コードを設計し、バグを見つけるのは「脳」です。
僕たちエンジニアは、その「脳」という最重要ツールのメンテナンス方法について、あまりにも無頓着すぎた。WPFの最新テクニックを学ぶ前に、まず自分の脳を最高のコンディションに保つこと。
これが、僕が海外で燃え尽きかけて学んだ、一番大事な「パフォーマンス術」の第一歩です。
…ただ、これだけではまだ足りませんでした。
体調（ハードウェア）は万全になった。でも、今度は僕の「心（ソフトウェア）」が悲鳴を上げ始めたんです。
それが、海外で働くエンジニアが必ずぶち当たる「ストレス」と「失敗への恐怖」という、もっと厄介な問題でした。
襲い来る「不安」との戦い。僕を救ったマインドフルネスと「失敗」の正しい活かし方
（承からのつづき）
さて、睡眠と栄養。この「ハードウェア（身体）」のメンテナンスを徹底したことで、僕のパフォーマンスは劇的に改善しました。霧が晴れた頭で、WPFの複雑な設計にも、地味なデバッグ作業にも向き合えるようになった。
「よし、これで俺も海外でバリバリやっていけるぞ！」
…そう思った矢先でした。
ハードウェアが快調になったことで、逆に、もっと厄介な問題がクッキリと浮かび上がってきたんです。
それは、僕の「ソフトウェア（心・思考）」の問題。
具体的に言えば、**「際限のない不安」と「失敗への極度な恐怖」**です。
海外で働くエンジニア、特に僕みたいに英語が第二言語の人間にとって、これ、本当にあるあるだと思うんです。
例えば、
- ミーティングで、自分の拙い英語のせいで、せっかく考えた設計（アーキテクチャ）の意図が正しく伝わらなかったらどうしよう…
- コードレビューで、ネイティブの同僚から「こんな簡単なことも知らないのか？」って思われるような指摘を受けたらどうしよう…
- Slackで飛び交うジョークやスラングの意味が分からず、会話から取り残されたらどうしよう…
技術（C#やWPF）には自信がある。でも、それを「伝える」部分で、常にハンデを背負っている感覚。
この「不安」が、僕の集中力をじわじわと蝕んでいきました。
WPFのコードを書いていても、頭の片隅で、さっきのミーティングでの自分のたどたどしい英語をリピート再生して「ああ言えばよかった…」と後悔したり。
デバッグ中にSlackの通知音が鳴るたびに、「緊急のトラブルか？」「俺、何かやらかしたか？」とビクッとしたり。
これ、エンジニアの仕事にとって致命的ですよね。
僕らの仕事、特にWPFのUI設計や、async/awaitを使った非同期処理のロジックを組む時って、**「深い集中（ディープワーク）」**が不可欠なんです。
WPFのVisualTree（ビジュアルツリー）とLogicalTree（ロジカルツリー）の違いを意識しながらカスタムコントロールを作っている時に、Slackの通知で思考が中断される。
…たったそれだけで、元の集中状態に戻るのに15分以上かかる、なんてザラです。
この状態、まさに僕の脳が「コンテキストスイッチング」を頻発させて、CPUリソースを無駄遣いしている状態でした。
そこで僕が取り入れたのが、「マインドフルネス」です。
「マインドフルネス」って聞くと、なんかスピリチュアルな「無になる」みたいなイメージ、ありませんか？
僕も最初はそう思ってました。でも、エンジニア向けに調べてみたら、全然違った。
僕なりの解釈ですが、**エンジニアにとってのマインドフルネスは、「脳のタスクマネージャーを起動する技術」**です。
僕の脳は、メインタスクである「コーディング」の裏で、「不安」「後悔」「未来の心配」みたいな、無駄なバックグラウンドプロセスが大量に動いて、CPU（集中力）を食い荒らしている状態でした。
マインドフルネスは、まず「あ、今、俺は”コーディング”タスクじゃなくて、”不安”タスクを処理してるな」と**『気付く』**ことです。
そして、『気付いたら』、そっとそのプロセスを終了して、意識をメインタスク（目の前のコード）に戻す。
僕がやったのは、すごく簡単なことです。
- ポモドーロ・テクニックの導入: 25分集中して、5分休む。その25分間は、Slackもメールも、スマホの通知も全部オフ。物理的に「割り込み（Interrupt）」を遮断します。
- 「呼吸」をアンカーにする: 25分の集中タイムが始まるとき。まず10秒だけ、深く息を吸って、吐く。意識を「今、ここ」に強制的に持ってくる儀式です。
- 「気付き」の訓練: コーディング中に「あ、またあのミーティングのこと考えてる…」と気付いたら、自分を責めずに、「はい、思考逸れたね。OK、コードに戻ろう」と、淡々と意識を戻す。
これを繰り返すうちに、明らかに「今、ここに集中する力」が強くなりました。
不安がゼロになるわけじゃないんです。でも、不安という「プロセス」にCPUを乗っ取られる時間が、劇的に短くなった。
これは、海外で働く上で、最強のストレス管理術になりました。英語がどうとか、評価がどうとか、そういう「今コントロールできないこと」に脳のリソースを割くのをやめられたんです。
そして、もう一つの「大ボス」が、「失敗への恐怖」でした。
体調を整え、集中力を手に入れた。それでも、僕は「失敗」をしました。
それは、WPFアプリケーションのコア機能である、データの「保存」ロジックに関するものでした。
要件の解釈を一部間違えていて、特定の条件下でユーザーが入力したデータが正しく保存されない、というクリティカルなバグを、リリース直前にQA（品質保証）チームに見つけられてしまったんです。
もう、血の気が引きました。
頭に浮かんだのは「終わりだ」「俺の評価はガタ落ちだ」「あの時、なんで確認しなかったんだ…」という自己否定のオンパレード。
これが、いわゆる**「固定マインドセット（Fixed Mindset）」**です。
「自分の能力は”固定”されていて、失敗は、自分の”能力の低さ”の証明だ」と思い込む、最悪の思考パターン。
この時、僕を救ってくれたのも、またあのリードエンジニア（オランダ人のおじさん）でした。
彼は僕を呼び出すと、怒るでもなく、ため息をつくでもなく、こう言ったんです。
「OK。バグは見つかった。それはラッキーだ。じゃあ、このバグから『何を学べる』？」
ハッとしました。
彼は、僕を「評価」するんじゃなく、バグを「データ」として見ていたんです。
これが、スタンフォード大学のキャロル・S・ドゥエック教授が提唱する**「成長マインドセット（Growth Mindset）」**との出会いでした。
「失敗は、自分の能力の”終点”ではなく、能力を伸ばすための”情報”である」
この考え方に切り替えた瞬間、世界が反転しました。
- デバッグが「罰ゲーム」じゃなくなった。バグは「俺のせいだ…」から、「お、面白い。どのロジックがこの想定外（Exception）を生んだんだ？」という「謎解き」に変わりました。WPFのデバッグツール（Snoopとか）でBindingエラーを追跡するのも、以前は苦痛でしたが、「なるほど、このDataContextがnullになるタイミングがあるのか。いいこと知ったわ」と、学習の機会に変わったんです。
- コードレビューが「攻撃」じゃなくなった。以前は、レビューコメントが付くたびに「うわ、また否定された…」とビクビクしていました。でも、成長マインドセットでいれば、それは「僕の知らないC#の書き方」や「僕が見落としていた設計の穴」を教えてくれる**「無料の技術コンサルティング」**に変わるんです。「ああ、この方がICommandの実装としてクリーンだな、ありがとう！」って、素直に思えるようになりました。
海外で働く、特に文化も言語も違う環境では、日本にいる時の10倍は「失敗」や「誤解」に遭遇します。
そのたびに「固定マインドセット」で「俺はダメだ…」と落ち込んでいたら、あっという間に燃え尽きます。
そうじゃなくて、すべての失敗を「お、新しいデータが取れたぞ」「次はこうアップデートしよう」と、git commitするみたいに、自分の経験値として積み上げていく。
「バグ（失敗）は、敵じゃない。最高の学習リソースだ」
このマインドセットの転換こそが、僕を「燃え尽き」から本当に救ってくれた、一番の「人生術」だったんです。
体（睡眠・栄養）を整え、心（マインドフルネス）を整え、そして、思考（グロースマインドセット）を整える。
この3つが揃って初めて、エンジニアは持続的に高いパフォーマンスを発揮できる「マインドフル・エンジニア」になれるんだと、僕は確信しました。
最強のスキルは「持続可能性」だった。明日からできるマインドフル・エンジニアリング
（転からのつづき）
「起」で僕の燃え尽き寸前の大失敗を、「承」で睡眠と栄養という「ハードウェア」の再構築を、そして「転」でマインドフルネスとグロースマインドセットという「ソフトウェア」のデバッグについてお話してきました。
長くなりましたが、僕がこの一連の経験から学んだ、たった一つの、しかし何よりも重要な「得する情報」であり「人生術」は、これです。
海外で働くITエンジニアにとって、最強のスキルはC#でもWPFでもなく、「自分自身の持続可能性（サステナビリティ）」である。
どういうことか。
僕たちはエンジニアとして、常に「拡張性（Scalability）」や「保守性（Maintainability）」の高いコードを書こうと努力します。async/awaitを使ってUIの応答性を保ったり、MVVMパターンでロジックとUIをきれいに分離したり。
なぜそんな面倒なことをするかと言えば、その方が「長持ち」するし、「将来の変更に強い」し、「バグが減る」からです。その場しのぎのコピペコードは、いつか必ず技術的負債になって、プロジェクト全体をクラッシュさせますよね。
これ、僕たちエンジニア自身にも、まったく同じことが言えるんです。
エナジードリンクと寝不足でひねり出すパフォーマンスは、まさしく「その場しのぎのコピペコード」です。
「不安」や「失敗への恐怖」を放置したまま働くのは、例外処理（try-catch）を忘れたままリリースするようなもの。いつか必ず、致命的な「例外（Exception）」でアプリ（＝あなた自身）がクラッシュします。
僕もそうでした。自分の「技術スタック（C#, WPF）」を磨くことばかりに夢中で、その技術スタックを動かしている「OS（自分自身）」のメンテナンスを、完全に怠っていました。
海外という、慣れない高負荷な環境（＝本番環境）で、デバッグもロクにしてないOSを動かそうとしていた。そりゃフリーズ（燃え尽き）もしますよ。
「マインドフル・エンジニア」とは、特別な人間になることじゃありません。
自分の「ハードウェア（身体）」と「ソフトウェア（心・思考）」の状態に常に気を配り、バグ（不調）があれば早期に検知し、適切なメンテナンス（睡眠・栄養・マインドフルネス）を怠らない。
そして、失敗（バグ）を「学習の機会」としてcommitし、自分自身を日々アップデート（グロースマインドセット）していく。
これって、僕たちが毎日やっている「エンジニアリング」そのものじゃないですか？
WPFのBindingがうまくいかない原因を探るように、自分の集中力が続かない原因を探る。
C#のコードをリファクタリングするように、自分の思考のクセ（固定マインドセット）をリファクタリングする。
そう考えると、僕たちが「エンジニア」として学んできた論理的思考は、すべて「自分自身を最適化する」ために応用できるんです。
さて、明日から。
この長いブログを読んでくれたあなたが、これから海外で働くにあたって、まず何をすべきか。
「全部やらなきゃ！」と気負う必要は、まったくありません。
（そういう「完璧主義」こそが、燃え尽きの第一歩ですからね！）
この記事で紹介した「得する情報」は、たった一つでいいから、試してみてください。
- 今夜、いつもより30分だけ早くPCを閉じて、ベッドに入ってみる。それだけで、明日のあなたの「脳のGC（ガベージコレクション）」は、いつもより少しだけうまく動くはずです。
- 明日、仕事中に「あ、今、関係ない不安を考えてるな」と気付いたら、1回だけ、深呼吸して意識を目の前のコードに戻してみる。それだけで、あなたの「CPU（集中力）」の無駄遣いを、数分だけ防げたことになります。
- 明日、コードレビューで指摘を受けたら、「うわっ」と思う代わりに、「なるほど、この視点はなかった。情報ゲット」と、心の中で（演技でもいいから）呟いてみる。それだけで、あなたの「固定マインドセット」に、小さなヒビを入れることができます。
海外で働くというチャレンジは、マラソンです。短距離走じゃない。
必要なのは、一瞬の爆発的なスピードではなく、どこまでも走り続けられる「持続可能性」です。
あなたのC#やWPFの技術は、素晴らしい武器です。
でも、その武器を振るい続けるための「体力」と「精神力」がなければ、宝の持ち腐れになってしまう。
僕もまだまだ道半ばです。今でも不安になるし、失敗もします。
でも、そのたびに「おっと、メンテナンスの時間だな」「いいデータが取れたぞ」と、自分自身をエンジニアリングするようになりました。
あなたの海外でのエンジニアライフが、燃え尽きることなく、持続可能で、実りあるものになることを、心から願っています。
最後まで読んでくれて、ありがとうございました！
コメント