- WPFで積み上げた“設計力”は、黙っていても伝わらない。
- コードの外にある「設計の意図」をどう可視化するか？
- “コードだけでは伝わらない”設計力をどう見せる？
- 実例ベース：UI設計ポートフォリオの構成テンプレート
- ポートフォリオの“語り口”は「設計視点のブログ形式」がおすすめ
- 海外向けなら英語での説明文を用意しておこう
- まとめ｜設計力は、資料で“見せる”からこそ伝わる
- “WPFで磨いた設計力”は、どの技術でも通用する
- なぜ「WPF出身」は他技術に強いのか？
- UI設計の“汎用スキルマップ”に変換してみる
- 「UI設計ができる人」を示す3つのキーワード
- UI設計力を“面接で語る”ためのストーリーテンプレート
- 設計視点を“次のキャリア”にどう活かすか？
- まとめ｜「設計力」は、翻訳力と語彙力で価値が決まる
- “作れる人”を超えて、“設計できる人”になるために
- 最後に立ちはだかる壁：「作った実績はある。でも…」
- ポートフォリオは「結果」ではなく「思考過程」を見せる場所
- “設計できる人”と見なされるための3つの工夫
- UI設計力を“ブランド”に育てる
- “WPFはレガシー”ではない。“設計の土台”だ。
- 【まとめ】UI設計力は、ポートフォリオという“言語”で語れ
WPFで積み上げた“設計力”は、黙っていても伝わらない。
「コードが書けること」と「設計できること」は違う
転職や案件提案のとき、WPFやUI開発の経験を伝える際に、こんな言葉を何度も聞いてきた。
「WPFの経験はあるんですね。でも、それって最近はあまり使わないですよね？」
「具体的に、どのような画面を作ってきたんですか？」
「ポートフォリオって、どこで見れますか？」
この問いにどう答えるかが、WPF経験者の“キャリアの分かれ道”になる。
UI設計力は、コードでは伝わらない。
実際、多くの開発者がGitHubにXAMLとViewModelのコードを載せている。
でも、それを見た面接官やクライアントが「おお、すごい！」と感動することはまずない。
なぜか？
- 見ただけでは、「なぜそう設計したか」がわからない
- 機能よりも“使いやすさ”の設計意図が伝わってこない
- UIに対してどんな哲学や考えを持っているかが見えない
つまり、UI設計力は“意図と言葉”とセットでなければ評価されないのだ。
海外のUI面接では、“設計の意図”を説明させられる
特に僕が海外で経験して驚いたのが、
「作ったものの背景や設計方針」をかなり深掘りされるという面接スタイル。
たとえばこういう質問が来る：
- 「なぜその構成にしたのか？」
- 「そのUIを、他のフレームワークでも再現するとしたら？」
- 「ユーザーの行動をどう想定して設計したのか？」
- 「スタイルやテーマは、再利用可能な構造になっているか？」
日本だと実装力や実績ベースの質問が多いけれど、
海外では“設計の思考”こそがスキルとして評価される。
WPF経験者にとって、ここは逆に“武器にできるポイント”なのだ。
「UI設計の思考」を見せるポートフォリオとは？
だから、Vol.5ではこういう課題を扱っていく。
✔︎ UI設計力を伝えるには、どういうポートフォリオが効果的か？
✔︎ コードだけではなく、“設計理由”をどう言語化するか？
✔︎ WPF経験を他技術にも応用可能な“設計力”として表現するには？
これは、「WPFで画面を作った」人の話ではなく、
「WPFで設計力を磨いた」人が、その価値をどう証明するかという話になる。
僕自身の例：コードから“設計意図”を取り出せなかった苦い経験
実を言うと、僕も最初はGitHubにアプリコードを載せて満足していた。
ある海外クライアントに「見せて」と言われて送ったけれど、こう返ってきた。
「これは機能としてはわかるけど、どうしてこの設計にしたのかが全然わからない」
そのとき初めて気づいた。
“設計者としての自分”は、コードだけでは伝わらない。
そこから、設計資料を付けたり、設計理由をREADMEに書いたり、
手描きの画面構成図を加えたりと、表現をどんどんアップデートしていった。
その結果、ようやく「UI設計ができる人」として認識されるようになった。
コードの外にある「設計の意図」をどう可視化するか？
“コードだけでは伝わらない”設計力をどう見せる？
ポートフォリオとは単に「作ったものを並べる場」ではなく、
“考えたこと”を伝えるためのツールだ。
UI設計力を評価してもらいたいなら、必要なのは：
「なぜ、こういう構造にしたのか？」
「ユーザー体験として、どんな配慮をしたのか？」
「再利用性や保守性は、どう考えたのか？」
これらの答えを見える形で埋め込んだポートフォリオである。
実例ベース：UI設計ポートフォリオの構成テンプレート
ここでは、僕が実際に海外向けに使った構成を紹介する。
ベースはWPFだけど、MAUIやBlazor、Reactでも応用可能。
✅ 1. サマリー：アプリの目的と設計観点
目的：
・「業務用在庫管理アプリ」
・倉庫スタッフの入力・確認作業を1画面で完結させる設計に挑戦した。
設計観点：
- ViewとViewModelの完全分離（責務の明確化）
- 入力と出力の画面構造を並列化し、操作性を強化
- 再利用可能なUserControlを3つ抽出・共通化
✅ 2. 画面構成図（構造視点で描く）
- ツール：PowerPoint、draw.io、手書きスキャンでもOK
- 目的：パーツの分割と責任を視覚化
- ポイント：1画面＝1責務、複雑な箇所は子Viewに切り出す
📌 例）
[MainWindow]
├─ [HeaderView]：ナビゲーション操作
├─ [InventoryInputView]：新規入力
├─ [InventoryListView]：在庫一覧
└─ [ItemDetailControl]：選択時の詳細表示
✅ 3. ViewModel設計図：状態とロジックの責任を整理
InventoryViewModel.csではどんなプロパティ・コマンドをもっていたか？- それはどのViewとどう連携していたか？
- データ取得とUI状態更新の責任はどう分離していたか？
📌 表で整理するとGood：
| ViewModel | プロパティ | バインド先View | 更新タイミング |
|---|---|---|---|
| InventoryViewModel | ObservableCollection | InventoryListView | データ取得後に即反映 |
| SelectedItem | InventoryItem | ItemDetailControl | 選択変更時に更新 |
| SaveCommand | RelayCommand | SaveButton | 入力検証OK時のみ実行可能 |
✅ 4. テーマ設計とStyle管理
WPFの強みはテーマ・リソースの構造化だ。
これをポートフォリオで見せられると、**“全体設計できる人材”**として評価されやすい。
App.xamlで定義したResourceDictionary構造- コントロール単位のStyleと共通化のルール
- ダークテーマ対応の工夫（テーマ切替ロジックなど）
📌 Bonus：カラーパレット設計図やフォントスケール設計図があると映える。
✅ 5. ユーザー操作フローとUI側の責任設計
WPFに限らず、UI設計の本質は“ユーザー操作の翻訳”にある。
- ユーザーが入力 → 検証 → 保存 する流れに
UI側で何をどう制御しているか？ - 例）Saveボタンは常時活性か？CanExecuteか？
- 入力エラー時のフィードバックはどこで行うか？
- 保存中にUIをブロックしているか？
📌 操作シナリオごとのUI責任を表形式で整理するのがおすすめ：
| シナリオ | UI責任 | ViewModel責任 | 表示制御方法 |
|---|---|---|---|
| 入力開始 | 入力欄活性 | 新規モデル作成 | IsEnabled=True |
| 入力内容が不正 | エラー表示 | IDataErrorInfo | ValidationTemplate |
| 保存ボタン押下 | 画面ロック＋スピナー表示 | データ登録＋通知発行 | Visibility + Task処理 |
ポートフォリオの“語り口”は「設計視点のブログ形式」がおすすめ
コード＋構成図だけでは足りない。
一番効果的なのは、「設計ブログ風」に自分で説明を書いてしまうこと。
✅ サンプル構成：
- タイトル例
→「在庫管理WPFアプリを、ユーザー視点で設計してみた」 - 課題背景
→ Excel管理の煩雑さ、入力ミスの多さ - 設計方針
→ MVVM徹底、画面分割、Validation設計の明確化 - UI構成解説
→ レイアウト、View-VM責任分離、Style再利用など - 設計上の悩みと解決法
→ Command連携のタイミング、Theme切替の構造化 - 振り返り・改善点
→ WPFで実装したが、MAUIならこう書ける など
海外向けなら英語での説明文を用意しておこう
LinkedInや海外案件に応募する際は、英語での説明があると圧倒的に強い。
以下のテンプレートを活用できる：
🔤 UI Portfolio Explanation（英語例）
This application was designed for internal warehouse inventory management.
The UI is structured with clear separation of responsibilities using MVVM.
Each user action flow (input, validation, save) is mapped to a specific ViewModel command.
All styles and themes are centrally managed with ResourceDictionaries to ensure maintainability and scalability.
まとめ｜設計力は、資料で“見せる”からこそ伝わる
- ポートフォリオは「作った証拠」ではなく「設計した証拠」にする
- XAMLコードより、構成図・責任図・設計意図が価値を生む
- ブログ形式・英語展開で、“グローバルUI人材”としての強みになる
“WPFで磨いた設計力”は、どの技術でも通用する
なぜ「WPF出身」は他技術に強いのか？
これまでの回で見てきたように、WPFという技術には次のような特徴がある。
- UIとロジックを分離するMVVMパターン
- UI構成を宣言的に組むXAML構文
- Style、Template、ResourceDictionary など再利用と拡張性を重視した仕組み
これらは、実はWebやクロスプラットフォームのUI技術にもほぼ共通して求められる設計観点だ。
つまり、WPFでUI設計をちゃんとやってきた人は、以下のような問いに自然に答えられる：
- 「そのUIはどうしてその構成になっているの？」
- 「状態管理はどう責務分離してる？」
- 「再利用性はどう担保してる？」
- 「ユーザー行動とUIの対応関係はどう設計した？」
→ この“設計的な語彙力”が、どの技術にも通じる武器になる。
UI設計の“汎用スキルマップ”に変換してみる
では実際に、WPFでのスキルを他の主要UI技術にどう“翻訳”できるのか？
以下はスキルマップの一例：
| WPFでの経験 | 対応可能な技術領域 | 翻訳ポイント |
|---|---|---|
| MVVM、双方向バインディング | Blazor, Angular, React | 状態とUIの責任分離、UIイベントのロジック分割 |
| ResourceDictionaryとテーマ管理 | TailwindCSS, CSS Modules | 一貫性のあるテーマ構築、スタイル再利用設計 |
| ControlTemplate、Style再定義 | Flutter, Jetpack Compose | コンポーネントベースUIの見た目と機能の分離 |
| ValidationRuleやIDataErrorInfo | React + Formik / FluentValidation | 入力チェック・ユーザーガイド設計 |
| Commandパターン | useCallback, EventCallback | イベント制御、CanExecute相当のUI制御ロジック構造 |
こうした翻訳マップを自分のポートフォリオに一緒に載せてしまうと、見る側にとっての理解が一気に深まる。
「UI設計ができる人」を示す3つのキーワード
他技術への応用や面接で伝える際に使える、“UI設計力”を説明するためのキーワードを紹介する。
🔑 ① “状態と表示の分離”を意識して設計している
例：
「WPFの頃から、ViewModelにロジックと状態を閉じ込め、Viewは極力受動的に保つ設計を実践していました。
現在はBlazorやReactでも同様に、UI側ではなるべく状態を持たず、必要なデータだけPropsやContext経由で渡しています。」
🔑 ② “再利用可能な構造”を常に意識している
例：
「WPFのResourceDictionaryやUserControlの設計で、可変性と再利用性を両立する設計が重要だと学びました。
今はWebコンポーネントやFlutterのWidgetにおいても、粒度や責務の明確化を特に重視しています。」
🔑 ③ “ユーザー操作の流れ”を起点にUIを構築している
例：
「画面構成は常に、ユーザーの行動フローに合わせて構築することを意識しています。
WPFではCommandとBindingで、ReactではuseEffectやCallbackで、各アクションの意味を明確化しています。」
UI設計力を“面接で語る”ためのストーリーテンプレート
WPF経験を他技術に応用できる「設計力」として言語化すると、こういった面接回答が可能になる。
質問例：
「なぜそのようなUI設計にしたのですか？」
回答テンプレート：
「WPF時代に学んだのは、ユーザー操作とアプリケーションの状態をどう切り分けるかという点です。
具体的には、入力エリアごとにUserControlを分け、各ViewModelが独立した責任を持つように設計していました。
この考え方は、現在Reactでフォーム系UIを設計する際にもそのまま応用しており、
状態管理とUI描画の責任を切り分けることで、再利用性と保守性を両立させています。」
→ 面接で高評価を得るには、“設計思想”をコードに閉じ込めないこと。
語れる準備をしておくことが、WPF経験を“価値”に変える第一歩となる。
設計視点を“次のキャリア”にどう活かすか？
WPF経験を活かして、どんなキャリアの方向性があるのか？
設計力を武器にした次のポジションを見てみよう。
🧭 ① UIアーキテクト
- 全体のUI設計戦略・コンポーネント設計を担う
- チーム内のデザインガイドやテーマ管理を設計
- 新旧UI技術を横断する「設計リーダー」
🧭 ② プロダクトUI責任者（スタートアップ向け）
- ユーザー体験全体を設計・提案できる人材
- “コードを書く人”から“UIを体験として構築する人”への進化
- デザイナー不在の現場でも設計ができる
🧭 ③ クロス技術のUI設計リード
- WPF → MAUI / Blazor へのマイグレーションを設計する人材
- 技術間のギャップを埋めるブリッジ役
- UI再構成・コンポーネント再設計の中心人物に
まとめ｜「設計力」は、翻訳力と語彙力で価値が決まる
- WPFの経験は、設計思想として他技術に応用可能
- 面接や提案時には、「なぜそう設計したか」を自分の言葉で語れるように
- UI設計力は、他技術を横断して“軸”になるキャリアの武器になる
- コードの外にある“設計言語”を持つことで、技術変化に左右されない人材へ
“作れる人”を超えて、“設計できる人”になるために
最後に立ちはだかる壁：「作った実績はある。でも…」
ポートフォリオを作ってみたけれど、こんな言葉をもらったことはないだろうか？
「見栄えはいいけど、設計力が伝わってこないんだよね」
「UIは整ってるけど、なぜそういう設計にしたのかが分からない」
僕も最初は、“完成品”だけを見せることが大事だと思っていた。
でも本当に大切だったのは、“なぜその形にしたか”という設計の背景をどう伝えるかだった。
ポートフォリオは「結果」ではなく「思考過程」を見せる場所
多くの開発者が誤解しがちなのが、
ポートフォリオ ＝ 作った成果物を見せるだけの場
という考え方。でも実際は、
ポートフォリオ ＝ 自分がどう考え、設計し、改善してきたかを見せる“設計のドキュメンテーション”
これが真の役割だ。
つまり、ポートフォリオで差がつくのは：
- コードの綺麗さやUIの美しさではなく
- 「なぜそうしたのか」を言語化してあるかどうか
“設計できる人”と見なされるための3つの工夫
ここでは、実際に評価されたポートフォリオ施策を紹介する。
✅ 1. 「設計の振り返り」セクションを作る
どんなにシンプルなUIでも、「設計の選択」をしているはずだ。
- なぜUserControlで分けたのか？
- なぜCommandで処理を委譲したのか？
- なぜそのテーマ構造にしたのか？
これらを思考の記録として、READMEや紹介ページの最後に記載しておくと、「この人は考えて設計してる」と伝わる。
✅ 2. “もし○○だったら？”という設計的問いを入れる
UI設計を語る上で、仮想の設計判断を記載すると、柔軟性や深さが伝わる。
例：
「このUIは、現在デスクトップ専用ですが、もしモバイルにも対応するとしたら、
以下のように画面構成とViewModel設計を再考する必要があると考えました。」
→ こういった“設計上の仮定とシミュレーション”ができる人は、アーキテクトとしての素養を強く印象づける。
✅ 3. “設計思想”を1枚絵でまとめる
これは特に海外企業に効果的だった方法。
PowerPointや手描きで構わないので、自分の設計スタイルを図式化する。
構成例：
My UI Design Principles
1. Structure Over Style
2. Responsibility-Oriented ViewModel
3. Reusability via Component Abstraction
4. Explicit State Transition
5. Consistency Through Theming
こうした「設計思想まとめ」は、**ポートフォリオを超えて“自分の設計ブランド”**として機能しはじめる。
UI設計力を“ブランド”に育てる
ここまで来ると、単なる実績アピールではなく、
**「この人にUI設計を任せたい」**という信頼のフェーズに入る。
ここからはさらにその信頼を育て、“UI設計ができる人”としての認知とキャリアの幅を広げる方法を紹介する。
🔰 継続発信のすすめ：「設計思考の言語化ブログ」
ポートフォリオは一度作って終わりではない。
設計思考を定期的に発信することで、設計スキルをアップデートし、他者にも伝わりやすくなる。
発信ネタ例：
- WPFのバリデーション設計をBlazorで再現してみた話
- Component粒度の切り方：再利用性 vs カスタマイズ性
- UIは何を“持たない”べきか？「余白の設計思想」
🌍 グローバル展開：「英語＋日本語の二重発信」
ポートフォリオ記事を日本語と英語の両方で書くと、海外チームやグローバル案件でも一気に評価されやすくなる。
設計は言語を超えるが、言語がないと伝わらない。
その壁を越えるだけの努力を、設計の重みで見せることができれば、どんな現場でも通用する。
🧭 “指名される人”になる：UIアーキテクトキャリアの入口
最終的に、WPF経験者が目指せるのは、“UIの専門家”という新たなポジション。
- チーム全体の画面設計をガイドする
- デザイナーとエンジニアの間をつなぐ
- ビジネス要件をUIに落とし込む“翻訳者”として機能する
ここでは、コードを書くだけでなく、チームの設計言語を設計するというフェーズに入る。
“WPFはレガシー”ではない。“設計の土台”だ。
僕自身、WPFという技術の先行きに不安を感じた時期があった。
でも今、WPFでの経験はこう定義している。
「UI設計の基礎を叩き込まれた修行時代」
その経験を、ReactやMAUI、Flutter、Blazor…どこにでも活かしている。
「WPFをやってきたこと」は、**“設計を学んだ証”**として、確かな意味を持つ。
【まとめ】UI設計力は、ポートフォリオという“言語”で語れ
- UI設計力を評価されたいなら、成果物ではなく思考過程を見せる
- 「なぜそうしたか」「他の選択肢は？」「将来的には？」という問いに答えること
- 自分の設計哲学を図式化・言語化することで、“設計ブランド”として定着させる
- WPFという経験を、「今通用するUI設計力」として再翻訳しよう
コメント