- 「WPFの次」を考え始めた日、僕が立ち止まった理由
- WPFから“次”へ橋渡しするために、僕がやった具体的なこと
- まとめ｜“過去の技術”は、次のステージへの足場になる
- 選択肢が増えた時代に、“選べる人”になるという戦略
- まとめ｜“選ぶ力”は、キャリアの自由度を最大化する
- WPFの延長線で、未来をデザインする方法
- まとめ｜WPFは、終わりじゃない。むしろ始まりだった。
「WPFの次」を考え始めた日、僕が立ち止まった理由
“WPFエンジニアの限界”を感じたあの日
ある朝、Slackに一通のメッセージが届いた。
内容はこうだった。
“We’re planning to rewrite our internal desktop tools as cross-platform apps. Can you join the discussion?”
そのとき、心の中でザワついた。
「……ついに来たか」
と同時に、僕の中で「WPFだけじゃ通用しなくなる時代」がリアルに見え始めた瞬間だった。
10年やってきたWPF。それでも焦った理由
WPFという技術は、僕に多くのことを教えてくれた。
- UI/UXの奥深さ
- クリーンアーキテクチャの重要性
- データバインディングの巧みさ
- ユーザー目線の設計とは何か
それらの知識と経験は、間違いなく“UIエンジニアとしての基礎体力”を鍛えてくれた。
でも、ふと冷静に見てみると、
- モバイルに展開できない
- macOSで動かせない
- ストア配布に向かない
- Webとの親和性が低い
──というように、“囲われた世界”の技術でもある。
僕の中で初めて、「このままだと、通じない現場も出てくるかもしれない」という不安が芽生えた。
でも、“乗り換える”のではなく“繋げる”という選択肢
この時点で、選択肢は2つあった。
1. 思い切ってWPFをやめて、完全にWebやモバイルにシフトするか？
2. WPFで得たUI設計スキルを、次の技術に“橋渡し”する形で広げるか？
僕が選んだのは後者だった。
なぜなら、10年積み上げたスキルを**「捨てる」んじゃなくて「活かす」方向に持っていきたかった**からだ。
“WPFの次”はどれか？技術選定で悩んだ日々
そこで出てくるのが、次のような選択肢たち：
| 技術名 | 特徴 | WPFとの親和性 |
|---|---|---|
| .NET MAUI | クロスプラットフォームでC#だけでiOS/Android/Windows/macOS開発可 | XAMLベースで構造が似ている |
| Blazor | Web UIをC#で開発（Razor構文）、WebAssembly対応も | UIの構成思想がMVVMに似ている |
| Uno Platform | WPF/XAMLに近いUIをWebやモバイルへ展開できる | XAML資産がそのまま活かせる |
| Avalonia UI | クロスプラットフォームのWPFクローン的存在 | 完全なWPFライクUI構築が可能 |
| Electron.NET | Web技術でのデスクトップアプリ構築、でも.NETで制御可能 | Webスキルは必要、でもC#ベースで書ける |
どれも魅力的だったし、それぞれに“未来”を感じた。
MAUIを最初に触ってみた理由
最初に僕が触ってみたのは**.NET MAUI**だった。理由は単純。
「XAMLが使えるから、慣れてる」
実際にいくつかサンプルアプリを作ってみたけど、以下のような感想を持った。
✅ MAUIの良かった点：
- XAMLがほぼWPFそのままに近い（学習コストが少ない）
- C#だけでAndroid/iOSアプリが作れる感動
- MVVMパターンがそのまま応用できる
- Community Toolkitなどで便利機能がそろっている
🤔 難しかった点：
- ビルドが重くてデバッグがややストレス
- デバイス依存のレイアウト調整が必要
- プラットフォームごとに細かな挙動の違いがある
でもそれでも、「あ、これはWPFエンジニアにとっての“自然な進化先”だな」と感じた。
Blazorを試して感じた“WebとC#の未来”
次に試したのはBlazor。
WebAssemblyベースで、**“HTML + C#”**というスタイル。
XAMLではないけど、コードビハインド的な書き方やコンポーネント思想はMVVMに近い。
驚いたのは、JavaScriptを書かずにSPA（Single Page Application）が作れたこと。
UI設計も、状態管理（State Management）も、DIも、全部C#で完結する。
これは、長年C#でやってきた自分にとって、「Webの世界の入り口」としてちょうど良かった。
“次の選択肢”を選ぶ前に考えておくべき3つの視点
ここで焦って乗り換える前に、僕は自分にこう問いかけた。
- 自分がどの分野で価値を発揮したいか？
→ エンタープライズ？B2C？IoT？医療？ゲーム？ - UIスキルをどう“再利用”できるか？
→ 単にコードが書けるだけじゃなくて、UX設計・状態管理・レイアウト設計など - “新技術を学ぶこと”が目的になってないか？
→ 学ぶこと自体が目的化すると、結局「使える技術」にならない
まとめ｜“WPF卒業”じゃなくて“WPF継承”という考え方
WPFという技術を単に「古いからやめる」のではなく、
「自分の強みとして引き継ぎながら、どこへ広げていくか」を考えるのが大事だと感じた。
そして、MAUI・Blazor・Uno・Avaloniaなど、
今の.NETには**“WPFのその先を選べるルート”が複数ある。**
これは、WPFエンジニアにとって“今”が一番面白い時期なんじゃないか？
そんな風にも思えてきた。
WPFから“次”へ橋渡しするために、僕がやった具体的なこと
海外現場で“選ばれた技術”はMAUIだった
僕が参加したある北欧企業の案件。
医療機器の操作用UIを作るというプロジェクトだったが、
要件に次のようなものが含まれていた。
- iPadで使えること（タッチ前提）
- Windows PCでも同じ操作感で動作すること
- オフラインでも一部機能は利用可能
- 英語／ドイツ語／フィンランド語対応（ローカライズ）
こうなると、従来のWPFオンリーでは難しい。
でも、Webだけでもリスクがある（院内ネットが不安定）。
そこで提案されたのが、.NET MAUIだった。
これが、僕にとって“初めて実務で使うMAUI案件”になった。
WPF経験が活きた！MAUIプロジェクトでの役割
最初は「MAUI？よく知らないけど…」という感じだったが、
プロジェクトが始まってすぐにこう言われた。
“Your experience with WPF MVVM is exactly what we need. Can you lead the UI structure?”
──驚いた。
Webやモバイルの経験が浅くても、WPFで培った設計力が買われたのだ。
具体的にはこんな役割を任された：
- MVVMベースのプロジェクト構造を定義（ViewModelファースト設計）
- XAMLのスタイル・リソース設計（テーマ切替／アクセシビリティ対応）
- Platform-Specific Serviceの切り替え提案（iOSとWindowsの処理差）
- DataTemplateSelectorやConverterの再設計（WPF由来のテク）
WPFで当たり前にやっていたことが、そのままMAUIの品質向上に繋がった。
MAUIで“つまずいた”ところも正直に書く
もちろん、全てがスムーズにいったわけではない。
WPFと違ってMAUIでは戸惑った点も多かった。
❌ 困ったポイント：
- デバッグ環境が重い＆不安定
→ Android Emulator、iOS Simulatorの起動が長い。ちょっとコード変えただけでビルド再実行…。 - レイアウトが機種依存でずれやすい
→ GridやStackLayoutは、画面サイズによって微妙に崩れる。 - XAMLの制限・差異
→ WPFで使っていたTrigger系が一部使えない or 替えが必要。DataTriggerが効かない場面も。 - Documentationの情報がまだ少ない
→ 新しい技術ゆえに、StackOverflowでも解決が難しい場面があった。
でも、逆にこの苦労が、WPFから学んだ応用力を活かす場面にもなった。
たとえば：
- デバッグに時間がかかる → MVVMベースでロジックだけUnit Testを分離
- レイアウト崩れ → 自作のResponsive Layout Helperを導入
- Triggerが使えない → カスタムAttached Behaviorで補完
WPFで「こうやって工夫してきた」という引き出しが、ここでも活きた。
Blazorは“Webの入り口”として最高だった
別の機会に、Blazor WebAssemblyで作る管理画面案件にも参加した。
ここでは、React経験者と一緒に作業する機会があり、こんな会話があった。
React Dev：「なんでJavaScript使わずにWebアプリ作れるの？」
僕：「C#でUIロジックも書けるんだ。しかもDIやStateContainerも使えるよ」
React Dev：「…それ、ちょっとすごくない？」
──Blazorは、“WPFの構文感覚を持ったまま、Webに進出できる”技術だった。
HTML＋C#＋Razorという構成に最初は戸惑ったが、
- Component分割
- イベントバインディング（
@onclick,@bind-Value） - Stateの管理と再レンダリング
などが、MVVMのViewModelと似た構造で作れる。
WPF→MAUI／Blazorに必要だったスキルマップ
ここで、僕が意識した「スキル橋渡しマップ」を共有する。
| WPFスキル | MAUIに対応する知識 | Blazorに対応する知識 |
|---|---|---|
| XAML設計 | MAUIのXAML + ResourceDictionary | Razor構文（HTML＋C#混在） |
| MVVMパターン | ViewModel + DI（CommunityToolkit.MVVM） | コンポーネント構成 + Cascading Parameter |
| データバインディング | {Binding}構文・Converterも同様 | @bind + EventCallback |
| UI設計 | Platform-specific customization | Responsive Web Designの知識 |
| カスタムコントロール | Handler・Effectの作り方 | 再利用可能なComponent設計 |
このように、“WPF→MAUI/Blazor”はスライド的に移行可能だった。
ただし、UIレンダリング方式・デプロイ方法・プラットフォーム固有制約の理解は新たに必要だった。
案件ごとに“どの技術が最適か”を選べる力を持つ
最後に、僕が得た最大の気づきはこれだった。
技術を“選べる側”に回れるようになることが、最強のキャリア設計だ。
WPFを捨てるんじゃない。
WPFから派生したスキルを元に、
- モバイル（MAUI）
- Web（Blazor）
- ハイブリッド（Uno, Avalonia）
といった選択肢を現場に応じて選べるようになった。
まとめ｜“過去の技術”は、次のステージへの足場になる
- WPFからMAUI・Blazorへの移行は、技術転換ではなくスキル継承
- 10年積み重ねた設計力・構文知識・UI哲学は、次の技術でも活きる
- “学び直し”ではなく“応用力”が鍵
- 新技術に詳しくなるより、新技術をどう活かせるか？を語れる力が重要
選択肢が増えた時代に、“選べる人”になるという戦略
MAUIとBlazor、実際に使って感じた“決定的な違い”
MAUIとBlazor。
どちらも「C#でUIを書く」ことができる。
どちらも.NETエンジニアにとって“次の選択肢”として魅力的。
でも、現場で使うと、その思想の違いが明確に見えてくる。
MAUIの本質：
→ ネイティブアプリを.NETで作ること
→ iOS／Android／macOS／Windowsに一つのコードベースで対応する
Blazorの本質：
→ Webアプリを.NETで作ること
→ ブラウザ上で動作するSPA（Single Page Application）に対応
この違いは、「誰に」「何のために」届けるアプリか？によって大きく影響する。
MAUIの強みは「オフライン＆デバイス密着」
MAUIを選んだ方が良いと実感したのは、こんな現場：
- 製造業で、現場タブレット上でQRコードを読み取る
- ネット環境が不安定でも、ローカルに保存しておける必要がある
- バッテリーの関係で、リソース消費は最小限にしたい
WPFエンジニアの僕にとって、MAUIはWPFの感覚をモバイルに持ち込める感覚だった。
特に、XAMLとMVVMがそのまま活きるのは本当にありがたかった。
<!-- MAUIでもこう書ける -->
<Entry Text="{Binding ProductCode}" Placeholder="Enter Code" />
<Button Text="Scan" Command="{Binding ScanCommand}" />
この“構文の互換性”があることで、心理的・技術的ハードルが非常に低い。
Blazorの強みは「デプロイのしやすさ＆コスト効率」
一方で、Blazorが選ばれた案件ではこういう条件が多かった：
- 内部管理ツールの刷新（SaaS連携あり）
- Web経由でどこからでもアクセス可能にしたい
- スマホでもブラウザで最低限動けばOK
- 社内ユーザーなので、UIの高度さより“早さと保守性”重視
特に印象的だったのは、“インストール不要”の圧倒的な楽さ。
.NETアプリなのに、ユーザーには「URLを送るだけ」で済む。
<!-- Blazorでのバインディング -->
<InputText @bind-Value="UserName" />
<button @onclick="Submit">Submit</button>
WPFのような複雑なバインディングは少ないけど、
ビジネスロジックとUIの分離構造は、WPFの経験があれば理解しやすい。
技術選定の基準：僕が実務で使っている3つの質問
選択肢が多くなればなるほど、選ぶ判断基準が大切になる。
僕がいつも使っているのは、次の3つの質問：
❶「そのアプリ、ネットに常時つながってる必要ある？」
→ YESならBlazorでOK。
→ NOならMAUIやデスクトップ系の方が安心。
❷「そのUI、どのくらい“リッチ”にしたい？」
→ ドラッグ＆ドロップ、リアルタイムUI更新が必要ならMAUIかWPF。
→ フォーム入力やCRUD中心ならBlazorで十分。
❸「デプロイと保守、どれだけ簡単にしたい？」
→ PCがバラバラな環境、ITリテラシー低いユーザーが多いならBlazor。
→ 統制されたデバイスでの展開（社内タブレットなど）ならMAUIでも問題なし。
“第三の道”として見つけた：AvaloniaとUno Platform
選択肢はMAUIとBlazorだけではなかった。
✅ Avalonia UI：
→ 完全にWPF互換を意識したクロスプラットフォームUI。
→ Linuxでも動く。macOSもOK。
→ C# × XAMLのまま書けて、WPF移行にも最適。
<!-- AvaloniaのXAML：WPFとほぼ同じ -->
<TextBox Text="{Binding UserInput}" />
<Button Content="Go" Command="{Binding GoCommand}" />
WPFコード資産の再利用性が非常に高い。
今後、Linux対応が求められる業界では一つの答えになるかもしれない。
✅ Uno Platform：
→ UWP（Universal Windows Platform）系の技術をベースに、WebAssembly／iOS／Androidでも動く。
→ Visual Studioからそのまま複数出力できる。
→ WPFライクな構造＋Web展開も可能＝理論上、最も広く届けられるUI技術の一つ。
境界を超えるエンジニアへ：UI設計力があれば、技術は後からついてくる
僕がここまでで学んだのは、こういうことだ。
“どの技術を選ぶか”ではなく、“何を届けたいか”が先にあるべき
WPFでUI設計を10年やってきた。
だからこそ気づけた。
**「ツールが変わっても、設計思想は変わらない」**ということ。
そして今は、こういうエンジニア像を目指している。
💡 技術ではなく“意図”で選べるエンジニア
- 要件から最適な技術スタックを提案できる
- 既存資産（WPF）を活かす or 捨てる判断ができる
- 「作ること」だけでなく、「届け方」も考えられる
まとめ｜“選ぶ力”は、キャリアの自由度を最大化する
- MAUIはWPFエンジニアにとって、最も自然な進化先
- BlazorはWeb領域へ安全に移行できる踏み台
- AvaloniaやUnoは、OS横断型アプリの未来を見据えた選択肢
- 技術を渡り歩くより、目的を持って技術を選ぶ姿勢が信頼される
WPFの延長線で、未来をデザインする方法
「WPFから離れる」のではなく「WPFを拡張する」という道
ある日、海外の同僚に聞かれた。
“You’ve been working with WPF for years — don’t you think it’s time to move on?”
僕はこう答えた。
“Maybe. But I don’t think of it as ‘moving on.’ I think of it as ‘expanding from WPF.’”
この一言に、今の自分のキャリア観がすべて詰まっていた。
10年以上やってきたWPFは、
もはや“ひとつの技術”ではなく、僕にとっての“軸”だった。
「今はMAUIだ」「Webが主流だ」という声に流されずに
たしかに、トレンドを見ればWPFは“レガシー”だ。
- 求人数はWebやモバイルの方が多い
- 若手エンジニアはWPFを知らない
- 情報発信やコミュニティも縮小気味
だけど、“使われてない”わけじゃない。
むしろ、「これからも使われ続ける領域」が確実にある。
たとえば：
- 製造業や医療現場などの業務端末
- 金融やインフラ系のイントラ向けツール
- 長期運用前提のスタンドアロンアプリ
そこでは、WPFは今も現役で戦っている。
「じゃあ、そのままでいいのか？」──その問いの先に
ここで勘違いしてほしくないのは、
「WPFだけでいい」なんて全く思ってないということ。
むしろ、「今WPFをやっている人」ほど、
今こそ“その先”の可能性を意識するべきだと思う。
じゃないと、こうなる：
- WPFに閉じこもる → 案件が減る → 技術が錆びる → キャリアが詰まる
僕はこれを避けたくて、「拡張」というキーワードを選んだ。
僕がやっている“WPFエンジニアの拡張活動”
✅ 自分のUI資産をMAUIでもBlazorでも再利用できる形に変換する
→ XAMLの構造を意識して保ちつつ、StyleやTemplateはポータブルに記述する
✅ GitHubに“WPF → MAUI移行シリーズ”を投稿
→ 同じ悩みを持つエンジニアとつながれる
→ 英語で発信すれば、グローバルな評価にもつながる
✅ WPFで培った知見を“UI設計原則”として言語化
→ コントロール配置・状態管理・イベント設計など、技術を越えて共有可能
✅ “UI×業務”の知識を汎用化
→ 例：「医療業界で必要とされる入力体験とは？」など
WPF経験を“他技術と対話できる視点”に変える
たとえば：
| 技術 | WPFとの違いを語れるか？ | 強みを補完できるか？ |
|---|---|---|
| MAUI | スマホ・mac対応／PlatformHandler | オフラインUI設計力が活きる |
| Blazor | DOM操作／HTMLベースUI | State・Data管理の応用力が使える |
| React Native | JSX構文・JavaScript制御 | MVVMパターンの代替視点として話せる |
| Flutter | Dart言語／Widgetベース構成 | ツリー設計の比較知見を語れる |
こうやって、“技術間の翻訳”ができるようになると、
エンジニアとしての抽象度と市場価値が一気に上がる。
そして今、僕が目指すのは「UIアーキテクト」という次のステージ
WPFをやってきた人は、
UIの構成・設計・保守・改善というあらゆる側面に深く触れている。
それは、まさに「UIアーキテクト」に必要な要素だ。
- 技術選定（どのUI技術を使うか）
- 実装戦略（再利用・拡張・保守性）
- UXとの連携（ユーザー行動をどうUIに落とすか）
- 開発フローへの組み込み（デザイナー・PMとの調整）
WPFはそのすべてを体験できる“濃い現場”だった。
だからこそ、今後は**“ツールを使える人”から、“UIを設計できる人”へ**
というキャリアのフェーズアップを目指している。
“WPFからの拡張”が意味するもの
- 技術的な変化に対応する力
- トレンドに飲まれず、自分の判断基準を持つ力
- 既存スキルを言語化し、新しい技術とつなげる力
この3つがあれば、WPF経験は“武器”になる。
むしろ、その武器は、他の人には真似できない深さを持っている。
まとめ｜WPFは、終わりじゃない。むしろ始まりだった。
- WPFは今も現場で活躍中。特に業務・インフラ系で根強い需要あり
- MAUIやBlazorへの移行は“乗り換え”ではなく“拡張”
- WPFのXAML・MVVM・UI設計力は他技術でも応用可能
- UIアーキテクト的視点を持つと、技術横断の判断力が身につく
- “選べる人”になることが、グローバルキャリアの鍵
コメント