WPF×MAUI共存戦略：混在時代をどう設計するか

なぜ今「WPF×MAUI共存」が話題なのか？

「WPFって、もう古いんじゃないの？」
海外の現場で、こう聞かれたことが何度もある。正直ちょっとモヤっとした。たしかにUIフレームワークの世界はトレンドの移り変わりが早い。でも、「古い＝終わった」ではない。むしろ、“安定して使われ続けている”という実績そのものが武器になることも、僕の経験からはっきり言える。

でも最近、その「WPF一強」だった現場にもじわじわと変化の波が来ている。そう、**.NET MAUI（Multi-platform App UI）**の登場だ。モバイル、デスクトップ、Macまでカバーする“クロスプラットフォーム時代の新星”としてMAUIが注目されている。

「これからはMAUIが主流になる」
「WPFはレガシー、もう卒業すべき」
そんな声も増えてきた。確かに、MAUIは魅力的だ。XAML資産もあるし、C#で書けるし、Xamarinからの進化系ということで企業も興味を持っている。

でも、現実はそう甘くない。既存の業務システムはWPFでがっつり作り込まれている。簡単には捨てられない。
さらに、特に欧米やアジアの金融・医療・製造系の企業では、WPFで作られた業務アプリがまだ“現役バリバリ”で使われているケースが圧倒的に多い。

つまり、「WPF→MAUI」みたいな単純な移行じゃなくて、「WPFとMAUIがしばらく共存する時代」が始まってるんだよね。

---

共存＝混在？じゃあ設計はどうするの？

この“混在”っていう状態がクセモノ。UIを設計する側としては、「どっちの技術を軸に考えるか？」で悩まされる。
たとえば、次のようなパターンがある：

• メインの業務アプリはWPF。でもタブレット向けの軽量UIだけMAUIで作りたい
• 新規開発はMAUIベースで。でもWPF側のビジネスロジックを共有したい
• グローバル展開を見据えて、iOS/Androidにも出したい。でも本社はWPFに慣れてる
• 開発チームが日本×海外で分かれていて、技術の選定方針がバラバラ

こんなふうに、「どっちも必要なんだけど、どうつなぐか？」という設計上のジレンマが多発してる。

そしてこのとき、一番問われるのが「アーキテクチャ設計の柔軟性」だ。
単なるコード共有じゃなくて、UIごとに適切な責務を分離し、必要に応じてWPFにも、MAUIにも展開できる構造を作る。

この“共存を前提にした設計力”は、正直なところ、海外でも重宝されるスキルだと思う。実際、ヨーロッパのある現場で「WPFとMAUIを両方扱える人材」がすごく評価されていて、僕もその設計レビューで貢献できた。

---

日本発のWPF経験は「海外で通じる武器」になる

日本では、WPFエンジニアって割と「局所的なポジション」と見られがち。でも海外では違う。「WPFの設計ができる＝レガシーにも強い＋.NETに深い知見がある」ということで、むしろ“インフラ的な視点を持ったアーキテクト候補”として評価されることが多い。

さらにMAUIやBlazorといった「.NETモダンUI技術」とセットで経験があると、「この人、共存を意識した設計ができるんだな」と、単なるコーダーではなく、UIアーキテクト的な立場で見られるようになる。

つまりWPFだけやってきた人も、ちょっと視点を変えてMAUIを学び、共存戦略を考えるだけで、グローバルでの市場価値がグンと上がる可能性がある。

「混在」は避けられない。じゃあどう設計する？―実例と5つの原則―

「WPFか、MAUIか」じゃなく「WPFも、MAUIも」

最近のプロジェクトでは、「WPFからMAUIへのフル移行」はほぼ見かけない。理由はシンプルで、既存のWPFシステムが、まだちゃんと動いていて業務に耐えてるから。だからこそ、段階的に共存・切り替えしていく設計が必要になる。

ここでは、実際に僕が関わった欧州某国のエネルギー管理システム（WPF＋MAUI混在）の事例をベースに、**「共存時代に効く5つの設計原則」**を紹介していきます。

---

原則①：UIは独立、ロジックは共通 ―「PresentationとLogicの完全分離」

これはもう鉄則中の鉄則。UI（WPFとMAUI）は分けて作り、ビジネスロジックやモデル層はできるだけ共通DLLとして設計する。
こうすることで、WPFの画面もMAUIの画面も、同じロジック・バリデーション・データアクセスを使えるようになる。

/Project.Shared
 ├── Models
 ├── Services
 └── ViewModels (共通のMVVMロジック)

 /Project.WPF
 └── Views (WPFのXAMLとコードビハインド)

 /Project.MAUI
 └── Views (MAUIのXAMLとコードビハインド)

この設計にしておけば、WPFからMAUIへの“見た目だけ”の置き換えもやりやすいし、1つの機能追加を両方に展開するのも最小工数で済む。

---

原則②：MVVMの「V（View）」は書き分けるのが正解

「共通のViewModelで画面ロジックを回す」は良い考えなんだけど、Viewの構造自体はWPFとMAUIでは違いすぎる。
WPFはDataGrid最強、MAUIはCollectionViewやListView前提。そうなると「無理にXAMLを共通化しようとしない」ほうが、結果的にメンテナンス性が高くなる。

→ UIは各フレームワークに最適化して、“適材適所”で分けて実装。
これ、海外の設計レビューでもかなり納得されやすい戦略。

---

原則③：DI（Dependency Injection）とサービス設計で“切り替え可能”に

どちらのUIが呼ばれても、内部で使うサービス（API呼び出しやDB操作など）が共通であることは非常に重要。そこで登場するのがDI。

// 共通インターフェース
public interface ICustomerService
{
    Task<List<Customer>> GetCustomersAsync();
}

// 実装クラス（共通DLL or プラットフォーム固有）
public class CustomerService : ICustomerService
{
    // 実装内容
}

WPF側、MAUI側ともに、同じインターフェース経由で依存解決すれば、どこでも同じ振る舞いになる。
これで**「1つのViewModelがどのUIにも対応できる」**設計が可能になる。

---

原則④：ローカライズ設計を“グローバル対応前提”で

MAUIを使っていくと「海外展開したいから英語対応してよ」というリクエスト、必ず出てきます。WPF時代のリソースベースのローカライズを、.resxに集約する設計にしておくと、MAUIでもそのまま流用しやすい。

さらに、以下のポイントも重要：

• リージョン別フォーマット対応（通貨、日付形式など）
• 左から右だけでなく、右から左（RTL）言語も想定する
• フォント選定に注意（WPFはOKでもMAUIで表示崩れが起きる）

グローバルプロジェクトを想定して設計するだけで、採用市場での信頼感はグンと増します。

---

原則⑤：テストは“UIではなくロジック”にフォーカス

WPFもMAUIも、UIの自動テストは正直に言ってツラい。そこで割り切りが必要。

• UIのテスト：手動 or スナップショットベースで最低限
• ビジネスロジックのテスト：共通DLL層で徹底的に自動テスト

**「テスト可能な設計」＝「保守しやすい設計」＝「海外チームに引き継ぎやすい設計」**にもなるので、特にリモートチーム開発の現場ではこの考え方が歓迎されます。

---

実際のプロジェクトでの効果

この原則を導入したプロジェクトでは、以下のような効果が得られました：

• UIを切り替えても、デバッグやロジック修正が1箇所で済む（開発効率UP）
• 新規MAUIタブレットアプリを2週間でリリース（既存WPFのロジック流用）
• 国際チーム（日本、スウェーデン、インド）で分担しやすくなった

設計レビューでは「この共存戦略、別の案件にも使えそうだね」と言われ、UIアーキテクトとしての信頼が大きく高まりました。

---

まとめ：「設計力」こそが次世代エンジニアの武器

「WPFとMAUI、どっちが正解か？」って話じゃない。
「両方を理解し、つなぐ設計ができる人」こそ、これからの海外現場で必要とされる人材です。

次回の**「転」パート**では、実際の混在開発で起こりがちなトラブルや、海外エンジニアチームとの連携での落とし穴、文化的ギャップの乗り越え方など、「技術＋国際コミュニケーション」のリアルに迫ります。

設計だけじゃ回らない。混在プロジェクトのリアルな“壁”とその乗り越え方

設計は完璧。でも、うまくいかない。

「アーキテクチャはしっかりしてるし、コードも共通化できてる。よし、これで回るはず！」
…と思っていた時期が、僕にもありました。

でも実際に多国籍チームでWPF×MAUI混在開発を進めてみると、いくつも見えてくる“設計ではどうにもできない壁”があるんです。
それは、技術の壁ではなく、「人」や「文化」、そして「組織」の壁。

ここでは、実際にあったリアルな混在プロジェクトのトラブルや、そこから学んだ乗り越え方のヒントを紹介していきます。

---

1. 「WPFわかんない」vs「MAUI触りたくない」問題

◆現場の温度差

僕が関わったプロジェクトでは、日本のチームがWPFを長年担当していて、ソースも設計思想も完全に“WPF脳”。
一方で、オーストラリア側はモバイル開発に強く、MAUI（というよりXamarin由来の文化）で進めたい。

このとき何が起きたかというと、

• 「WPFのMVVMが重い。もっと軽く書けるでしょ？」（海外チーム）
• 「MAUIのBindingって何か中途半端じゃない？」（日本チーム）

という、お互いの“正解”が噛み合わない状態になったんですね。

◆乗り越え方：「共通理解」をコードで示す

ここでやったのは、“共通パターン”のサンプルを一緒に作ることでした。たとえば：

• ViewModelBase.cs（共通ロジック）をどのUIでも動く形で用意
• WPFでもMAUIでも、データの取得・更新ロジックを同じ流れで動くようにデモ

これがあると、「なるほど、同じ構造で動くんだな」と理解が早まり、思想よりも“動く事実”を共有することでチームの空気が変わりました。

---

2. 海外エンジニアと「XAMLの美学」がズレる問題

◆WPF職人魂 vs カジュアルUI派

日本のWPFエンジニアって、XAMLにすごくこだわる人が多いんですよね。ControlTemplateの使い分け、Triggersの最適化、あとはStylesでのテーマ切り替えなど。

一方で、MAUI出身の海外エンジニアは、「もっとコンパクトに書こうよ」「コードビハインドで済むならそれでいいじゃん」というスタンスの人も多い。

◆乗り越え方：「仕組み」より「価値」に視点を戻す

XAMLのこだわりって、見た目や保守性のためにやってるわけですよね。でも、それが伝わらないと、「なんでそんなに複雑にするの？」となってしまう。

このとき使ったのが、ユーザー目線のプレゼンテーション。
具体的には：

• 同じ機能をWPF流とMAUI流で並べて表示
• 表示速度、アクセシビリティ、スタイル統一度などを比較
• 「なぜXAMLに手間をかけるのか？」をUX改善という“価値”で説明

これでようやく、「ああ、そういう理由でやってるんだね」と、納得してもらえました。
技術的な“やり方”ではなく、その先の“目的”を共有することがカギになります。

---

3. タイムゾーンと進行スピードのズレ問題

◆「待ち」のストレスがチームを腐らせる

これはグローバル開発あるあるなんですが、時差があると、

• 「レビュー待ちで1日止まる」
• 「夜にプルリクが来て、朝には違う方向に進んでる」
• 「朝会で言ったことが翌日には忘れられてる」

という、**“タイムラグによるコミュニケーション不全”**がよく起きます。

◆乗り越え方：ローカルオーナーシップ×非同期コミュニケーション

この問題の対策としては、2つのアプローチが効きました。

1. 「モジュール単位」で責任を分ける
   　→ たとえば、「WPFの一部は日本チームが完全オーナーで持つ」とし、確認やレビューを待たずに進める。
2. 「ドキュメント＋動画」で非同期共有
   　→ プルリクだけじゃなく、5分の Loom動画で意図を説明。
   　→ NotionやConfluenceでアーキテクチャ説明を“動く図”付きで整理。

これによって「空気で伝える」文化から脱却でき、“時間が合わなくても伝わる”設計体制に進化できました。

---

4. 「誰が責任を持つのか分からない」問題

◆混在開発の“宙ぶらりん”地帯

WPF側のバグなのか、MAUI側の通信問題なのか、判断がつきにくいエリアが出てきます。
でも誰も「自分の守備範囲」とは言い切れず、責任の所在がぼやける。これは特に、「UI共通ロジック」や「APIゲートウェイ」の周辺で起こりがち。

◆乗り越え方：「クロスレビュー体制」と「責任の境界線の言語化」

• コードレビューを**別UI担当の人にも回す（MAUI→WPFなど）**ことで、視点を交差させる
• モジュールごとに「責任の終点（ここまでWPF、ここからMAUI）」を明文化

「この関数を呼び出すまでがWPF、結果受け取って描画するのがMAUI」
みたいに責任範囲をはっきりさせるだけで、チームの安心感が変わります。

---

5. 「文化的なフィードバックスタイルの違い」問題

◆遠慮 vs 率直すぎ

日本人エンジニアは、レビューであまり強く言わない傾向があります。
逆に、オーストラリアやオランダの開発者はストレートに改善点を指摘してくることも多い。

それで最初は日本側が「責められている」と受け取り、MAUI側も「全然反応が返ってこない…」と困惑。完全にすれ違ってました。

◆乗り越え方：「フィードバックの文化」を翻訳して共有する

ここで使ったのは、「フィードバックスタイルの共通言語化」。具体的には：

• チーム全体で「どう指摘すれば伝わりやすいか？」をミニワークショップ形式で確認
• 例）「Not great」→「もっとこうすると良くなるかも、という提案だよ」と解説
• 逆に日本人が遠慮がちに書くとき、「それは“反対ではないが懸念あり”という意味だよ」と説明

こうした“文化の翻訳”を少しずつやることで、コミュニケーションの空気が滑らかになっていきました。

---

結論：技術力だけじゃ、共存は回らない

ここまで読んでいただいた方は気づいたかもしれません。
**WPF×MAUIの混在開発において、最大の課題は“人と組織の壁”**なんです。

どれだけ美しい設計をしても、チームの理解・連携・責任共有がなければ、それはただの“理想”で終わる。

だからこそ、“技術をつなぐ設計力”と同時に、“人をつなぐ言葉や構造”を持つことが、今のエンジニアには求められているんだと思います。

WPFしかやってない、はむしろ武器になる ― グローバルで生きる“UIアーキテクト”の条件

「レガシー扱いされる自分」に、凹んでない？

正直な話、海外の現場に入って最初に感じたのは、**「あ、WPFってやっぱ古いって見られてるんだな…」**という温度差だった。

SlackやGitHubのやりとりで、MAUI推しの若手エンジニアたちが「レガシーシステム」って言葉を使うたび、ちょっと胸がチクっとする。
日本の現場で長年積み上げてきたWPFスキルに、自信がないわけじゃなかった。でも、**「このスキルは世界で通じるのか？」**と、不安になる瞬間が何度もあった。

でもある日、転機が来た。

---

「この構造、どうやって整理したの？」と聞かれた日

MAUI側の新機能が不安定で、急遽WPFの既存画面に実装を戻すことになった。
そのとき、MAUIチームのリードがWPFプロジェクトの構造を見て、Slackでこう言った。

“This is insanely modular and clean. Who designed this layer separation?”

（この構造、めっちゃモジュール化されててクリーンだな。誰がこのレイヤー分離設計したの？）

そう、WPFで「当たり前」にやってきた分離設計やMVVMの実装が、グローバルなチームでは“評価される専門性”だったんです。

その日を境に、僕の立ち位置が変わりました。

---

WPF×MAUI時代に“重宝される人材”とは？

今の時代、単一のUI技術だけじゃなく、「橋渡しできる」人材が求められている。
WPFを深く理解している人が、MAUIやBlazorといった次世代技術とどうつながるかを考えられる、そういう人が“アーキテクト”として求められています。

✔ こんな人がグローバルで評価される

• 「WPFで育ち、MAUIにも展開できる」柔軟性を持つ人
• MVVMパターンを理解し、技術を超えてUI設計を言語化できる人
• UIの違いを「対立軸」ではなく「役割分担」として捉えられる人
• 英語で構成や設計思想を説明できる“プレゼン力”を持っている人

実際、北欧やドイツなど、WPFが今でもがっつり使われている現場では、こういった人材はとても重宝されていて、ポジションも年収もワンランク上です。

---

英語ポートフォリオで“共存設計力”をどう伝えるか？

① 技術栄養素ではなく、「構造」と「意図」で語る

WPFやMAUIの単なる画面キャプチャだけじゃ伝わらない。
重要なのは「この構造にした理由」を英語でしっかり伝えること。

例：

Project: Energy Dashboard System (WPF + MAUI Hybrid)

Role: UI Architect & Lead Developer

Challenge:
- Maintain existing WPF structure while introducing a mobile MAUI interface.
- Avoid redundant business logic between platforms.

Solution:
- Separated ViewModel and Services into a Shared .NET Standard library.
- Defined a presentation layer boundary to allow UI-specific customization.

Result:
- 40% code reuse across platforms
- Faster onboarding for new MAUI developers

② 共存状態の図解（Architecture Diagram）

1枚の図で、「どこが共通で、どこが分離されているか」を見せるのがかなり有効です。
たとえば：

[ WPF UI ] → [ Shared ViewModel ] → [ Shared Service ] → [ API ]
[ MAUI UI ] → ↑

この“シンプルで意図のある図解”が、技術者以外にも理解してもらいやすい。

---

“UIアーキテクト”という次のキャリア像へ

もし今、あなたが「WPFしかやってこなかった」と感じているなら、実はそれって**“グローバルアーキテクトへの入り口”**かもしれません。

WPFは深い。
WPFは複雑。
でもだからこそ、「構造を整理する力」が圧倒的に鍛えられている。

それを活かして、

• MAUIと共存する構成を考える
• モバイルとデスクトップのUI責務を設計する
• グローバルチームとの設計レビューに耐えうる英語力をつける

そうやって、一歩一歩「つなぐ人材」になっていけば、単なる開発者から“UIアーキテクト”へとステップアップする道が見えてきます。

---

これから始める人へ ― スキルロードマップ（2025年版）

最後に、「WPFエンジニアがグローバル対応のUIアーキテクトを目指すためのロードマップ（簡易版）」を紹介します：

🔹ステージ1：WPFを“設計の目線”で見直す

• MVVMの目的を再確認
• ViewとViewModelの役割整理
• ResourceDictionaryやThemeの構造理解

🔹ステージ2：共通化・移行性を意識した構成にする

• Service層・モデル層の分離
• .NET Standardまたは .NET 8ライブラリへの分離
• DI/IoCパターン導入

🔹ステージ3：MAUIを触って“違い”を体感

• WPFとのXAML比較
• CollectionViewやShell構成の理解
• モバイル特有の制約やUXの違いに気づく

🔹ステージ4：グローバル設計力を磨く

• 英語での設計ドキュメント作成
• Diagramツール（draw.io, Whimsical等）で構成図を作る
• GitHubのREADMEやPRに「Why this design?」を書く練習

🔹ステージ5：ポートフォリオ公開＆転職チャレンジ

• 自作のWPF×MAUI共存アプリをGitHub公開
• READMEは英語と日本語の両方で用意
• LinkedInや海外転職サイトでポートフォリオ共有

---

最後に：混在時代は、「橋をかけられる人」が主役になる

WPFとMAUI。
デスクトップとモバイル。
日本と海外。
新技術と既存資産。

この“間”に立てる人、つまり**「翻訳者」でもあり「架け橋」になれる人**が、これからの時代は必要とされる。

もしあなたが、「WPFしかやってない」と思っているなら――
今が、その“橋渡しエンジニア”になるチャンスです。

混在は、混乱じゃない。
そこには、設計という言語でつなげる“余白”がある。
そしてその余白こそが、あなたの活躍の舞台になるはずです。