え、WPFエンジニアがKafka？ 海外で「こいつ、分かってるな」認定されるための、バックエンド越境術

「またこのデータ、更新されてない！」WPFエンジニアが直面する”裏側”の壁

さて、まずは俺の盛大な失敗談から語らせてくれ。

あれは、今担当してる製造ラインの監視システムの改修プロジェクトでのこと。俺はWPFで、ラインの稼働状況やエラーをリアルタイムで表示するダッシュボード画面を担当してた。

ある日、マネージャーから「Koji、ユーザー（工場の現場監督）からクレームだ。ダッシュボードに表示されてる『部品Aの在庫数』が、実際の在庫と合ってないらしい。至急、確認してくれ」って言われたんだ。

「えー、またかよ」

正直、うんざりしてた。この手の「データ不整合」クレーム、これで3回目だったから。

俺はすぐさま自分のWPFアプリのコードを見直す。データを取得してるAPIのエンドポイントも確認する。でも、俺のコードは完璧だ。APIから返ってきたJSONを、忠実に画面にバインドしてるだけ。

「俺のせいじゃない。これはバックエンドの問題だ」

そう確信した俺は、バックエンドチーム（インドとリモートで繋いでる）にチャットを投げた。

俺：「Hey、また在庫数が合ってないってクレーム来てるんだけど。そっちのAPI、ちゃんと最新のデータ返してる？」

まあ、今思うと最悪のコミュニケーションだよね（笑）。

案の定、バックエンドのリーダー（めちゃくちゃ優秀だけど、ちょっと怖い）から、秒で返信が来た。

リーダー：「Koji、APIは『受け付けたリクエスト』を返してるだけだ。実際の在庫計算は、非同期のバックグラウンド処理でやってる。そっちの処理キューが詰まってるか、ジョブが失敗してるのかもしれん。こっちでログ見るから、とりあえずWPF側で『データは数分遅れる可能性があります』って注釈でも入れとけ」

……チーン。

俺、この時「非同期のバックグラウンド処理」って言われて、マジで意味が分からなかったんだ。

いや、もちろんasync/awaitは知ってるよ？ でも、彼が言ってたのは、そういうレベルの話じゃなかった。

俺のWPFアプリが叩いてた「在庫更新API」は、実は「在庫更新リクエストを『受け付ける』だけ」の入り口に過ぎなかった。

その裏側では、こんなことが起きてたんだ。

  1. WPFアプリ：「部品A、1個使ったよ！」とAPIを叩く。
  2. APIサーバー：「OK、受け付けた！」と即レスポンス（この時点では在庫DBは更新されてない）
  3. APIサーバー：「『部品A、1個使った』っていう『イベント（出来事）』を、メッセージキューっていう箱に放り込む」
  4. ヒマな時に、別の「バックグラウンド・ワーカー（処理専用のプログラム）」が、キューからその「イベント」を取り出す。
  5. ワーカー：「お、仕事来たな。『部品A』の在庫をDBから読み込んで、1個引いて、DBに保存する、と」
  6. （この処理が終わって、初めてDBの在庫数が更新される）
  7. 俺のWPFダッシュボード：「最新の在庫ちょうだい！」と別のAPIを叩く。
  8. API：「OK、今のDBの状態は『在庫100個』だよ」（まだワーカーの処理が終わってない）
  9. 俺のWPF：「（さっき使ったのに）在庫100個」と表示する。
  10. 現場監督：「おい！今使ったのに減ってねえぞ！」（クレーム）

これが、俺が直面してた「壁」の正体だったんだ。

俺はWPFの画面しか見てなかった。でも、ユーザー（現場監督）が見てるのは「現実（リアル）」の在庫と、「画面（WPF）」のギャップだ。そして、そのギャップを生み出していたのが、俺がまったく知らなかった「バックエンドの仕組み」だったわけ。

この時、俺は痛感した。

「クライアントサイドエンジニア（WPF）の仕事って、もしかしてバックエンドの仕組みを『いかにユーザーに隠蔽して、快適に使わせるか』ってことなんじゃないか？」

「データは数分遅れます」なんて注釈を出すのは簡単だ。でも、それはエンジニアの「逃げ」でしかない。

そうじゃなくて、例えば、

  • APIが「受け付けた」と返してきたら、画面では「更新処理中…」とスピナーを出す。
  • 裏側でワーカーの処理が終わったら、バックエンドから何らかの通知（SignalRとか）をもらって、「更新完了！」と表示を変える。

こういう「気の利いた」UI/UXを提供してこそ、プロのWPFエンジニアじゃないのか？

そして、こういう「気の利いた」実装をするためには、俺たちWPFエンジニアも、バックエンドが「今、何をしてるのか」を知る必要がある。

そこで俺は、バックエンドのリーダーに頭を下げて、彼らのアーキテクチャを教えてもらうことにした。

「非同期処理って何？」「メッセージキューって何で必要なの？」「ていうか、その『Kafka』ってやつ、何がすごいの？」

これが、俺とKafkaの出会いだった。

WPFエンジニアの俺が、なぜクライアントのUXを突き詰めた結果、Kafkaに行き着いたのか。

そして、このKafka（イベントドリブンアーキテクチャ）の基本を理解してると、海外の現場でいかに「こいつ、分かってるな」って一目置かれるようになるのか。

次の「承」では、いよいよ本題のKafkaについて、WPFエンジニアの視点から「それ、おいしいの？」っていう話を、具体的なユースケース（そう、お題にあった「ユーザープロファイルの再インデックス」とかね）を交えながら、分かりやすく解説していくぜ。

なぜKafka？ 「ただのキュー」じゃダメな理由と、WPFエンジニアが”得する”本当の強み

さて、「起」で俺の盛大な「データ合ってねえぞ！」事件を話したわけだけど。

あの後、俺はバックエンドのリーダーに（今度はめちゃくちゃ低姿勢で）「すまん、俺に非同期処理とやらを教えてくれ」と頼み込んだんだ。

リーダーはニヤリと笑って、ホワイトボードに図を描き始めた。

「Koji、お前が知ってる『キュー』ってのは、多分これだ」

そう言って彼が描いたのは、RabbitMQとかAzure Service Busみたいな、いわゆる「メッセージキュー（MQ）」の仕組みだった。

  1. **Producer（生産者）**がメッセージ（仕事）をキュー（箱）に入れる。
  2. **Consumer（消費者）**がキューからメッセージを1個取り出す。
  3. Consumerがその仕事を処理する。
  4. 処理が終わったら、メッセージはキューから削除される。

「これ、シンプルだろ？ 仕事が来たら、空いてるヤツが処理する。FIFO（ファーストイン・ファーストアウト）が基本だ。お前のWPFアプリからの『在庫使ったよ』リクエストも、今まではこれに近い仕組みで処理してた」

俺はうなずいた。「分かりやすいっすね。で、問題は？」

「問題は、**『処理が終わったら、メッセージは削除される』**ってとこだ」

リーダーは続けた。

「いいか、Koji。さっきの在庫計算の例で、もし『在庫を1個引く』っていう計算ロジック自体にバグがあったらどうなる？」

俺：「え…？ バグを修正して、再デプロイしますけど…」

リーダー：「だよな。でも、バグってた間に処理されちまった過去のメッセージは、もうキューから消えてる。 在庫の『現在値』は、もうグチャグチャだ。復旧するには？ DBの全トランザクションログを漁るか？ 悪夢だろ？」

ゾッとした。確かに、そうだ。

「じゃあ、どうするんですか？」

「そこでKafkaだ」

リーダーは、さっきの図を全部消して、まったく違う図を描き始めた。

「Kafkaは、厳密には『キュー』じゃない。**『永続的なログ（記録台帳）』**だ」

彼が描いたのは、銀行の取引台帳や、船の航海日誌みたいなイメージだった。

  1. **Producer（WPFアプリからのAPIとか）**が、「イベント（出来事）」をKafkaに送る。
    • 例：「（時刻A）部品Aを1個使用」
    • 例：「（時刻B）部品Bを10個入荷」
    • 例：「（時刻C）部品Aを5個使用」
  2. Kafkaは、そのイベントを受け取った順番通りに、ログ（台帳）に追記していく。
  3. 重要なのはここ。このログは、誰かが読んでも消えない。
  4. **Consumer（バックグラウンド・ワーカー）**は、このログを「読む」。
    • Consumer A（在庫計算係）：「フムフム、『部品Aを1個使用』だな。DBの在庫を… 99… っと」
    • Consumer B（BIダッシュボード係）：「お、『部品Aを使用』イベントが来たな。今日の使用量グラフを更新しとこ」
    • Consumer C（監査ログ係）：「『部品Aを使用』… 記録しとこ」

「分かるか？ Koji。Kafkaのすごいところは、『一つの出来事（イベント）』を、関係するヤツらが全員、好きなタイミングで読めることだ。データはKafkaに一元化されてる」

俺は、だんだん分かってきた。

「なるほど… じゃあ、さっきの『計算ロジックにバグがあった』場合は？」

「いい質問だ」とリーダーは笑った。

「その場合、まずバグを修正した新しいConsumer D（新・在庫計算係）を用意する。そして、そいつにこう命令するんだ」

「おい、お前はKafkaのログを、一番最初（0番地）から全部読み直せ」

「えっ、そんなことできるんですか！？」

「できる。それがKafkaが『台帳』と呼ばれる理由だ。Consumer Dは、過去の『部品Aを1個使用』『部品Bを10個入荷』…っていう全イベントを、正しい（バグ修正後の）ロジックで最初から全部再計算していく。

時間はかかるかもしれんが、終わる頃には？ **100%正確な『現在の在庫数』**が、DB上に再構築されてる。過去のメッセージが消えてないから、これができるんだ」

これが、俺がお題で出したかったフックの一つ、**「集計メトリクスの再計算（Re-calculating aggregated metrics）」**の正体だ。

在庫数の集計、ユーザーごとの月間アクティビティ集計… そういう「積み上げ式」のデータがバグった時、Kafkaなら「ゼロからやり直せる」強さがある。

この「やり直し」の威力、もう一つ、WPFエンジニアにもっと身近な例で話そう。

お題のフックにあった**「ユーザープロファイルの再インデックス（Re-indexing user profiles）」**だ。

想像してみてくれ。

君のWPFアプリに、社内ユーザーを検索する機能があるとする。

ユーザーが自分のプロファイル（名前、部署、電話番号）をWPFアプリで更新する。

  1. WPFアプリ：「『Koji』が部署を『開発部』から『R&D』に変更したよ」とAPIを叩く。
  2. APIサーバー：「OK！」と、その「UserUpdated」イベントをKafkaに投げる。
  3. 裏側では、2つのConsumerが待機してる。
    • Consumer A（DB係）：「UserUpdated」イベントを読んで、メインのSQLデータベースを更新する。（これは必須）
    • Consumer B（検索係）：同じ「UserUpdated」イベントを読んで、検索用のインデックス（Elasticsearchとか）を更新する。

これで、WPFアプリから検索しても、DBの生データを見ても、常に情報は最新… のはずだった。

ある日、マネージャーが青い顔でやってきた。

「Koji！ 検索機能がバグってる！ 俺の部署、昨日『R&D』に変えたのに、検索結果だとまだ『開発部』のままだぞ！ しかも、俺だけじゃなくて、ここ数日プロフ変更したヤツ全員だ！」

君は冷や汗をかく。

調べると、Consumer B（検索係）にバグがあり、ここ3日間、インデックスの更新に失敗し続けていたことが判明した。メインのDBは正しいのに、検索だけが古い。

さあ、どうする？

もしこれが「伝統的なキュー」だったら？

Consumer Bが処理に失敗した（あるいはバグでスルーした）「UserUpdated」メッセージは、もうこの世から消えている。

復旧するには？ DBとElasticsearchの全データを比較して、差分を洗い出して、手動（あるいは地獄のバッチ）でインデックスを更新するしかない。考えただけで吐きそうだ。

でも、俺たちのバックエンドはKafkaだ。

慌てる必要はない。

  1. まず、Consumer Bのバグを修正する。
  2. 修正版のConsumer Bをデプロイする。
  3. そして、そいつにこう命令する。「お前の『読み込み位置（オフセット）』を、3日前のログまで巻き戻せ。そこから全部、もう一回読み直してインデックスを作り直せ」

Consumer Bは「へい、合点！」と、過去3日分の「UserUpdated」イベント（「Kojiが部署変更」「Satoが電話番号変更」…）を怒涛の勢いで読み込み直し、正しいロジックでElasticsearchを更新していく。

数分後、マネージャーの検索結果も正しく「R&D」に更新された。

これが、Kafkaの「イベント・リプレイ（Event Replay）」、”時間を巻き戻す”能力だ。

で、この話をWPFエンジニアの俺が知ってて、何の「得」があるのか？

「それ、バックエンドの人の仕事でしょ？」って思う？

大アリだ。

この「バックエンドは非同期で、最悪『巻き戻し』が効く」って事実を知ってると、俺たちクライアントサイド（WPF）のUI/UXの設計思想が、根本から変わるんだ。

例えば、ユーザーがプロファイルを変更して「保存」ボタンを押した時。

Kafkaの仕組みを知らないエンジニアは、APIが「OK」って返してきたら、何も考えずに「保存しました！」ってトーストを出すだろう。

でも、その直後にユーザーが検索して「あれ？変わってねえぞ！」ってクレームになる（俺がやらかしたヤツだ）。

でも、今の俺ならこう設計する。

APIが「OK（＝Kafkaにイベント投げたよ）」って返してきたら、画面にはこう出す。

「更新リクエストを受け付けました。システム全体に反映されるまで、最大で数分かかる場合があります」

これだよ！

これは「逃げ」の注釈じゃない。「システムの実態」を正確にユーザーに伝える、誠実なUI/UXだ。

ユーザーは「OK、ちょっと待てばいいんだな」と納得する。クレームは、発生しない。

さらに、SignalRみたいなリアルタイム通信と組み合わせれば、

  1. API：「受け付けたよ（JobID: 123）」と返す。
  2. WPF：「処理中…」とスピナーを出す。
  3. 裏でConsumer A (DB係) と Consumer B (検索係) が仕事を終える。
  4. 全員の仕事完了を監視してる別のヤツが、「JobID: 123 完了！」ってイベントをSignalR経由でWPFにプッシュする。
  5. WPF：「更新が完了しました！」とトーストを出す。

どう？

これ、めちゃくちゃ「分かってる」エンジニアの仕事だと思わないか？

WPFエンジニアだからって、WPFのことだけ知ってればいい時代は終わったんだ。

俺たちの仕事は、ピカピカの画面を作ることじゃない。「裏側の複雑な仕組み」をユーザーに意識させず、いかに快適な体験（UX）に翻訳するかだ。

そのためには、Kafkaみたいなバックエンドの「常識」を越境して学んでおくことが、海外の現場で「こいつ、使えるな」と一目置かれるための、最強の「人生術」なんだよ。

…と、まあ、ここまでが「概念」の話。

「理屈は分かった。でも、Koji、お前WPFエンジニアだろ？ どうやってKafkaと『会話』するんだよ？ C#でどう書くんだ？」

って声が聞こえてきそうだ。

OK、分かった。

次の「転」では、いよいよ禁断の（？）デモコードだ。

WPFエンジニアの俺が、C#を使って、超シンプルなKafkaの「Producer（イベント投げる側）」と「Consumer（イベント読む側）」をライブコーディング風に解説してやる。

これで君も、今日から「Kafka、ちょっと分かるぜ？」って言えるようになるはずだ。

C#でKafkaを”喋る”！ 爆速ライブコーディング（WPFエンジニアの流儀）

「承」で、Kafkaが「消えないログ（台帳）」であり、「時間を巻き戻して」イベントを再処理できるっていう、バックエンドの魔法について語った。

あの話を聞いて、俺は「すげえ！」と思うと同時に、こう思ったんだ。

「…で、それ、どうやってC#から叩くの？」

WPFエンジニア（というか、C#大好きマン）としては、結局のところ「コードで書けないものは信じない」タチでね。

バックエンドのリーダーに「C#でKafka触るライブラリとかあるんすか？」って聞いたら、「おう、Confluent（コンフルエント）のクライアント使え。それがデファクトスタンダードだ」と教えてくれた。

よし、やってやろうじゃねえか。

今日は、俺たちWPFエンジニアが、C#を使ってKafkaと「会話」する方法を、ライブコーディング風に解説する。

これを読めば、「ああ、KafkaってC#から見ると、ただの『C#のライブラリ（Nuget）』じゃん」ってことが分かるはずだ。

準備：ローカルにKafkaを”飼う”

まず、練習相手のKafkaがいないと始まらない。

「え、サーバー立てるの？ 無理」って思うだろ？

大丈夫。今どきはDockerがある。

詳しい説明は省くけど、docker-compose.yml っていう設定ファイルに数行書くだけで、自分のPC（Windows）上で、一瞬でKafka環境が起動する。

俺がテストで使ってる、最小限のdocker-compose.ymlを置いとく。

YAML

version: '3'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
  kafka:
    image: confluentinc/cp-kafka:latest
    depends_on:
      - zookeeper
    ports:
      - "9092:9092" # PCの9092ポートをKafkaに
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_CREATE_TOPICS: "user-profile-updates:1:1" # お試し用トピック

これをdocker-compose.ymlって名前で保存して、そのフォルダでdocker-compose up -dってコマンド一発。

はい、お疲れ様でした。君のPCのlocalhost:9092で、もうKafkaが動いてる。

（※別途Docker Desktopのインストールは必要だぜ！）

その1：Producer (イベントを投げるヤツ) をC#で書く

まずは「イベントを投げる側」＝Producerだ。

これは、例えばWPFアプリの「保存」ボタンが押された時に、裏で動くAPIサーバーが実行するコード、みたいなイメージだな。

Visual Studioで、普通の「コンソールアプリ (.NET Core)」を一個作る。

Nugetパッケージマネージャーで、Confluent.Kafka をインストール。これだけ。

じゃあ、コードだ。

C#

using Confluent.Kafka;
using System;
using System.Threading.Tasks;

// Producer（イベント投げるヤツ）
class Program
{
    static async Task Main(string[] args)
    {
        // 1. Kafkaサーバーの「住所」を指定
        var config = new ProducerConfig { BootstrapServers = "localhost:9092" };

        // 2. Producerを組み立てる
        //    <Null, string> は「キーは無いけど、値はstring」って意味
        using (var p = new ProducerBuilder<Null, string>(config).Build())
        {
            try
            {
                // 3. 実際にイベントを "投げる"
                //    'user-profile-updates' という名前の台帳（Topic）に、
                //    「Kojiがプロフ更新したよ」ってメッセージを書き込む
                var dr = await p.ProduceAsync("user-profile-updates",
                                              new Message<Null, string> { Value = "User 'Koji' updated profile to 'R&D'" });

                Console.WriteLine($"イベント送信完了！ [台帳の {dr.Partition}番地, {dr.Offset}番目 に書き込んだよ]");
            }
            catch (ProduceException<Null, string> e)
            {
                Console.WriteLine($"やべ、送信失敗: {e.Error.Reason}");
            }
        }
    }
}

どう？

拍子抜けするほどシンプルだろ？

  1. ProducerConfig: Kafkaサーバーのアドレス（localhost:9092）を指定する。
  2. ProducerBuilder: 設定を元にProducerインスタンスを作る。
  3. ProduceAsync: これが心臓部。「どの台帳（Topic）に」「どんなメッセージ（Value）」を送るか指定して、非同期で送信！

これだけ。たったこれだけのコードで、君のC#アプリは、さっきDockerで立てたKafkaに「Kojiがプロフ更新したぜ」っていう**”消えない事実”**を刻み込むことができたんだ。

その2：Consumer (イベントを読むヤツ) をC#で書く

さて、投げっぱなしじゃ意味がない。

今度は「イベントを読む側」＝Consumerだ。これが「在庫計算係」とか「検索インデックス係」になる、バックグラウンド・ワーカーの本体だ。

同じソリューションに、もう一個コンソールアプリを追加しよう。

もちろん、Confluent.Kafka をNugetでインストールする。

C#

using Confluent.Kafka;
using System;
using System.Threading;

// Consumer（イベント読むヤツ）
class Program
{
    static void Main(string[] args)
    {
        var config = new ConsumerConfig
        {
            BootstrapServers = "localhost:9092",

            // 4.【最重要】"俺たち、誰よ？" を名乗る
            GroupId = "search-indexer-group", // 俺は「検索インデックス係」グループだ

            // 5. 台帳を最初から読むか、最新から読むか
            AutoOffsetReset = AutoOffsetReset.Earliest // とりあえず最初から全部読む
        };

        using (var c = new ConsumerBuilder<Ignore, string>(config).Build())
        {
            // 6. 'user-profile-updates' という台帳（Topic）を "購読" する
            c.Subscribe("user-profile-updates");

            var cts = new CancellationTokenSource();
            Console.CancelKeyPress += (_, e) => {
                e.Cancel = true; // Ctrl+Cで優雅に終了
                cts.Cancel();
            };

            Console.WriteLine("イベント待機中... (Ctrl+C で終了)");

            try
            V            {
                // 7. 無限ループでKafkaからの通知を "待つ"
                while (true)
                {
                    // Kafkaからイベントが来るまで、ここで待機
                    var cr = c.Consume(cts.Token);

                    // イベントが来た！
                    Console.WriteLine($"[検索インデックス係] 仕事きたぞ！: '{cr.Message.Value}'");
                    
                    // (本当はここで、Elasticsearchに書き込む処理とかをする)
                    // (処理が終わったら、Kafkaに「ここまで読んだよ」と自動でコミットされる)
                }
            }
            catch (OperationCanceledException)
            {
                // Ctrl+C が押された
                c.Close();
                Console.WriteLine("Consumer、終了します。");
            }
        }
    }
}

こっちもシンプルだ。

大事なのは ConsumerConfig の中身だ。

  1. GroupId: これが「承」で話した「魔法」の正体だ。
    • GroupId = "search-indexer-group" と名乗ることで、Kafkaは「ああ、君は『検索インデックス係』ね。OK、君が『どこまで読んだか』を俺が覚えておくよ（＝オフセット管理）」と認識してくれる。
    • もし、もう一つ別のGroupId = "stock-calculator-group" を持つConsumerを起動したら？ そいつは、「検索インデックス係」とは無関係に、同じログを最初から（あるいは最新から）読み始めることができる。
  2. AutoOffsetReset = AutoOffsetReset.Earliest: もしKafkaに「君たち（search-indexer-group）が読んだ記録」がまだ無い場合、どこから読み始めるか。Earliestなら「台帳の一番最初から」、Latestなら「今この瞬間に届いた、最新のイベントから」だ。

あとは、c.Subscribe(“topic-name”) で購読を宣言して、while(true) ループの中で c.Consume() を呼ぶだけ。

Consume() は、新しいイベントがKafkaに来るまで、プログラムの実行を「一時停止」してくれる。そして、イベントが来たら（さっきのProducerアプリを起動したら！）、処理が再開して、メッセージ（cr.Message.Value）が手に入る。

やってみよう！

  1. docker-compose up -d でKafkaを起動。
  2. Consumerアプリを先に起動する。「イベント待機中…」と表示される。
  3. Producerアプリを（何回か）起動する。
  4. Consumerアプリのコンソールに、起動した回数分「仕事きたぞ！」って表示されるはずだ！

どうだ？

WPFエンジニアの君が、「イベントを投げる側」と「非同期でそれを受け取って処理する側」を、両方ともC#で書けた瞬間だ。

「承」で話した「時間を巻き戻す」っていうのは、どうやるのかって？

簡単だ。

Consumerアプリのバグを修正したとする。

そしたら、Kafkaが用意してるコマンドラインツール（kafka-consumer-groups.sh とか）を使って、Kafkaサーバーにこう命令するんだ。

「おい！ 『search-indexer-group』 の読み込み位置（オフセット）を、一番最初の『Earliest』にリセットしろ！」

これだけ。

次に俺たちのC# Consumerアプリを（コードは一切変えずに）起動すると、Kafkaが「お、お前ら、最初から読み直せって命令が出てるぞ」と、台帳に記録されてる全イベントを、もう一度最初から全部流し込んでくれる。

これが、お題のフックにあった**「特定イベントの再処理（Re-processing specific events）」**の、一番シンプルで強力な実現方法だ。

（※「特定のイベント”だけ”」を再処理するのは、本当はもっと高度なテクニックが要るけど、基本はまず「全部やり直す」だ）

C#で書いたコードは、結局のところ「ラッパー」に過ぎない。

でも、この20〜30行のコードを書けるかどうか、裏側でKafkaとGroupIdが何をしてくれてるかを知ってるかどうかが、「ただのWFPer」と「システム全体を分かってるエンジニア」の、決定的な境界線になるんだ。

この知識（コード）を手に入れた俺は、もうバックエンドチームに「APIが〜」なんて文句を言うだけのUIエンジニアじゃなくなった。

「こっちのWPFでこういうUX（例：更新中スピナー）を実装したいから、バックエンド側でKafkaのこのTopicをConsumerが処理完了したら、SignalRでキックバックくれる？」

…なんていう、「越境した」会話ができるようになったんだ。

さて、この「越境」が、具体的に俺のキャリア、つまり海外での「人生」にどういう影響を与えたのか。

WPF + Kafkaっていう一見ミスマッチなスキルセットが、どうやって俺の市場価値を（比喩じゃなくマジで）ブチ上げたのか。

次の「結」で、この話の「オチ」と、君たちが今すぐ得られる「得する人生術」を、全部話そうと思う。

WPFエンジニアが”越境”した日：専門性という「武器」と「足枷」

さて、長々と俺の「失敗談」と「そこから学んだこと」に付き合ってくれて、本当にありがとう。

「起」でクソみたいなデータ不整合に頭を抱え、「承」でKafkaの「時間を巻き戻す」っていうヤバい概念を知り、「転」では実際にC#でKafkaを動かすコードまで見てきた。

で、だ。

この話を読んだ君は、きっとこう思ってるはずだ。

「わかった。Koji、お前がKafkaを学んで『得した』ってのは、結局なんだったんだ？」

「WPFエンジニアの俺が、なんでそんなバックエンドの面倒事まで知らなきゃいけねえんだよ」と。

その答えを、今から包み隠さず話そう。

俺が手に入れた「得する情報」であり「人生術」は、突き詰めると、たった二つのシンプルな事実にたどり着く。

1. 会話ができる（=信頼される）エンジニアになれた

これが、俺の「日常」を一番変えたことだ。

Kafkaをかじる前の俺は、言ってみれば「UIのことしか考えてないヤツ」だった。

不具合が起きれば「俺のWPFコードは悪くない。APIの問題だ」とチャットを投げるだけ。

アーキテクチャの会議に呼ばれても、バックエンドチームが「ここのスループットが…」「イベントソーシングが…」とか話し始めると、正直（ああ、早く終わんねえかな…）ってスマホをいじってた。

だが、Kafkaを知った今の俺は違う。

リーダーが「ここの新規機能、どう実装する？」とホワイトボードに図を書き始めたら、俺はこう切り込める。

俺：「ちょっと待った。その処理、非同期にしないとWAF（WPFアプリ）側が固まりません？ APIには即レスさせて、重い処理はKafkaのTopicに投げて、Consumer側でゆっくり処理させるべきじゃないっすか？」

俺：「あと、WPF側で『処理中』ってスピナー出すUI/UXにしたいんで、Consumerが処理完了したら、SignalRかなんかで『終わったよ』ってイベントをクライアントにプッシュする口、作れません？」

…どうだ？

WPFエンジニアが、WPFの画面（XAML）の話じゃなく、バックエンドのアーキテクチャの話をしてるんだぜ。

これができるようになった瞬間、周りの目がマジで変わった。

バックエンドの連中から「おお、Koji、お前わかってんじゃん」「Kojiがそう言うなら、UI側でUX担保してくれるんだな。OK、任せた」と、**「信頼」**が生まれた。

俺はもう「UIだけ作るヤツ」じゃない。「システム全体を理解した上で、最適なUI/UXを設計・実装できるエンジニア」として、やっと認められたんだ。

海外の現場では、「自分の担当範囲」しかやらないヤツは、マジで評価されない。

自分の専門性（WPF）を武器にしつつ、平気で隣の領土（バックエンド）に「越境」していくヤツが、一番重宝される。

Kafkaは、俺にとって、その「越境」のための最強のパスポートだったんだ。

2. 俺の「市場価値」が、ワケわからんことになった

こっちの方が、もっとゲスくて、もっと大事な話かもしれない（笑）。

「人生術」として、これ以上「得する」話はないぜ。

ある日、ふと自分のLinkedInのプロフィールを更新してみようと思った。

スキル欄に、今までは C#, WPF, .NET, MVVM … とか、まあ、ありふれたWPFエンジニアのスキルを並べてた。

そこに、俺は、一行付け加えてみたんだ。

Apache Kafka

…たったこれだけだ。

自分でも「俺、ConsumerをC#で書いただけじゃん」って、ちょっとビビりながら（笑）。

その数日後から、LinkedIn経由で来るスカウトメッセージの「質」が、劇的に変わった。

以前：「やあKoji！ 我が社で、レガシーなWPFアプリの保守をしないか？」（給料もそこそこ）

今：「拝啓Koji殿。我々は、リアルタイムの金融トレーディング・ダッシュボード（WPF）を、イベント駆動型アーキテクチャ（Kafka）で全面刷新するプロジェクトを率いる、リードエンジニアを探しています。あなたのスキルセットは、まさに我々が求めていたものです。一度、お話ししませんか？」（報酬：~~ヤバい額~~）

冗談みたいな、本当の話だ。

考えてみれば当たり前だ。

  • 「C# と WPF ができます」 … そんなエンジニア、世界中にゴマンといる。
  • 「Kafka がわかります」 … バックエンドやデータエンジニアなら、まあまあいる。

だが、

「リッチなWPFクライアントのUXと、Kafkaの非同期イベント駆動アーキテクチャを、両方理解して『ブリッジ』できるエンジニア」

…は？

…めちゃくちゃ、いなくね？

俺は、知らず知らずのうちに、市場でとんでもない「レアカード」になってたんだ。

WPF という俺の専門性は、Kafka という一見まったく関係ない知識と掛け合わさることで、「足枷（あしかせ）」… つまり「お前はUIしかできない」という呪いから解放され、**「最強の武器（他に誰も持ってないコンボ）」**に昇華したんだ。

君へ、最後のメッセージ

ここまで読んでくれてありがとう。

俺が伝えたかったのは、「今すぐKafkaを学べ」ってことだけじゃない。

（いや、学んだ方がいい。C#で書けるんだから、面白いぞ！）

俺が本当に伝えたかった「人生術」は、

「自分の専門性の”となり”にあるものを、怖がらずにつまみ食いしろ」

ってことだ。

俺たちWPFエンジニアにとって、それは Kafka だったのかもしれない。

Azure や AWS のインフラかもしれない。

Python のAI/機械学習ライブラリかもしれない。

Blazor や MAUI でWebやモバイルに越境することかもしれない。

海外でエンジニアとして生き残る、いや、「得して」生きていくコツは、それだ。

自分の「専門性」という”武器”を磨き続けるのは当然。でも、それだけじゃ「足枷」になる。

自分の専門性を、別の何かと「掛け算」して、誰も持っていない「レアカード」になること。

俺たちの戦場は、もう MainWindow.xaml.cs の中だけじゃない。

Dockerを起動しろ。Nugetで Confluent.Kafka をインストールしろ。

君のC#スキルは、君が思ってるよりも、ずっと遠くまで「越境」できるパスポートなんだぜ。

コメント

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