きっかけと問題意識
C#の仕事をしてると、「まあ、なんとかなるでしょ」って思ってませんか？
僕もそうでした。WPFでがっつりUI設計して、業務アプリを作り込んで、ちょっとしたパフォーマンスチューニングもお手の物。「C#には困ってないし、アメリカ行ってもそのまま通用するでしょ」――そう信じていた自分が、まさか“C#だけじゃ話にならない”瞬間に出くわすとは思ってもいませんでした。
■ 渡米直後にぶち当たった“違和感”
アメリカに来て最初の仕事。某中規模SaaS企業で、金融向けダッシュボードアプリのリファクタリングプロジェクトに入ったんですよ。
「WPF経験もあるし、WinFormsのレガシーコードも読める。これならいける」って思ったんですが……プロジェクトの話についていけない。
理由は明確でした。
**「このコード、全部マイクロサービスで再構築するんだよ」**って一言で、世界が変わったんです。
■ モノリス思考が染みついたC#エンジニアの悲劇
日本ではまだまだ**“一枚岩”のモノリシックなアプリ構成**が主流の会社、多いですよね？
プレゼンテーション層もビジネスロジック層もデータアクセス層も、すべて1つのアセンブリにまとまってて、クラス間の依存も強め。でもそれって、「ちゃんとした設計してる」っていう感覚がある。
だけど、アメリカの現場では違いました。
サービスは全部分解されて、API単位でスケール可能な構成。
コードレビューでは「この処理はなぜ1つのサービスでやってるの？分離できるよね？」なんて普通に言われます。
僕のWPFで培った「UIとロジックをどう分離するか」的な議論とは、まったく次元が違いました。
■ 会議の言葉がわからない、ではなく“文脈”がわからない
例えば、会議で「Let’s decouple this logic to a worker service and hook it with Azure Event Grid」なんて話が出てくる。
「え、Worker Serviceって何？Event Gridってイベントログビューアの話じゃないの？」
完全に置いてけぼりです。
.NETの知識はあるのに、クラウド前提・スケーラビリティ前提の思考が全然足りてなかった。
「C#でコードが書けること」と「マイクロサービス時代に設計できること」は、まったく別のスキルセットだったんです。
■ C#のままでは“専門性”が足りない？
衝撃でした。
「え？でもC#って.NET Coreになって、Linuxでも動くし、Docker対応してるし、むしろ最強じゃないの？」って思ってた。
でも現場の人たちはこう言います。
“Yeah, C# is fine. But do you understand distributed systems?”
そう、問題は**「言語」ではなく「設計スキル」**だったんです。
C#はツールに過ぎない。
マイクロサービス時代に必要なのは「どう分離し、どうつなぎ、どうモニタリングし、どうスケールさせるか」という**“考え方”のほう**だった。
マイクロサービス時代にC#エンジニアが取るべきアクション
あの“置いてけぼり会議”から、僕のエンジニア人生は静かに激変していきました。
「これじゃ通用しない」って思った瞬間から、C#の“コード職人”じゃなく、“設計できるエンジニア”に進化しなきゃって腹をくくったんです。
■ 「まずはAzure触っとけ」と言われた理由
上司（といってもすごくフランクなシニアエンジニア）に相談したら、
**「まずAzure触れ。特にFunctionsとApp ServiceとEvent Grid」**って即答されました。
なんでAzure？って思うかもしれません。AWSもGCPもあるのに。
でも**C#エンジニアにとってAzureは“伸びしろの宝庫”**だったんです。
- Visual Studioや.NETとの親和性が高い
- Azure Functionsで“イベント駆動型”の考え方が自然に身につく
- ドキュメントがC#前提で書かれていて読みやすい
WPFで慣れたVisual Studioの快適さを保ちつつ、クラウドネイティブなアプリを“遊び感覚”で構築できる。
まずはローカルでAzure Functionsを書いて、イベントトリガーでDBにデータ入れるだけの簡単なアプリを作ってみたら……もう目から鱗でした。
■ 使い慣れたC#で“分散アーキテクチャ”を学ぶ
次に試したのが、Microsoftが公開してる eShopOnContainers。
これは.NETで構築されたマイクロサービス・サンプルアプリで、
- 各サービスがgRPCやRabbitMQでつながってたり
- Identity Serviceが認証を受け持ってたり
- Dockerで全部立ち上がったり
とにかく「これが実務か！」っていうリアリティが満載でした。
重要だったのは、新しい言語を覚えなくても、既存のC#スキルの延長線で“マイクロサービス的思考”が学べること。
この体験を通じて、
- サービス間通信の責任範囲
- ステートレスとスケーラビリティの考え方
- ログとモニタリングの重要性
といった、今まで無意識に「自社のITインフラ任せ」にしていた部分を設計視点で理解するようになったんです。
■ C#エンジニアがDockerと仲良くなると世界が変わる
マイクロサービス＝Docker。これは避けられない。
最初は「仮想環境？それってHyper-Vじゃダメなの？」って戸惑ったけど、使ってみて驚きました。
Dockerfileに「dotnet publish」書くだけで、C#アプリがどこでも動く。
しかも、Visual Studio 2022以降はDocker連携も進んでて、ローカルデバッグもボタンひとつ。
WPFでローカルだけ完結してた頃とは全く違う、「どこでも、誰とでも動くアプリ」が作れるようになってきた実感がありました。
このときに学んだ技術：
- Docker & docker-compose
- ASP.NET Core Minimal API
- gRPC (高パフォーマンスなサービス間通信)
- Azure Container Registry & Azure App Service
特にMinimal APIはC#でも「必要な機能だけ書ける」って感覚があって、サービス分割には最適でした。
■ 「コードじゃなく、設計を語れ」が評価される現場
ある日、コードレビューでこう言われたんです。
“Your implementation is clean, but can you explain your boundary decision?”
え、**境界設計の意図まで問うの？**って最初は面食らいました。
でも、これがアメリカの現場で求められてる“設計スキル”の正体でした。
マイクロサービス時代の現場では、
- 「なぜこのサービスはここで責務を切ってるのか」
- 「このイベントはどのチームに通知すべきなのか」
- 「この処理を同期で行うと何がボトルネックになるか」
みたいな「コードの外側の設計判断」が日々問われる。
この思考に慣れてくると、「ただのC#コーダー」から「設計もできるC#エンジニア」に一歩踏み出した実感がありました。
■ 日本で培った“丁寧な実装力”が活きた瞬間
ちなみに、日本での経験が無駄になったかというと、全然そんなことはなかったです。
特に、
- UI設計で気を配るユーザー体験の視点
- WPFのMVVMパターンで鍛えた責務分離
- レビューで指摘されない“安定した実装”
これはアメリカでも評価されます。
「この人、なんでこんなにコード崩れないの？」って言われたとき、
「あ、それ日本の現場で叩き込まれました（笑）」って笑いながら答えたのを覚えてます。
ただ、その上で**「設計意図を言語化して共有できること」が新しい評価軸**だったんです。
コードじゃ足りない。チームで生き残るための“ふるまい”
スキルのキャッチアップがひと段落したある日、僕はふと気づいたんです。
「技術はある。でも、まだチームの“仲間”にはなれてないかもしれない」って。
■ アメリカ現場での“評価軸”は「空気を読むこと」じゃなかった
日本の開発現場では、相手の意図を察して、黙って対応して、
「気が利くな」と思われることで信頼を得てきました。
でも、アメリカは違う。
黙ってる＝関与してない、理解してないと思われる。
だから最初のうちは、
「おれ、空気読んで動いてるのに評価されない」
って、地味にへこんでました（笑）。
■ 設計レビューは“ディベート”の場
初めて設計レビューに出たとき、かなり衝撃を受けました。
全員が自分の意見をガンガン出してぶつけ合うんです。
- 「このサービスはこっちの責務じゃない？」
- 「そのAPI非同期にする意味ある？」
- 「Event GridよりService Busの方がよくない？」
僕は最初、その空気に圧倒されて黙ってました。
でもそのままだと、「この人は設計に興味ないんだ」って思われてしまう。
で、ある日思い切って、
「このユースケースって、ユーザー登録よりも支払い完了をトリガーにした方が自然じゃないですか？」
って意見を出したら、「いいね、それ、理由ある？」って、ちゃんと聞いてくれたんです。
技術的に完璧な意見じゃなくても、発言することで会話の一部になれる。
これが、僕にとっての最初の“文化突破”でした。
■ 「Yes」と言わない、でも「No」だけでもダメ
文化的なギャップでもうひとつ苦戦したのは、「断り方」。
日本では、「あ、それちょっと難しいですね…」って曖昧に断ることが多いですが、
アメリカでは、それだと「結局どうするの？」と逆に混乱を招く。
一方で、「No, that’s impossible」と即答すると、「ネガティブな人」と取られる。
ある先輩が教えてくれた“魔法のフレーズ”がこちら。
“I see your point. One thing I’m concerned about is…”
これを使えば、
- 相手の意見を否定せずに、
- 自分の技術的な懸念を丁寧に伝えられる。
つまり、「反対する」のではなく「一緒に考える」スタンス。
この言い回しを覚えてから、設計レビューや朝会でも、意見が通りやすくなった気がします。
■ Slackは“コード以外の人格”を伝える場所だった
意外なところでも信頼構築のカギがありました。
それが、Slackなどのチームチャット。
日本の感覚だと、業務外のことをSlackで書くのって「サボってる感」があるけど、
アメリカではむしろ**“雑談こそがチームビルディング”**。
ある日、チームの誰かが「My dog turned 3 today!」って写真貼ってたから、
「So cute! Happy birthday to your dog!」って返したら、
その日の夕方には「Hey, Hiro, wanna join us for lunch Friday?」って誘われてました（笑）。
Slackの雑談で“人間味”を見せることが、チームに溶け込むためのファストパスだったんです。
■ “できるやつ”じゃなくて“信頼されるやつ”を目指す
時間が経つにつれて、僕のコードレビューにコメントが少なくなっていきました。
最初は「見てもらえてないのか？」って不安だったけど、違いました。
ある同僚がこう言ってくれたんです。
“I trust your judgment, Hiro. You always think through your boundaries.”
つまり、「あいつの設計は安心できる」って思ってもらえていたんです。
それって、C#の知識やクラウドの知識を超えて、
設計の意図を伝え、会話をし、信頼を積み重ねることで得られたものだった。
■ 日本人エンジニアとしての強みを“翻訳”する
僕たちが日本で身につけてきたものって、
実はすごく海外でも通用する。でも、伝え方を変えなきゃ伝わらない。
- 丁寧な設計 → 「Why this approach?」にちゃんと答える
- テストの網羅性 → 「How did you ensure coverage?」で具体的に説明する
- 段取り力 → JiraやNotionで可視化して伝える
つまり、スキルを“ローカル言語”から“グローバル言語”に翻訳していく作業が必要だったんです。
C#は道具、あなた自身が価値になる時代へ
アメリカで働き始めてから1年半。
気づけば、週次の設計レビューで**“ファシリテーター役”を任されるまでになっていました。**
C#のコードが書けるだけだった僕が、
クラウドアーキテクチャを語り、設計会議をリードし、
チームの中核として**「意思決定の一員」になった。**
そしてこの経験が、僕自身の「キャリア観」を大きく塗り替えてくれたんです。
■ 「テクノロジー」よりも「視座」のほうが価値になる時代
最初は、C#だけで何とかしようとしてました。
でも現場に入って分かったのは、“言語”よりも“構造”を考える力が重要だということ。
たとえば、こんな質問がよく飛んできます：
- 「このアーキテクチャ、スケールに耐えられる？」
- 「このサービス、他のチームに再利用される想定ある？」
- 「障害が起きたとき、どこをログで追える？」
これって、C#でどう書くかというより、どう設計するか・どう守るかの話ですよね。
そう、求められているのは「道具の使い方」じゃなく、
“構造と価値”を考えられる人間なんです。
■ 海外で得た“武器”は、C#の枠を超えて使える
今、僕が次に取り組んでいるのは、BtoB向けのSaaS製品の設計リード。
C#は変わらず使ってるけど、それは「中心」じゃなく「選択肢の1つ」になりました。
- バックエンドは .NET 8 + gRPC
- 一部サービスは Node.js（API Gateway用）
- インフラは Azure Kubernetes Service（AKS）
- 分析は Pythonでバッチ処理
昔の僕だったら、「他言語ムリ！」ってなってたかもしれないけど、
今は「問題に対してベストな解決策を構成できるか」が軸になってる。
それは、C#を軸にクラウドや分散設計を学び、
チームと対話しながら意思決定を積み重ねた日々があったからこそ、できるようになったことなんです。
■ 僕のキャリアは、“グローバル対応済みC#エンジン”で走っている
僕が海外での経験を通じて再定義した自分の価値、それは：
「C#で描ける設計図を、グローバル基準で翻訳し、提案できる人」
たとえば、こんな場面でそれを実感します：
- オフショアチームとのやりとりで、英語で設計意図を共有
- 非C#エンジニアにも分かる形でサービス構成を説明
- ビジネス側の人に「この設計がどうビジネス価値に貢献するか」を言語化
つまり、「C#で動くモノを作れる」だけじゃなく、
**「チームを動かせるエンジニア」**に成長できた、ということなんです。
■ これから海外を目指すC#エンジニアに伝えたいこと
もし、この記事を読んでいるあなたが、
- C#しか使ったことがない
- 英語は得意じゃない
- モノリスでの開発が中心
- クラウドもDockerも触ったことない
そんな状況だったとしても、大丈夫です。僕もまったく同じスタートでした。
大切なのは「スキルセット」じゃなく、「マインドセット」。
つまり、
- わからないことを素直に認めて、
- 小さく手を動かして、
- チームと会話して、
- 成長の余地を楽しめること。
そして、“技術者”から“設計者”へ、さらに“価値提案者”へと進化する勇気です。
■ 最後に：C#の未来は、あなたの使い方次第
モノリシックなアプリケーションが悪いわけじゃない。
WPFでUIを美しく作るのも素晴らしい。
でも、もし「このままでいいのかな」と思っているなら――
C#を“書く”だけでなく、“語れる”ようになってみてください。
クラウドに載せて、イベントドリブンにして、サービス単位で語れるようになったとき、
あなたのC#スキルは世界で通用する「武器」になります。
そしてその武器は、**誰かに雇われるためのものではなく、
“チームに価値を提供するための道具”**になるはずです。
そのとき、あなた自身が**モノリス（ひとりの職人）から、マイクロサービス（価値の集まり）**へと進化しているはずです。
コメント