海外開発のリアルと「スピードの壁」

― なんで俺だけ夜中にアラート飛んでくるの？から始まった物語 ―

海外でC#（WPF中心）エンジニアとして働く中で、一番衝撃だったのが 「スピードの基準が違う」 という現実でした。

日本の開発現場でももちろんスピードは求められますが、海外に出ると、それが “生活習慣レベル” で違うんです。

たとえば、僕が北米の開発チームに入って最初に言われたのは：

“Move fast. Break things. Fix fast.”
（早く動け。壊していい。すぐ直せ。）

この価値観、最初は正直めちゃくちゃ怖かったです（笑）。
壊していいって言われても、こっちは「え、壊したら怒られない？？」と不安になる。

でもさらに驚いたのは、スピードを求める割に、
「オペレーションは楽にして当たり前」
と、みんなが本気で考えていることでした。

---

■ 海外エンジニアの “夜中アラート文化” への反逆

あるとき、.NETのAPIを抱えるチームに一時的に合流し、夜中に何度かアラートが飛んできた時期がありました。
（時差の関係で日本時間の深夜＝アメリカの夕方、つまりちょうど負荷が高い時間帯）

毎回アラートに飛び起きて対応していると、翌朝、アメリカ側のリードにこう言われました。

“Why are you fixing it manually? Automate it, man.”
（なんで手で直してるの？オートメーションすれば？）

この衝撃。
「アラートが鳴った → エンジニアが起きて対応する」
という前提が、そもそも 文化として存在しない。

彼らはもっとドライで、

• スケール？自動化しよう
• 障害？自己修復すべき
• 人間が起きる必要？ないでしょ

という価値観が徹底していました。

---

■ そこで出会った “Serverless” という考え方

僕がそこで強烈に感じたのは、

「あ、これが海外で求められるエンジニアか」

ということ。

C#やWPFのようなデスクトップアプリ中心の開発がベースにあると、
どうしても “自前で構築する発想” が染みつきがちです。

でもクラウドネイティブな環境の海外では、

• “できるだけ作らない”
• “任せるところはクラウドに任せる”
• “アプリはビジネス価値に集中する”

という文化がかなり強い。

その象徴が Serverless。

海外のチームメイトがよく言うのは、

“We don’t deploy servers. We deploy features.”
（サーバーをデプロイしてるんじゃない、機能をデプロイしてるんだ。）

サーバー管理に時間を取られたくない、
運用で心を削られたくない、
深夜に呼び出されたくない、
だからServerless。

めちゃくちゃ合理的。

---

■ Serverless が「開発スピード」を必然的に生み出す理由

Serverlessはただの技術トレンドじゃなくて、海外の開発文化の一部になっています。

理由はいくつかあって、特に大きいのが３つ。

① 自動スケーリングと自己修復で “人間レスキュー” を無くす

サーバーの負荷でアラートが鳴る？
そんなのServerlessが勝手にスケールすればいい。

CPUスパイクで落ちる？
何台か落ちても勝手に新しいインスタンスが立ち上がる。
エンジニアは寝ていてOK。

海外だとこれは「普通」です。

② マイクロサービスとの相性が爆発的に良い

Serverless（FaaS）は “必要な分だけ動く小さなサービス” という性質を持つので、
マイクロサービスの設計思想に驚くほどフィットします。

• 小さく作る
• 独立してデプロイ
• 影響範囲が小さい
• すぐ直せる

結果、スピードがそのまま品質になる。

③ デプロイが軽い → 改修が早い → 心理的にも楽

Serverlessはデプロイがとにかく軽いです。
小さな関数を差し替えるだけのことが多いので、

• スピードが早い
• 恐怖が少ない
• どんどん改善する

海外のエンジニアが “Continuous Delivery は当たり前” と言う理由はここ。

---

■ 僕が学んだ「海外で生き抜くための開発哲学」

海外の現場で Serverless を通じて強烈に学んだことはひとつ。

“運用に時間を使うな。イノベーションに時間を使え。”

ということ。

日本だと「安定運用を保つ」ことが強めに求められがちですが、
海外では “運用は自動化して、価値を作る方に注力する” が鉄則。

Serverless は、その生き方を後押ししてくれる最強のツールでした。

---

■ これから海外に出るエンジニアへ伝えたいこと

C#やWPFを中心にやっていた僕でも、
Serverless やクラウドの文化に触れたことで、人生レベルで視野が変わりました。

• なぜ海外はこんなにスピードが早いのか
• なぜ夜中に呼び出しが少ないのか
• なぜ改善のサイクルが速いのか

その答えの大部分が Serverless 的な価値観 にありました。

テクノロジーの話でもありますが、
実は “働き方の話” でもあるんですよね。

Serverless が海外現場で広がっていった理由

― 「もうサーバー触りたくないんだよね」から始まる海外式開発文化 ―

海外でエンジニアとして働いていると、ある時期から明らかにチームの口癖が変わっていきました。

“Do we really need a server for that?”
（それ、本当にサーバーいる？）

最初は冗談だと思っていたのですが、どうやら本気らしい。
アメリカのクラウドカルチャーは極端で、

• できる限りサーバーを持たない
• 設定ファイルすら触りたくない
• OSのパッチ対応はもう絶対やらない

という思想が浸透していました。

C#（特にWPF）バックグラウンドから来た僕にとって、この文化は完全に衝撃でした。

WPFアプリを作るときなんて、
「設定ファイル？自分で管理するのが当たり前」
「サーバー性能？負荷を見てスケール決めるのが普通」
という世界だったので、価値観が180度違っていました。

---

■ Serverless が海外で急速に支持された3つの “現場リアル”

海外の現場では、Serverless はただの技術トレンドではなく、
“現場の課題に真っ直ぐ応える道具” として広がっていきました。

以下、僕が実際に体験しながら強く感じた３つの理由です。

---

① 人手不足の海外現場では、運用に人を割けない

海外の開発現場では、日本よりもエンジニアの流動性が高く、
「いますぐ人が欲しいのに全然見つからない」
という状況が普通に起きます。

その結果何が起こるかというと――

“運用に人を割く余裕がない”

夜中にインフラ担当を呼ぶ？
誰が？担当いないよ？ みたいな状況も多い。

そのため、海外のチームでは、

• スケールは自動
• 障害復旧も自動
• ログ収集も自動
• 更新も自動

という世界が”前提“として進んでいきました。

特にAWS Lambda や Azure Functions のような
「イベント駆動 × 自動スケーリング」
の仕組みは、この現場のニーズに完璧にフィットしたのです。

---

② マイクロサービスとの相性が良く、チームの“独立性”が保てる

海外のチームは、とにかく “担当範囲を狭くする” 文化があります。

要するに、

• 他チームに依存したくない
• 自分たちのリリースに外部要因を持ち込みたくない
• 必要な機能は自分たちだけで完結させたい

という思想です。

そこで Serverless は相性抜群でした。

関数単位で API を作れるので、
部署ごとに小さな機能を独立して持つことができます。

僕が関わっていたプロジェクトでも、

• 決済だけ Lambda
• 通知は別チームが Functions
• 画像処理は Cloud Run
• ログ収集は別の小チームが構築

というように、完全分離していました。

その結果、

• 他チームのデプロイ待ちがゼロ
• 依存関係の調整も最小限
• トラブル時の影響範囲が局所的

という “海外らしいスピード設計” が成立していました。

---

③ デプロイが早すぎて、改善スピードが上がる

Serverlessのデプロイはめちゃくちゃ速いです。

これが海外の開発文化と相性が良すぎる。

特に印象的だったのが、
アメリカ人の同僚が言ったこの一言。

“Just ship it.”（まず出せ）
“If it breaks, fix in 5 min.”（壊れたら5分で直せばいい）

Serverless だと本当に5分で直せてしまう。
これは “技術が文化を支えている” 好例でした。

小さなFunctionだからすぐ直せるし、
デプロイも速いし、
ロールバックも一瞬。

その結果、

• 失敗が怖くない
• 改善が日常化する
• スピードが積み重なる

という理想的な循環が生まれました。

---

■ 海外で体験した「Serverless移行プロジェクト」の裏側

あるチームでは、旧来型の.NET API が大量に残っていて、
パフォーマンスも不安定、夜中アラートも頻発という状態でした。

僕がジョインしたとき、チームリードが開口一番言ったのがこれ。

“We are gonna delete all servers.”
（全部のサーバー消すから）

最初は何を言っているのかわからなかったですが、
彼の頭の中はすでに「運用ゼロの世界」を描いていました。

その後半年ほどかけて、

• 巨大なAPIを関数単位へ分割
• 認証やログなどはクラウドサービスに寄せる
• DBアクセスもイベントドリブンに最適化
• スケーリングは完全自動化

といったステップを踏み、
最終的に “深夜アラートゼロ” を達成しました。

そのとき、チーム全員が心から言ったのが、

“Why didn’t we do this earlier?”
（なんでこれをもっと早くやらなかったんだ…？）

これを聞いて、
僕の中でもServerlessに対する価値観が完全に変わりました。

---

■ Serverless は「技術」ではなく「働き方のアップグレード」

日本にいた頃の自分に言いたいのはこれです。

Serverlessは、働き方そのものを変える技術だ。

夜中にアラートで起こされないこと。
人間がやらなくていいことを任せられること。
小さく作って素早く直せること。
チームが依存せずに進められること。
改善を恐れなくなること。

どれもエンジニアの生活を“底上げ”してくれるものでした。

これはただのクラウド技術ではなく、
エンジニアの人生の効率を劇的に良くするための哲学
だと、本気で感じています。

Serverlessがもたらした“予想外の変化”

― 技術だけじゃない。働き方も、価値観も、キャリア戦略も変わった ―

Serverlessに移行して劇的に便利になった――
ここまでは前回の「承」で話したとおりなのですが、
実は、もっと大きな変化がその後にやって来ました。

それは、
「単なる技術移行ではなく、働き方そのものの改革になった」
ということ。

正直、ここまでは予想できていませんでした。

海外で働くエンジニアとして、Serverlessは僕に
“働き方の再定義” とも言えるレベルのインパクトを与えてくれたのです。

ここでは、驚いたポイントを3つの観点から共有します。

---

■ ① Serverlessが「仕事の優先順位」を変えた

Serverless移行が進む中で、チーム全体の“仕事の順番”が劇的に変わりました。

特に大きかったのは、
「作業の8割が運用 → 改善に変わった」
という変化。

以前は、

• 夜間アラート対応
• 負荷監視
• ログのチェック
• スケール設定の調整
• サーバーパッチ
• メンテナンスウィンドウの準備

などに時間を取られ、改善どころではありませんでした。

しかし、Serverlessが本格的に動き出してからは、
これらの作業がほぼゼロになっていきました。

するとどうなるか？

「じゃあ何をやる？」
という問いが生まれるわけです。

そして海外チームが出した答えは、とてもシンプルでした。

“More innovation.”（もっとイノベーションしよう）

負荷試験に時間を使うのではなく、
新しいユーザーストーリーを考える時間が増える。

ログ監視ではなく、
改善アイデアの検証に時間を使える。

ミーティングも
“問題の火消し” から
“未来をどう良くするか” へ。

エンジニアの働き方が、
問題対応型から価値創造型へ shift した のです。

---

■ ② チームの「心理的な変化」が大きかった

技術が変われば人のメンタルも変わる。
これ、Serverlessで初めて実感しました。

特に大きかったのは、
“失敗の恐怖” が消えたこと。

Serverlessの世界はデプロイもロールバックも一瞬です。
なので、失敗してもすぐ直せる。

これによって、チームメンバーが一斉に
チャレンジするようになった のです。

▼ Before（Serverless以前）

• リリースは怖い
• 大型APIは直すのが怖い
• 「壊したらどうしよう」が頭をよぎる
• レビューも慎重になりすぎて重くなる

▼ After（Serverless移行後）

• 「壊れても直せばいいよね」という空気
• 改修が怖くない
• 新しい案が出やすい
• 小さく出して早く改善が文化になる

とくに印象的だったのが、
普段は発言が少なかった若手エンジニアが、
堂々と改善案を出すようになったこと。

Serverlessがもたらしたのは、
単なるスピードではなく 心理的安全性 でもあったのです。

---

■ ③ 「コードを書く量」がむしろ減った

海外でServerlessをフル活用し始めてから、
ある日ふと気づいたことがあります。

“あれ、コード量がめっちゃ減ってない？”

最初は気のせいかと思っていたのですが、
チームリードも同じ意見でした。

特に減ったのは以下の部分。

• スケール処理
• リトライ処理
• 障害検知
• ログフレームワーク
• 認証周りのボイラープレート
• APIの「余計な」インフラコード

これらを自前で書かなくてよくなると、
コードの質も変わるんです。

本当に必要なコードしか残らない。

まるで不純物が取り除かれたように、
ビジネスロジックのコアだけが美しく残る感じ。

これはWPFアプリを作るときにも活かせる考えで、
“コードは少ないほど強い” という哲学が、
僕の中に深く刻み込まれました。

---

■ ④ 海外で求められるスキルセットが変わる

Serverlessが広がるにつれて、
海外のエンジニアに求められるスキルも変化していきました。

特に大きいのは以下の3つ。

1. “作らないスキル” が求められる

Serverlessでは、自前で作らないことが正義になる場面があります。

• API管理 → API Gateway
• 認証 → Cognito / Identity
• フロー管理 → Step Functions
• スケーリング → 自動
• 監視ログ → CloudWatch / Azure Monitor

これらを“作ろうとする人”は海外ではむしろ嫌われます。

“Why reinvent the wheel?”
（なんで車輪を再発明するの？）

という文化があるから。

2. 設計思考がめちゃくちゃ重要になる

Serverlessは「簡単に作れる」のが強みですが、
だからこそアーキテクチャが雑になりやすい。

海外では、
“無駄に関数を増やすな”
“データフローをちゃんと設計しろ”
という意識が強く求められます。

3. “意図して作らない”勇気が必要

Serverlessの真価は、
“作らないことで価値が生まれる”
という逆説にあります。

余計な仕組みを作らない勇気。
クラウドに任せる決断。
これが海外で強く評価されるポイントでした。

---

■ ⑤ Serverless がもたらした「余白」がキャリアを成長させた

Serverlessによって運用から解放されると、
エンジニアには “時間の余白” が生まれます。

その余白で何をするか――
ここがキャリアの分岐点になります。

僕がその時間でやったのは、

• アーキテクチャ設計の勉強
• DDDの理解を深める
• Azure/AWSのサービス理解
• 英語で技術記事を書く
• チーム改善の提案
• コードレビューの質を上げる

特に大きかったのは、
“コミュニケーション能力の向上”。

海外では、
「技術が強いだけの人」は評価されません。

• なぜその設計が必要か
• どんなリスクがあるか
• どんな価値があるか

これを、
短く、明確に、英語で伝える必要があります。

Serverless化で時間が生まれたおかげで、
僕はこの「伝える力」も磨くことができました。

---

■ Serverlessは、エンジニアを「燃え尽き」から救う技術だった

振り返ってみると、Serverless移行は
“精神的な負担の軽減”
にものすごく効果がありました。

夜中アラートが無くなる。
運用タスクも減る。
デプロイも怖くない。
改善がしやすい。
チームが前向きになる。

これは、
エンジニアのバーンアウトを防ぐための技術
でもあったのです。

海外での仕事は刺激が多い反面、
ストレスも大きく、負荷も高い。

そこで Serverless のような仕組みが
“余白” を生み出し、
エンジニアの生活を根本から整えてくれたのだと感じています。

Serverless時代にエンジニアとしてどう生きるか

― キレイなコードよりも、余白を生み出せるエンジニアであれ ―

ここまで、
Serverless が海外現場にもたらした変化や、
働き方・心理・文化の変化について書いてきました。

最終的に僕が辿り着いた結論を先に言うと、

「エンジニアにとって最大の武器は“余白”だ」

ということ。

Serverlessは、その“余白”を圧倒的に増やす技術であり、
それが結果として、
キャリア、働き方、生活の質を大きく押し上げてくれました。

ここでは、Serverless時代にエンジニアがどう生きればいいのか、
僕なりの結論を４つの観点でまとめます。

---

■ ① エンジニアの価値は「作る量」ではなく「残す時間」で決まる

海外の現場で学んだ最大の教訓はこれです。

“エンジニアの生産性は、どれだけコードを書いたかでは測れない。”
“どれだけ改善・挑戦・思考の時間を生み出したかで決まる。”

Serverlessは、
その“時間を生み出す技術” なんですよね。

例えば、

• サーバーメンテ不要
• スケール調整不要
• 障害復旧自動
• モニタリング自動
• インフラ構築ほぼ不要
• デプロイ高速
• ロールバック一発

これ、全部 “考える時間” を増やしてくれます。

そして、考える時間が増えると何が起こるか？

▼ 得られるもの

• より良い設計ができる
• ユーザー体験を改善できる
• チームに提案できる
• 新しい技術を学ぶ余裕ができる
• 仕事の質が上がる
• 自分の市場価値が勝手に伸びる

Serverlessは技術というより、
“思考力を取り戻すための武器”
なんです。

---

■ ② 「作らない勇気」を持てるエンジニアは強い

海外の現場ではよくこんな会話が起こります。

“Can we avoid building this?”
（これ、作らずに済まない？）

“Is there a managed service for this?”
（何か既製品で代用できない？）

Serverless時代のエンジニアは、
「作る技術」より「作らない技術」 が評価されます。

たとえば、

• 自作の認証 → クラウドの認証サービスへ
• 自作のバッチ → Lambdaのイベント駆動へ
• 自作のワークフロー → Step Functionsへ
• 自作のログ基盤 → クラウドネイティブのログ監視へ

作らない選択をすると、
保守コストが激減し、
チームのスピードも上がります。

日本では「作ること」が褒められがちですが、
海外では真逆で、

作らない選択をしたエンジニアほど尊敬される

という価値観です。

Serverlessはその文化を後押しします。

---

■ ③ 「自分の価値観」をアップデートすることで、キャリアが伸びる

Serverlessは、技術というより“価値観のアップデート”です。

僕自身、海外でServerlessに出会ってから、
エンジニアの仕事観が完全に変わりました。

例えば、

▼ Before（価値観が古い時代）

• できるだけ自前で作る
• 設定はこだわって調整する
• APIは巨大であっても仕方ない
• デプロイは重いもの
• 運用は頑張るもの
• 夜中アラートは職業病

▼ After（Serverlessで価値観が変わる）

• 自前で作るのは最終手段
• 設定はクラウドに任せる
• ロジックは小さく、軽く
• デプロイは0.5秒で終わるもの
• 運用はほぼ自動化すべき
• 夜中アラートは「技術負債」の証拠

価値観が変わると、
キャリアの方向性も自然と変わり、

• “設計できるエンジニア”
• “ムダを削れるエンジニア”
• “改善に強いエンジニア”

として評価されるようになりました。

技術を学ぶより、
価値観をアップデートする方が、
キャリアにはるかに大きな影響があります。

---

■ ④ Serverless時代に求められる“人生術”

最後に、Serverless × 海外経験から導いた
“エンジニアの人生術” をまとめます。

① ムダを嫌うことは、人生の幸福度を上げる

無駄な運用、無駄な作業、無駄なレビュー…
減らすほど人生が軽くなりました。

② 小さな成功を積み上げると、失敗が怖くなくなる

Serverlessの小さなデプロイ文化は、
人生にも応用できます。

• 小さく試す
• 小さく直す
• 小さく進む

これ、海外エンジニアの生存戦略でもあります。

③ “任せる力” はエンジニアの武器になる

人によっては「任せるのは弱さ」と思うかもしれませんが、
海外では「任せる＝強さ」です。

クラウドに任せる
サービスに任せる
自動化に任せる
チームに任せる

任せるほど、自分の価値は上がります。

④ 作らずに価値を出せるエンジニアはどこでも通用する

Serverlessの本質はこれです。

作らずに価値を生み出すエンジニアになる

これができれば、
日本でも海外でも、
どの国でもどの環境でも強く生きられます。

---

■ 最後に：Serverlessは、エンジニアの未来を軽くする

僕がこのシリーズで伝えたかったのは、技術の説明ではありません。

Serverlessは、
エンジニアの働き方・価値観・人生の質をアップデートする技術
だということ。

• 余白が生まれ
• 心が軽くなり
• キャリアが伸び
• ミスが怖くなくなり
• 改善が楽しくなり
• 自分の時間を取り戻せる

Serverlessは、
エンジニアにとっての“未来を軽くする道具”です。

これから海外を目指す人も、
クラウドをもっと深めたい人も、
「自分の働き方を変えたい」と思っている人も。

ぜひ、“作らない勇気” を持って、
Serverlessという新しい働き方に踏み出してみてください。