なぜ“伝わるポートフォリオ”が必要なのか？
海外で働きたいエンジニアの皆さん、こんにちは。
僕は日本でC#とWPFを中心にUI設計やアプリケーション開発をやってきて、今は海外で仕事をしています。今回は、「UI設計をどうやって英語のレジュメやポートフォリオに落とし込むか？」という、けっこう見落とされがちだけど超重要なテーマについてお話しします。
◆ ポートフォリオの“壁”は意外とUIデザインにある
実は、UI設計ってスキルとしての主張が難しいんです。
コードはGitHubに載せれば見えるし、機能は仕様書で語れる。でも「なぜこのUIにしたの？」「どうしてこの情報設計？」って、書かないと伝わらない。
日本語の職務経歴書では“ユーザー視点を大切にしたUI設計”って書いてればそれっぽく見える。でも、英語圏のレジュメやポートフォリオではそれじゃ全然足りない。
◆ 「UI設計やってます」は、実は伝わらない
まず押さえておきたいのは、「UI設計やってました」じゃ評価されないという現実。海外の採用担当者やPMは、
- Why（なぜそのUIにしたのか？）
- How（どうやって設計し、実装したのか？）
- What（結果どういう効果が出たのか？）
を見ています。
たとえば、あるWPFアプリの「ナビゲーション構成をタブからサイドバーに変更した」って話も、英語ではこう説明できると強い：
“Redesigned the navigation layout from a top-tab structure to a collapsible sidebar, improving user task flow and reducing average operation time by 30%.”
ここまで書けると「お、ちゃんとUI設計やってたんだな」と思ってもらえる。
逆に、ただ“UI開発を担当”って書くだけでは、**コーディングだけやってた人かも？**と疑われるリスクがあります。
◆ 僕自身の失敗談
実を言うと、僕も最初はレジュメもポートフォリオも“自信作”だったんです。
WPFでMVVMしっかりやって、XAMLも綺麗に書いて、英語にしてGitHubにアップして。
でも、全然オファーが来なかった。
「なぜ？」って英語のネイティブの友人に聞いたら、言われたのは：
“This is a good UI, but we can’t tell if it’s your decision or just company rules.”
つまり、「お前の判断か、仕様どおりやっただけか、見えない」って言われたわけです。
ショックでしたね。
そこから**UI設計における「意思決定の説明力」**が超大事だと気づきました。
◆ なぜ今、それが大事なのか？
UIの役割って昔より重くなってるんですよ。
SaaSや業務アプリでも、UXを売りにしてるサービスが増えてて、フロントエンドがプロダクトの成功を握ってる。
だからこそ、「あなたがどこまで設計に関わったか」を伝える力が、ポートフォリオでめちゃくちゃ重要になってます。
特にWPF出身だと、“見た目”より“構造”に意識が向きやすいんだけど、**UI設計のアピールは「ビジュアル」より「意図」**なんです。
◆ 「UI設計をどう書くか？」というスキルセット
つまり、これからのUIエンジニアは：
- UI構築の技術力
- UI設計の判断力
- UI意図の説明力（＝英語での言語化）
この3つをセットで持ってることが必要。
だからこそ、レジュメもポートフォリオも“作って終わり”じゃなく、“語れる内容”が必要なんです。
“英語レジュメとポートフォリオ”にUI設計力をどう落とし込むか？
◆ ステップ1：UI設計経験を“構造化”する
まず大事なのは、「やったこと」じゃなく「判断したこと」を軸に整理すること。
たとえば、ただこう書くのではなく：
“Developed UI screens using WPF and MVVM pattern.”
↓
こんな風に、**「なぜそう設計したのか」「どんな効果が出たか」**をセットで書く：
“Designed and implemented an operator-facing dashboard in WPF using the MVVM pattern, improving data discoverability by reorganizing layout elements based on user task frequency.”
これ、ポイントは3つ：
| 項目 | 例文内での対応 |
|---|---|
| 設計対象 | “operator-facing dashboard” |
| 判断理由 | “based on user task frequency” |
| 成果・効果 | “improving data discoverability” |
英語でアピールするには、**What（何を）+ Why（なぜ）+ So what（どう効果が出た）**の3点セットが鍵です。
◆ ステップ2：英語レジュメで使える表現テンプレート
英語が苦手でも安心してください。よく使うフレーズにはテンプレートがあります。
✅ UI設計プロジェクトの書き出しテンプレ
Redesigned [対象UI] to improve [目的] by [方法や設計判断]...
例：
Redesigned legacy inventory management UI to improve task efficiency by restructuring workflows and consolidating controls into grouped panels.
✅ 成果を示すフレーズ
…resulting in [成果・効果]
例：
…resulting in a 25% decrease in task completion time and improved user satisfaction (based on internal survey).
✅ チーム連携・仕様策定の貢献表現
Collaborated with [誰と] to define [仕様・方針] and ensure alignment with [目的]...
例：
Collaborated with product owners to define UI component behavior and ensure alignment with accessibility standards (WCAG 2.1).
こうした表現をいくつか覚えておけば、どんな案件も英語で“見せられる”ようになります。
◆ ステップ3：ポートフォリオで“UI設計の意図”を伝える3つの見せ方
UI設計の経験はGitHubのコードだけでは伝わりません。視覚＋説明のセットが必要です。
以下、僕が使っている方法をご紹介します。
① Before/AfterのUI比較（画像付き）
🖼 Before（旧UI）→ After（改良UI）のスクリーンショットを並べて、「何をどう改善したか」をコメントで説明。
例：
「タブ構造が深くなりすぎていたので、画面遷移をサイドバー＋メインビューに整理 → 1画面で完結する設計に変更」
② 情報設計の“構造図”を作る
UI要素のレイアウトや情報フローを図にして、なぜこの順番・構成にしたかを見せる。
Figma, Excalidraw, Draw.ioあたりがおすすめです。
③ “判断の裏付け”としてのリサーチやフィードバック
「実際にどんなユーザー課題があってこのUIにしたのか？」
アンケート結果、社内レビュー、ユーザーテスト結果などがあると非常に説得力があります。
◆ UIポートフォリオのおすすめ構成（Notion or GitHub PagesでOK）
僕が実際に海外就職活動で使っていたポートフォリオの構成です：
- Overview（プロジェクト概要）
- Challenge（課題と背景）
- My Role（自分の担当範囲）
- Design Decision（UIの設計判断と意図）
- Outcome（成果・効果）
- Screenshots / Demos（画像やリンク）
- Key Takeaways（得た学び）
特に 4. Design Decision のセクションが命です。
「なぜボタン配置を変えたのか」「なぜ画面遷移を統合したのか」など、**“UIデザインのロジック”**を英語で語れると圧倒的に強いです。
◆ よくある失敗と改善ポイント
| 失敗例 | 改善例 |
|---|---|
| UIの見た目だけ載せて満足してしまう | 「なぜその見た目なのか」の説明を追加する |
| 実装技術の説明だけで終わる | 「誰のために、なぜそう設計したか」を書く |
| コード量や画面数をアピールしがち | 結果や改善効果を数字で示す |
◆ 「実務じゃなくてもいい」ポートフォリオで見せられるUI設計力
海外では、「個人プロジェクトでもいいから、UI設計に責任を持った経験があるか？」を見ています。
なので、副業アプリや練習アプリでも、「UI判断を自分でして、理由を語れる設計」であれば十分評価対象になります。
GitHubで技術力を、Notionや自作ページで設計意図を見せるのが王道です。
英語面接で“UI設計力”をどう語るか？ − 試されるのは「言語化」と「ロジック」だった。
◆ いざ面接。「どこまでUI設計に関わったの？」の洗礼
レジュメやポートフォリオが評価されて、いよいよ面接へ――
ここで必ずと言っていいほど聞かれるのがこの質問です：
“So, what was your role in designing this UI?”
これ、さらっと聞かれる割に、めちゃくちゃ鋭い。
なぜかというと、**「実装者なのか、設計者なのか」**を見極めたいからです。
UI設計に関わったと主張していても、答え方次第で：
- ただのフロントエンド実装担当に見られるか、
- それとも設計意図を持つUX志向エンジニアと認識されるか、
が分かれてしまう。ここが面接突破の分水嶺です。
◆ 回答例：設計の「背景」と「意図」を話せるか？
質問に対して、こんなふうに答えられると評価されます：
“I was responsible for redesigning the task management panel. Initially, users were overwhelmed by too many visible options. Based on user feedback and task frequency analysis, I grouped controls into logical sections and used progressive disclosure to reduce cognitive load.”
ここで見せているのは：
| 要素 | 内容 |
|---|---|
| 課題 | ユーザーが情報過多で困っていた |
| 判断材料 | ユーザーの声＋使用頻度分析 |
| 設計意図 | 情報を段階的に開示して負担軽減 |
この「設計判断のロジックを言語化できるか」が、まさに設計者かどうかの判断基準です。
◆ 面接でよく聞かれた質問（実体験より）
僕が実際に海外で受けたUI設計に関する質問をいくつかご紹介します：
- “What were the biggest UX challenges you faced in that project?”
→ チャレンジを説明し、どう解決したかを話す - “How did you validate your design decisions?”
→ ユーザーテスト、インタビュー、KPIなどの裏付け - “Can you walk me through a specific UI you designed and explain your reasoning?”
→ Before/Afterを比較しながら話すと効果的 - “Did you collaborate with designers or product owners?”
→ UI設計がチームでどう進められたかを伝える - “How do you balance usability and business requirements?”
→ 両立のために行った工夫（例：ユーザー行動を定量化して意思決定）
これらの質問には「構造化したロジック」で答える必要があります。
◆ 面接でやりがちなNG回答とその改善方法
| よくあるNG回答 | なぜNGか | 改善のヒント |
|---|---|---|
| “I implemented the UI as designed.” | 設計に関わってないように聞こえる | “I contributed to refining the UI layout based on team discussions and user feedback.” |
| “I used MVVM and XAML efficiently.” | 技術だけ話していて設計意図が不明 | “I structured the ViewModel to support reusable UI components with consistent behavior.” |
| “We made the UI more user-friendly.” | 抽象的すぎて評価しづらい | “We simplified navigation by grouping actions contextually, reducing click depth by 40%.” |
面接では、「どんな課題があり、どう判断して、どんな成果を出したか」というストーリー性が命です。
◆ UI設計の経験が少ない人でも語れる内容
「設計に直接関わっていなかったからアピールできない」と思っている方もご安心を。以下のような視点で語ればOKです：
- 「既存のUI仕様をどう読み解いて実装に落とし込んだか」
- 「UI改善のアイデアをどうチームに提案したか」
- 「ユーザーからの問い合わせ内容をどうUI改良につなげたか」
つまり、「自分の中にあったUX視点や工夫」を拾い上げて言語化すれば、それも立派なUI設計力の一部です。
◆ 実際に評価された受け答え事例（海外面接より）
質問：“Can you describe a UI improvement you proposed and how it affected the product?”
回答例（僕が答えて好感触だった内容）：
“In a logistics app I worked on, operators were often confused by the color-coded status system. I suggested replacing color codes with iconography plus tooltips. We A/B tested it and found a 35% reduction in support tickets related to shipment status confusion.”
ここでは、
- “気づいた課題”
- “提案したUI改善”
- “結果どうなったか（数値で）”
が自然に盛り込まれています。
◆ 海外面接で「評価されるUI設計力」の特徴まとめ
| 評価される人 | 評価されにくい人 |
|---|---|
| 意図を言語化できる | 「やりました」で終わる |
| 判断材料を語れる | ただ仕様に従っただけ |
| 課題→改善→結果の流れを語れる | 実装技術の話だけをする |
| 他職種との連携を説明できる | 個人作業の話ばかり |
◆ 僕が意識した3つの面接準備法
- ポートフォリオのプロジェクトを「自分の言葉で語れる」よう練習
→ 各プロジェクトに「Why, How, What」のメモを英語で整理しておく。 - “改善前・改善後”の画面や説明を口頭でも言えるようにしておく
→ UIを言葉で描写できるスキルが、非デザイナーの強みになります。 - 模擬面接でロジックを磨く
→ 英語で「なぜそのUIにしたか？」を話す練習を3回やっただけでも効果絶大でした。
WPFのUI設計スキルを、グローバルな武器に変えるために ― キャリアにつなげる3つの戦略
◆ 1. 「WPFだから評価されない」は、もう古い。
まず言いたいのは、「WPFってもう古いから海外じゃ通用しないんでしょ？」という不安は、半分正解・半分誤解です。
確かに、WPFはモバイルやWebに比べてニーズは限定的。でも、次のような条件では今でも需要があります：
- 業務アプリ・医療・製造業界向けの内部ツール
- パフォーマンスが重視される、リッチなデスクトップ環境
- 既存システムがWPFベースで、継続保守が必要なケース
しかも、こうしたプロジェクトでは**「UI設計に自分の判断が入った経験」がある人材が極端に少ない。
つまり、「UIの背景や判断ロジックを語れるWPFエンジニア」は希少価値がある**ということです。
◆ 2. 「ポートフォリオ＋LinkedIn」で“世界からスカウトされる状態”を作る
ポートフォリオを作ったら終わりではなく、見てもらう場所に置くことが重要です。
僕が最も効果を実感したのはLinkedInの活用でした。
✅ プロフィールの見せ方で変わる注目度
以下のように書き方を変えるだけで、海外の採用担当の反応が劇的に変わりました：
Before：
UI development in C# and WPF for enterprise apps.
After：
UI designer/developer with 5+ years of experience crafting user-centric interfaces in WPF. Special focus on information architecture, task-oriented layout design, and accessibility optimization.
✅ UI設計スキルを「タグ化」する
#UIArchitecture#WPFUX#HumanCenteredDesign#TaskFlowOptimization
こうしたタグをプロフィールやポートフォリオ紹介に加えると、検索に引っかかりやすくなります。
◆ 3. UI設計力を活かせるポジションはWPF以外にもある
今後、WPF以外にもスキルを拡張していきたい場合、UI設計の経験はそのまま武器になります。
◆ UI設計が活かせる職種（例）：
| 職種名 | 活かせるUIスキル |
|---|---|
| Blazor / MAUI開発者 | XAMLやMVVMの知識、状態管理の整理 |
| フロントエンドエンジニア（React/Vue） | コンポーネント設計、UI状態の分離 |
| プロダクトデザイナー/UXデザイナー | ユーザー行動に基づく設計判断 |
| Technical PM / Solution Architect | UI設計と業務要件の橋渡し能力 |
「C#×WPFのUI設計経験」は、設計判断＋ユーザー視点の説明力さえあれば、フロントにもUXにも展開可能。
**“設計の理由を語れる技術者”**は、技術をまたいでも常に求められる存在です。
◆ UI設計スキルを強みにするための“5つの継続アクション”
最後に、今後のキャリアで「UI設計が評価される人」になるための習慣的アクションをご紹介します。
| アクション | 解説 |
|---|---|
| ① UI改善ログを残す | なぜ改善したか、どう変わったかを定期的に記録（Notionなどで） |
| ② 英語で「UI設計の一文日記」 | 毎日一つ、設計判断を英語で書いてみる（例：“Grouped action buttons by frequency of use.”） |
| ③ 海外のUX記事を読む | Smashing Magazine / UXPlanet / Nielsen Norman Groupなど |
| ④ 他人のポートフォリオを分析 | 海外エンジニアのNotionやUXfolioから学ぶ |
| ⑤ 海外フォーラムで意見を投稿 | Redditのr/UI_designやStackOverflowで議論参加も◎ |
これを3ヶ月でも続けると、**「UIを語る英語脳」＋「言語化スキル」**が一気に変わります。
◆ 最後に：あなたの「UI設計力」は、世界に通用する
もし今、
- 「自分のUI設計って、そんなに評価されるのかな…？」
- 「英語でちゃんと説明できる自信がない…」
と思っていても大丈夫。僕も最初は全然できませんでした。
でも、「なぜそのUIにしたか」を意識して整理するだけで、あなたの設計はただの作業から世界で通じる意思決定へと変わります。
コードと同じくらい、「説明できる設計」が評価される時代です。
あなたのWPF経験は、国境を越えるUIの言語に変換できる力を秘めています。
ポートフォリオとレジュメ、そしてあなた自身の言葉で、**“UI設計者としての物語”**を世界に届けましょう。
コメント