― 期待とワクワク、そして最初の壁 ―
正直に言って、最初に「海外でITエンジニアとして働こう！」って決めたとき、設計手法でこんなに苦労するなんて思ってなかったんですよ。特に、C# WPFの設計開発に関しては、日本でそれなりに経験積んできたし、自分なりに自信もあったんです。MVVM？もう何度もやってきた。Dependency Injection？AutofacもUnityも触ってきた。だから、「まぁ、言語が同じなら何とかなるでしょ！」くらいに軽く考えてました。
最初の海外案件が決まったときは、本当に嬉しかった。アメリカの某ソフトウェア企業でのプロジェクト。WPFアプリケーションのリプレイス案件で、アーキテクチャ設計から関わるポジション。「これぞキャリアのステップアップだ！」なんて、一人で勝手に盛り上がってました。
でも、最初のキックオフミーティングで早速現実を突きつけられることに…。
プロジェクト開始から、英語で飛び交う「Design Pattern」「Architecture Decision Record（ADR）」「Scalability」「Testability」…日本でよく耳にしてた単語なのに、ニュアンスがまるで違う。さらに追い打ちをかけたのが、「Domain-Driven Design（DDD）で進めます」というPMの一言。
…え？DDD？えっと、エリック・エヴァンスの青本、昔ちょっと読んだけど…。でも正直、日本の案件ではそんなに深く使ったことない…。
しかも次の瞬間、アーキテクトから飛んできたのが「So, Hiro, how do you propose to structure the domain layer?」という質問。
……いや待って、それって今この場で答えないとダメなやつ？（笑）
この瞬間、めちゃくちゃ焦ったんです。わかってる風を装いながら、「Let me draft some ideas and get back to you.」なんて答えたけど、内心はパニック。家に帰ってから即、YouTubeで「DDD beginner」「Domain Layer example」「WPF Clean Architecture」あたりの動画を鬼のように漁りました。
このとき痛感しましたね。「あ、自分、設計手法の“表面”しか理解してなかったんだ」って。
日本では、ドキュメント文化とかウォーターフォール式で流れ作業的に設計を進める案件が多くて、深い設計議論に参加する機会が少なかった。正直、MVVMでViewModel分けときゃいいでしょ？くらいに思ってた部分もあった。でも、海外の現場は違った。設計に対する議論の深さ、事前の設計レビューの回数、チーム全員が設計思想にガッツリ関わるカルチャー…。まるで「設計そのもの」がプロジェクトの命綱みたいな扱いでした。
そのギャップに、自分の中で「やばい、設計知識が全然足りない…！」という焦りが一気に膨れ上がっていきました。
― 焦りと学びの日々、海外流設計思想への適応 ―
正直、このままじゃマズい、って本気で思ったんです。
「海外エンジニアデビュー戦でいきなり設計力不足がバレる」なんて、絶対に避けたかった。
家に帰ると、毎日YouTubeで「Domain-Driven Design」「Clean Architecture」「SOLID Principles」「CQRS」「Event Sourcing」とかの動画を片っ端から見まくりました。英語で聞くとまた難易度が上がるんですけど、そこは気合で乗り切るしかない。
でも、ただ動画見るだけじゃダメだってすぐに気づいた。なぜなら、次の設計レビューでまた撃沈したから（笑）。
◆ 初めての海外設計レビューでの赤っ恥
2週間後、ようやく作った「初版アーキテクチャドキュメント」を持って、設計レビューに挑みました。
内容は以下のような、まあ“よくある日本式”な資料。
- システム構成図（ざっくり）
- 各レイヤーの役割説明
- データフロー図（これもざっくり）
- あとはとりあえずMVVM使ってますよ感を出すスライド（笑）
これで何とかなるだろう…と思ってたら、会議が始まって3分で雲行きが怪しくなりました。
アーキテクト：「This looks like a layered architecture… but where’s your domain model?」
プロダクトオーナー：「Also, can you walk us through your decision process for selecting this approach? Did you consider scalability and testability trade-offs?」
同僚エンジニア：「And how will you handle cross-cutting concerns like logging, exception handling, and transaction management?」
……え、そこまで深く聞く？
正直、国内案件なら「とりあえず動けばいいでしょ」的な空気感でスルーされてた部分。
自分：「Umm… Good questions… Let me revisit and update the design accordingly.」
その場は笑って流してくれたけど、内心はもうズタボロ。
◆ なぜ彼らはそこまで設計にうるさいのか？
その日の夜、猛烈に悔しかったので、海外エンジニア向けの設計文化について調べまくりました。
その中で気づいたのが、「設計＝ビジネス価値への直結」という感覚の違い。
日本だと「納期優先」「動けばOK」「詳細設計書は後追いで作る」みたいな案件も多かったけど、
海外は「最初の設計ミスが後工程で何倍ものコストに跳ね返る」という思想がめちゃくちゃ根付いてる。
特にアメリカは「TDD文化」「Clean Code信仰」「レビュー文化」「設計ドキュメント至上主義」が当たり前。
プロジェクト開始時点で「システム全体の変更耐性」や「スケーラビリティ」「保守性」についてガチで議論する。
具体的に痛感したのは以下の3つ：
- 「理由なき設計はNG」
→ なぜその設計にしたのか？ なぜそのパターンを選んだのか？ 「理由と言語化」が求められる。 - 「変更に強いか？」
→ 将来的に仕様変更が入っても壊れない構造かどうかを最初から問われる。 - 「ドメイン知識の理解が前提」
→ ビジネスロジック層は、単なる「機能の集まり」じゃなくて、「業務ルールの表現」であるべき。
これまで「Controller → Service → Repositoryで流せばとりあえずOK」みたいな感覚でやってきた自分にとって、まさに文化衝撃。
◆ 設計勉強のやり直し開始
そこからは、毎晩のように設計本を読み漁りました。英語で書かれた技術書にも本気で手を出しました。
特に役立ったのはこのあたり：
- 「Domain-Driven Design Distilled」（Vaughn Vernon 著）
→ DDDのエッセンスが短くまとめられていて、非ネイティブでも読みやすい。 - 「Clean Architecture」（Robert C. Martin 著）
→ レイヤー分離の意義とか、設計原則について実例豊富。 - YouTube チャンネル：IAmTimCorey、Nick Chapsas
→ C#寄りの設計解説が多くてわかりやすい。 - Pluralsightの「Architecting Applications for the Real World」シリーズ
→ 有料だけど、実際の設計プロセスが動画で見れて超参考になった。
特に意識したのは、「ドキュメントとしてどう説明するか？」という視点。
設計思想を英語で伝えるって、ただ技術用語を並べるだけじゃダメなんです。論理展開、背景説明、課題と解決策の対比…これができないと、また次のレビューで刺される（笑）。
◆ 少しずつ変わり始めた「設計への向き合い方」
ある日、ふと気づいたんです。「あ、最近、設計の勉強が楽しいかも」って。
もともと、プログラミングそのものは好きだったし、論理的に物事を整理するのも嫌いじゃなかった。でも、日本で働いてたときは「仕様が変わるたびに作り直し」「レビューは形だけ」「そもそも詳細設計書って後追いで書くもの」…そんな環境だったから、設計について深く考えること自体がほとんどなかった。
でも海外現場では違う。「設計＝チームの未来を守る盾」みたいな存在感がある。
この頃から、次第に「自分もその盾を作れるエンジニアになりたい」って思い始めてました。
もちろん、まだこの時点では失敗も多かったし、次の「転」パートでまた心が折れる事件が起きるんですけど（笑）、少なくともここで自分の中に「設計に本気で向き合うスイッチ」が入ったのは間違いありません。
― 設計レビュー地獄とメンタル崩壊寸前 ―
「よし、今度こそ大丈夫だ！」
夜遅くまで残業して、休日も潰して、死ぬ気で作り直したアーキテクチャドキュメント。
今度はちゃんとドメインモデル図も作ったし、各レイヤーの役割も明確に記述したし、依存関係の流れも説明できるようにした。クラス図もシーケンス図も、英語での注釈付きで用意した。
さらに、前回のレビューで出た「理由を言語化しろ」という指摘を反映して、「なぜこの設計パターンを選んだのか」「どんなトレードオフがあるのか」についても資料に盛り込んだ。
これでさすがにいけるでしょ…！
そう信じて挑んだ、2回目の設計レビュー。
◆ 絶望のフィードバックタイム
レビュー開始から最初の15分は、いい感じだった。
アーキテクトやPMが「Hmm… Looks better than last time.」とか「You’ve clearly put in the work.」とか、ちょっと褒めてくれる空気もあった。
…が、そこから地獄が始まった。
アーキテクト：「Okay, let’s deep dive into your domain model. Can you explain the aggregate boundaries and invariants here?」
プロダクトオーナー：「Also, how are you planning to ensure eventual consistency between these services?」
シニアエンジニア：「I noticed your repository layer still has some business logic leaking into it. Can you explain why?」
テックリード：「And what’s your strategy for unit testing this service layer given the current dependencies?」
さらに追い打ちで、QAチームの人からはこんな一言。
QA：「From a testability perspective, this tight coupling is going to make mocking difficult. Any plan for abstraction?」
……もう完全にフリーズですよ、自分。
英語力の問題じゃなくて、そもそも「そんな深いところまで考えてない！」っていう設計レベルの問題。
しかも、一度答えに詰まると、次から次へと「ここも突っ込まれる」「あそこも矛盾してる」「この設計、保守性ゼロだろ」みたいな指摘が飛んでくる。
気づいたときには、Zoom越しに冷や汗ダラダラ。顔が真っ赤になってるのが自分でもわかる。
◆ レビュー後、マジで落ち込んだ夜
レビューが終わった瞬間、ノートPCの前で30分くらい呆然としてました。
Slackを開けば、レビュー参加者から「Thanks for the effort! Let’s iterate.」みたいな優しいコメントが並んでるけど、全然心に入ってこない。
「俺、やっぱり海外で通用しないのかな…」
「このままじゃ、契約切られるかもしれない…」
「何のために日本で10年以上エンジニアやってきたんだろう…」
自己否定の嵐。
正直、転職して海外案件に飛び込んだこと自体を後悔しかけてました。
「日本で安定して働いてたほうがよかったんじゃないか」って、本気で考えた。
夜、ベッドの中でスマホ見ながら「海外エンジニア 挫折」「ITエンジニア 海外設計 レベル差」とかで検索しまくってました（笑）。
YouTubeで海外エンジニアの失敗談とか、転職失敗した人の動画を無限に再生して、「ほら、やっぱり自分だけじゃない」って慰めようとしてた。
◆ それでも逃げなかった理由
でも、次の日の朝。
SlackにアーキテクトからDMが来てました。
アーキテクト：「Hey Hiro, I know yesterday was tough. But trust me, we’ve all been there. You’re making progress. Let me know if you want to pair up on the next design iteration.」
…これ、めちゃくちゃ救われました。
「ああ、みんな最初はここでつまずくんだ」「ここで折れるか、食らいつくかが分かれ道なんだ」って、少しだけ思えたんです。
それからは、「もう失敗してもいいから、できること全部やってみよう！」という開き直りモードに入った。
- 早朝からドキュメントを書き直し
- お昼休みにUdemyの「Software Architecture」講座を受講
- 夜はYouTubeで「Design Patterns in C#」をひたすら視聴
- 休日はGitHubで海外のオープンソースプロジェクトのソースを読んで、実際のアーキテクチャ構造を研究
さらに、レビューで出された指摘項目を全部リストアップして、Notionで「設計改善タスクリスト」まで作った（笑）。
◆ 英語＋設計＝ダブルパンチの壁
この時期、特にキツかったのは「英語での設計説明」。
日本語なら「凝集度が低い」「責務が曖昧」「依存関係逆転させた方がいい」とかパッと説明できるけど、英語で言おうとするともう大混乱。
例：
- 「凝集度が低い」→ 「The cohesion of this module is low, which may lead to maintenance issues…」
- 「責務が曖昧」→ 「The responsibility of this class seems ambiguous, making it hard to understand its purpose.」
- 「依存関係逆転」→ 「We might need to apply Dependency Inversion Principle here to reduce coupling.」
単語レベルで詰まるし、文法ミスるし、何より早口のネイティブがかぶせてくると聞き取れない（笑）。
でもここで救いだったのが、同僚がすごく丁寧にフィードバックをくれたこと。
Slackでのやりとりは全部ログに残るから、あとで読み返して復習もできた。
分からない単語はその場でメモして、次の日に英語辞書アプリで調べまくった。
設計スキルと英語力、両方一気に鍛えられるこの状況…。
めちゃくちゃキツいけど、ある意味で今までで一番「エンジニアとして成長できる瞬間」だったのかもしれない。
― 挫折を乗り越えて、ようやく掴んだ「設計の自信」 ―
あの設計レビュー地獄から数週間。
メンタルも一時期はどん底だったけど、それでも自分は逃げなかった。
毎日「小さな改善」「小さな成功」を積み上げていくことに集中しました。
「今日はユニットテスト用の設計改善ができた」とか、「今日は初めて自分から設計提案できた」とか、ほんの少しの進歩でも自分で自分を褒めるようにしました。
◆ 「設計メンター制度」の存在が救いだった
そんな中、アーキテクトが「Hiro、もしよかったら次の1ヶ月、週1で1on1設計レビューやらないか？」って声かけてくれたんです。
これ、海外エンジニア文化の素晴らしいところの一つだと思うんですが、「成長する人には投資する」っていう空気がめちゃくちゃあるんですよね。
日本だと「自己学習はプライベートで勝手にやって」「先輩に聞くのは迷惑かも」って思いがちだったけど、こっちでは「分からないなら早く聞け」「改善したいならどんどん聞け」っていう文化。
その1on1では、こんなことを学びました：
- 「設計は常にトレードオフ」
→ 完璧な設計はない。どこを優先して、どこを割り切るか。それを言語化することが大事。 - 「アーキテクトは説明責任を持つ仕事」
→ 誰が見ても「なぜその設計にしたのか」がわかる状態にすること。それがプロの設計。 - 「早めにフィードバックをもらえ」
→ 「これで完璧！」と思ってからレビューに出すより、「7割できた段階」でフィードバックをもらって修正するほうが圧倒的に効率がいい。
この「早めに相談、早めに修正」のサイクルに切り替えてから、レビューでの指摘もどんどん減っていきました。
◆ 初めての「Good Design」評価！
ついにその日がやってきました。
次の設計レビュー。例のアーキテクトが、自分の作った資料を一通り見た後、こう言ったんです。
アーキテクト：「This is a solid design, Hiro. You’ve addressed the major concerns from last time. I can see real improvement. Good job!」
…ヤバい、本当に嬉しかった。
心の中でガッツポーズしてました（笑）。
他のチームメンバーからも、
- 「The dependency inversion here is well thought out.」
- 「The domain model is clean and easy to understand.」
- 「This should scale well with future requirements.」
…みたいなコメントが次々と。
これまで「設計レビュー＝ダメ出し地獄」だった自分が、初めて「設計レビュー＝成果を認めてもらえる場」になった瞬間でした。
◆ 自分なりの「海外設計攻略法」
この経験を通じて、自分の中で一つの答えができました。
それは、**「設計力は技術力だけじゃなく、説明力・英語力・ビジネス理解力の総合戦」**ってこと。
以下、当時の自分に言いたいアドバイス（笑）：
- 「とにかく早くアウトプットを出せ」
→ 100点の設計より、まずは60点でいいから出して、フィードバックを浴びまくる方が成長が早い。 - 「英語での設計説明は事前にテンプレを作れ」
→ 毎回ゼロから説明するとパニックになる。自分用の英語フレーズ集をNotionにまとめてた。例：- 「The main reason I chose this architecture is…」
- 「One trade-off with this approach is…」
- 「We can mitigate this risk by…」
- 「設計の背景には必ずビジネス理由があると意識する」
→ 「なんとなくこうした」ではなく、「この設計はビジネス要件Aと技術制約Bを両立するため」と言える状態にする。 - 「海外の設計書を真似しろ」
→ GitHubの有名プロジェクト、Microsoftのサンプル、DDDのOSS…全部教材。
◆ 「設計が好きになった」って素直に言える今
こうして、最初は苦手意識しかなかった「設計」という仕事が、今ではむしろ「自分の得意領域」になりつつあります。
もちろん、まだ海外の超ベテランたちには全然敵わないけど、それでも「この案件、Hiroに設計お願いしよう」って言ってもらえることが増えてきました。
あのとき、逃げなくて本当によかった。
今振り返ると、あの最初の地獄レビューも、自分を鍛えるための必要なプロセスだったんだなって思えます。
◆ 最後に：これから海外エンジニアを目指す人へ
もしこのブログを読んでる人で、「海外案件で設計レビューが怖い」「自分の設計スキルに自信がない」って思ってる人がいたら、ひとつだけ伝えたいです。
「大丈夫、最初はみんなつまづくから。でも、そこから逃げずに一歩ずつやれば、必ず乗り越えられる」
そして何より、失敗は恥じゃない。
「その失敗から何を学ぶか」「どう次に活かすか」…それこそが、グローバルエンジニアに必要な本当のスキルだと思います。
コメント