海外でC# / WPFエンジニアとして設計開発に携わっている「僕」です。こちらでの生活も長くなってきましたが、日々コードと格闘しながら、日本との文化や考え方の違いに驚かされることも多いです。
今回は、僕が海外の現場で叩き込まれた「生き残るためのエンジニアリング」について、実体験を交えてお話ししようと思います。特に、これから海外に飛び出したい、あるいは外資系などで働き始めたばかりのエンジニアの方に、ぜひ届けたい内容です。
1. なぜ「守りの設計」が攻めのキャリアを作るのか？
「昨日の夜、ぐっすり眠れた？」
月曜日の朝、オフィスでコーヒーを片手に同僚と交わす挨拶は、これです。日本にいた頃は「お疲れ様です」がデフォルトでしたが、こっちでは「ちゃんと休めたか」「プライベートを侵害されなかったか」が、エンジニアとしてのパフォーマンスを測る重要なバロメーターになっています。
なぜこんな話から始めたかというと、僕が海外に移住して最初に食らった洗礼が、技術的なスキル云々よりも、この「システムに対する根本的な信頼感のなさ」だったからです。
壊れないものを作るのは「傲慢」である
僕が今働いているチームのリードアーキテクト（絵に描いたようなギークなドイツ人です）に、最初のプロジェクトでこっぴどく言われた言葉があります。
「君のコードは、世界が平和であることを前提にしているね。それはエンジニアとしての『傲慢』だよ」
当時の僕は、C#とWPFを使って、かなり複雑な業務用のダッシュボードを開発していました。MVVMパターンをきれいに適用し、DI（依存性の注入）を駆使し、非同期処理（async/await）も完璧に制御しているつもりでした。でも、彼に言わせれば、それは「正常系という名のファンタジー」を実装しているに過ぎなかったんです。
予防的エンジニアリング（Preventative Engineering）の核
グローバルに展開するシステムを扱っていると、想像を絶するようなことが日常的に起きます。ネットワークの瞬断、想定外のロケール設定によるレイアウト崩壊、予告なきAPIのレスポンス変更。これらは「例外」ではなく「日常」です。
そこで僕が出会ったのが、**『The Preventative Engineering Playbook（予防的エンジニアリング・プレイブック）』**です。このプレイブックの核になるのは、以下の3本の柱です。
- Architecting for failure（失敗を前提とした設計）： エラーをシステムの一部として優雅にハンドリングする。
- Chaos engineering（カオスエンジニアリング）： あえて障害を引き起こし、システムの弱点をあぶり出す。
- Proactive threat modeling（プロアクティブな脅威モデリング）： 初期段階から攻撃を想定してセキュリティを組み込む。
2. WPF/C#での実践 —— 「優雅な失敗」を設計に組み込む
具体的な技術の話をしましょう。僕らC# / WPFエンジニアが、どうやって「失敗を前提とした設計」をコードに落とし込んでいくのか。
「信じない」ことから始めるデータバインディング
MVVMパターンにおいて、多くのエンジニアが「ViewModelにデータが届いた時点できれいな状態である」と過信しがちです。しかし、僕は以下の3段階のガードを必ず入れるようにしています。
- 型レベルのガード：
Nullable<T>を適切に使い、nullが来ても落ちないようにする。 - ビジネスロジックの検証：
INotifyDataErrorInfoを使い、UI側で「今、このデータは腐っていますよ」という状態をユーザーに優雅に伝える。 - デフォルト値の設計： データが壊れていても、アプリ全体をクラッシュさせるのではなく、「データ読み込み不可」というプレースホルダーを表示し、他の機能は維持する。
async/await は「諸刃の剣」
不適切な非同期処理は、デバッグが極めて困難なフリーズを引き起こします。海外のシニアエンジニアにレビューで口酸っぱく言われるのは、**「CancellationToken」と「タイムアウト」**の徹底です。
C#
// 予防的エンジニアリングの実装例
public async Task<Data> LoadDataAsync(CancellationToken ct)
{
try
{
// 30秒で潔く諦めるタイムアウト設計
return await _service.GetDataAsync(ct).WaitAsync(TimeSpan.FromSeconds(30));
}
catch (OperationCanceledException)
{
// ユーザーによるキャンセルやタイムアウトを「正常な失敗」として処理
return Data.Empty;
}
}
回復力（Resilience）を Polly に頼る
自前でリトライ処理を書くのはバグの温床です。C#エンジニアなら 「Polly」 というライブラリは避けて通れません。サーキットブレーカーやリトライポリシーを数行で定義でき、「週末に呼び出されない」ための強力な防壁となります。
3. 混沌を味方につける —— カオスエンジニアリングと脅威モデリング
「リリース前は絶対安静」ではなく、「リリース前に徹底的にいじめて、弱点を見つけておこうぜ」というのが海外流の攻めの姿勢です。
WPFアプリに「混沌」を注入する
僕のチームでは、定期的に「Game Day」を開催します。ネットワーク遅延シミュレーターでパケットロス率を30%に設定したり、メモリ使用量を意図的に跳ね上げたりして、WPFのレンダリングがどう挙動するかを見ます。
理論上の設計だけでは見えてこない「現実の泥臭い挙動」をあぶり出し、アプリを「図太く」育てていく。これが「想定外」を「想定内」に変える唯一の方法です。
「悪いやつ」の視点を初期段階で持つ
もう一つ徹底されているのが**脅威モデリング（Threat Modeling）**です。設計の最初の段階で、エンジニア全員で「どうやったらこのシステムを悪用できるか」というブレインストーミングをします。有名な「STRIDE」モデルなどを用い、脆弱性を「放置」ではなく、改善への「招待状」として捉え直します。
4. 技術より大事な「安眠」の話 —— プロの市場価値とは
これまで「守り」に心血を注ぐプレイブックを語ってきましたが、その本当の理由は極めて個人的なものです。それは、**「自分の人生の主導権を、システムに明け渡さないため」**です。
「プロの仕事」とは、何も起こさないことである
海外では「トラブル対応で夜遅くまで頑張ること」は、責任感の表れではなく「設計の欠陥」と見なされることがあります。優れたエンジニアほど、定時に帰り、夜は熟睡しています。
彼らが「安眠」できるのは、システムが「優雅に失敗する（Graceful Failure）」ことを知っているからです。予防的措置を息をするように設計に組み込むことは、自分の自由時間を守るための最強の防壁なんです。
最後に：これから海外を目指す君へ
もしあなたが今、「いつ壊れるか分からないシステムが怖い」と感じているなら、ぜひこのプレイブックを少しずつ取り入れてみてください。
- まずは、C#のコードに一つの
CancellationTokenを入れることから。 - ViewModelで「データが null だった時の表示」をデザインすることから。
- チームメンバーと「ここ、どうやったら壊せるかな？」と雑談することから。
その一歩一歩が、あなた自身のキャリアとプライベートを、確実に「レガシー」から「レジリエンス（回復力）」のあるものに変えていきます。
いつか、世界のどこかの現場で、あなたと一緒に仕事ができる日を楽しみにしています。その時は、お互いの「安眠の秘訣」について語り合いましょう。
参考文献・おすすめのリソース
- 『Clean Architecture』 (Robert C. Martin 著): 設計で「守り」を固めるためのバイブル。
- 『The Phoenix Project』 (Gene Kim 他 著): 予防がいかに組織を救うかを描いた名著。
- Polly (.NET resilience library): C#エンジニア必携のリトライ・サーキットブレーカーライブラリ。
- Microsoft Azure Well-Architected Framework: 「失敗を前提とした設計」のクラウド実践指針。
次に僕がお手伝いできること：
- 今回の記事全体（起承転結）を要約した「SNS投稿用のまとめ（XやLinkedIn向け）」を作成しましょうか？
- この記事にふさわしい「アイキャッチ画像の生成プロンプト」を作成しましょうか？
- 特定のセクション（例：WPFでのPollyの具体的なコード実装例）をさらに技術的に深掘りしますか？
コメント