「WPF、まだ使ってるの？」って聞かれたそのとき、僕は笑った。
「え、まだWPF使ってるの？もう時代遅れじゃない？」
正直言うと、これ、何度も聞かれました。日本でも、海外でも。特に転職活動中、アメリカの某企業のリクルーターと話していたとき、まさにこう言われたんです。
でもその時、僕は笑ってこう返しました。
「WPFは、消えてないどころか、むしろ“隠れた現役エース”だってこと、知ってます？」
ちょっと生意気に聞こえるかもしれないけど、でもこれは僕なりの“反撃”でした。なぜなら僕は、C# × WPFの技術で、いくつものプロダクトの設計や改善に関わってきたし、その延長線上でアメリカ企業の現場にも関わる機会を得られたから。
WPFというと、もう15年以上前の技術で、今さら新しく学ぶ意味なんてあるの？と疑問に思う方も多いと思います。確かに、UIフレームワークの世界はどんどん進化していて、MAUIやBlazor、Electron、React Nativeといった技術がどんどん登場してきてますよね。
でも、実はアメリカの現場、特に**“堅い業界”——医療・製造・金融——では、WPFはいまだに超・現役**なんです。むしろ「WPFを維持・改良できる人材がいないからこそ、今こそ価値がある」っていう現実を、僕は現場でひしひしと感じました。
アメリカの企業現場で見た、WPFの“リアルな姿”
アメリカ現地のエンジニアやPMとやり取りしていて面白かったのは、WPFに対するスタンスが**“捨てたいけど、捨てられない”という複雑な愛憎入り混じった感情**だったという点です（笑）。
ある日、ミーティング中にこんな会話がありました。
「この業務システム、10年以上前にWPFで作られてて、UIのパフォーマンスは悪くないんだけど、開発者がいなくて困ってるんだよね…」
そこに僕が登場したわけです。
「え？WPF、できますよ？」
…場が一瞬、静まり返りました。
なぜなら彼らは、WPFをメインで扱っている現役エンジニアがもう周りにいないと思っていたんです。WPFを“語れる”人材は希少種になっていた。
実際に、求人サイト（たとえば Dice や Indeed US）を見てみると、「WPF + MVVM + Entity Framework」というキーワードが含まれた求人は、少数ですが高年収帯で残っているんですよね。つまり、「やれる人が少ないニッチ＝高く評価される」構図が成立しています。
だから今こそ、キャリア戦略としての“WPFリバイバル”
僕がこの記事で伝えたいのは、「WPFは古いけど、価値が終わったわけじゃない」ってことです。
むしろ、“価値の可視化が遅れているだけ”。
たとえば、アメリカでは既存システムがWPFでできていて、全面刷新なんて無理な中小企業や、業務ロジックがWPF + C#のデスクトップアプリにどっぷり組み込まれている企業が山ほどあります。
こういうところでは、新しいUI技術よりも、
- 既存のアーキテクチャを理解できる力
- MVVMやカスタムControlTemplateなど、WPFならではのUI設計知識
- レガシーとモダンの橋渡しができる発想力
が求められるんです。
僕はその“ニッチ需要”にピタリとハマったおかげで、実務の中でもどんどん声がかかるようになりました。そして今では、「WPFができる」だけでなく、「WPFからUI全体戦略を設計できる」ことが、自分の武器になっています。
WPFは“消せない”——アメリカの現場がWPFを手放せない3つの理由
1. 「UIの安定性」こそが命の業界がある
アメリカの現場で関わったプロジェクトのひとつが、医療機器の操作ソフトでした。正確には、病院で使われる診断装置のインターフェースを担当。
最初に言われた要件が、こうです：
「UIのパフォーマンスは重要じゃない。とにかく一度も落ちないこと、誤操作を防ぐことが最優先。」
WebベースのUIだと、予期せぬブラウザの動作やネットワーク遅延で不具合が出る可能性がありますが、WPFはローカルで動くため、そのリスクがほぼゼロ。
しかも、XAMLの構造が「UIとロジックをきれいに分けて書ける」MVVMと相性が良く、メンテナンス性も高い。
医療、航空、防衛産業など、「安定性」や「UIの再現性」が最重要な業界では、WPFのような堅牢なデスクトップUIが“唯一無二の選択肢”になる、というのが現場の肌感覚でした。
2. レガシー資産の規模が想像以上にデカい
次に関わったのは製造業のオートメーション制御アプリ。これもまたWPF。
ヒアリング時に言われたのは：
「このアプリ、2011年からWPFで育ててきて、いま画面数が400以上あるんだよね。全リプレイスなんて、夢のまた夢だよ（笑）」
…つまり、**「変えたくても変えられない」**んです。
しかも、UIはWPFでも、ロジックの多くがバックエンドと密結合したC#ロジックで構成されているため、UIだけを分離してWebに移植、みたいなことが簡単にはできない。
だから結局、「WPFを知っていて、かつ新しい設計思想を取り入れられる人が欲しい」となるわけです。
まさに、僕のようにMVVMや依存性注入（DI）、ReactiveUIなどを実務で回してきたエンジニアが、どんぴしゃでフィットする。
3. “Web移行”は理想だけど、予算がない現実
アメリカの中堅企業やローカル企業って、「最新技術に全面的に投資できる体力」がある企業ばかりではないんです。特にパンデミック以降、「リスクが少ないアップデート」が求められる傾向が強まってます。
現場のCTOがこんなことを言ってました：
「Angularにリプレイスしようかと検討したこともあるけど、結局ユーザー（工場スタッフ）が求めてるのは、“今と同じUIが動くこと”だったんだよね」
つまり、「UI体験を変えずに、安心して改善する」。その要望に応えられるのが、WPF × モダン設計パターンというソリューションだったんです。
その結果、「.NET 6/8に載せ換えて、パフォーマンス改善＋UIはWPF継続」みたいな形が選ばれる。
僕がそこで提案したのは、
- モジュール化されたMVVMパターン再設計
- ResourceDictionaryによるUIの再利用可能化
- メモリリーク改善のためのデバッグ手法（WPF特有）
こういった「“レガシーWPF”のままではなく、2020年代の開発者らしい整理されたWPF設計」が、現地でも大いに評価されました。
“古いけど、最新”という逆説
ここで改めて言いたいのは、WPFは単に“古いUI技術”ではなく、“現場で磨かれ続けている現役技術”だということです。
- リアルタイム性
- ローカルパフォーマンス
- 安定性と再現性
- 保守性・拡張性のバランス
これらを必要とするプロジェクトでは、今でも“WebよりWPF”の方が求められている。そして、そこには“若手のWPFエンジニア”が全然足りていない。
だから、今WPFができる人＝即戦力 × レアスキル人材として扱われている、というのが現実なんです。
それでも“WPFは時代遅れ”と思われがちなのはなぜか？
実は、技術の人気度って「開発者が好きかどうか」ではなく、「誰がその技術に魅力を語るか」に左右されがちです。
Web系は語る人が多くてコミュニティも活発。でもWPFは、昔から“真面目で静かな業務系エンジニア”が多かった。だから、魅力が語られずに誤解されてきたのかもしれません。
僕自身も、アメリカの現場でそれを実感しました。
逆に言えば、WPFをやってるエンジニアが**「ちゃんと自分の仕事や成果を言語化できれば、それは十分にアピールになる」**ってことなんです。
WPFが導いた“次のキャリア”——ニッチを極めた先に広がる世界
「WPFだけじゃ足りない」と気づいた日
アメリカの現場でWPFがまだ現役ということを肌で感じた僕ですが、それと同時に、ある種の“限界”も見えました。
それは、**「WPF＝あくまでクライアント側」**という事実。
どんなにUI設計が美しくても、どんなにMVVMパターンが洗練されていても、アプリケーションの全体アーキテクチャを考えるには、WPFだけでは足りない。
例えばこんな課題がありました：
- ユーザー情報はどこで管理する？（Azure AD？オンプレAD？）
- ログデータをクラウドに送って分析したいけど、セキュリティポリシーは？
- 他のWebベースシステムとどうつなぐ？API設計は誰がやる？
- WPFアプリからのバージョン管理やアップデート、どうする？
…そう。「WPFが得意なだけ」では、プロジェクトの中核には立てないと痛感したんです。
そして僕は、“UIアーキテクト”を目指すようになった
そこで僕がとった行動は、「WPFを出発点に、UIのその先も設計できる人」になるという方向転換でした。
つまり、WPFに閉じない知識・スキルを広げていったんです。具体的にはこんな感じ：
| 分野 | 取り組んだ内容 |
|---|---|
| クラウド連携 | Azure Functionsでログ送信、SignalRでリアルタイム通知機能の試作 |
| API設計 | ASP.NET Core + OpenAPIでWPFから呼び出すREST APIを自作 |
| DevOps/CI/CD | GitHub ActionsやAzure DevOpsでWPFの自動ビルド＆リリース |
| UI哲学 | Fluent DesignやMaterial DesignのUIガイドラインをWPFに応用 |
この取り組みを重ねていく中で、**「WPFは、UI体験設計の基礎体力をつけるには最適なトレーニングだった」**と実感するようになりました。
なぜなら、XAMLは手間がかかる分、「UIを論理的に構成する力」が育つ。そして、それはWeb UIにも、MAUIにも、Blazorにも応用可能なんです。
“WPFからの進化”が、逆にグローバルキャリアを引き寄せた
この考え方をポートフォリオやLinkedInに載せ始めてから、徐々に変化が起きました。
特に反応が良かったのが、次のようなトピックです：
- 「業務系WPFアプリにMaterial Designを取り入れて、若手のUX理解を促進」
- 「WPFアプリとクラウドのログ分析基盤を連携。非エンジニアもデータ活用できる設計へ」
- 「レガシーWPFアプリの設計思想をドキュメント化して、オフショア移管に成功」
こういう具体的な“価値提供のストーリー”が、海外の採用担当に刺さったんです。
今やUIとアーキテクチャの境界はあいまい。「UIエンジニア」は「UIアーキテクト」へと進化していく時代です。
WPFという一見“古い”技術で、でも“深く現場を知り尽くしたエンジニア”として積み上げてきた経験こそが、僕のグローバルキャリアの鍵になった。
「キャリアは“古さ”で決まらない。深さと横の広がりで決まる。」
ここまで読んでくださった方の中には、
「でも自分はまだWPFしか知らない」
「Webもクラウドもよく分からない」
そんな不安を感じてる方もいるかもしれません。
でも、僕が伝えたいのはこれ：
💡 “古い技術”でも、“時代に合わせて語れる人”は強い。
💡 “ひとつの技術”を突き詰めた先に、視野が広がる。
だからこそ、WPFは捨てるべきものではなく、“深掘りするための土台”として、むしろ今こそ活かすべきなんです。
“WPFの経験”を、次の扉を開く武器にする方法
「WPFやってます」だけじゃ伝わらない。だから、“こう”語ろう。
ここまで読んでくれたあなたならもう気づいていると思います。
WPFは、まだ使われている。しかも、ちゃんと価値がある。
でも、その価値は「WPFできます！」と言うだけじゃ、海外では伝わらないんです。
なぜなら、WPFという単語だけでは、
- 技術が古いという誤解
- Webやモバイルと切り離されているイメージ
- UIは“見た目だけ”と思われがちな立ち位置
…こうした「伝わりにくさの壁」にぶつかるから。
だからこそ僕は、WPFの経験を“現代的な価値”に変換して語ることを意識するようにしました。
たとえばこんな風に：
| × よくある言い方 | 〇 伝わる言い方 |
|---|---|
| 「WPF開発してました」 | 「業務アプリのUI設計・UX改善にWPF＋MVVMで貢献しました」 |
| 「画面数が多いアプリを担当」 | 「400画面を再設計。共通テンプレート化で保守性を50％改善」 |
| 「デスクトップアプリを維持」 | 「クラウド連携を導入し、オンプレ中心のWPF資産を段階的にモダナイズ」 |
つまり、「技術名」ではなく「どう価値を出したか」を語ることが、特にグローバルな転職市場では重要なんです。
英語レジュメ＆ポートフォリオでは“戦略的にWPFを見せる”
ここで、海外で通用するために僕が実践してきたレジュメ＆ポートフォリオのコツを紹介します。
✅ 英語レジュメでのWPFの書き方（例）
UI Architect / Senior Software Engineer
- Led modernization of a WPF-based manufacturing control system used in 3+ factories.
- Applied MVVM, DI (Dependency Injection), and custom ControlTemplate patterns.
- Migrated legacy .NET Framework to .NET 6 with improved UI performance (30%).
- Introduced logging and error tracking via Azure Application Insights.
ここでは「WPF」だけじゃなく、「モダナイズした」「UIのパフォーマンス改善をリードした」といった実行内容＋成果を明示します。
✅ 英語ポートフォリオでは…
- Before/AfterのUI比較スクリーンショット（※顧客情報は隠す）
- WPFの設計思想（MVVM、DI、DataTemplateの使い方）を解説した図
- GitHubには簡易アプリを公開し、READMEで「課題 → 解決方法」をストーリー化
さらに、海外のフォーラム（Reddit / Stack Overflow / DEV.to）で自分の設計の考え方を英語で発信していくと、意外と「WPFやってるの？話を聞かせて！」という声がかかるようになります。
「英語が苦手…」でも大丈夫。まずは“テンプレ化”から始めよう
僕も最初は、英語で技術の説明をするのが怖かったです。
でも、「実務でやってきたことを、パターン化して書く」ことで、少しずつ慣れていきました。
たとえば以下のような“言い換えテンプレ”を持っておくと便利です：
| 日本語でやったこと | 英語での書き方テンプレ |
|---|---|
| 画面の共通化をした | Consolidated UI layouts using reusable templates for consistent UX |
| 旧.NETから新.NETへ移行 | Migrated legacy .NET Framework project to modern .NET Core/.NET 6 |
| 開発チームにUI設計ガイドを導入 | Introduced a UI design guideline to unify component structure among teams |
英語に自信がなくても、こういうフレーズを使えば最低限は伝わるし、何より「行動と成果が明確」なのが評価されます。
WPFは“過去の技術”ではない。未来につながる“入り口”だ。
正直、WPFだけを続けていくのはリスクもあります。MAUIやBlazor、Webやクロスプラットフォーム技術の波は確実に押し寄せてきます。
でも、WPFを「終わった技術」と切り捨てるのではなく、
- UIの本質を理解するための修行場
- ロジックとUIを分離する設計の基礎
- モダナイズの出発点
と捉えれば、これほど実戦的な経験は他にないと思っています。
僕自身、WPFを土台にして今はMAUIやWeb UI、クラウド連携まで視野を広げていますが、あのWPFでの経験がなければ、UIアーキテクト的な視点を持つことはできなかったでしょう。
最後に──あなたのWPFキャリアが、世界を広げる。
このシリーズのテーマは「WPFの今と未来」。
確かに、流行りではない。
でも、まだ必要とされている。
そして、きちんと使いこなせば、“次のキャリア”の強力な武器になる。
WPFの経験を過小評価せず、それを言語化し、発信し、つなげていく。
それこそが、ニッチを武器にするキャリアデザイン。
あなたのそのWPFの知識は、国内だけじゃなく、世界のどこかで誰かが待っている技術かもしれません。
コメント