異国の地でC#と格闘する僕らが、本当に戦っている敵の正体
エディタの前の「空白」の時間
その日、僕はオフィスの窓から見える曇り空を眺めながら、もう1時間も同じクラスファイルを睨みつけていました。
手元には冷めきったコーヒー。画面にはVisual Studio。書いては消し、書いては消しているのは、複雑なアルゴリズムではありません。ごく単純なMVVMパターンの、ViewModel側のプロパティ変更通知の実装でした。
「INotifyPropertyChangedの実装なんて、息をするように書けるはずだろう？」
普段の僕ならそうです。でも、その日は違いました。
頭の中が、とんでもなくうるさかったんです。
海外でエンジニアとして働くというのは、日本で働くのとはまた違った種類の「ノイズ」に常に晒され続けることを意味します。
その日の僕の脳内は、まるで例外処理（try-catch）が入っていない無限ループに陥ったスレッドのような状態でした。
- 「さっきのミーティング、あの英語のニュアンス、本当に正しく伝わったかな？」
- 「ビザの更新書類、来週までに人事に出さないとマズいな」
- 「このWPFのレンダリングパフォーマンス、クライアントの古いPCで耐えられるか？」
- 「というか、ランチの時に同僚が言ってたジョーク、あれどういう意味だったんだ？」
- 「日本の友達のインスタ、楽しそうだな……」
これら、仕事に関係あることもないことも含めた全ての思考が、**「Inner Noise（脳内ノイズ）」**となって、僕のコグニティブ・バンド幅（認知的帯域）を食いつぶしていたのです。
エンジニア、特に設計や複雑なロジックを組む僕たちにとって、もっとも重要なリソースは「集中力」です。よく「ゾーンに入る」とか「フロー状態」と言いますが、あの状態に入って初めて、僕らは複雑なシステム構造を脳内に展開し、バグのない美しいコードを書くことができます。
しかし、海外生活という環境は、そのフロー状態への没入を全力で阻害してきます。言語の壁、文化の違い、孤独感、将来への不安。これらがバックグラウンドプロセスとして常に脳のメモリを消費し続けているのです。
WPF開発と「脳内メモリ」の密接な関係
少し技術的な話をしましょう。僕がメインで扱っているC#のWPFというフレームワークは、非常に強力ですが、同時に開発者に対して高い抽象度での思考を要求します。
View（見た目）とViewModel（ロジック）を疎結合にするために、データバインディングやコマンド、Behaviorsといった概念を駆使します。XAMLで書かれたUIの挙動が、裏側のC#コードのどのプロパティと連動し、それがModel層のどのデータに影響を与えるか。この一連のデータの流れ（Data Flow）を、開発者は脳内でシミュレーションしながら設計します。
この作業は、脳内のワーキングメモリを大量に消費します。
「ここのプロパティが変わると、こっちのトリガーが発火して、コンバーターを通って……あ、ここで非同期処理が走るからUIスレッドに戻さないと」
というような思考のタワーを積み上げている最中に、「あ、そういえば来月の家賃振り込んだっけ？」というノイズが一つ入るだけで、積み上げたタワーは一瞬で崩壊します。
日本にいた頃は、生活に関わる部分が「自動化」されていました。言葉は通じるし、役所の手続きもわかるし、空気も読める。だから、脳の容量の90%をコードに向けることができました。
しかし、海外に出ると、生活の維持そのものに脳の30%〜40%を持っていかれます。残りの60%で、今まで通りの、いや、それ以上のクオリティの仕事を求められる。しかも英語で。
これが、多くの海外エンジニアが最初にぶつかる「見えない壁」の正体です。
技術力不足ではない。語学力不足でもない。
**「脳内ノイズによる、思考リソースの枯渇（Resource Exhaustion）」**なのです。
「気合い」で解決しようとして壊れた日
最初、僕はこれを「気合い」と「長時間労働」でカバーしようとしました。
集中できないなら、集中できるまでデスクに座っていればいい。ノイズがうるさいなら、ヘッドホンで大音量の音楽を流せばいい。
結果どうなったか。
**「Pre-Mortem Procrastination（事前の先送り）」**という泥沼にハマりました。（これについては、次の章で詳しく解説しますが、要は「始める前から負けている」状態です）。
あるプロジェクトの締め切り前、僕は重要な機能実装を任されていました。複雑なDataGridのカスタマイズで、パフォーマンスチューニングが必要な難易度の高いタスクです。
朝、席に着く。「よし、やるぞ」と思う。
でも、頭の中には「昨日のコードレビューでの指摘」「同僚とのちょっとした会話の行き違い」「夕飯の買い出し」といったノイズが渦巻いている。
そのノイズから逃げるように、僕は無意識にメールチェックを始め、Slackの全てのチャンネルを巡回し、技術ブログを読み漁り、気づけば昼になっていました。
「午前中、一行もコードを書いていない」
この事実は、さらなる強烈なノイズとなって襲いかかってきます。「俺はここで何をしているんだ？」「給料泥棒じゃないか？」「やっぱり海外なんて無理だったんじゃないか？」
自己嫌悪のノイズは、最も凶悪なウイルスのように脳全体に感染します。
午後になっても集中力は戻らず、焦って書いたコードはバグだらけ。
夕方、マネージャー（陽気なオージーです）に「進捗どう？」と聞かれた時、僕は曖昧な笑顔（Japanese Vague Smile）で誤魔化すことしかできませんでした。
その夜、アパートに帰って、冷えたピザを食べながら思いました。
「C#のガベージコレクション（GC）は優秀なのに、なんで俺の脳みそのGCはこんなにポンコツなんだろう」と。
C#では、使われなくなったメモリはGCが自動的に解放してくれます。しかし、人間の脳、特に不安やストレスを抱えた脳は、不要になった思考（ノイズ）をいつまでも握りしめ、メモリリークを起こし続けます。
このままでは、エンジニアとしてのパフォーマンスが出せないどころか、メンタルが潰れてしまう。
ノイズは「消す」ものではなく「飼いならす」もの
そこで僕は気づきました。
僕に必要なのは、新しい技術書を読むことでも、英語の勉強時間を増やすことでもない。
この**「Inner Noise（脳内ノイズ）」を管理するための、エンジニアリング的なアプローチ**だと。
システム開発において、ノイズ（例外や想定外の入力）を完全にゼロにすることは不可能です。大事なのは、エラーハンドリングを適切に行い、システム全体をクラッシュさせない設計にすること。
人間の脳も同じです。不安や雑念を「無くそう」とするのは無理があります。人間だもの。
でも、それらを「キャッチ」し、「分類」し、適切なタイミングで「処理」する仕組みを作ることはできるはずです。
僕はそこから、心理学や脳科学、そして生産性向上に関する文献を漁り、自分のエンジニアとしての働き方に落とし込む実験を始めました。
試行錯誤の末、たどり着いたのが、今回ご紹介する3つのテクニックです。
- The “Thought-Catching Net”（思考捕捉ネット）：割り込み処理を制御する
- “Pre-Mortem Procrastination”（検死解剖的先送り回避）：デッドロックを事前に防ぐ
- The “Focus Reset Button”（フォーカスリセットボタン）：メモリを明示的にクリアする
これらは、精神論ではありません。
C#で言うところの、Taskによる非同期制御、try-catchによる例外処理、そしてDisposeによるリソース解放に近い、極めてロジカルな「脳の運用技術」です。
次章（承）では、これらのテクニックを具体的にどう実践し、僕がどうやって「書けないエンジニア」から脱却して、海外の現場で「お前、仕事早いな」と言われるようになったのか。その具体的なメソッド（Source Code for Life）を公開します。
Visual Studioを開く前に、まずは自分の脳内環境（IDE）の設定を見直してみませんか？
驚くほど、世界がクリアに見えるようになりますよ。
脳のCPU使用率を最適化する「3つの思考デフラグ術」
前回の記事で、僕ら海外エンジニアが戦っているのは、複雑な仕様書やレガシーコードだけでなく、頭の中を埋め尽くす「脳内ノイズ」だとお話ししました。
言語の壁、ビザの不安、そして技術的な課題。これらがバックグラウンドプロセスとして常駐し、本来WPFの美しいUI設計に割くべきリソースを食いつぶしている状態です。
では、具体的にどうすればいいのか？
精神統一？ 滝行？ いえいえ、僕らはエンジニアです。根性論ではなく、システム的アプローチで解決しましょう。
僕が試行錯誤の末にたどり着いた、脳のメモリリークを防ぎ、パフォーマンスを最大化する「3つのメソッド」を、コードの実装パターンに例えながら解説します。
1. The “Thought-Catching Net”（思考捕捉ネット）
〜割り込み処理（Interrupt）をキューイングせよ〜
集中してコードを書いている時、ふと「あ、昨日のプルリク、マージされたかな？」とか「帰りに牛乳買わないと」といった雑念が浮かぶこと、ありますよね？
これを僕は「脳内割り込み（Hardware Interrupt）」と呼んでいます。
多くの人は、この割り込みが発生した瞬間、無意識にAlt + Tabを押してブラウザを開いたり、スマホを手に取ったりしてしまいます。これが最悪です。
一度コンテキストスイッチが発生すると、元の深い思考（ゾーン）に戻るのに平均で23分かかるという研究データもあります。牛乳のことを一瞬考えただけで、ViewModelの設計図が頭から飛び、再構築に20分ロスする。これはあまりに高コストです。
そこで登場するのが**「Thought-Catching Net（思考捕捉ネット）」**です。
【実装方法】
やり方は極めてアナログかつシンプルです。
キーボードの横に、A5サイズくらいの**「紙のノートとペン」**を常に置いておくだけ。
脳内にノイズ（雑念）が発生した瞬間、作業を止めずに、視線だけをノートに移し、そのキーワードを殴り書きします。
- 「牛乳」
- 「ビザ書類」
- 「田中さんにSlack」
ポイントは、**「その場では何もしない」**こと。ただ書き留めるだけです。
C#で言えば、UIスレッドをブロックせずに、重い処理をTask.Runでバックグラウンドキューに投げるイメージです。「後で処理するから、今はとりあえずキューに入れておく」と脳に言い聞かせるのです。
【なぜ効くのか】
人間の脳は「未完了のタスク」を気にする性質（ツァイガルニク効果）があります。「忘れるかもしれない」という不安が、ワーキングメモリを占有し続けるのです。
しかし、紙に書き出すことで、脳は「外部ストレージに保存された（永続化された）」と認識します。これで脳内のメモリ（RAM）からそのタスクを解放（Dispose）できるのです。
僕はこれを始めてから、コーディング中に突然襲ってくる「得体の知れない不安」が激減しました。「不安になったら書く」。これだけで、驚くほど深く潜れます。ネット（網）で雑念を捕まえて、後でまとめて料理すればいいのです。
2. “Pre-Mortem Procrastination”（検死解剖的先送り回避）
〜例外を事前にCatchして握りつぶす〜
「さあ、これから重たいリファクタリングをやるぞ」という時ほど、なぜかデスクの片付けを始めたり、新しいキーボードを探し始めたりしませんか？ これがいわゆる「先送り（Procrastination）」です。
これを防ぐためのテクニックが**「Pre-Mortem（検死解剖）」です。
通常、Post-Mortem（事後検証）はプロジェクトが失敗した後に「なぜ失敗したか」を分析するものですが、Pre-Mortemはその逆。プロジェクト（この場合、今の作業セッション）を始める前に**、「今回の作業が失敗するとしたら、何が原因になるか？」を先にシミュレーションするのです。
【実装方法】
朝、仕事を始める前、あるいは大きなタスクに取り掛かる前の5分間。コーヒーを片手にこう自問します。
「もし今日、僕が全く集中できずに1日を終えるとしたら、その犯人は誰だ？」
答えは具体的であればあるほど良いです。
- 「たぶん、14時くらいに眠くなってYouTubeを見始めるだろう」
- 「あの難解な非同期処理のバグに行き詰まって、現実逃避でTwitterを見るだろう」
- 「同僚のMikeが話しかけてきて、そこから長話になるだろう」
犯人（例外発生源）が特定できたら、事前にtry-catchブロックを書いておきます。
- 「14時に眠くなる」→ 対策： 13:55にアラームをかけ、強制的に外の空気を吸いに行く。
- 「バグで行き詰まる」→ 対策： 15分悩んで進まなければ、必ず誰かに相談するというルールを決める。
- 「Mikeが話しかけてくる」→ 対策： 今日はあらかじめ「集中モードだから急用以外はSlackで」とイヤホンをしてオーラを出す。
【エンジニア的視点】
これは、設計段階でコーナーケースを洗い出す作業と同じです。
バグが出てからデバッグするより、設計段階で潰しておくほうがコストが低いのは自明の理。自分の行動パターンという「バグだらけのレガシーコード」に対して、先にテストケースを書いておくのです。
これをやるだけで、「あ、今YouTube見ようとしてるな、これ朝予想した通りのバグだ」と客観的に自分を見ることができ、踏みとどまることができます。
3. The “Focus Reset Button”（フォーカスリセットボタン）
〜明示的にGC（ガベージコレクション）を発動させる〜
いくら対策しても、長時間集中していれば脳のキャッシュはゴミデータで溢れます。
パフォーマンスが落ちてきたな、と感じた時、多くの人は「休憩」と称してスマホを見ます。ニュースサイトを見たり、SNSをチェックしたり。
断言します。それは休憩ではありません。情報の追加ロードです。
疲れている脳に、さらに新しいノイズを流し込んでいるだけです。これではメモリリークは解消されません。
必要なのは、脳を「空っぽ」にする**「Focus Reset Button」**です。
【実装方法】
僕が実践しているリセットボタンは、以下のマイクロ・ブレイクです。
- 20-20-20ルール（視覚のリセット）：20分おきに、20フィート（約6メートル）先を、20秒間ぼーっと眺める。画面上のピクセルに固定された焦点を物理的に解放します。オフィスの窓から見える木でも、向かいのビルの壁でもいいです。情報を「入力」せず、ただ「見る」。
- 4-7-8呼吸法（自律神経のリセット）：システムが暴走（イライラ、焦り）し始めたら、椅子に座ったまま行います。4秒かけて鼻から吸い、7秒止めて、8秒かけて口から吐き切る。これを3セット。強制的に副交感神経を優位にし、脳のクロック周波数を正常値に戻します。
- トイレ・デバッグ（場所のリセット）：どうしてもロジックが組めない時は、席を立ってトイレに行きます。不思議なことに、席を立って歩いている最中や、手を洗っている瞬間に「あ、あそこのBindingModeがTwoWayになってないじゃん！」と解決策が降りてくることがよくあります。脳科学的にも、場所を変えることで脳の活動領域（Default Mode Network）が切り替わることがわかっています。
【コードとしての人生】
これらの休憩は、C#で言うところのGC.Collect()（強制ガベージコレクション）や、Flush()メソッドです。
メモリを空けないまま次の処理を詰め込んでも、OutOfMemoryExceptionで落ちるだけ。
「何もしない時間」を能動的に作ること。それが、次の1時間、最高のパフォーマンスでコードを書くための唯一の手段です。
こうして、**「思考捕捉ネット」で割り込みを制御し、「先送り回避」で例外を事前に防ぎ、「フォーカスリセット」**で定期的にメモリを掃除する。
この3つを回すことで、僕は海外という高負荷な環境でも、なんとか正気を保ちながらエンジニアとして生きています。
しかし、これらのテクニックを駆使して「効率的」になった先に、実はもう一つの大きな「罠」が待っていました。
効率化された時間で、僕は何をすべきなのか？
ただ馬車馬のようにチケットを消化するだけでいいのか？
次章「転」では、このノイズコントロールの先に見えてきた、**「エンジニアとしてのキャリアの本質」**についてお話しします。
それは、効率化のテクニックよりももっと泥臭く、そして温かいものでした。
生産性だけじゃない。「ノイズ」が教えてくれる、自分らしいキャリアの在り処
「最適化」された孤独なマシン
前章で紹介した「3つの思考デフラグ術」を駆使することで、僕の生産性は劇的に向上しました。
出社と同時に「Pre-Mortem」で障害を予測し、仕事中は「Thinking Net」で雑念をキャッチし、「Focus Reset」で脳をクリアに保つ。
Visual Studioのキータイプ音だけが響く静寂の空間。
同僚のジョーク（英語のノイズ）には愛想笑いで即座にreturn;し、ランチタイムもイヤホンをして技術ポッドキャストを聞きながらサンドイッチを流し込む。
WPFの複雑なデータバインディングも、非同期処理の競合も、次々と解決していきました。
マネージャーからは「最近、すごい集中力だな。チケットの消化率がチームで一番だ」と褒められました。
計画通りです。僕は「海外でも通用する優秀なエンジニア」になれたはずでした。
しかし、ある金曜日の夕方、ふと空虚感に襲われました。
「あれ、俺、日本にいた時とやってること変わらなくないか？」
もっと言えば、チャットGPTやGitHub Copilotが生成するコードと、僕が書いているコードにどれほどの差があるんだろう？
ノイズを極限まで排除し、仕様書通りに機能を実装するだけの存在。それは、あたかも「人間らしさ」という機能を削ぎ落とした、最適化されすぎたレガシーコードのようでした。
e.Handled = true の落とし穴
WPFやWindowsフォームをやっている人ならわかると思いますが、イベントハンドラには e.Handled = true というプロパティがあります。これを true に設定すると、そのイベントはそこで処理済みとみなされ、親コントロールや他の要素には伝播しません（バブリングが止まります）。
僕がやっていた「ノイズ対策」は、まさにこれでした。
周囲の雑音、同僚の無駄話、現地の文化的な摩擦、自分自身の将来への不安。これらすべてに対して、即座に Handled = true をセットし、自分の内側に届かないように握りつぶしていたのです。
でも、システム開発において「全てのエラーを握りつぶす（Swallow Exceptions）」のがアンチパターンであるように、人生においても全てのノイズを遮断するのは危険でした。
ある日、プロジェクトで大きな仕様変更の話が持ち上がりました。
僕は自分のタスクに集中するあまり（ノイズを遮断していたあまり）、オフィスのコーヒーメーカーの周りで同僚たちが話していた「クライアントの担当者が変わったらしいよ」「あそこ、実はモバイル対応を優先したがってるらしいぜ」という噂話（＝ノイズ）を完全にスルーしていました。
結果、僕は「仕様書通りだが、誰も望んでいない機能」を完璧なコードで実装してしまいました。
同僚のMike（また彼ですが）は、コードは汚いけれど、その「噂話」というノイズをキャッチし、「だったら今のうちに構造変えておこうぜ」と提案していたのです。
「ノイズの中には、シグナルが混ざっている」
通信工学で言うS/N比（信号対雑音比）の話です。ノイズをゼロにしようとフィルターを強くかけすぎると、微弱だけど重要なシグナルまでカットしてしまう。
海外で働くことの価値は、実はこの「雑音」の中にこそあったのです。
異文化の摩擦、言葉の通じないもどかしさ、予期せぬトラブル。これらは一見、開発効率を下げる「ノイズ」です。しかし、そこから逃げてヘッドホンをするなら、日本からリモートワークをしているのと変わりません。
そのノイズという名の「混沌」に身を浸し、そこからパターンを見つけ出し、適応していくプロセスこそが、僕らがわざわざ海を渡った理由だったはずです。
「不安」という名のコンパイラ警告
そしてもう一つ、僕が必死に「Thought-Catching Net」で捕獲して隔離していた「内なるノイズ」について。
「このままでいいのか？」「自分の技術は通用するのか？」という不安の声です。
僕はこれを「集中を乱す敵」だと思っていました。
しかし、静寂の中でコードを書いている時、ふと気づいたのです。
これは敵ではない。**コンパイラが出している Warning（警告）**なのだと。
C#のコンパイラは優秀です。致命的なエラー（Error）だけでなく、「この書き方は将来バグになるかもよ」「この変数は使われてないよ」と警告を出してくれます。
多くの初心者は警告を無視してビルドを通そうとしますが、熟練したエンジニアは警告を「コードの品質を上げるヒント」として扱います。
僕の脳内で鳴り響いていた「不安」も同じでした。
「英語のプレゼンが怖い」というノイズは、「準備不足だぞ、もっとリハーサルしろ」という警告。
「新しいフレームワークについていけるか不安」というノイズは、「今のスキルセットに依存しすぎているぞ」という警告。
それらを「雑念」として紙に書いて忘れるだけでは、根本的な解決にはなりません。
ノイズコントロールの真髄は、**「作業中は棚上げにする（非同期処理にする）」ことですが、「後で必ず向き合う（awaitする）」**ことまでがセットだったのです。
非同期処理の await を忘れるな
技術的な話に戻しましょう。
Task.Run() で重い処理を別スレッドに逃がすのは良い。でも、その結果を await で受け取らなければ、処理の結果は虚空に消えます（Fire-and-Forget）。
僕は「思考捕捉ネット」で捕まえた不安や雑念を、仕事が終わった後に見返す時間を設けました。
- 「ビザの更新が不安」→ （アクション）今週末に弁護士のサイトを調べるタスクに変換。
- 「同僚の英語が聞き取れない」→ （アクション）悔しいから、今度ランチに誘って1対1で話してみる。
かつては「集中を阻害するゴミ」に見えていたメモ書きが、見方を変えると**「自分を成長させるためのTODOリスト」**に変わりました。
そう、ノイズはゴミじゃない。まだ処理されていない「生データ」だったのです。
「カオス」を受け入れる設計思想
C#には「防御的プログラミング（Defensive Programming）」という考え方があります。想定外の入力が来ても落ちないようにガチガチに固める手法です。
しかし、最近のクラウドネイティブな世界では「回復性（Resiliency）」や「カオスエンジニアリング」という考え方が主流です。
障害やノイズは発生する前提。システムの一部が落ちても、全体としては機能し続ける。むしろ、障害を経験することでシステムが強くなる。
人間も同じです。
「絶対に集中しなきゃいけない」「ノイズを入れてはいけない」という防御的な姿勢は、脆（もろ）い。
一度集中が切れたら、自己嫌悪で崩壊してしまう。
そうではなく、
「ノイズは入ってくるものだ」
「集中は切れるものだ」
「不安は感じるものだ」
と受け入れる。
WPFのデータバインディングのように、内面の変化（不安）と外面の行動（タスク）をリアルタイムに同期させる必要はないのです。
一方向（OneWay）でいい。不安はそこにある。でも、手は動かす。
そして、たまに手を止めて、そのノイズに耳を澄ませてみる。
そうやって「ノイズを飼いならす」から「ノイズと共存する」へとマインドセット（設計思想）をリファクタリングした時、僕の海外生活は、単なる「労働」から、彩り豊かな「冒険」へと変わっていきました。
完璧な静寂なんて、サーバー室の中だけで十分です。
僕らは人間なのだから、もう少しノイズ混じりのアナログな信号を愛してもいいのではないでしょうか。
静寂の中で書き上げる、君だけのソースコード
ツールは手段であり、目的ではない
ここまで、海外生活につきまとう「脳内ノイズ」と戦うための具体的なメソッド（思考捕捉ネット、検死解剖的先送り回避、フォーカスリセット）と、そのノイズを「シグナル」として捉え直すマインドセットについてお話ししました。
これらを読んで、「よし、明日から完璧にノイズをコントロールして、バリバリコードを書くぞ！」と意気込んでいる方もいるかもしれません。
ですが、最後に一つだけ、C#エンジニアの先輩として、あるいは同じ異境の地で泥臭く生きる同志として、伝えておきたいことがあります。
それは、**「ライフハックという名のフレームワークに依存しすぎるな」**ということです。
WPFの開発において、MVVMフレームワーク（PrismやMVVM Lightなど）は非常に便利です。しかし、フレームワークを使うこと自体が目的になってしまい、「ここの実装、フレームワークの規約に合わないから」といって、本来ユーザーが求めているUX（ユーザー体験）を犠牲にしては本末転倒です。
人生も同じです。
今回紹介したテクニックは、あくまで「手段」です。
思考をノートに書き出すのも、呼吸を整えるのも、全ては**「あなたが、あなたらしく在るため」**のライブラリに過ぎません。
もし、テクニックを実践すること自体がストレス（新たなノイズ）になるなら、そんなものはUninstall-Packageしてしまえばいい。
大事なのは、効率的に働くことそのものではなく、効率化によって生まれた「余白」で、何をするかです。
仕様書のないプロジェクトへようこそ
日本でエンジニアをしていた頃、僕らの前には常に「仕様書」がありました。あるいは、空気という名の「暗黙の仕様」がありました。
それに沿ってコードを書けば、正解とされ、評価されました。
しかし、海外に出た瞬間、その仕様書は白紙になります。
「どんなキャリアを築くか？」
「どんなライフスタイルを送るか？」
「そもそも、なぜこの国にいるのか？」
これら全てを、自分で定義し、設計し、実装しなければなりません。
これは、既存のプロジェクトの保守運用（Maintenance）ではなく、完全な**新規開発（Greenfield Project）**です。
しかも、ドキュメントなし。テストケースなし。頼れるシニアエンジニアもいない。
不安で当たり前です。脳内ノイズが鳴り止まないのは、あなたの脳が正常に機能している証拠です。
「コンパイルエラー」や「警告」が出ないコードなんて、Hello Worldレベルの単純なプログラムか、まだ一行も書いていない空ファイルだけです。
複雑で、高機能で、野心的なアプリケーションほど、バグや例外と戦いながら作られるものです。
あなたの人生が今、不安やノイズでうるさいなら、それはあなたが**「壮大で難しいプロジェクト」**に挑んでいる証です。
どうか、そのノイズを誇ってください。
「完璧なコード」より「動き続けるシステム」を
ソフトウェアエンジニアリングの世界には、「Done is better than perfect（完璧を目指すより終わらせろ）」という言葉があります。
また、近年のDevOpsの文脈では、「MTBF（平均故障間隔）を伸ばすより、MTTR（平均復旧時間）を短くせよ」と言われます。
つまり、「壊れないシステム」を作るのは無理だから、「壊れてもすぐに直せる力」をつけろ、ということです。
海外生活も同じです。
落ち込まないメンタルなんて手に入りません。
集中力が途切れないスーパーマンにはなれません。
でも、
「落ち込んだ時に、どうやってリカバリーするか」
「集中が切れた時に、どうやってリセットボタンを押すか」
その「復旧手順書（Runbook）」を、自分の中に持っておくことはできます。
今回紹介した「Thought-Catching Net」や「Pre-Mortem」は、まさにそのための復旧手順書です。
これさえあれば、何度クラッシュしても、必ず再起動できます。
ラスト・コミット
僕の好きなC#の機能に、usingステートメントがあります。
リソースを使い終わったら、確実に解放（Dispose）して、きれいな状態で終わらせる。
1日の終わり、仕事を終えてPCを閉じる時。
脳内ノイズ対策を頑張った自分に対して、心のなかでusingブロックを閉じてあげてください。
「今日の仕事はここまで。不安も、焦りも、未完了のタスクも、一旦メモリから解放します。お疲れ様、俺」
そして、クリアになった頭で、その国の空気を吸い、その国のビールを飲み、あるいは現地の友人と語らってください。
それこそが、あなたが海を渡ってまで手に入れたかった「報酬」のはずです。
エンジニアは、コードで世界を変えることができます。
でもその前に、あなた自身の世界（Inner World）を、心地よく、バグの少ない、素敵な場所にリファクタリングしてください。
あなたの書くコードが、そしてあなたの歩む人生が、エラーのない美しいビルドになりますように。
遠い異国の空の下から、あなたのプルリクエスト（挑戦）を応援しています。
Let’s build something great.
コメント