海外で働いている皆さん、そしていつか海を渡りたいと計画している皆さん、こんにちは。 2026年現在、僕はロンドンの空の下、相変わらずC#のコードを書き、WPFの入り組んだUIスレッドと格闘し、設計ドキュメントを英語でシバき倒す毎日を送っています。こっちの現場は「成果」に対する評価がストレートな分、いかに自分のパフォーマンスを一定に保つかが、エンジニアとしての生存率に直結します。
ところで、皆さんは**「今日、デスクに座って最初の一歩を出すまで」**に、どれくらいのエネルギーを使っていますか？
「えーっと、まずはメールを見て、あ、Slackもチェックしなきゃ。あ、あのプルリクどうなったっけ……」
そんな風に、「何をすべきか」をその場で考えているとしたら、それはエンジニアとして非常に「もったいない」状態かもしれません。今回は、インフラの世界では当たり前になった**「Infrastructure-as-Code（IaC）」**の考え方を、自分の「脳」と「環境」に応用する人生術についてお話しします。
「今日、何から始めるんだっけ？」を全滅させるメリット
海外のテック企業で働いていて、僕が一番痛感したこと。それは、「英語で仕事をする」というだけで、脳のCPUとメモリが想像以上に食われるという事実です。
複雑な設計の議論を英語で戦わせ、文化の違うチームメイトと意思疎通を図る。これだけで、僕らノンネイティブの脳内リソースは常にカツカツです。そんな状態で、「今日のタスクは何だっけ？」「ランチは何を食べよう？」「このコードの定型文、どう書くんだっけ？」なんて小さな決断（Decision Making）を繰り返していたら、肝心の「本気で考えるべき設計」のフェーズには、もう脳がオーバーヒートして動かなくなってしまいます。
これを心理学の用語で**「決定疲れ（Decision Fatigue）」**と言いますよね。
そこで僕が導入したのが、**「Infrastructure-as-Code for Your Mind（脳のインフラ構成管理）」**という考え方です。
「手動設定」の自分を卒業する
インフラの世界でIaC（TerraformやCloudFormationなど）がなぜ重宝されるかといえば、それは「再現性」と「予測可能性」があるからです。手動でポチポチと設定したサーバーは、時間が経てば「どう設定したか」を忘れ、再現できなくなります。いわゆる「秘伝のタレ」状態。これ、僕らの日常生活や仕事の進め方にも全く同じことが言えると思いませんか？
- 「昨日は集中できたのに、今日はなんだか調子が出ない」
- 「新しいプロジェクトが始まるたびに、環境設定で数日溶かしてしまう」
- 「何から手をつけていいか分からず、とりあえずSNSを眺めてしまう」
これらはすべて、自分自身の「実行環境」がIaC化されておらず、毎回**「手動でセットアップ」**しているから起こるエラーなんです。
デジタル空間のデプロイ：テンプレートと自動化で「ゼロから考える」を捨てる
海外の現場で「お前、仕事早いな！」と言われるエンジニアの共通点は、**「真っ白な画面からスタートすることがほぼない」**という点です。どんな作業も、彼らはあらかじめ用意された「テンプレート」という名のコンポーネントをデプロイするところから始めます。
1. 「dotnet new」とスニペットでボイラープレートを抹殺
C#やWPFを触っていると、避けて通れないのが「お決まりのコード（ボイラープレート）」です。新しいViewModelを作るたびにINotifyPropertyChangedを実装したり、RelayCommandを定義したり……。これを毎回手打ちしているとしたら、それはインフラを手動で設定しているのと同じです。
僕は自分専用のdotnet newテンプレートと、IDEのLive Snippetsを徹底的に作り込んでいます。
vm-baseと打てば、プロパティ通知とロギングが仕込まれたViewModelの骨格が出る。xaml-viewと打てば、よく使うGrid定義とリソース辞書が読み込まれたViewが立ち上がる。
2. 「モード」別の環境立ち上げスクリプト
僕のPCには、その日の「仕事のモード」に合わせて必要なアプリとウィンドウ配置を一瞬で整えるPowerShellスクリプトが用意されています。
- Coding Mode: Visual Studio, Terminal, Browser (Docs) を特定のレイアウトで起動。Slackとメールは起動しない。
- Meeting Mode: Miro (設計ツール), Outlook, Teams をオープン。
スクリプトを叩いて、**「システムが強制的にそのモードになる」**ようにプロビジョニングしてしまうわけです。
物理空間と時間のプロビジョニング：カレンダーを「レシピ」で固定する
いくらデジタル環境が整っていても、デスクの上が散らかっていたり、カレンダーが他人の予定で埋め尽くされていたら、脳のCPUは別のプロセスに持っていかれてしまいます。
1. 物理空間のプロビジョニング
僕は、自宅でもオフィスでも**「開発インターフェース」**を常に一定に保っています。
- デバイスの固定化: キーボード、マウス、トラックパッド。これらは全く同じモデルを2セット用意して、自宅とオフィスに配置しています。
- 視覚ノイズの排除: デスクの上にあるのは、PC、モニター、そして一杯のコーヒーだけ。視覚に入る「片付けるべきもの」は、メモリを浪費するノイズだからです。
2. カレンダーを「レシピ」でブロックする
もっと強力なのが、時間のIaC化、つまり**「カレンダー・ロッキング」**です。僕は自分の1週間を、あらかじめ決まった「レシピ」に従ってプロビジョニングしています。
| スロット名 | 時間帯 | 内容 |
| Deep Work Block | 9:00 – 12:00 | 誰にも邪魔されない聖域。複雑なロジックの実装。 |
| Admin/Meeting Slot | 14:00 – 16:00 | 英語での議論、事務的な返信。 |
| Deployment Preparation | 17:00 – 17:30 | 翌日の「最初のタスク」を決め、ファイルを開いたままにする。 |
Google スプレッドシートにエクスポート
このレシピを守ることで、朝起きて「今日、何からしよう？」と悩むコストがゼロになります。
再現性のある自分が最強。メンタルオーバーヘッドを削ぎ落とした先にある景色
人生をIaC化して数年。ロンドンの移り気な天気や、突発的な仕様変更、そして英語でのタフな交渉……。そんな「予測不能な外部要因」に囲まれながらも、僕は以前よりずっと穏やかで、クリエイティブな状態でコードを書き続けられています。
低レベルな決断を抽象化する
僕らがC#でインターフェース（Interface）を定義するのは、具体的な実装の詳細を気にせずに、より高いレベルのロジックに集中したいからです。
「朝何を食べるか」「どのツールでバグを追うか」といった**低レベルな決断（実装の詳細）**をルーチンというインターフェースに閉じ込める。すると、脳に残るのは広大な「空きメモリ」です。そのメモリを使い、海外のチームメイトと「そもそもこの機能はユーザーにとって価値があるのか？」という本質的な議論を戦わせる。これこそが、僕らエンジニアが本当に情熱を傾けるべき仕事です。
今日からデプロイできる「最初の一行」
IaC化なんて、何から手をつければいいか分からない……という方に。今日からできる最初のアクションは、**「明日、デスクに座って最初に行う『3つの操作』を、今すぐメモすること」**です。
- メールではなく、今日書きかけのコードを開く。
- お気に入りの音楽を再生する。
- タイマーを25分セットする。
何でもいいです。明日の朝、そのメモを見た瞬間に、脳が「あ、今はセットアップの時間だね」と理解し、迷わず実行できる状態にする。これだけで、あなたの人生の「構成ファイル」は書き始められたことになります。
📚 おすすめのリソース
- 『Atomic Habits』 (James Clear 著): 習慣を「システム」として設計するためのバイブル。
- 『Deep Work』 (カル・ニューポート 著): 集中力を確保し、高価値なアウトプットを出すための戦略。
- Architecture Decision Records (ADR): 決断をコードのように保存する技術。
最後に。海外で働くということは、不確実性の海に身を投じるということです。だからこそ、せめて「自分の管理下にある環境」だけは、徹底的に予測可能にしておいてほしい。
メンタルオーバーヘッドを削ぎ落とした先には、技術への純粋な好奇心と、異国での生活を心から楽しめる余裕が待っています。Happy Deployment and Happy Life!
コメント