【海外ITエンジニアの告白】サーバーレスは「技術」じゃない、「思考法」だ。～インフラ地獄から抜け出すための実践的進化論～

「また横文字か…」C# / WPF畑の僕が、サーバーレスを毛嫌いしていた理由

（※ここから「起」の本文です）

どうも、海外の片隅でC#とWPF（Windows Presentation Foundation）を使って、日々デスクトップアプリケーションの設計と開発に明け暮れているエンジニアです。

突然ですが、みなさん「サーバーレス」って言葉、好きですか？

正直に告白します。僕は、つい2年ほど前まで、この言葉がめちゃくちゃ嫌いでした。

「また始まったよ、Web系スタートアップのキラキラしたバズワードが」

「こっちはガチガA（ガチガチのActive Directory）環境で、ステートフルな極太クライアント動かしてんだぞ」

「サーバーレス？ サーバーなしでどうやって仕事すんだよ、物理法則無視か？」

もうね、こんな感じ。完全に「食わず嫌い」です。

僕のキャリアは、Windowsフォームから始まり、WPF、UWPと、Microsoftのクライアントサイド技術と共にあります。僕らの世界では、「サーバー」っていうのは、物理的に（あるいはVMとして）ドーンと存在していて、そこにIIS（Internet Information Services）を立てて、WCF（Windows Communication Foundation）のエンドポイントを生やして、クライアントアプリ（WPF）がそこ（・・・・）に繋ぎに行く…というのが「常識」でした。

インフラはインフラチームが管理するもの。僕らはC#のコードとXAMLのUIに集中する。それが「分業」であり「プロフェッショナル」だと思っていました。ぶっちゃけ、インフラのことなんて、ネットワーク設定が面倒くさいし、OSのパッチ当てとかマジで興味ないし、「知らなくてもいいこと」だとさえ思っていたんです。

この考え、日本で働いていた時は、なんの問題もありませんでした。むしろ、それが「効率的」でした。

でも、海外（今働いている国）に来て、この「常識」が、僕の足を引っ張る「重り」に変わったんです。

海外の（特に僕がいるような中規模の）テック企業って、驚くほど「T型」というか、「越境」を求めてくるんですよね。「君の専門はC#とWPFだね。OK。ところで、この機能のデプロイパイプライン、どう思う？」「このAPIのエンドポイント、ちょっとレイテンシーがひどいんだけど、インフラ側とアプリ側、どっちがボトルネックだと思う？」

…え？ 知らんがな。

僕はC#のコードは書けるけど、CI/CDパイプラインのYAMLを最適化したり、AWSやAzureの監視ダッシュボードを読み解いたりする訓練は、積んでこなかった。

そんな時、僕の同僚（インド出身のフルスタックエンジニア）が、僕が2週間かけて「新しいVMの申請」だの「ファイアウォールの穴あけ依頼」だのをやっている横で、サクッとAWS LambdaとAPI Gatewayを組み合わせて、僕がやろうとしていた機能のプロトタイプを2時間で動かしたんです。

衝撃でした。

僕：「え、サーバーは？ OSは？ IISの設定は？」

彼：「ん？（笑）サーバー？ そんなもの（を意識するの）は時間の無駄だよ。僕らはコードを書くだけ。インフラはAWSが勝手にやってくれる。これがサーバーレスさ」

僕は、頭を鈍器で殴られたような気分でした。

僕が「インフラチーム」という名の「他人」と、メールとチケットで何往復もキャッチボールしている間に、彼は「本質的な価値」（＝コード）に集中し、あっという間にビジネス上の要求を満たしてしまった。

この時、僕は悟ったんです。

「サーバーレス」っていうのは、「サーバーがない」っていう物理的な話じゃない。

これは、**「俺（エンジニア）が、本来集中すべきじゃない面倒ごとから、いかに解放されるか」っていう、壮大な「抽象化」のムーブメントであり、もっと言えば「エンジニアとしての時間単価を最大化するための思考法」**なんだ、と。

僕らC# / WPFエンジニアは、ガベージコレクション（GC）の仕組みがあるから、メモリの解放をいちいち手動でやらなくていいことを「当たり前」に享受していますよね？ メモリ管理という「面倒ごと」から解放されて、「ロジック」に集中できている。

サーバーレスは、それの「インフラ版」なんです。

OSのパッチ当て、ミドルウェアのバージョン管理、スケーリングのためのサーバー増設…そういう「面倒ごと」を、クラウドベンダーに丸投げして、僕らはひたすら「ビジネスロジック（コード）」に集中する。

これって、特に海外で「結果」を求められるエンジニアにとって、最強の「人生術」だと思いませんか？

「インフラがまだ準備できてなくて…」

「デプロイに時間がかかって…」

そんな「言い訳」が一切通用しない環境で、最速で「動くもの」をデプロイし、価値を提供する。そのための実践的な進化論が、サーバーレスという概念なんだと、僕は理解しました。

このブログ記事は、かつての僕のように「サーバーレス？ ああ、Web系のね」と斜に構えている、特にクライアントサイドやエンタープライズ系の開発者（そう、WPFをやっているあなたです！）に向けて書いています。

この記事を読み終える頃には、サーバーレスが単なるバズワードではなく、あなたの「市場価値」と「日々の開発効率」を爆上げしてくれる、超（ちょう）実践的な「武器」であり「思考法」であることが、きっと理解してもらえるはずです。

「承」以降では、この「思考法」が具体的にどういうもので、いかに我々の開発オーバーヘッドを削減し、爆速デプロイを実現するのか。そして、あの大企業たちがどうやってコレを活用しているのかを、実例を交えて解き明かしていきます。

“サーバーがない”んじゃない。”どうでもいい”んだ。～インフラ抽象化がもたらす「爆速」開発の正体～

（※ここから「承」の本文です）

「起」の記事では、C# / WPFひと筋だった僕が、海外の現場で「サーバーレス」という概念に（文字通り）殴られ、長年信じてきた「常識」がガラガラと崩れた話をしました。

僕が2週間かけてVM申請やファイアウォールの設定に奔走している横で、同僚が2時間でAPIをデプロイした、あの衝撃。

彼の言葉を、もう一度思い出してみましょう。

「サーバー？ そんなもの（を意識するの）は時間の無駄だよ」

この言葉、当時の僕には「サーバーなんか使わないぜ」という、ちょっとイキった（失礼）発言に聞こえたんです。でも、それは大きな間違いでした。

サーバーレス（Serverless）って、別に「サーバーが存在しない（No Server）」という意味じゃないんですよね。もちろん、AWSやAzure、Googleの巨大なデータセンターには、それこそ星の数ほどの物理サーバーがラックに詰まって、ブンブン唸（うな）りを上げて稼働しています。

じゃあ、何が「レス（Less）」なのか？

それは、**「僕らエンジニアが、サーバーの存在を意識する（・・・・・）必要がなくなる」**ということです。

もっとぶっちゃけて言えば、「起」のサブタイトルにも書きましたが、サーバーのことが「どうでもよく（・・・・・・）」なるんです。

これこそが、「インフラの抽象化」の正体です。

ピンと来ない人もいると思うので、僕らWPFエンジニアに馴染み深い「伝統的な開発（僕が日本でやっていたやり方）」と、サーバーレスの世界を、具体的に比較してみましょう。

【シナリオ】

WPFアプリ（クライアント）から呼び出す、簡単な「顧客データを一件取得するAPI」を作るとします。

比較１：旧世界（オンプレミス or IaaS）

僕が「APIを作ろう」と思い立ってから、実際にWPFアプリから HttpClient.GetAsync(...) を叩けるようになるまで、どれだけ「コード以外の面倒ごと」があったか。

  1. 申請と調達（数日～数週間）
    • 「インフラチーム様、お疲れ様です。かくかくしかじかでAPIサーバー立てたいので、VM（仮想マシン）を1台ください」と申請書を書く。
    • スペック（CPU、メモリ、ディスク）をどうするか聞かれる。将来の負荷なんてわからないけど、とりあえず「中」くらいで申請する。
    • コストセンターの承認、マネージャーの承認…とハンコ（比喩）が押されていくのを待つ。
  2. OSとミドルウェアのセットアップ（数時間～数日）
    • やっとVM（Windows Server 2019とか）が払い出される。
    • RDP（リモートデスクトップ）で接続。
    • 「役割と機能の追加」からIIS（Webサーバー）をインストール。
    • 「あ、.NET Framework 4.8が要るんだった」とランタイムをインストール。
    • 「やべ、再起動かかった」
    • 「SSL証明書どうしよう…とりあえずオレオレ（自己署名）で…いや、ちゃんとしたのインフラチームにもらわないと…」と、またメール。
  3. ネットワーク設定（地獄）
    • 「WPFクライアントからAPIに接続できません！」
    • 「ああ、ファイアウォールのポート（443）が閉じてますね」
    • 「ネットワークチーム様、お疲れ様です。かくかくしかじかで、XXサーバーからYYサーバーへの443ポートを開けてください…」
    • （数日後）「開けました」
    • 「…まだ繋がりません！」
    • 「ああ、クライアント側の（・・・・・・・）ファイアウォールも開けないとダメですね」
  4. やっとデプロイ
    • Visual Studioから「発行」で、ビルドしたWCFサービスやWeb APIのDLL群を、サーバーの C:\inetpub\wwwroot\... 配下にコピーする。
    • IISのアプリケーションプールを再起動。

…どうです？

APIのロジック（C#コード）自体は、たぶん30分もあれば書けるのに、その「ガワ（インフラ）」を準備するためだけに、僕らは何日、下手すりゃ何週間も使っていたわけです。

しかもタチが悪いのは、このインフラ、一度作ったら「お守り」し続けないといけないこと。

  • 「Windows Update（パッチ当て）のために、週末にメンテ（サービス停止）します」
  • 「ログがディスクを圧迫したので、夜中に叩き起こされてログ削除しました」
  • 「朝起きたら、IISのアプリプールが死んでて、叩き直しました」

これ、僕らアプリケーション開発者の「本質的な仕事」でしょうか？ 違いますよね。

僕らは、WPFのUIをどう使いやすくするか、C#のロジックをどう効率化するか、そこに脳みそと時間を使いたいんです。

比較２：新世界（サーバーレス）

じゃあ、あのインド人の同僚がやった「サーバーレス」なやり方（AWS LambdaやAzure Functionsを想定）だと、どうなるか。

  1. クラウドのコンソール（Webサイト）を開く。
  2. 「新しいFunctions（関数）を作る」とポチる。
  3. トリガー（起動条件）を選ぶ。
    • 「HTTPリクエストで起動する」を選ぶ。（＝APIになる）
  4. コードを書く（あるいはアップロード）。
    • さっき言った「顧客データを一件取得する」C#のロジック（関数）だけを、Web上のエディタにコピペするか、Visual Studioから直接デプロイする。（プラグインがある）

終わり。

デプロイが終わると、https://xxxx.azurewebsites.net/api/GetCustomer?id=… みたいなURLが自動で発行されます。

もう、WPFアプリから HttpClient.GetAsync(…) が叩けます。

…え？ と思いません？

  • VMの申請は？ → いらない。
  • OSのセットアップは？ → いらない。 （クラウドベンダーが管理してる）
  • IISのインストールは？ → いらない。
  • パッチ当ては？ → いらない。 （勝手にやってくれる）
  • ファイアウォールは？ → いらない。 （HTTP(S)のエンドポイントは最初から公開されてる ※もちろんIP制限なども設定可能）

あの「旧世界」で僕らがやっていた「面倒ごと」の95%が、消滅するんです。

これが、**「インフラの抽象化」**がもたらす、とんでもないパワーです。

僕らは「サーバーのお守り」から解放され、ただひたすら「価値を生むコード」に集中できる。

だから、あの同僚は僕が2週間かかったことを、2時間で（実際はもっと早く）終わらせることができた。これが**「爆速デプロイ（Faster Deployments）」**の正体です。

即時的なゲイン：運用オーバーヘッドの削減

「でも、運用は結局大変なんでしょ？ アクセスが集中したらどうするの？」

そう思いますよね。僕も思ってました。

旧世界（VM）の場合：

もし朝の9時に、WPFクライアント（全社員）からのアクセスが集中したら、僕が「中」スペックで申請したVMは、CPU使用率100%に張り付いて、応答しなくなります（＝アプリがフリーズする）。

対策？ VMのスペックを「大」に上げる（お金がかかるし、また申請が必要）か、VMを2台、3台に増やす（＝ロードバランサーの導入…また面倒ごとだ…）。

新世界（サーバーレス）の場合：

サーバーレス（Functions / Lambda）は、「リクエストが来た時だけ起動する」という設計になっています。

そして、リクエストが1000個同時に来たら、クラウド側が勝手に1000個（のインスタンス）を起動してさばいてくれます（※細かい制限はあるけど、概念として）。

そして、処理が終わってリクエストがゼロになったら、勝手に（・・・・）インスタンスをゼロにして、寝てくれます。

これが何を意味するか？

  1. 無限の（ほぼ）スケーラビリティ： アクセス集中で「サーバーが落ちる」という概念が（ほぼ）なくなる。僕らはもう「サイジング（スペック見積もり）」に悩まなくていい。
  2. 劇的なコスト削減： リクエストがゼロ（深夜とか）の時、サーバーは起動していないので、コストも（ほぼ）ゼロになります。VMみたいに「24時間365日、起動してるだけでチャリンチャリン課金される」ことがない。
  3. 運用オーバーヘッドの消滅： サーバーが「落ちる」ことも「再起動」も「パッチ当て」も（僕らが）する必要がない。これ以上「楽」な運用があるでしょうか？

「爆速でデプロイ」できて、しかも「運用（お守り）がゼロ」になる。

これが、僕らがサーバーレスを採用すべき、超・即物的な「得する」理由です。

「どうせスタートアップのお遊びでしょ？」

「いやいや、そんな都合のいい話、ウチみたいなエンタープライズ（お堅い大企業）には無理だよ」

「ルンバとかNetflixとか、そういうイケイケのWeb系企業の話でしょ？」

甘い。

かつての僕も、そう思って現実から目をそらしていました。

確かに、Netflixはサーバーレス（AWS Lambda）の超ヘビーユーザーです。彼らが世界中に4K動画を安定配信できる裏側では、動画のエンコード（変換処理）や、ファイルの監視、ユーザー認証の補助など、無数のLambda関数が動いています。

でも、もっと「お堅い」企業も、とっくにサーバーレスの「うまみ」に気づいています。

例えば、あのコカ・コーラ。

彼らは、世界中にある自動販売機の在庫管理や決済処理、顧客向けのロイヤリティプログラム（ポイントサービスとか）のバックエンドに、サーバーレス（AWS）を全面的に採用しています。

なぜか？

従来のやり方（VMと自前サーバー）でやっていたら、新しいキャンペーンのAPIを作るのに6ヶ月かかっていたのが、サーバーレスに移行したら数週間になったから。

しかも、コスト。自販機が使われない深夜、アクセスがゼロの時は、サーバーコストもほぼゼロになる。この「使った分だけ課金」という合理性が、巨大企業の経営にすら刺さっているんです。

もっと身近な例で言えば、iRobot社（ルンバの会社）。

世界中の何百万台ものルンバが、掃除しながら集めた「部屋のマップデータ」をクラウドに送っています。もし特定の時間（みんなが仕事から帰ってきてルンバを一斉に動かす時間とか）にアクセスが集中したら？ 従来のサーバーならパンクします。

でも、サーバーレスなら、その瞬間だけ爆発的にスケールして全リクエストをさばき、終わったら静かにゼロに戻る。

もう、お分かりですよね。

サーバーレスは「バズワード」でも「お遊び」でもない。

**「ビジネスを最速で回し、運用コストを最小化する」**ための、超・現実的な「進化」であり「選択肢」なんです。

…と、ここまでサーバーレスの「うまみ」を語ってきました。

インフラの面倒ごとから解放され、コードに集中でき、爆速デプロイとゼロ運用が手に入る。

でも、C# / WPFエンジニアの皆さんは、まだこんな疑問を抱いているはずです。

「いや、それはわかった。でも、それって結局、Netflixやコカ・コーラみたいな『Web API』の話だろ？」

「俺たちが作ってるのは、ステートフル（状態を持つ）で、リッチで、極太な『デスクトップアプリ』だ」

「俺たちのWPFアプリと、サーバーレスが、どう関係あるんだよ？」

鋭い。最高にいい質問です。

次の「転」では、まさにその核心に迫ります。

僕が実際に、この「サーバーレス思考」を使って、レガシーなWPFアプリの**「あのクソ重いバッチ処理」や「あの超面倒な認証基盤」**を、どうやって劇的に改善したのか。

Web系だけのものだと思っていた「サーバーレス」を、僕らWPFエンジニアが「得する」ためにどう「武器」として使うか。その超・具体的な実践テクニックを、余すところなくお話ししようと思います。

Netflixもやってる「それ」。あなたのWPFアプリにも「サーバーレス思考」を組み込む方法

（※ここから「転」の本文です）

「起」で僕のサーバーレスへの偏見が崩れ去り、「承」で、サーバーレスが「インフラの面倒ごと」をいかに抽象化し、爆速デプロイとゼロ運用を実現する「とんでもない武器」であるかを語りました。

Netflixやコカ・コーラといった巨大企業が、VM（仮想マシン）の管理やパッチ当てといった「本質的でない作業」から解放され、いかに「ビジネス価値（コード）」に集中しているか。その「うまみ」は、もう十分ご理解いただけたかと思います。

でも、僕を含め、この記事を読んでくれているC# / WPFエンジニアの多くは、まだこう思っているはずです。

「いや、わかるよ。わかるけどさ。それって結局、Web APIとか動画配信とか、そういう『Web系』の話でしょ？」

「俺たちが作ってるのは、ユーザーの手元（デスクトップ）で動く、ガチガチの**『極太クライアント（Rich Client）』**なんだよ」

「俺たちのWPFアプリと、その『サーバーレス』ってやつが、具体的にどう繋がるんだ？ あんまり関係ないんじゃないの？」

……はい。僕も、まったく同じことを思ってました。

僕らのWPFアプリは、ユーザーのWindows PC上で、リッチなUI（XAMLで組んだ複雑な画面）と、複雑なビジネスロジック（C#のコード）が密結合して動く。それが価値であり、Webアプリには真似できない操作性を実現しているんだ、と。

バックエンドと通信するにしても、せいぜい社内に立てたIIS（のWCFかWeb API）を呼ぶくらい。インフラはインフラチームが管理するもの。僕らの仕事は、あくまでクライアントサイド。

この「固定観念」。

これこそが、僕らを「インフラ地獄」の片棒を担ぐ共犯者にし、ユーザーに「フリーズするアプリ」を提供し続ける「呪い」の正体だったんです。

「転」では、この「呪い」を解きます。

サーバーレスは「Web APIを作る技術」ではありません。

何度も言いますが、これは**「面倒ごとを抽象化し、コード（価値）に集中するための思考法」**です。

そして、この「思考法」は、僕らWPFエンジニアが日々直面している、**あの忌まわしき「クソ重い処理」や「超面倒な認証」**を解決する、最強の処方箋（しょほうせん）になります。

今日は、僕が海外の現場で「あ、これサーバーレスでやれば”得”できるじゃん！」と気づき、実際にWPFアプリのアーキテクチャを変えて大成功した、超・具体的な2つの実例をお話しします。

実例１：「あのクソ重いバッチ処理」からの解放

WPFエンジニアの皆さん、こういう経験ありませんか？

【恐怖のシナリオ】

ユーザーが、WPFアプリのメイン画面から「月次レポート生成」ボタンをポチッと押す。

すると、アプリが5分間、完全にフリーズする。（ウィンドウが白くなって「応答なし」になるアレです）

ユーザーは「また固まったよ…」とため息をつきながら、コーヒーを淹れに行く。

【なぜ、こうなる？】

コードを読んでみると、だいたいこうなっています。

  1. 「レポート生成」ボタンのクリックイベントハンドラ（C#）が発火。
  2. DB（社内のSQL Serverとか）に接続。
  3. 生データを数万件、クライアントPCにフェッチしてくる。
  4. クライアントPCのCPUとメモリを使って、その数万件のデータを foreach でゴリゴリ集計・加工する。
  5. ClosedXML や iTextSharp みたいなライブラリを使って、ExcelやPDFを生成する。
  6. クライアントPCのデスクトップにファイルが保存され、やっとフリーズが解ける。

このアーキテクチャの何が最悪か？

それは、「処理の実行（CPU、メモリ）」と「処理時間（待ち時間）」のすべてを、ユーザーの貧弱なクライアントPCに押し付けていることです。

  • ユーザーAのPCはハイスペックだから3分で終わるけど、ユーザーBのPCはメモリ8GBの古いノートPCだから10分かかる（あるいはメモリ不足でクラッシュする）。
  • 処理中は、アプリがフリーズするので、ユーザーは他の作業が一切できない。
  • 開発者は「あのユーザーのPCでだけクラッシュする」という、再現性のないバグに悩まされる。

これを、僕らは「クライアントがリッチだから仕方ない」と諦めてきました。

【サーバーレス思考の適用】

ここで、あの同僚の言葉を思い出します。

「そんなもの（を意識するの）は時間の無駄だよ」

このシナリオで「無駄」で「面倒ごと」は何か？

それは、**「クライアントPCのスペック（という不確定要素）に依存すること」そして「ユーザーの貴重な時間をフリーズさせて奪うこと」**です。

じゃあ、どうするか？

答えは簡単。その重い処理、クライアントでやるの、やめましょう。

【解決策：Functions + Blob Storage】

僕がやったのは、この処理を丸ごと「サーバーレス」にぶん投げることでした。

  1. WPFアプリの「レポート生成」ボタンは、Azure Functions (or AWS Lambda) で作ったAPI（HTTPトリガー）に、「レポート生成お願いね。条件はこれ（JSON）」とリクエストを送るだけにします。
  2. Functions（クラウド側）は、リクエストを受け取ったら、即座に「OK、やっとくわ」とWPFアプリに202 Accepted（受理しました）を返します。
  3. WPFアプリは、ここでフリーズが解けます。 ユーザーは「受付ました」というトースト通知を見て、もう他の作業ができます。（待ち時間、ほぼゼロ！）
  4. ここからが本番。Functions（クラウド側）は、非同期で、クラウドの潤沢なリソース（CPU、メモリ）を使って、DBから生データをフェッチし、ゴリゴリ集計・加工します。（これが「承」で話した「勝手にスケールする」ってやつです）
  5. 処理が終わったら、Functionsは生成したExcelやPDFを、Azure Blob Storage (or AWS S3) という「ファイル置き場」に保存します。
  6. （通知方法）
    • [A] プル型: WPFアプリは、5秒おきくらいに「あのファイル、もうできた？」と別のFunctions（状態確認用API）をポーリング（問い合わせ）する。
    • [B] プッシュ型（これが最高）: Functionsは、処理が終わったら Azure SignalR Service 経由で、WPFアプリに直接「終わったよ！ダウンロードURLはこれね」とプッシュ通知します。

【得られた「得」】

このアーキテクチャに変えた結果、何が起きたか。

  • ユーザーの「フリーズ地獄」が消滅。 ボタンを押したら、あとは勝手に処理が進み、終わったら通知が来る。もうコーヒーを淹れに行く必要はありません。
  • 開発者の「PCスペック依存」バグが消滅。 処理はすべてクラウド側で動くので、ユーザーのPCがどれだけ貧弱でも関係ない。
  • コストが劇的に安い。 このレポート生成、1日に10回しか使われないなら、Functionsが動くのはその10回（合計しても数分）だけ。その数分間の「実行時間」にしか課金されません。旧世界のように、バッチ処理のためだけにVM（サーバー）を24時間365日動かし続ける（＝24時間課金され続ける）のとは、比べ物にならない安さです。

重い処理は、クライアント（WPF）ではなく、サーバーレス（Functions）に丸投げする。

これこそ、WPFエンジニアが真っ先に採用すべき「サーバーレス思考」です。

実例２：「あの超面倒な認証基盤」の抽象化

もう一つの「地獄」が、「認証」です。

【恐怖のシナリオ】

僕の会社は、オンプレミス（自社内）にActive Directory (AD) を持っていました。

社内のLANに繋がったWPFアプリは、「統合Windows認証」で、ユーザーはパスワード入力なしでシームレスにログインできていました。めでたしめでたし。

…パンデミック（コロナ禍）が起きるまでは。

全社員がテレワークになり、海外支社からもアクセスしたい、という要求が爆発しました。

さあ、どうする？

  • 案1： 全員に「VPN」を強制する。
    • → 遅い、面倒くさい、VPNが切れたらアプリも落ちる。ユーザー体験は最悪。
  • 案2： 認証サーバー（IDP）を自前で構築する。
    • → IISでWeb APIを立てて、ユーザー名とパスワードをPOSTで受け取って、ADに問い合わせて…
    • → トークン（JWT）を発行・管理・失効するロジックを自前で実装？
    • → 待って、パスワードをネットワーク越しに送るの？ セキュリティは？ ハッシュ化は？ ソルトは？

…考えただけで、吐き気がします。

「認証」は、アプリ開発において最も重要で、最も面倒くさく、**絶対にミスが許されない（・・・・・）**領域です。

【サーバーレス思考の適用】

ここで、再びあの言葉を思い出します。

「そんなもの（を意識するの）は時間の無駄だよ」

このシナリオでの「無駄」で「面倒ごと」は何か？

それは、**「認証という車輪の再発明（しかも超ハイリスク）を、自前でやろうとすること」**です。

【解決策：IDaaS (Identity as a Service) への丸投げ】

僕は、認証の実装を一切（・・）やめました。

代わりに、Azure AD B2C (or AWS Cognito, Auth0) と呼ばれる、クラウド上の「認証基盤サービス」に、すべてを丸投げしました。

これらは、認証機能に特化した「サーバーレス」サービス（IDaaS）です。

僕ら開発者は、もはや「ユーザーのパスワードがDBに平文で保存されてないか」とか「多要素認証（MFA）の仕組みどうしよう」なんてことを、1ミリも心配しなくてよくなります。

  1. Azure AD B2Cの管理画面（Webサイト）で、「こういうルール（例：メールアドレスとパスワードでログイン、Googleアカウントでもログイン可、パスワードリセット機能あり、MFA必須）」を設定します。（コードは1行も書かない）
  2. WPFアプリ側は、MSAL (Microsoft Authentication Library) という公式ライブラリをNuGetからインストールします。
  3. WPFアプリの「ログイン」ボタンが押されたら、MSALの AcquireTokenInteractive メソッドを呼ぶだけ。
  4. すると、WPFアプリ上に「Webビュー（埋め込みブラウザ）」がポップアップし、さっきAzure AD B2Cで設定したログイン画面が（勝手に）表示されます。
  5. ユーザーがそこで（安全な場所で）認証を済ませると、WPFアプリはコールバックで「トークン（JWT）」を受け取ります。
  6. あとは、実例1で作ったFunctions（API）を呼ぶときに、HTTPヘッダーにそのトークンを Bearer としてくっ付けるだけ。

【得られた「得」】

  • 自前で認証基盤を構築・運用するコスト（時間・工数・セキュリティリスク）がゼロになりました。
  • VPNなしで、世界中のどこからでもセキュアに（MFA込みで）WPFアプリが使えるようになりました。
  • API側（Functions）も、送られてきたトークンがAzure AD B2Cが発行したものか検証するだけ。ユーザー管理のロジックから完全に解放されました。

まとめ：「思考法」としてのサーバーレス

もうお分かりですよね。

サーバーレスは「Web系の技術」なのではなく、**「本質的でない、面倒な仕事を、いかに抽象化して丸投げするか」**という「思考法」なんです。

僕らWPFエンジニアは、「UI/UX」という「クライアントでしかできないこと」に全集中すべきです。

そして、

  • 重い処理（バッチ、集計）
  • 面倒な処理（認証、ファイル管理）
  • スケールが必要な処理（API）

これらは全部、サーバーレス（Functions, IDaaS, Storageなど）にぶん投げてしまえばいい。

それこそが、現代における最も「賢い分業」であり、海外の現場で僕が学んだ「爆速で価値を生む」エンジニアの働き方です。

WPF（クライアント）は「顔」としてUXに集中し、サーバーレス（バックエンド）は「内臓」として面倒ごとをすべて引き受ける。

この「サーバーレス思考」を身につけることが、僕らをインフラ地獄から解放し、エンジニアとして「得」をするための、最大の鍵となります。

さて、この「思考法」をさらに推し進めていくと、僕らエンジニアの「キャリア」や「人生術」そのものにも、大きな影響を与えてきます。

次の「結」では、このサーバーレスの先にある、僕らが本当に目指すべき「エンジニアとしての価値」とは何なのか。

技術で「得」をし続けるための人生術について、僕の海外での経験も踏まえながら、最後にお話ししたいと思います。

技術で「得」するエンジニアの人生術：サーバーレスの先にある、本当の「価値」とは

（※ここから「結」の本文です）

長かったこの話も、ついに最終回です。

「起」では、C# / WPFひと筋だった僕が、海外の現場で「サーバーレス」という言葉への偏見を叩き割られた話をしました。

「承」では、サーバーレスが「インフラのお守り」という面倒ごとをいかに抽象化し、爆速デプロイとゼロ運用を実現する「とんでもない武器」であるかを、Netflixなんかの実例を交えて解説しました。

そして「転」では、それがWeb系だけの話ではなく、僕らWPFエンジニアが直面する「クソ重いバッチ処理」や「超面倒な認証基盤」を解決する、超・具体的な処方箋であることをお見せしました。

僕はこのブログを通じて、一貫して「サーバーレスは技術じゃない、思考法だ」と言い続けてきました。

そして、この「思考法」こそが、僕らがエンジニアとして、いや、一人のプロフェッショナルとして「得」をするための、最強の「人生術」だと確信しています。

今日はその「結論」を、僕の海外での経験も踏まえてお話しします。

あなたの「時給」を最大化する、たった一つの考え方

僕らがこの仕事で「得」をするって、どういうことでしょう？

もちろん、給料が上がること、キャリアアップすることも大事です。でも、僕が海外で痛感したのは、もっと根本的なこと。

それは、自分の「時給」の価値を最大化することです。

ここで言う「時給」っていうのは、会社から貰う給料を労働時間で割った、単純な金額のことじゃありません。

あなたの**「脳みそと、人生の残り時間（＝命）を、1時間あたり、どれだけ『価値ある仕事』に投下できているか」**という、本当の意味での「時間単価」です。

思い出してみてください。

僕らが「旧世界」でやっていたインフラの面倒ごと。

  • OSのパッチ当て（深夜メンテ）
  • IISのアプリプール再起動（原因不明のハングアップ対応）
  • VMのスペック見積もりと申請（未来予測という名のギャンブル）
  • 自前の認証ロジックの実装（車輪の再発明、セキュリティリスクとの戦い）

これらをやっている時間、僕らの「脳みそ」は、本当に「価値」を生んでいたでしょうか？

ぶっちゃけ、生んでないですよね。

それは、Netflixやコカ・コーラが証明したように、「誰か（クラウドベンダー）が、自分よりもうまく、安く、安全にやれる仕事」です。

こういう仕事を、僕は**「コモディティ（日用品）ワーク」**と呼んでいます。

僕らエンジニアは、技術が好きだからこそ、「自分で作りたい」「全部わかってないと気が済まない」というワナに陥りがちです。特に僕らWPFエンジニアは、リッチクライアントという「全部入り」の世界にいたから、その傾向が強い。

でも、海外の現場（特に僕の同僚のようなトップパフォーマー）は、その辺が超（ちょう）ドライです。

「それは、俺がやるべき仕事か？」

「それ、AWS (or Azure) がもっとうまくやってくれないか？」

彼らは常に自問自答しています。

そして、「コモディティ・ワーク」だと判断した瞬間、即座に「サーバーレス（Functions, IDaaS, S3など）」のようなPaaS / SaaSに丸投げするんです。

なぜか？

そうやって「コモディティ・ワーク」を人生から「削除」することで、捻出（ねんしゅつ）した「時間」と「脳のメモリ」を、本当に「価値ある仕事」に全振りするためです。

あなたにしかできない「本当の価値」とは何か

じゃあ、「価値ある仕事」って何でしょう？

それは、**「あなた（の会社）にしか生み出せない、独自の価値」**のことです。

  • WPFアプリの、あのボタン配置を1ピクセル動かすことで、ユーザーの操作ミスを劇的に減らすこと。（＝UXの追求）
  • ユーザーヒアリングを通じて、「月次レポート」のロジック（集計方法）そのものを改善提案すること。（＝ドメイン知識の深掘り）
  • 「転」で紹介したように、「フリーズするアプリ」という苦痛を、「非同期＋通知」というアーキテクチャで根本的に解決すること。（＝アーキテクチャ設計）

これらは、AWSもAzureもGoogleも、やってくれません。

あなたの会社の、あなたのチームの、あなたの「脳みそ」でしか生み出せない、「コア・バリュー」です。

サーバーレス思考の「人生術」とは、

「コモディティ・ワーク（どうでもいい面倒ごと）は、サーバーレスで徹底的に抽象化（丸投げ）し、自分の有限なリソース（時間・脳）を、コア・バリュー（自分にしかできない価値）に集中投下する」

という、シンプルな戦略です。

この戦略を身につけたエンジニアは、「得」をします。

なぜなら、会社やマーケット（市場）は、「コモディティ・ワークをどれだけ頑張ったか」では、あなたを評価しないからです。

深夜にパッチ当てを完遂しても、「ご苦労様（笑）」で終わりです。給料は上がりません。

でも、「転」でやったみたいに、「5分フリーズしてたアプリが、ボタン押したら即レスポンス返ってくるようになりました。もうユーザーは待たなくていいです」と実現したら、どうです？

それは**「目に見える、明確な、ビジネス上の価値」**です。

これこそが、あなたの評価と「時給」を爆上げする「仕事」なんです。

サーバーレスの先にある「進化」

僕はこの一連の記事で、「Serverless: Beyond Buzzword – A Practical Evolution（バズワードを超えて：実践的な進化）」というフックに基づいて話をしてきました。

この「進化」の正体は、もうお分かりですよね。

僕らエンジニアは、「手を動かしてモノを作る（Build）人」から、**「価値を組み立てる（Assemble）人」**へと進化しなきゃいけない。

レゴブロックの「パーツ（OS、Webサーバー、認証）」を一個一個いちから粘土こねて作るんじゃなくて、すでにある最高のレゴブロック（＝サーバーレスの各サービス）を、最速で、最も賢く組み上げて、顧客が欲しがる「作品（＝ソリューション）」を完成させる。

それができるエンジニアが、これからの時代、特にスピードと結果がすべてである海外の現場では、圧倒的に「得」をします。

もしあなたが、かつての僕のように「WPFエンジニアだから」「C#畑だから」と、自分の領域を決めつけ、インフラの面倒ごとを「仕方ないもの」として受け入れているなら、今日からその「思考停止」をやめてみてください。

あなたの目の前にある、その「面倒ごと」。

それ、本当にあなたがやるべき仕事ですか？

それ、サーバーレスに丸投げできませんか？

その「問い」こそが、あなたを「インフラ地獄」から解放し、エンジニアとして、そして一人のプロフェッショナルとして、本当に「得」をするための「人生術」への、第一歩です。

コメント

タイトルとURLをコピーしました