WPF時代にやっておいてよかった7つのこと

  1. 「終わった技術」と言われても、僕のキャリアの土台だった
    1. 「まだWPFやってるの？」から始まった海外での違和感
    2. 「なんでそんなにUIの整理がうまいの？」と聞かれて気づいたこと
    3. “レガシー”に見えたWPFは、実は“鍛錬場”だった
  2. 僕を鍛えたWPFの“あの苦労”が、今になってキャリアの武器になる
  3. ① XAMLだけに頼らず「View構造」を設計していたこと
  4. ② Bindingのトラブルに何度もぶつかって、依存性を減らす習慣がついたこと
  5. ③ MVVMを“思想”として理解しようとしたこと
  6. ④ ValidationやCommandなど、UIの“責任範囲”を考え抜いたこと
  7. ⑤ スタイル・テーマの一元管理に挑戦したこと
  8. ⑥ 小さなアプリでも“設計ドキュメント”を残す癖をつけたこと
  9. ⑦ WPFで苦しんだ分、他技術に移ったときに「比較と言語化」ができるようになったこと
  10. まとめ｜WPFでの苦労は、今の“設計者としての視点”につながっている
  11. WPFで鍛えた「設計力」は、UIの未来に通用する
    1. 「WPFって今も役に立つの？」という問いに、いま答えるとしたら
  12. なぜWPF経験は“汎用性の高い設計資産”になるのか？
  13. 他技術との“スキル変換マップ”を見てみよう
  14. 「UI技術の移り変わり」に振り回されないキャリアを作るには？
  15. WPF出身者が“次に狙うべきキャリア領域”
    1. 🎯 ① クロスプラットフォーム開発の設計リーダー（MAUI / Flutter）
    2. 🎯 ② WebフロントのUI設計アーキテクト（Blazor / React）
    3. 🎯 ③ UI/UXコンサル・デザインガイドライン策定担当
  16. WPF経験は“使い尽くす”ことで価値が出る
  17. まとめ｜「WPFは時代遅れ」ではない。「時代の先を考える訓練だった」
  18. それは遠回りではなく、“設計者への近道”だった
  19. あのWPFの苦労、どうやって“キャリアの言語”にする？
  20. ✅ Step 1：単なる“技術名”ではなく、“設計視点”で語る
    1. NG例：
    2. OK例：
  21. ✅ Step 2：ポートフォリオに「設計理由」と「思想」を載せる
    1. ✅ UI設計書風ポートフォリオ構成例：
  22. ✅ Step 3：UI設計力を可視化する“比較記事”を発信する
  23. ✅ Step 4：面接で語るなら、“構造の癖”を引き合いに出す
    1. 質問：
    2. 回答例：
  24. ✅ Step 5：「UIアーキテクト的視点」を育てる行動
  25. ✅ 「時代遅れ技術」をどう扱うかが、“時代の先を行く設計者”を分ける
  26. ✅ 最後に：7つのことは、“設計の語彙力”だった

「終わった技術」と言われても、僕のキャリアの土台だった

「まだWPFやってるの？」から始まった海外での違和感

海外に出て最初に感じたのは、「技術の主流の違い」だった。

  • フロントエンドといえばReactやVue
  • モバイル開発はFlutterかMAUI
  • .NETといえばWeb APIかBlazor Server

ある意味当然だ。
WPFはあくまでデスクトップ向け。しかもWindows限定。
クラウド全盛の今、”限られた領域”に見えるのも無理はない。

でも――

実際にプロジェクトをいくつもこなす中で、WPF出身者にしかできない設計・思考・実装があることを強く実感した。

「なんでそんなにUIの整理がうまいの？」と聞かれて気づいたこと

WPFの案件を離れた後も、MAUIやBlazorでのプロジェクトに参加した。
そこで驚かれたのは、僕のUIまわりの設計力だった。

  • 「Stateの整理がうますぎて、保守が楽」
  • 「どうして先回りしてアクセシビリティまで考えられるの？」
  • 「入力フォームの構造が自然すぎて、迷わない」

最初は何が評価されているのか、正直よくわからなかった。

でも、あるとき気づいた。

「あ、これ全部、WPF時代に苦労して手に入れた“戦い方”じゃないか。」

“レガシー”に見えたWPFは、実は“鍛錬場”だった

WPFには独特のクセがあった。
MVVMに慣れるまで、データバインディングで何度泣いたか。
ControlTemplateやStyleを極めようとすれば、設計地獄に突入する。

でも――

その泥臭さが、今の僕にこういう力をくれた：

  • UIを機能じゃなく「体験」で設計する視点
  • プロダクト単位での再利用性・拡張性を見抜く力
  • 「構造化」「分離」「ルール化」を前提にしたUI思考

だから、この記事ではあえて振り返りたい。

「もしあの頃のWPFで、これをやっておいて本当によかったと思えること」

を、7つに絞って紹介していこうと思う。

僕を鍛えたWPFの“あの苦労”が、今になってキャリアの武器になる

① XAMLだけに頼らず「View構造」を設計していたこと

WPF初期の頃、ついやってしまいがちだったのが**「とにかくXAMLに全部詰め込む」**こと。
Page、Grid、StackPanel、Controlのネストが深くなりすぎて、開くだけで気が重くなる…。

でも、ある時から「画面を論理的に分割」して考えるようになった。

  • ユーザーが“1回の操作で完了する”範囲はどこか？
  • 1コンポーネント＝1責任に切り出せているか？
  • 見た目じゃなく“操作フロー”でViewを定義しているか？

この発想は、のちのちMAUIやBlazorでレイアウトを組むとき、まるごと活かされた。
HTMLやRazorに置き換わっても、「画面を分けて考える力」は不変だからだ。

② Bindingのトラブルに何度もぶつかって、依存性を減らす習慣がついたこと

「バインディングが反応しない」「UIに値が反映されない」
この“WPFあるある”に、何度も地雷を踏んだ。

  • INotifyPropertyChanged の実装漏れ
  • コンテキストの違いによるデータバインド失敗
  • 遅延読み込みと表示タイミングのズレ

そうした経験が、自分に**“構造的な設計”の習慣**を育ててくれた。

  • ViewModelからViewへの依存をゼロにする
  • ObservableCollectionやRelayCommandの導入で標準化する
  • 設計段階で「何が更新対象か」を明確にする

これ、Blazorでも驚くほど役立った。
StateHasChangedや@bindのバグ調査で、**WPFでの“データ流通の癖”**がそのまま使える。

③ MVVMを“思想”として理解しようとしたこと

「MVVMパターンを使ってます」と言いながら、
結局はコードビハインドが太ったまま……ってこと、WPF界隈では珍しくない。

でも、自分の中でMVVMを「思想」として再定義したのが転機だった。

UIは“状態の可視化装置”に過ぎない。ロジックとUIは切り離すべき。

その結果：

  • ユーザー操作は全部Command化
  • 状態変更はすべてプロパティに集中
  • コントロールとロジックの接点はBindingとCommandのみ

この“UIとロジックの距離感”は、ReactやAngularの世界に入っても大きな武器になった。
状態管理＝UX設計という視点が根付いたのは、WPFの功績だと心から思う。

④ ValidationやCommandなど、UIの“責任範囲”を考え抜いたこと

WPFでは、「入力チェック」「データ保存」「UIブロック」など、
ユーザーインタラクションまわりの処理を**“どこでどう責任を持たせるか”**が常に問題だった。

僕が試行錯誤の末にたどり着いた考え方は：

  • 入力検証＝ViewModelの責任
  • 実行制御＝CommandのCanExecuteにまとめる
  • UI制御＝IsEnabled, Visibilityなどのプロパティで制御
  • ローディング表示＝Viewからの最小限の通知で切り替え

このような**「UIの責任を分離する設計力」**は、あらゆるUIフレームワークに共通して求められる。

今では、BlazorやMAUIで「UIの振る舞いをどこで設計すべきか」という議論になると、
WPFでの設計原則がロジカルに提示できるようになった。

⑤ スタイル・テーマの一元管理に挑戦したこと

見た目がぐちゃぐちゃのWPFアプリを何度もリファクタリングした経験から、
「テーマ設計の重要性」を学んだ。

  • ResourceDictionary に色・フォント・余白を統一管理
  • 共通StyleをApp.xamlで全体適用
  • コンポーネントごとにStyleの分離と再利用

この“デザインの再現性と一貫性”は、大規模UIプロジェクトの命綱だった。

そして驚いたのは、BlazorやMAUIでもまったく同じ設計が使えるということ。

Tailwindでも、Figmaでも、**「デザイン設計は構造設計」**という感覚がベースになる。

⑥ 小さなアプリでも“設計ドキュメント”を残す癖をつけたこと

WPF時代に苦労したのは、「自分が作ったUI構造を後から理解できなくなる」こと。

だから途中から、プロトタイプでも以下のような設計メモを必ず残すようにした。

  • 画面構成図（手書き or PowerPoint）
  • View-ViewModel間のプロパティ一覧
  • 各コンポーネントの責任範囲メモ
  • 共通StyleとControlTemplateの概要表

これがのちにUIアーキテクト的な文書作成力に直結した。

海外チームとの連携では、「コードだけで伝える」のは難しい。
でもこの習慣のおかげで、設計を“言語で伝える”ことが自然にできるようになった。

⑦ WPFで苦しんだ分、他技術に移ったときに「比較と言語化」ができるようになったこと

いざBlazorやMAUIに移ったとき、一番役立ったのは、
WPFとの違いを“言語化”できたこと。

  • 「WPFのこの部分は、Blazorではこう書く」
  • 「MVVMのここがReactのHooksに近い」
  • 「UIの責任範囲の分け方はWPFのほうがシンプルだった」

この比較視点を持てたのは、WPFで“深く悩んだ”からこそ。
表面的な違いじゃなく、思想レベルでの対比ができるようになった。

これは面接でもチーム会話でも圧倒的な強みになる。
「この人、ただ技術を知ってるんじゃなくて、ちゃんと“考えた人”だ」と信頼される。

まとめ｜WPFでの苦労は、今の“設計者としての視点”につながっている

  • UIを「体験」として捉える思考が養われた
  • 責任分離、構造化、テーマ管理などの基本設計力が身についた
  • 新技術への“翻訳”と“比較”が言語化できるようになった
  • 結果として、UIアーキテクトというキャリアへの土台ができた

WPFで鍛えた「設計力」は、UIの未来に通用する

「WPFって今も役に立つの？」という問いに、いま答えるとしたら

正直、WPFの現場にいたときは思っていた。

「この技術、いつまで使えるんだろう……」
「Webの波に飲まれて、置いていかれるんじゃないか」

でも、MAUIやBlazor、あるいはReactやFlutterといった別領域のプロジェクトに参加して気づいた。

WPFで身につけたUI設計の“基礎体力”は、今のどんなUI技術にも直結している。

なぜWPF経験は“汎用性の高い設計資産”になるのか？

それは、WPFが次のような要素を強く要求してくる技術だったから：

  • 抽象化と再利用（Style, Template, Resource）
  • 責務の分離（MVVMパターン）
  • 宣言的UI構築（XAML）
  • 双方向バインディングによるUI同期
  • ユーザーインタラクション設計（Command, Validation）

これらは、Webやモバイル、クロスプラットフォームの世界でもまったく同じように求められている。

他技術との“スキル変換マップ”を見てみよう

WPFのスキル移行先の技術変換される能力・思考軸
MVVM + BindingBlazor の双方向バインディング、React の状態管理状態と表示の分離、再描画の最適化
XAMLによる宣言的UI設計FlutterのWidget構成、ReactのJSXUIをコードで設計する「パーツ化」思考
StyleとResource管理Tailwind / CSS変数 / Design Systemテーマ・再利用・一貫性の設計
ValidationRule、IDataErrorInfoFormik（React）やFluentValidationUXとしてのエラーハンドリング設計
CommandとCanExecuteBlazorのCommandパターンやReactのuseCallbackユーザー操作制御、実行状態の可視化
ViewModel設計と責務分離クリーンアーキテクチャ（Web/モバイル）コンポーネントの責務を切り分けて保守性を高める設計

→ 技術が変わっても、設計の本質は変わらない。
　WPFで身につけたそれらは、他技術に“翻訳”するだけで活きてくる。

「UI技術の移り変わり」に振り回されないキャリアを作るには？

UIは流れが速い。数年単位で主流が変わる。

  • WPF → Silverlight → UWP → MAUI（クロス）
  • React → Vue → Svelte → Solid.js（Web）
  • Xamarin → Flutter → Jetpack Compose（モバイル）

でも、こうした波の上を泳げるかどうかは、「技術名」ではなく「設計力」で決まる。

UI技術に振り回される人
＝「ライブラリ依存の実装者」

UI技術を渡り歩ける人
＝「設計思想を持つアーキテクト」

そして、WPFはまさに後者を育てるトレーニング場だった。

WPF出身者が“次に狙うべきキャリア領域”

🎯 ① クロスプラットフォーム開発の設計リーダー（MAUI / Flutter）

  • MAUIはWPFに似た設計思想（XAML、MVVM）
  • Flutterは構造設計の観点が似ている（Widgetツリー）
    → UI設計の再利用・責務分離・テーマ制御が直感的にできる

WPF経験者は、「設計の深さ」で先回りできる人材として重宝される。

🎯 ② WebフロントのUI設計アーキテクト（Blazor / React）

  • コンポーネント設計（再利用・抽象化）はWPFで鍛えた経験が活きる
  • 双方向バインディングと状態管理の応用も豊富
  • デザインシステムとの連携やスタイル設計も得意分野

WPFをやってきた人ほど、ReactやBlazorの“難しさの本質”を最初から見抜ける。

🎯 ③ UI/UXコンサル・デザインガイドライン策定担当

  • WPFでの「構造設計」「テーマ設計」「再利用」経験は体系化しやすい
  • プロダクトを横断するUIルール整備、設計原則の策定などができる
    → 世界中で求められる“UIアーキテクト的職能”

コードを書くより「UIの思想を設計する」仕事ができるようになるのが、WPF卒業後のキャリアの進化形。

WPF経験は“使い尽くす”ことで価値が出る

ポイントはここ：

「WPFを終わらせる」んじゃなくて、
「WPFを起点に“使い尽くす”ことでキャリア価値に変換する」こと。

  • UI思想を整理して他技術に翻訳
  • 設計原則を言語化してチームで共有
  • 技術間の橋渡し役として活躍

WPFで苦しんできたからこそ、できる仕事がある。

まとめ｜「WPFは時代遅れ」ではない。「時代の先を考える訓練だった」

  • 技術は変わっても、UI設計の“問い”は同じ
  • WPFで得たスキルは、他のUI技術に翻訳・応用できる
  • キャリアの次の一手は、“コードを書く人”から“体験を設計する人”へ
  • 今こそWPFを“卒業”ではなく、“活用”という視点で捉え直すべきとき

それは遠回りではなく、“設計者への近道”だった

あのWPFの苦労、どうやって“キャリアの言語”にする？

WPFでの経験を、いざ転職や案件で語ろうとしたとき、こんな壁にぶつかった。

「それって、いま通用する技術ですか？」
「WPF…ああ、レガシーですね」

……悔しかった。

でも、そこから一歩踏み込んで、WPFで得た“設計的視点”を言語化し直すようになってからは、むしろ高く評価されるようになった。

この結章では、WPF経験をどう再定義して「価値に変える」のか。
その実践例と未来への応用を紹介していく。

✅ Step 1：単なる“技術名”ではなく、“設計視点”で語る

NG例：

  • 「WPFで画面をたくさん作りました」
  • 「BindingやMVVMに詳しいです」

OK例：

  • 「業務特化UIの設計において、ユーザー操作の最小単位ごとにView分割を行っていました」
  • 「画面構成や再利用性、アクセシビリティ要件を統合的に設計した経験があります」
  • 「業務ドメインとUI構造を接続するため、ViewModel層にドメイン知識を整理し、責務を明確に保つよう設計していました」

“技術で何を作ったか” ではなく、
“何をどう設計したか” が伝わる表現に変える。

✅ Step 2：ポートフォリオに「設計理由」と「思想」を載せる

画面のスクリーンショットだけでは、“設計者”としての力は伝わらない。
そこで、以下のような構成にしておくと効果的：

✅ UI設計書風ポートフォリオ構成例：

  1. 目的（Why）
    　この画面は、どういうユーザーに、どんな目的で提供するのか？
  2. 構造設計（How）
    　画面構成をどのように分割したのか？レイアウト思想は？
    　→ XAMLの構成図や簡易画面遷移図を添付
  3. 設計方針（What）
    　データバインド、コマンド、Style、テーマ設計はどう管理したか？
    　→ ResourceDictionaryの構造やValidationパターンなども記載
  4. 振り返り
    　保守性、拡張性、ユーザビリティの観点からの反省と改善案

こういった「ドキュメント付きUIポートフォリオ」は、海外では特に高評価されやすい。

✅ Step 3：UI設計力を可視化する“比較記事”を発信する

転職・副業・フリーランスを考えるなら、発信は最大のポートフォリオになる。

たとえばこんなタイトルでnoteやZenn、LinkedIn記事にするのはどうだろうか？

  • 「WPFで学んだUI設計をBlazorにどう応用したか」
  • 「デザイナーと連携するためのResourceDictionary設計術」
  • 「MVVMは時代遅れ？いえ、“状態設計”という視点でまだ生きてます」

実際、僕自身、こういった記事を書いたことで
“UI設計がわかる開発者”という立ち位置を得ることができた。

✅ Step 4：面接で語るなら、“構造の癖”を引き合いに出す

技術面接で「UI設計」について聞かれたとき、こう答えてみてほしい：

質問：

「これまでのUI設計で意識していたことは？」

回答例：

「WPF時代に、バインディングとレイアウトの責務分離で何度も失敗した経験があり、
それ以降、UI構造と状態管理は必ず分けて設計するようにしています。
その癖が、今でもReactやBlazorでの実装に自然と出ています。」

こういう“設計上の癖”や“原体験”が語れると、**一目で“考えてきた人”**だとわかってもらえる。

✅ Step 5：「UIアーキテクト的視点」を育てる行動

いま現場でWPFを触っている人にこそ伝えたい。

今が**“設計のトレーニング期間”**であることに、早く気づいたほうがいい。

次のような行動が、キャリアの後半で大きな差を生む：

  • 自分のXAML設計を、他人に説明できるようにメモする
  • Resource設計の粒度や再利用性を定義してみる
  • Component単位での“責任”を言語化してみる
  • デザイナーがいなくても“UI美学”を持つ
  • 「WPFっぽいWebUIの設計」を一度考えてみる

✅ 「時代遅れ技術」をどう扱うかが、“時代の先を行く設計者”を分ける

技術の寿命は短い。
でも、“設計力”の寿命は長い。

そしてその設計力は、しばしば“時代遅れ”の技術の中でしか磨けない。

WPFは、技術的には下火かもしれない。
でも、そこで“どうUIを設計し、どう改善し、どう表現したか”は一生の武器になる。

むしろ、流行技術しかやってこなかった人には持てない武器だ。

✅ 最後に：7つのことは、“設計の語彙力”だった

僕がこのVol.4で伝えたかった「7つのこと」とは――
“WPFという苦労を通して、UI設計を語れる語彙力を得た”ということ。

  • 技術トレンドの海で溺れない“軸”をくれた
  • 世界中のUIエンジニアと議論できる“視点”をくれた
  • 自分の経験を資産として語る“構造”をくれた

それこそが、WPFがくれた最大の贈り物だった。

コメント

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