―「もうWPFの時代じゃない？」そう思ったあの頃の自分に教えてあげたい―
「WPF、続ける意味あるのかな？」と思っていたあの頃の僕へ
正直なところ、数年前の僕はちょっと焦ってました。
Web全盛。スマホアプリの波。
ReactだFlutterだと、みんなが次々に新しいUI技術に乗り換える中で、
僕はというと、相変わらずWPFで業務アプリを作り続けていた。
朝から晩まで、GridとStackPanelと格闘し、INotifyPropertyChangedにうんざりしながら、
MVVMパターンの癖に慣れ、
「もうコードよりXAMLの方が好きかも…」なんて思ってたあの頃。
でも、ふと疑問に思ったんです。
「この技術、もう先がないんじゃないか？」
「転職しようと思っても、WPFじゃ評価されないんじゃないか？」
「みんな新しい技術やってるのに、自分は置いていかれてるのでは…？」
“ニッチ”という言葉が怖かった時期
特に辛かったのは、LinkedInやTwitter（現X）で流れてくる投稿たち。
- 「Reactで爆速フロントエンド開発！」
- 「Flutterでマルチプラットフォーム対応しました！」
- 「Blazor最高！WPF？まだ使ってるの？笑」
WPFを続けてる自分が**「時代遅れ」みたいに思えて**、
実績を積んでるはずなのに、なんだか自信を失いかけていました。
でもあるとき、海外のエンジニアと話す機会がありました。
彼は、今もWPFで複数の医療系ソフトを作っている開発リーダーで、こんなことを言ってくれたんです。
「WPFって、奥が深いし、ビジネスアプリでは今でも現役だよ」
「むしろ、“今のWPF”をちゃんと使える人がどんどん貴重になってる」
「新しい技術を追いかけるのもいいけど、深く掘れる技術を持ってるのは大きな強みだよ」
…その言葉に、少し救われました。
振り返って思う。「あの頃やっておいてよかった」と心から言えること
それからもWPFを続けてきた結果、いまでは海外案件で設計からレビューまで任されることも増え、
「UIアーキテクト」としてのキャリアにも道が開けました。
だから今、WPF時代を振り返ってみて、こう思います。
「あのとき“次が見えなくても”、やってきたこと全部が今に生きている」
そして、これから海外を目指すWPFエンジニアにこそ伝えたいんです。
「新しい技術をやってない＝価値がない」ではない、ってことを。
むしろ、WPFという“完成された深い技術”の中で、
どれだけ設計力・表現力・抽象化力を鍛えたかが、
これからの武器になる。
本記事の構成について
というわけで、今回の記事では、そんな**“やっておいてよかった”と思える7つの経験や習慣**を、僕のリアルな失敗・発見とともに紹介していきます。
全部、「今WPFをやっている人」にこそ共感してもらえることばかりです。
ちなみにこの7つは、単なるTipsじゃありません。
- 海外の案件でも通用した
- 他のUI技術（MAUI / Blazor / Web）にも応用できた
- 面接や英語レジュメで強みとして語れた
…という、実績ベースで「本当にやってよかった！」と胸を張って言えるものです。
こんな人に読んでほしい！
- 「WPFしかやってこなかった…これでいいのかな？」と不安を感じている方
- 「UI設計力を強みにしたいけど、どう伸ばせばいいかわからない」方
- 「将来、海外でUIエンジニアやUIアーキテクトとして働きたい」と考えている方
- 「他のUI技術へのキャリア展開のヒントが欲しい」方
“WPF時代にやっておいてよかった”と思えた7つのこと
WPFにどっぷり浸かっていた日々。
当時は「これでいいのかな…」と不安だったけど、
今では**「あれ、全部やっておいてマジで良かった…！」**って思えることがある。
それは単なるコーディングスキルじゃなくて、
“思考の癖”とか“設計への向き合い方”とか、
もっと本質的な部分だったりします。
ここでは、僕が「WPF時代にやっておいてよかった！」と心から思える7つのことを、エピソードとともに紹介します👇
① MVVMを「自分の言葉」で語れるようにした
MVVM（Model-View-ViewModel）は、WPF開発者なら避けて通れないパターン。
でも最初は本当にチンプンカンプンで、「これ、なんで必要なの？」というレベルでした。
転機になったのは、「新人にMVVMを教えることになった」時。
「なぜViewとViewModelを分けるの？」
「Commandとイベントハンドラって何が違うの？」
「Bindingしてるけど、PropertyChangedが効かないのはなぜ？」
…もう、説明してるこっちが試されてる（笑）。
このとき、「自分の中で理解できてなかったこと」が浮き彫りになったんです。
だからこそ、自分なりの言葉で「MVVMってこういう思想なんだよ」と説明できるようになるまで徹底的に噛み砕きました。
この経験は、海外面接で聞かれた「How do you separate logic from view?」にスラスラ答えられる力になりました。
② ControlTemplateとUserControlの違いを“体感”で理解した
最初のうちは、画面ができればそれで満足してたんです。
でもある日、複雑なレイアウトを複数の画面で再利用しようとしたら、カオスになった。
- UserControlにしたら、テンプレート適用が難しくなり…
- ControlTemplateにしたら、コードビハインドで詰み…
ここで初めて、**「UserControlはロジックを持つ」「ControlTemplateは見た目だけ差し替える」**という本質を体感しました。
この理解があったおかげで、Blazorのコンポーネント設計やReactの再利用構造を設計するときにも、迷わず対応できるようになった。
③ Style / Resource設計に“設計思想”を込めた
StyleやResourceDictionaryって、慣れるまでは「設定ファイル」くらいの感覚ですよね。
でも実は、“デザインシステム”の原型でもある。
僕はあるプロジェクトで、「この色、どこに使っていいかわからない」「フォントサイズがバラバラ」という声をきっかけに、リソースの共通化に取り組みました。
- 色、フォント、ボタンサイズを定義
- 画面ごとの適用ルールを決定
- ResourceDictionaryを名前空間で分割＆モジュール化
結果的に、**「誰が作っても統一感のあるUI」**が作れるようになった。
これはまさに、海外でも求められる“UIアーキテクト的な視点”でした。
④ 英語でUI仕様書を“自分で書いた”
最初は抵抗あったんですよ、英語で仕様書書くの。
でも海外案件で「UI構成図」や「状態遷移図」が求められるようになってから、
**「これ、自分で書けるようになった方が早いな」**と気づいてトライ。
- UIの要素と役割を英単語で表現（例：Filter Panel, Action Button, Readonly View）
- 表現を簡潔に（”Shows warning if input is empty.”）
- FigmaやPowerPointで図解を英語ラベル付きに
これ、やってみるとめちゃくちゃ力になります。
なぜなら、“UIを言語化する力”は、どの技術でも通用するから。
特にUIアーキテクトを目指すなら、この力はマストです。
⑤ 他人の画面をレビューする癖をつけた
これ、地味だけど効果抜群。
WPFチームのレビュー文化がなかった頃、「他人のXAMLに口出すなんて…」と思ってたけど、逆にそこにこそUI改善のチャンスがあった。
- 「このBinding、Nullのときに崩れない？」
- 「このTextBox、Tabキーでフォーカス飛ばないよ？」
- 「この画面だけ、Saveボタンが右上だけど他は右下だよ？」
…といったフィードバックができるようになったのは、
日頃から“誰かのUIを観察する習慣”があったから。
これは、UXレビューの現場やFigmaコメント文化にもスムーズに応用できました。
⑥ “使いにくいUI”を勝手に再設計してみた
個人的に、これが一番成長に効いたかも。
業務システムの“使いにくい”UIに出会ったとき、
「これ、どう改善できるかな？」と自分で勝手に再設計してみるクセをつけました。
- ワイヤーフレームをFigmaやPowerPointで再構成
- 情報グルーピング、導線の短縮、ボタン配置の見直し
- Before/Afterを自分で比較
これを何度も繰り返した結果、
UI改善の“引き出し”が圧倒的に増えました。
さらに、ポートフォリオに「Before/After」形式で載せると、
英語が苦手でも“改善力”が一目で伝わるという利点もあります。
⑦ WPF以外のUI技術に“翻訳”してみる練習をした
WPFで学んだパターンを、他のUI技術に置き換えてみる。
これ、最初は趣味で始めたんですけど、実はめちゃくちゃ良かった。
たとえば：
- MVVMパターン → BlazorのComponent+EventCallback
- ResourceDictionary → SCSSの変数とMixin構造
- ControlTemplate → ReactのSlot構造やコンテナパターン
こうやって**“概念レベルで理解する力”**を養ったおかげで、
転職活動でも「この人はWPFしかできない人じゃない」と思ってもらえるようになりました。
WPFの経験が、“海外で戦えるスキル”に変わった瞬間
「WPFだけで、本当に海外で通用するの？」
これは、僕が転職活動を始める前にずっと感じていた疑問でした。
なぜなら、海外求人の技術スタックを見ても、React、Angular、Flutter、Blazor…
WPFって、まず見かけないんです。
「WPFメインの自分が、どうやってアピールすればいい？」
「WPFってだけで落とされるんじゃない？」
「やっぱりWebにキャッチアップしておかないと無理？」
そんな風に不安でいっぱいでした。
でも、実際に海外向けにレジュメを出し、ポートフォリオを見せ、面接に進んでいく中で、少しずつ気づいたんです。
「あれ？WPFでやってきたこと、けっこう評価されてるぞ…？」
英語レジュメでは“WPF”より“設計力”で語る
ここで、僕が意識した3つの翻訳ポイントを紹介します。
✅ 1. 技術名じゃなく、設計視点を強調する
❌ NG例：
Developed UI with WPF, using MVVM and DataBinding.
⭕ OK例：
Designed a component-based UI architecture that separated view logic using MVVM, improving maintainability and testability across 40+ screens.
→ ポイントは、「UIをどう考えて設計したか」を語ること。
✅ 2. 結果ベースで伝える
❌ NG例：
Used ResourceDictionary and ControlTemplate.
⭕ OK例：
Standardized UI design through templating and resource management, reducing inconsistencies across 5 modules and decreasing onboarding time by 30%.
→ 「だから何が良くなったの？」を必ず添える。
✅ 3. “技術を超えた貢献”を入れる
⭕ 例：
Collaborated closely with designers and PMs to translate UX concepts into maintainable components, acting as a bridge between design and development.
→ WPFでも「翻訳者」になれるんです。
海外面接で「評価された」質問と答え
特に印象深かった海外面接でのやり取りを2つ紹介します。
💬 Q1. “Tell me about a challenging UI you’ve worked on.”
A（僕の回答要約）
「製造業の案件で、50以上のWPF画面がバラバラの設計になっていて、学習コストとバグが多発していた。そこで共通のコントロールテンプレートとStyleガイドを整備し、ResourceDictionaryを分割設計。これにより、新人開発者の立ち上がりが半分になりました。」
→ 面接官「それってReactのComponent化と同じ考え方だね！」
→ 僕「Yes! That’s why I believe my WPF experience is transferable.」
💬 Q2. “How do you ensure UI consistency across large teams?”
A（要約）
「UI用の命名規則と、XAML Styleの共通ベースを作成してCIでチェック。さらにPull Requestレビューで“画面レビュー”の観点も入れて、コード＋UI両方をレビューできる文化を作った。」
→ 面接官「CodeレビューだけじゃなくてUIレビューも？面白いアプローチだね。」
ポートフォリオで「刺さった」構成とポイント
僕のWPF経験を海外で評価されたポートフォリオは、以下の3構成で作りました👇
🟡① Before/After UI改善例（スクリーンショット付き）
- 業務画面を改善した前後のUIを並べる
- 「課題 → 解決案 → 結果」を簡単な英語で解説
- Figma or PowerPointでの設計意図も添付
例：
“Improved user navigation by reorganizing menu structure and grouping related actions, reducing task time by 40%.”
🟡② コードサンプル＋構造図
- ViewModelとCommand設計の分離構成図
- ResourceDictionaryやテンプレート階層の図解
- GitHubでシンプルなWPFデモプロジェクトを公開
例：
https://github.com/yourname/WpfUiPatterns
🟡③ “Thinking Process”の可視化（考え方を図に）
- 状態管理図
- エラーフィードバックの設計ポリシー
- タブ切り替えやウィザード進行のステート設計
→ 技術よりも「考え方」で魅せることができる。
実際、どんなプロジェクトに採用された？
僕が面接通過・アサインされたのは、こんなプロジェクトでした👇
✅ 医療デバイスのUI再設計（WPF→Blazorへ移行中）
- WPF経験者として既存UIの課題整理と移行設計を担当
- 「このUIって何が使いにくいの？」という問いに答える役割
- MAUIやBlazorの構成に落とし込む設計レビューにも関与
→ つまり、「移行の橋渡し」ができる人材として評価された
✅ 海外スタートアップの業務SaaS UI設計支援
- WPF経験からくる「業務UIの本質理解」が高評価
- Web技術未経験でも「構造思考がある」ことでプロトタイプ設計に参加
- デザイナーとFigmaですり合わせしながら仕様化できた
海外では「プラットフォームより、UI設計の原則」が重視される
面白いことに、どの面接官も技術名よりも以下を見ていました。
- 「この人、UIの再利用性を考えてるか？」
- 「ユーザー体験を言語化できるか？」
- 「UIとロジックの分離ができるか？」
- 「デザイナーやPMと協業する視点があるか？」
つまり、“WPFできる”ことより、“UIを設計できる”ことの方が重要視されていたんです。
転職活動でWPFを“強み”として使うために
最後に、WPFで築いた経験を海外で活かすために僕が実践してよかった3つのことを紹介します👇
🧠 ① UI設計ポリシーを英語でまとめた
例：「Every input should have a default value.」「Group related actions visually.」
→ 英語にすることで“思考の型”が明確に
📘 ② WPFコードをGitHubに英語コメント付きで公開
→ 面接前に見せられる“構造と思考”の証拠に
📹 ③ 画面操作を録画して、設計意図を5分動画で紹介
→ 英語力に自信がなくても「見せる」で勝負できる
“WPFの時代”が、あなたの武器になる未来の話
「これからのUIキャリア、どう描く？」
7つの「やってよかったこと」を振り返ってみると、
そのすべてに共通していたのは──「設計を考え抜く力」と「ユーザー視点」。
これはつまり、
- “技術トレンド”に左右されない
- “プラットフォームを超える”
- “価値を翻訳できる”
──そんなUIアーキテクト的な思考力そのものだったわけです。
そしてこの力こそ、海外でUIエンジニアとして生きていく上で、最大の武器になるんです。
「もうWPFの仕事は少ないから…」で終わらせるのはもったいない
よく見かける意見です。
「WPFはレガシー」「もうWebに移行した方がいい」
たしかにその通り。今後、WPFの新規案件が爆増することはないでしょう。
でもね、ここが大事：
“WPFができる”ことじゃなく、
“WPFで設計できるようになった”ことが武器なんです。
だからもし、あなたがこれまでWPFで、
- 複雑な業務UIを構築した経験がある
- チーム内でUI設計やレビューに関わったことがある
- ResourceやStyleの設計ルールをまとめたことがある
- UXを意識して設計の工夫をしてきた
…なら、そのすべてが今からでも**“国際的に通用するスキル”**になります。
今からできる“UIアーキテクトへの準備”3ステップ
じゃあこれから何をすればいいの？っていう話をまとめます👇
✅ ステップ①：自分の設計思想を言語化する
たとえば、以下の問いに英語 or 日本語で答えられるようにしてみましょう：
- あなたのUI設計におけるこだわりは？
- 「良いUI」って、あなたにとってどんなUI？
- UIの統一性ってなぜ大事？どうやって保ってきた？
これを**“答え”じゃなく、“語れるエピソード”で話せるようにしておく**と、面接・ポートフォリオ・ブログすべてで武器になります。
✅ ステップ②：英語でUIポートフォリオを作る
前回も書いたように、WPF経験を活かすには見せ方が大事。
- Before/After UI
- WPF設計の構造図（View-ViewModel構成、Template構成）
- 改善の理由と効果を簡単な英語で記述
- GitHub＋動画（LoomやYouTube）でもOK！
難しい英語じゃなくても大丈夫。
“Grouped similar actions to reduce decision load.”
“Separated logic with MVVM for easier maintenance.”
このくらいでも十分伝わります！
✅ ステップ③：他技術への“翻訳スキル”をつけておく
あなたの中にある「WPFでやってきた設計の原則」を、
他のUI技術でどう再現できるか？の発想力を磨きましょう。
- WPF → MAUI の画面構成比較
- XAML Style → CSS + Tailwind
- Command + ViewModel → React Hooks + Context
この“翻訳スキル”があると、**「この人は適応力がある」**と見なされやすくなり、海外転職の武器になります。
WPFという土台が、あなたの「UIキャリアの原点」になる
よく言われるのは、
「WPFは終わった技術」
でも僕にとってはこうです：
「WPFは、考える習慣をくれた技術」
- UIの構造をどう分けるか？
- 情報をどう見せればユーザーが迷わないか？
- チームでどう再利用しやすく設計するか？
- UXって何？業務にどう影響するの？
これを毎日悩みながら作った経験は、どんな技術が主流になっても、絶対に腐らない。
“未来のあなた”が感謝する準備を、いま
最後に、あの頃の自分に言ってあげたい言葉があります。
「WPFしかやってこなかったじゃない。
WPFで“ちゃんと考える人”になれたんだよ。」
そして今、もしあなたが同じように不安を抱えているなら、
これだけは伝えておきたいです。
「WPFの設計力は、世界に通じる武器になる」
あとは、それを翻訳し、発信し、見せていく準備をしていくだけ。
あなたの中にある“設計力”を、世界に届けていきましょう。
コメント