「UIアーキテクトって何？WPFエンジニアの次なる航路を探し始めた話」

キャリアの「次」が見えなかったWPFエンジニア時代

「次、どうする？」
これは、ある日、ふとコーヒー片手にSlackを眺めながら自問自答した言葉だった。僕はその時、ドイツのソフトウェア企業で働くWPFエンジニアだった。プロジェクトは安定してるし、コードも書ける。MVVMも熟知してるし、チームレビューも慣れたもの。だけど、**“その先”**が見えなかった。

WPFって、WindowsアプリのUI作るには最強のフレームワークだと思う。XAMLでのデザイン、強力なデータバインディング、豊富なカスタムコントロール。何より、**「ユーザーの手に直接触れる部分を自分の手で作っている」**という実感があった。

でも、そんなある日。
「このプロジェクトが終わったら、次はなに作るの？」
「自分はずっとWPFでいいの？」
「もしWPFが縮小していったら、自分の強みって通用する？」

そんな疑問が、じわじわと頭に浮かんできた。で、ネットを漁って、Qiitaを見て、RedditやStack Overflowを徘徊して、行き着いたのが**“UIアーキテクト”**というキャリアパスだった。

---

「アーキテクト」って聞くだけでなんか遠い存在だった

「アーキテクト」って言葉、最初は正直、自分には関係ない世界の人だと思ってた。
クラウドインフラとか、大規模なシステム設計とか、そういう“すごそうな人たち”の肩書きというイメージ。

でも、実はUIにも「アーキテクト」がいる。しかも、UX/UIのクオリティが売上に直結するようなSaaS企業やFinTechスタートアップではめちゃくちゃ重要なポジションになってる。

ちょっと具体的に言うと、UIアーキテクトって以下のようなことを担う職種：

• アプリ全体のUI設計思想の策定（Consistency, Accessibility, Responsiveness…など）
• デザインシステムの技術面の実装・管理
• 開発チームへのUIコンポーネントガイドラインの共有
• フロントエンド（WPFやBlazor、MAUIなど）における技術選定と設計レビュー
• UXデザイナーとの連携・調整役

要するに、見た目のデザインを超えて「技術としてのUI」を設計・統括するのがUIアーキテクトってことらしい。で、WPFで長年やってきた自分の経験――特にMVVMの理解、XAMLの高度なコントロール設計、アクセシビリティ対応のノウハウ――が、これにめちゃくちゃ近いという事実に気付いた。

---

WPF経験がUIアーキテクトへの“筋トレ”になっていた？

WPFって、「ちょっとしたUIを手軽に作る」っていうよりも、「深く考えて、正しく設計する」のが求められるフレームワークだと思う。

例えば、DataTemplateの最適化、Bindingエラーの解析、UIのレスポンス改善、ユーザー入力の検証ロジック、Styleの共通化、リソースディクショナリの設計…。全部「設計力」が問われる。

これってまさに、UIアーキテクトに求められるスキルと直結してる。だからこそ、自分が無意識に積んできた経験が、次のキャリアへの“下地”になってることに気づいた。

しかも、今の時代はWPFからBlazorやMAUIへの移行もあるし、企業によってはReactやFlutterなどへの技術選定も任されることがある。そういったUI技術の比較検討・選定に強いエンジニアが、UIアーキテクトとして非常に重宝されるんだ。

---

「コードだけじゃないUI」を考えるようになった瞬間

このあたりから、「自分のキャリアは“WPFエンジニア”で終わらせなくていいんじゃないか？」って思えるようになった。というより、**“自分がユーザーに届けたい価値ってなんだっけ？”**と、もう一段深い問いを持つようになった。

• なぜこのUIにしたのか？
• なぜこの配置・遷移なのか？
• ユーザーの期待と実際の操作感のギャップは？
• アクセシビリティや国際対応は？
• デザインと実装の間をどう埋める？

これって、コードだけじゃなく「設計」「戦略」まで踏み込む思考。そして、それこそがUIアーキテクトの土俵なんだと知った。

気づいた“道”を、どう歩き始めたか

「よし、UIアーキテクトを目指してみよう」
そう決めたのは、ある意味で自然な流れだった。だけど、いざ動こうとすると、何から始めればいいかわからなかった。

当時の僕の状態をざっくり言うと：

• メイン言語はC#、WPFが中心
• 英語での業務コミュニケーションはそこそこ（技術MTGは対応可）
• UXデザイナーと共同作業した経験は少しだけ
• デザインシステムやFigmaの深い理解はなし
• Web系フロント（Reactなど）は未経験

つまり、「UIアーキテクトを目指すにはちょっとギャップがある」状態だった。

---

Step1：自分の「設計」を言語化するところから始めた

WPFって、「頭で考えて、手で組み上げるUI」だと思う。だから設計力が問われる。でも、それを他人に伝わる形で言語化する練習を、僕はしてこなかった。

たとえばこんなことを、Notionに書き起こすことから始めた：

• このDataTemplateをなぜこう設計したのか
• レスポンス改善のために何をしたか
• アクセシビリティ（たとえばTabIndexやScreen Reader）にどう対応したか
• UIの一貫性をどう保っているか（スタイル、テーマ、コントロール構造など）

これを英語で書いてみると、意外と難しい。でも、「これはUIアーキテクトの練習になる」と思って、とにかく書いた。そして、それをGitHubポートフォリオに添えてみた。

---

Step2：WebやMAUIにも“足を突っ込む”

次にやったのは、「WPFだけでは足りない」問題への対策だった。
なぜなら、海外求人を探していると、UIアーキテクトポジションでは“クロスプラットフォーム”や“Web UI”への知識が求められることが多いからだ。

そこで僕は、MAUIとBlazorを使ってミニアプリを作ることにした。

• MAUI → WPFとの感覚が近く、モバイルUI設計の勉強になる
• Blazor → Web UIのアーキテクチャ理解とC#資産の活用

これに取り組んでいくうちに、「XAMLベースUI設計」と「WebベースのUI設計」の違いも体感できるようになった。結果的に、「技術的に中立な立場でUI設計を考える」視点が鍛えられてきた。

そして、WPFの知見とBlazorの知見を融合させて、**“クロスプラットフォームUI設計ガイド”**みたいなドキュメントを作った。これをLinkedInのポートフォリオに載せたことで、実際にリクルーターから「面白い取り組みですね」と連絡が来た。

---

Step3：社内で「UIの相談役」ポジションを自分で作った

「UIアーキテクト」って、別に役職名がそうじゃなくても、“その仕事をすること”自体がキャリアに直結すると思ってる。だから、当時いた会社で僕は、自ら「UIレビューの時間」を作るようにした。

• WPFプロジェクトのコードレビュー時に、UI観点の指摘も行うようにする
• UXチームが作ったワイヤーフレームに対して、「技術的にこうしたらもっと良くなる」というフィードバックを出す
• 週1回の「UI設計共有会」をエンジニア向けに開催（希望制）

最初は誰も来なかった（笑）。でも2ヶ月目くらいから徐々にデザイナーや若手エンジニアが参加するようになって、「〇〇さん、あの画面の設計ちょっと見てもらえますか？」と声をかけてもらえるようになった。

これは明確に、「UIに関する技術的な相談＝この人にすればいい」と社内で認識され始めた証拠だと思う。

---

Step4：LinkedInとポートフォリオで「UIアーキテクト候補です」と発信

「実績ができたら、発信しよう」っていうのはよく聞くけど、発信しないと実績として認識されない世界でもあるのがエンジニアのキャリア。

だから、僕は以下のような英語の投稿を定期的に出すようにした：

• UI設計で気をつけている10のこと
• WPFからMAUIへのUI構造の違いメモ
• デザイナーと開発者の間で起きがちなすれ違いと、その対策
• UIアーキテクトというロールの重要性と学び

そして、GitHubに載せたプロジェクトにも、**「UI設計観点での工夫」**をREADMEに明記した。

“This project aims not only to showcase a working MAUI app, but also to demonstrate the application of UI architectural principles across cross-platform environments.”

こうした発信がきっかけで、UIアーキテクトポジションでの面談に数件つながった。

---

ここまでのまとめ：UIアーキテクトになるまでの“布石”

✅ 自分のUI設計経験を言語化して記録した
✅ MAUIやBlazorなどを通してクロスプラットフォームUIにも挑戦
✅ 社内で「UIレビュー」を通じて実質的なアーキテクト業務を担当
✅ LinkedInやGitHubで発信し、海外からの反応を獲得

これらを通して、少しずつ「UIアーキテクト候補」としての立ち位置を築いていった。

海外UIアーキテクト転職、本気でやってみた

UIアーキテクトというキャリアパスが見えてきたとはいえ、それを**「他人から正式に認められる」**というのは、また別の話。
特に、日本から世界に出て「UIアーキテクトとして採用される」ことは簡単ではなかった。

このパートでは、実際の転職活動の流れ・英語での戦い方・評価されたこと／されなかったことを赤裸々に書いていこうと思う。

---

リアルその①：LinkedIn経由での応募は、まず見た目勝負

最初に気づいたのは、「履歴書よりLinkedInが本体」という現実だった。海外では採用担当もエージェントも、まずはLinkedInでその人の経歴・スキル・実績をチェックする。

だから僕は、LinkedInのプロフィールを以下のように整備した：

• タイトル：UI-focused Software Engineer | C# / WPF / MAUI / Blazor | Cross-platform UI Architect Candidate
• 概要欄（About）：
  • UI設計の原則（Consistency, Accessibility, Responsiveness）
  • 使用技術（WPF/MAUI/Blazor、Figma連携経験など）
  • 設計指向での取り組み（デザインシステム化、コードの再利用性）

さらに、ポートフォリオへのリンクも明記。
ここで意識したのは、「私は“UIデザインと技術の橋渡しができる人材”です」と明確に伝えることだった。

---

リアルその②：ポートフォリオの“語り方”がすべて

実際に何度か面接のチャンスを得たが、そこで強く感じたのは、
「コードを書けるだけ」ではUIアーキテクトとしては評価されないということだった。

求められるのは、**“設計の意図を、言語化しながらプレゼンできる力”**だった。
たとえば、ある面接で聞かれた質問はこうだ：

“Can you explain how you structure your UI components in a scalable WPF application, and why you chose that approach?”

ここで重要なのは、コード構造の説明だけじゃダメということ。
「なぜその構造にしたのか？」、「その設計がUXにもたらす影響は？」、「他の選択肢との比較は？」まで含めて話すことが求められる。

なので僕は、自作アプリの中から一つを選んで、プレゼン資料を5枚くらい作って練習した。

構成は以下の通り：

1. アプリの概要と目的
2. UI構成と画面フロー
3. 主要なコンポーネント構成（MVVM設計の工夫点）
4. アクセシビリティやレスポンス対策
5. 他技術（MAUI/Blazorなど）と比較した理由

この発表練習を通じて、「UI設計力は技術だけでなく、“説明力”でも評価される」ということを痛感した。

---

リアルその③：英語力の壁をどう越えるか

技術的には話せる。でも、「UIの話は抽象度が高い」から、語彙や比喩表現が必要になる。

たとえば「ユーザーの行動予測に基づいたUI配置」や「デザインシステムとの整合性」みたいな話をするには、以下のような表現を覚えておくと便利だった：

• “Maintain visual hierarchy and interaction predictability”
• “We established a reusable component library to enforce design consistency.”
• “I advocated for accessible-by-default design decisions, including keyboard navigation and screen reader support.”

これらの表現を自分の体験と組み合わせて語れるように準備しておくことが、英語面接での大きなアドバンテージになった。

---

リアルその④：履歴書と職務経歴書のチューニング術

海外では「職務経歴書（CV）」よりも、**“成果重視のレジュメ（1〜2枚）”**が求められる。そこで僕はこうした書き方をした：

UI Engineer (WPF / MAUI) | 2020 – 2024

• Led UI architecture for enterprise desktop apps (100k+ users), ensuring design consistency and modularity
• Designed and implemented reusable XAML components, reducing UI defect rate by 30%
• Collaborated with UX teams using Figma, translating wireframes into accessible and responsive UIs
• Spearheaded transition from WPF to MAUI, evaluating performance, maintainability, and developer experience

ポイントは、「具体的な数値」や「影響範囲」をできるだけ書くこと。
そして、“UI設計力”があることを数字と言葉で可視化する。

---

リアルその⑤：うまくいった応募と、落ちた応募の違い

海外のUIアーキテクト職に何十社と応募した中で、うまくいった会社には共通点があった。

✅ UIがビジネスの中核にある（例：SaaS、ヘルスケア、金融など）
✅ フロントエンドとバックエンドが分業されている組織体制
✅ アクセシビリティや国際対応に真剣な企業文化

一方で、以下のような応募先は、ことごとく落ちた：

❌ エンジニアがUIも全部「ついでにやる」ような会社
❌ UIデザインが外注されていて、実装側がコントロールできない現場
❌ UI技術よりもドメイン知識やバックエンド重視の職種

つまり、「UIアーキテクトとして活躍できる現場を選ぶ目」も大切だった。

---

結果：最終的にたどり着いた「一社」との出会い

何十社とやりとりして、ようやくご縁があったのは北欧のヘルスケア系スタートアップだった。
プロダクトはMAUI＋Blazorで動いており、アクセシビリティとUXが命。

面接では、まさに僕が作った「クロスプラットフォームUI設計ガイド」や、「WPFのXAML設計ベストプラクティス」が響いたようだった。

最終面接で言われたのは、こんな言葉だった：

“We’ve seen many developers with great technical skills, but very few can explain UI decisions the way you do.”

このとき初めて、「ああ、UIアーキテクトって、技術と会話の両方が問われるロールなんだ」と確信した。

UIアーキテクトとしての仕事が始まった

最終面接を通過し、無事にオファーを受け取ったときは、ただただホッとした。
でも、それ以上に感じたのは「ここからが本番だ」という緊張感だった。

新しい職場は北欧のヘルスケアSaaS企業。
プロダクトはMAUI＋Blazorベースで、医療従事者や患者が日常的に使う。
UIの「見た目」だけじゃなく、「安心感」「正確さ」「誤操作の回避」まで求められる、超実戦的な現場だった。

---

UIアーキテクトの仕事＝“技術”と“対話”の毎日

UIアーキテクトとしての役割は、本当に多岐にわたる。コードも書くけど、それだけじゃない。

たとえば、ある日のタスクリストはこんな感じだった：

• Figmaで作られた新しい画面案の構造レビュー
• デザインガイドに沿った新しいBlazorコンポーネントの提案
• モバイルとデスクトップでの共通UI設計についてチームとディスカッション
• 「このUIはAccessibilityガイドラインを満たしてる？」とQAチームと確認
• デザイナーと開発者のあいだで出た認識ズレの調整ミーティング
• 社内WikiにUI設計ルールを英語で書き起こす

そう、UIアーキテクトは「一人ですごいものを作る人」ではなく、「チームのUI体験を高める設計と対話の専門家」だった。

---

海外のチーム文化がくれた“余白”

働いて驚いたのは、日本との文化の違い。特にUIに対するアプローチが根本的に違う。

• 🇯🇵 日本：「とりあえず動くものを作る」「指示通りに再現」
• 🇸🇪 北欧：「ユーザーはどこで戸惑う？」「この画面、本当に必要？」

たとえば、新しい機能を作る際、日本では「要件定義書にあるから作る」が当たり前だったけど、今の職場では**「この機能って、本当に必要？」**と、UIから議論が始まる。

UIアーキテクトとしての僕の役割は、そこで技術的観点を持ちつつ、ユーザーの視点も代弁すること。
つまり、「UI＝デザインの最終工程」ではなく、「UI＝ビジネスとユーザー体験の対話の場」として位置づけられていた。

---

技術から“哲学”へ：UI設計における自分なりの信念が生まれた

この仕事を通じて、UI設計に対する“哲学”のようなものが、だんだん自分の中に育っていった。

「そのUI、誰のため？」

すべての設計判断の前に、この問いを自分に投げるようになった。

• ユーザーが迷わないように、情報量を減らすべきか？
• モバイル利用者の“片手操作”を前提にすべきか？
• 色覚障がいを持つ人にもちゃんと伝わる配色になっているか？

そして、答えが出たら、それをチームと共有できる言語で語る。
そのプロセスこそが、UIアーキテクトとしての“実務”だと実感している。

---

日本で得た武器が、海外で効いている

ここまで来て、あらためて思うのは、WPFで培った“設計力”は決して古くなっていないということ。
むしろ、**「UIを深く設計する力」**は、時代やフレームワークが変わっても通用する。

たとえば：

• DataTemplateの構造を意識した設計力 → MAUIやBlazorでも通用
• XAMLのスタイル再利用設計 → Web Componentsの思想と近い
• MVVMの構造把握 → Clean Architectureとの相性抜群
• 日本的な“気配りUI” → 北欧では「Thoughtful UX」として高評価

つまり、WPFで“深く考える癖”をつけたことが、今の自分の最大の強みになっている。

---

「UIアーキテクト」は、これからもっと必要になる

SaaS、モバイルアプリ、マルチデバイス対応…。
ユーザーが触れる「UI」の重要性は、これからも増す一方だ。

そして、デザインと開発の分業が進む中で、“橋渡し役”としてのUIアーキテクトの存在が求められるようになっている。

さらにAIの進化によって、UI自体もダイナミックに変化していく。

• ユーザーごとにUIを自動最適化？
• ノーコードツールの設計支援？
• アクセシビリティ対応の自動チェック？

そんな未来の中で、「UIをどう設計するか」という視点を持っている人の価値は、さらに高まると思う。

---

そして、次の挑戦へ

今の会社では、UIアーキテクトとしてしっかり立ち位置を築けた。
でも、自分の中ではまだ終わりじゃない。

• グローバルチームを横断してデザインシステムを構築してみたい
• 日本と海外のUI設計文化の違いを橋渡しできるポジションにつきたい
• OSSでUI設計のベストプラクティスを発信したい
• 自分の名前でUIアーキテクチャに関する書籍やブログを書いてみたい

そう、UIアーキテクトというキャリアは「ゴール」じゃなくて、「舞台に立ったばかり」だった。

---

最後に：これからUIアーキテクトを目指すあなたへ

もしあなたが、今「WPFだけでいいのかな」と感じているなら、それはとても健全な感覚だと思う。
そして、もし「UI設計っておもしろいな」と思えるなら、UIアーキテクトという道を、選択肢として本気で考えてみてほしい。

大切なのは、「UIを深く考える力」と「それを人に伝える力」。
この2つがあれば、どの国でも、どの言語でも、どんなUIでも、きっと通用する。