WPFから次の技術へ：僕のスキルポートフォリオ戦略

  1. WPFをメインでやってきた僕に、海外で何ができるのか？
    1. きっかけは、あるフリーランス案件だった
    2. “過去のスキル”を、どう“未来の資産”に変えるか？
  2. WPF経験を“スキルポートフォリオ”に変換する方法
    1. 「何ができるか」ではなく、「何をどう活かせるか」
    2. スキル変換表を作ってみた
    3. WPFでやってきた“こだわり”を言語化する
    4. 英語ポートフォリオにどう盛り込んだか？
      1. ⬜ トップページの見出し
      2. ⬜ 技術ブロックの例：MVVMの価値
      3. ⬜ デモプロジェクト（GitHub）
      4. ⬜ 使用技術リスト（Tech stackはあえて狭く）
    5. 「だから次はこれをやる」が語れる状態に
    6. まとめ：WPF経験者が作るべき「未来志向の棚卸し」
  3. WPF経験を次のステージへ ― 技術とキャリアの“壁”を越えて
    1. MAUIへの移行で見えた“理想と現実”のギャップ
    2. それでもWPFで鍛えた“UI力”は通じた
    3. 「技術の切り替え」ではなく、「アーキテクト視点の拡張」だった
    4. 海外面接で問われた“中身”とは
    5. ブレなかったのは「ユーザーが迷わないUI」の追求
    6. 「キャリア戦略」としての“技術選び”
    7. スキルの掛け算で“ニッチ”が“独自性”になる
  4. ニッチを越えて、普遍へ ― 僕の“スキルポートフォリオ戦略”の完成形
    1. 「自分の武器」を言語化できるかが、国境を越えるカギになる
    2. スキルポートフォリオの構成：僕の場合
      1. ① スキルマトリクス（過去→現在→未来）
      2. ② UIアーキテクトとしての原則
      3. ③ 実績付きデモ＋解説ブログ（英語）
    3. グローバル企業で評価される“スキルの見せ方”
      1. ✅ Resumeは「成果＋思考プロセス」で書く
      2. ✅ ポートフォリオはGitHub＋解説セットが強い
      3. ✅ 英語での自己紹介テンプレを持っておく
    4. まとめ：WPFはもう古い？──だからこそ、今がチャンス
    5. 🎁 おまけ：あなたが明日からできる、3つのステップ

WPFをメインでやってきた僕に、海外で何ができるのか？

「WPF？ まだやってるの？」
そんな声を、ここ数年で何度も聞くようになった。日本でも、そして海外の技術系フォーラムやLinkedInのDMでも、同じような反応が返ってくる。実際、.NET MAUIやBlazorの話題で盛り上がる今、WPFをメイン技術にしているエンジニアは、たしかに“少数派”になりつつある。
けれど――僕はそれを、むしろ「チャンス」だと思っている。

僕の名前はHiro（仮）。日本で10年以上、業務アプリや社内システムのUI開発をWPF中心に担当してきた。MVVM設計でクリーンアーキテクチャに近づけたり、XAMLで動的なデザインシステムを構築したり、時にはWCFや旧来のWinFormsとのブリッジ役もやったり…。プロジェクトの内容も規模も様々だったけれど、振り返ってみると一貫して「UIの質」にこだわってきた。

そして、30代後半に差し掛かるタイミングで、僕は“海外転職”という選択肢を本気で考えはじめた。

きっかけは、あるフリーランス案件だった

ある日、とある外資系スタートアップの案件に、リモートで関わるチャンスが訪れた。内容は「旧資産のWPFアプリをモダン化するプロジェクト」。設計はぐちゃぐちゃ、コードはスパゲッティ、ドキュメントはなし――まさに日本のSI案件で鍛えられた僕には“馴染み深いカオス”だった。
けれど、面白かった。英語でのコミュニケーション、海外エンジニアの開発スタイル、アジャイル文化の肌感…それらすべてが新鮮で、「WPFしかやってこなかった自分」が海外で通用するかどうかをリアルに試せた。

この経験で気づいたのは、「技術のモダンさ」よりも、「技術の深さ」の方が武器になる場面がある、ということだ。
WPFという技術そのものは、確かに“新しくはない”。でも、UIアーキテクトとしての思考法、業務システム特有のユーザー体験設計、MVVMパターンの応用力――それらは、今でもグローバルに通じる“ニッチな価値”だった。

“過去のスキル”を、どう“未来の資産”に変えるか？

じゃあ、ここからどうやって海外キャリアに繋げていくか。
僕は「WPFができる」ことをゴールにせず、「WPFから何を抽象化して、他の技術に転用できるか」をとことん考えた。
UI設計？UXアーキテクチャ？アプリ全体のState設計？
自分の経験をパーツに分解し、次に学ぶべき技術（MAUI、Blazor、React、Flutterなど）とつなげる「スキルブリッジ表」を作ったのもこの頃だ。

「WPFをやってた人に、これから何ができるか」
これは、世界中の“かつてのWPFエンジニア”全員に突きつけられているテーマだと思う。

WPF経験を“スキルポートフォリオ”に変換する方法

「何ができるか」ではなく、「何をどう活かせるか」

WPFの経験を持っていると、つい「WPFができます」「XAMLに詳しいです」「MVVMパターンを熟知しています」みたいな“技術名＋できます”形式で自分を語りがちになる。かつての僕もそうだった。けど、海外転職やグローバル案件に挑戦し始めて気づいたのは、それじゃ通用しないということ。

海外の企業やクライアントが求めているのは、**「あなたはこのプロジェクトにどう貢献できるか？」**であって、「WPFに詳しいこと」そのものではない。

例えば、こんな聞かれ方をしたことがある。

“How does your experience in WPF translate to cross-platform development strategies?”
（WPFの経験を、クロスプラットフォーム開発戦略にどう活かせますか？）

最初は答えられなかった。でも、そこから自分の中で「スキル変換表」を作るようになった。

スキル変換表を作ってみた

僕が最初に作ったのは、以下のような**「スキル変換マップ」**だった：

WPFスキル抽象化された設計スキル転用先の技術・分野
MVVM + RelayCommand + DataBinding状態管理の設計、UIロジックの分離React + Redux / MAUI / Flutter
XAMLによるUI設計宣言型UI、レスポンシブデザインへの応用Blazor / MAUI / SwiftUI
ResourceDictionary + DynamicResourceデザインシステム、テーマ管理Tailwind CSS / Material UI / MAUI Styles
Dispatcher + Thread管理非同期UI制御の理解JavaScriptのEvent Loop / .NET async/await
ValueConverter / DataTemplateSelectorUIレイヤの柔軟性設計Reactのカスタムコンポーネント設計

こうしてみると、「WPFしかやってない」というのは幻想で、実は僕は「UI設計力」を多角的に積み上げてきていたことに気づいた。

WPFでやってきた“こだわり”を言語化する

でも、これをただ表にまとめただけじゃ意味がない。次にやったのは、それぞれのスキルを具体的なエピソード付きで言語化すること。

例えば：

  • 「ユーザーから“動きが重い”と言われた画面を、非同期処理＋UIの段階的レンダリングで3秒→1秒に短縮した」
  • 「ResourceDictionaryを100ファイル以上に分割し、テーマ変更に耐えるスケーラブルなデザインシステムを組んだ」
  • 「XAMLのTriggerやStoryboardを組み合わせて、アニメーションで業務アプリの直感性を向上させた」

こういったエピソードを、“技術スタック”ではなく、“課題→工夫→結果”という流れで語れるようにする。これがそのまま英語の面接やポートフォリオの材料になる。

英語ポートフォリオにどう盛り込んだか？

実際に、僕はこの変換マップとエピソードをもとに、以下のような英語ポートフォリオサイトを構築した：

⬜ トップページの見出し

“I design future-proof UIs from deep-rooted legacy systems.”

⬜ 技術ブロックの例：MVVMの価値

“In a 3-year legacy WPF system, I restructured the UI logic using MVVM, decoupling the View from business rules and increasing test coverage from 15% to 68%.”

⬜ デモプロジェクト（GitHub）

  • ModernWpfSample: Fluent Designを取り入れたWPF UI
  • WPF-to-MAUI: 1つの業務画面をMAUI版に移植し、ソース比較付きで公開

⬜ 使用技術リスト（Tech stackはあえて狭く）

  • WPF / XAML / C# / MVVM Light
  • MAUI / .NET 8 / GitHub Actions（CI/CD）

「だから次はこれをやる」が語れる状態に

僕がポートフォリオや面接準備で大事にしているのは、「過去→現在→未来」がつながっていること。

「WPFで得た知見をこうやって抽象化し、それをMAUIやBlazorに展開しながら、最終的にはUIアーキテクトとして設計ガイドラインをまとめていきたい」

というストーリーが語れると、**“ニッチ”ではなく、“専門性”**として受け取られる。

まとめ：WPF経験者が作るべき「未来志向の棚卸し」

  • 自分がWPFで“何をしてきたか”ではなく、“それがどのような原則や設計哲学に基づいているか”を掘り下げる
  • スキル変換表を作って、他技術への展開を明示する
  • 「なぜMAUI？なぜBlazor？Reactじゃダメなのか？」という問いにも自分なりの答えを持つ
  • 英語で言語化できるようにしておく（Resume, LinkedIn, Portfolio, 面接）

WPF経験を次のステージへ ― 技術とキャリアの“壁”を越えて

MAUIへの移行で見えた“理想と現実”のギャップ

僕がWPFから次の技術へとスキルポートフォリオを広げる中で、最初に本格的に取り組んだのが .NET MAUI だった。WPFに近いXAML構文、データバインディング、MVU（Model-View-Update）とMVVMのハイブリッド的な思想──表面上はとてもスムーズに乗り換えられそうだった。

ところが、実際に手を動かしてみると、**意外な“壁”**がいくつも立ちはだかった。

たとえば：

  • 動的なレイアウト変更：WPFのようにGridとTriggerで自在に切り替え…と思ったら、MAUIのレスポンシブ対応はそれとは設計思想が異なり、CSS的な思考に近いものが求められた。
  • Commandの伝播：WPFで使っていたRelayCommandやイベントバブルの考え方が、MAUIでは意外とハマらない。
  • プラットフォーム依存：MAUIはクロスプラットフォームを謳っているけれど、実際には「Androidでは動くが、Windowsでは微妙」「iOSビルドで謎のエラー」なんてことも日常茶飯事。

それでもWPFで鍛えた“UI力”は通じた

でも、そんな中でも確かな自信に変わったのが、UI構造を言語化し、チームに伝える力だった。

例えば、MAUIプロジェクトでUIが複雑になった時、チームメンバーから「この画面、何を基準にレイアウトしてるの？」と聞かれたとき、僕はWPFで鍛えた以下のような資料を即座に作った。

  • ステート別のレイアウト構造図（XAML構造図ではなく“論理構成”ベース）
  • バインディング一覧とState依存関係
  • UI構成の「可読性」「操作ステップ数」「視線の動線」比較表

これを英語でまとめて「UI Design Brief」として提出すると、プロジェクトマネージャーからも「This level of design thinking is rare in mobile teams」と言われた。つまり、WPF時代に当たり前にやっていた“画面設計の説明力”が、MAUIや他の技術でも価値を持って通用したということ。

「技術の切り替え」ではなく、「アーキテクト視点の拡張」だった

ここで、僕の中の意識が大きく変わった。
単に「WPFからMAUIへ」と技術を“乗り換える”のではなく、設計アーキテクトとしての視座を拡張するという視点にシフトした。

たとえば、次のように捉え直した：

Before（旧来の視点）After（アーキテクト視点）
UIフレームワークごとにコードを覚えるUIの設計原則・状態遷移・UX思考を技術に落とし込む
「この技術をマスターしたらOK」「どんな技術にも共通する設計方針を持つ」
技術が古くなったら価値が落ちる技術が変わっても“抽象化した知見”は価値を持つ

海外面接で問われた“中身”とは

実際に、海外企業（特にヨーロッパ圏やシンガポールなどの開発チーム）での面接では、「技術名」よりも設計思想や意思決定プロセスに関する質問が多かった。例えば：

“How do you decide which UI pattern to apply in a new project?”
“Have you ever had to refactor a legacy UI structure? How did you approach it?”
“What trade-offs do you consider between responsiveness and maintainability?”

WPF時代にやってきた“地道な判断”──たとえば、

  • 「すぐに書けるけど、テストしにくい設計は避ける」
  • 「XAMLに詰め込みすぎず、ViewModelとModelで責務分離」
    といったポリシーが、まさにこの問いへのリアルな答えとして使えるのだ。

ブレなかったのは「ユーザーが迷わないUI」の追求

何を技術でやってきたか？よりも、「どんな価値観でUIを作ってきたか？」を話す場面が本当に多い。

僕の場合、それは “ユーザーが迷わない設計” だった。
たとえ複雑な業務フローでも、ユーザーが「次にどこを押せばいいか」「今どんな状態か」が一目でわかるUIにする──それが、WPF時代から変わらない自分の核だった。

その価値観がMAUIでもBlazorでも、さらにはFlutterの案件でも求められたことが、キャリアの指針となった。

「キャリア戦略」としての“技術選び”

ここで重要なのは、「次に学ぶ技術」を“流行”や“新しさ”だけで選ばないこと。
僕はWPFから次の一手を考えるとき、以下の3つの軸で判断していた：

  1. UIアーキテクトとしての視点を深められるか？
  2. 多国籍チームや海外市場で需要があるか？
  3. 自分の強み（設計力、保守性、業務系UI）を活かせるか？

この軸で考えると、.NET MAUI、Blazor、React＋TypeScriptなどはそれぞれ違った意味で“あり”だった。
結果的に、僕はMAUIとReactの両方に手を出し、**WPF×MAUI×Reactの“3枚構成ポートフォリオ”**を武器にしていった。

スキルの掛け算で“ニッチ”が“独自性”になる

最後に伝えたいのは、WPFがニッチであることを恐れないでほしいということ。
むしろ、それを「どう活かせるか」「どう語れるか」で、“他にはないポジション”が築ける。

WPF + MAUI
WPF + Blazor
WPF + React（状態設計の視点）
どれも、UI設計という本質的な強みを持ったエンジニアとして評価されうる。

ニッチを越えて、普遍へ ― 僕の“スキルポートフォリオ戦略”の完成形

「自分の武器」を言語化できるかが、国境を越えるカギになる

WPFをやってきた──それだけでは、たしかに今のグローバルIT業界では刺さらない。
でも、「WPFで培ったUI設計の原則を、どう他技術に応用してきたか」や、「どんな問題を、どんな戦略で解決したか」を語れるようになると、それは一気に海外でも通用するポートフォリオに変わる。

僕がこの数年で特に意識してきたのは、**スキルの“表現力”**だ。

どんなにすごい仕事をしていても、それを「WPFやってました」の一言で終わらせたら伝わらない。でも、たとえばこう言ったらどうだろう：

“I specialize in designing maintainable and scalable UI architectures. My experience in WPF has given me a deep understanding of UI state management, MVVM separation, and responsive layouts — principles I now apply across platforms including MAUI and React.”

この一言にたどり着くまでに、僕は何十回と履歴書を書き直し、ポートフォリオの構成を練り直し、海外のエンジニア仲間にレビューしてもらった。
技術を“並べる”のではなく、“つなげて、語る”こと。それが、スキルポートフォリオ戦略の核心だと今では思っている。

スキルポートフォリオの構成：僕の場合

最終的に僕が作った「見せるスキルポートフォリオ」は、次の3つの柱で構成されている：

① スキルマトリクス（過去→現在→未来）

WPFを起点に、現在学習・活用中の技術、そして目指す将来のスキル像をマトリクス化。

時期フレームワーク担当領域学んだ設計視点
2012-2018WPF (.NET 4.5〜)UI構築・業務アプリ保守MVVM、DataTemplate、UX思考
2019-2022WPF + .NET Core設計リード・DX化支援アーキテクチャ設計、CI/CD
2023〜MAUI / Reactグローバル開発PJ・UX設計クロスプラットフォーム対応、状態管理設計

② UIアーキテクトとしての原則

  • 状態はシンプルに設計せよ
  • 「変化する部分」と「変化しない部分」を分離せよ
  • ユーザーの“迷い”をゼロにするための一貫性を持たせよ
    これらの原則を「設計ガイドライン」という形で文書化し、海外案件でのディスカッション資料として活用している。

③ 実績付きデモ＋解説ブログ（英語）

GitHub上に複数のWPF・MAUI・Reactプロジェクトを公開し、各プロジェクトに紐づけて英語ブログを書いた。

例：

これらのコンテンツは、「技術力」ではなく「設計思考力」を見せるために作った。

グローバル企業で評価される“スキルの見せ方”

海外で働きたい、グローバルプロジェクトに関わりたい──そう考えるWPFエンジニアに伝えたいのは、以下のポイントだ。

✅ Resumeは「成果＋思考プロセス」で書く

ただ「WPFアプリを開発」ではなく、

“Refactored a 5-year-old WPF system using MVVM and data templates, reducing maintenance cost by 40% and improving UX consistency.”

✅ ポートフォリオはGitHub＋解説セットが強い

英語圏の採用担当者は「コードだけ」では理解しきれない。READMEやNotionページで「何を設計し、どう工夫したか」を添えるのが重要。

✅ 英語での自己紹介テンプレを持っておく

例えばZoom面接や案件獲得時に使う、以下のような1分スピーチ：

“Hi, I’m Hiro from Tokyo. I have over 10 years of experience in UI development, mainly using WPF. I focus on building maintainable UI architectures and am currently expanding into cross-platform frameworks like MAUI and React. My strength lies in designing interfaces that reduce user friction and support long-term scalability.”

まとめ：WPFはもう古い？──だからこそ、今がチャンス

WPFはたしかに「新しくはない」。
でも、「だからこそ武器になる」のが今の時代だ。

  • 少数派になることで、逆に専門性が際立つ
  • 他技術に展開するための抽象的な設計力を持っている
  • 海外ではまだWPF資産が多く、移行プロジェクトが多数存在する

つまり、「WPFをやってきたこと」がキャリアの足かせになるのではなく、“次の技術を理解するためのベース”になり得るということ。

僕は今、WPFで育ったからこそ、海外でReactのUI設計レビューを任されたり、MAUIのガイドライン策定に関われるようになった。

「WPF経験者のまま終わるな。WPF経験者だからこそ、その先に進める。」

それが、このVol.5で僕が最も伝えたかったメッセージだ。

🎁 おまけ：あなたが明日からできる、3つのステップ

  1. 自分のWPF経験を「問題解決ストーリー」に言語化してみる
  2. MAUIやBlazorのミニプロジェクトを作り、GitHubにアップする
  3. 英語の自己紹介＆成果紹介テンプレをNotionにまとめておく

コメント

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