面談で初めて気づいた、自分の“武器”が伝わらないという事実
「So, what’s your strength as a UI developer?」
画面越しの面談官が、あっさりとそう聞いてきた。
聞き返したい気持ちを抑えて、僕はこう答えた。
“I’m good at clean XAML and using MVVM patterns properly.”
……沈黙。
そのあとに返ってきたのは、興味というより困惑に近い表情だった。
「XAML？パターン？…それって誰でも言う話だよね？」
そう、彼は言わなかった。
でも僕には、**“それだけじゃ伝わらない”**という空気が痛いほど伝わってきた。
🔹「スキルがある」のに、「伝わらない」という矛盾
あの時、僕は確かにWPFでの経験もあり、設計力にも自信があった。
レビューでも褒められていたし、現場でも「頼れる人」として扱われていた。
けれど──
🌐 海外の面談で、
💬 言葉を尽くしても、
🔍「この人に任せたい」が伝わらない。
この“もどかしさ”は、決して英語力だけの問題ではなかった。
🔹「スキルの棚卸し」が日本語ベースでは足りなかった
日本の職務経歴書では、こう書けば十分通じる：
- WPF + MVVM での開発経験 ○年
- 業務アプリのUI設計・改善に従事
- ユーザビリティ改善による業務効率向上
でも、英語圏ではこう見られる：
“That’s experience. But what’s your strength? What do you bring that others don’t?”
この違いに気づくのが、遅すぎた。
🔹海外で求められるのは、“再現可能な強み”の言語化
英語での面談、ポートフォリオ、GitHub、LinkedIn──
すべてにおいて問われるのは「あなたの強みは何か？」という問い。
それは、**“何ができるか”ではなく、“なぜ評価されるか”**の話だった。
たとえば：
| 日本的表現（スキル） | 海外的評価（強み） |
|---|---|
| UI設計が得意です | I design UIs that require no onboarding or explanation. |
| MVVMを熟知しています | I’ve created maintainable, testable UIs across large-scale WPF systems. |
| 見やすい画面を作れます | My designs reduce user errors by surfacing context-sensitive actions. |
このように、“成果”と“再現性”を言語化してはじめて、市場で戦えるスキルに変わる。
🔹“強み”は、スキルそのものより「考え方×成果」で決まる
僕が実際に海外転職活動で意識を変えたのは、以下の3点：
- 経験を「事実」ではなく「価値」で語る
例：
– ✖️「XAMLを書いた経験があります」
– ✔️「ユーザーが迷わないレイアウト設計で、操作時間を25%削減しました」 - 「誰にとっての強みか」を明確にする
– 自分にとって得意なだけでなく、
– チームにとって、ユーザーにとって、どう役に立ったか？ - 「なぜそれができるのか？」を構造化する
– 強みには必ず裏付けとなる習慣や設計思想がある
– それを明示することで、再現性がある＝信頼される
🔹キャリアの“武器”は、「気づいていないこと」から始まる
UI設計に特化してきた人ほど、
「できて当たり前」「誰でもやってる」と思っているスキルがある。
それこそが、実は最大の差別化ポイントになる。
たとえば：
- 日本で培った“察する設計”が、英語圏では「ユーザーへの配慮」として評価される
- 細かすぎるドキュメント作成力が、海外では「再現性のある設計プロセス」として強みになる
- MVVMパターンの運用経験が、「チームの保守性への貢献」として説得力を持つ
“あえて言語化してこなかったこと”こそ、国境を越える武器になる。
スキルを“実績”に変える、3つのフレームワーク
「経験はあるけど、何を強みとして語ればいいか分からない」
これは、僕自身が長く抱えていた悩みだった。
WPFでいろんな画面を作ってきた。MVVMも知ってるし、ユーザーのことも考えて設計してきた。
でも──面談やプロフィールで「それをどう表現すればいいのか？」と聞かれた瞬間、言葉が止まる。
そこで僕がたどり着いたのが、“スキルの言語化”と“再現性の設計”を組み合わせる3つのフレームワークだった。
🔹①【成果変換フレームワーク】経験 → 実績 → 強み へ
まず最初に必要だったのは、「経験をそのまま語らないこと」。
僕が初期にやってしまった失敗はこうだ：
- ✖️「在庫管理システムの画面を作りました」
- ✖️「ユーザー登録画面をWPFで開発しました」
これでは、何が良かったのか、どんな設計力があったのかが何も伝わらない。
そこで、次のように“成果ベース”に変換するようにした：
| Before（経験ベース） | After（成果＋強みベース） |
|---|---|
| 在庫画面を作成 | ユーザーが2クリック以内で商品検索できるUIを設計し、問い合わせ件数を40％削減 |
| 登録画面を開発 | バリデーション＋マイクロコピーで入力ミスを75％減少させるUX設計を実現 |
👉 経験を「数字」と「貢献」で語ると、初めて“強み”として認識される。
特に海外面談では、**“So what?”（それで何が変わった？）**を常に問われる。
だからこそ、「やったこと」ではなく「どんな変化をもたらしたか」を語る準備が必要だった。
🔹②【再現性フレームワーク】プロセス → 思考 → 習慣 へ
成果を生んだ「考え方」や「やり方」を分解できると、それは**再現可能な“強み”**になる。
面談で「それはどうやって実現したのか？」と聞かれるのは、この“再現性”を見られているから。
たとえば、以下のように変換できる：
| 結果 | 設計者としての“考え方” |
|---|---|
| 操作時間25％削減 | 「主要な操作を3ステップ以内に収める」設計ルールを全体に徹底 |
| エラー率50％削減 | 状態ごとのUI分岐をViewModelで整理し、迷いを排除 |
| UXレビューで高評価 | 操作文脈を読み取れるレイアウトパターンの共通化を意識 |
海外の評価軸は、「それをまた別のチームで再現できるのか？」という視点であることが多い。
つまり、「あなたの強み＝チームに再現できる“設計思想”」ということだ。
🔹③【伝え方フレームワーク】主語を“自分”から“相手”へ
強みを語るときに、つい自分の得意なことを前面に出してしまいがちだ。
でも、海外では「誰のために、どんなインパクトを出したのか？」が重視される。
たとえば──
- ✖️「XAMLが書けます」
- ✖️「MVVMを使っています」
ではなく、
- ✔️「XAMLの共通化設計で、他メンバーの実装スピードを20％向上させました」
- ✔️「MVVMアーキテクチャで保守性を高め、新規開発者のオンボード期間を1週間短縮しました」
👉 「自分にできること」ではなく、「チームやユーザーに与える影響」こそが、強みの本質。
これを面談・履歴書・ポートフォリオに応用したとき、明らかに反応が変わっていった。
🔹WPFエンジニアとしての“言語化しづらい強み”を武器にする
UI設計者、とくにWPFに特化していると、「絵を見れば分かる」設計を日常的にやっている。
でも──それは他の人には“見ただけでは伝わらない”強みでもある。
だからこそ、言語化する意味がある。
- なぜこの配置にしたのか
- なぜこのデータ構造をViewModelに分けたのか
- なぜこのTriggerやStateを仕込んだのか
それらを説明できるようにすると、UIの“無言の設計”が、“有言の強み”へと進化する。
🔚まとめ：強みとは、「設計思考の言語化」である
- 経験だけでは評価されない
- 成果と再現性があって初めて信頼される
- 主語を「自分」から「相手」へ変えると伝わりやすくなる
それが、UI設計者として“海外で戦えるプロフィール”をつくる第一歩だった。
設計力を「語る」から「魅せる」へ──ポートフォリオと成長設計図の作り方
🔹「自分の設計力を見せる」とはどういうことか？
英語の面談で、「何を見せるべきか」に悩むことは多い。
コード？完成アプリ？プレゼン資料？
僕も最初は“とりあえずGitHubリンクを貼っておこう”というスタンスだったが、海外面談では次のように聞かれた。
“This app looks fine — but what was your thinking behind the design?”
“How did you approach user interaction in this part?”
“What trade-offs did you consider?”
つまり、「完成品の見た目」ではなく、「設計の思考過程」にこそ関心があるのだ。
そこで僕は、ポートフォリオを“設計の物語”に変える方向にシフトした。
🔹WPFエンジニア向け：設計視点ポートフォリオの構成例
以下は、実際に僕が使ったWPF UI設計ポートフォリオの構成テンプレートだ。
✅ 1. プロジェクト概要（1ページ）
- プロダクトの種類（例：販売管理ツール、社内用データ可視化アプリ）
- チーム構成、担当範囲（WPF/Front-end Leadなど）
- 使用技術（WPF, MVVM, Prism, ReactivePropertyなど）
✅ 2. UI構成と設計の意図（各画面ごとに）
| セクション | 内容例 |
|---|---|
| 画面レイアウト画像 | スクリーンショット or Figma/XAML構成図 |
| 設計意図 | なぜこの配置？なぜこの動き？ |
| 改善点 | 初期案 → 修正の経緯とレビュー対応 |
| 工夫した点 | ユーザー理解、文脈対応、アクセシビリティ など |
ポイントは、「何をどう設計したか」よりも**「なぜそう設計したのか」**にフォーカスすること。
✅ 3. 技術実装の特徴
- MVVMの適用例（e.g., 複数画面の状態管理設計）
- Validationのパターン（ReactiveForm / INotifyDataErrorInfo など）
- カスタムコントロール or 再利用可能なテンプレートの紹介
- 設計の変更をどうコードで支えたか（e.g., ViewModelのテスト性）
✅ 4. 成果と評価（定量的に）
| KPI | Before | After |
|---|---|---|
| 入力エラー率 | 22% | 5% |
| 操作時間（平均） | 14秒 | 8秒 |
| ユーザー満足度（社内アンケート） | 3.1/5 | 4.4/5 |
📝補足：数字が出せない場合は「仮説と観察結果」だけでもOK。
🔹UI設計を“育ててきた証拠”としての「成長設計図」
海外で意外と評価されるのが、**「あなたは今、何を伸ばそうとしているか？」**という問いに対して、答えを持っている人。
僕は以下のような資料を1ページで作ったことがある（NotionやMiroなどでもOK）：
▶️ 成長設計図の例：
| 項目 | 現在のレベル | 次に目指すステージ | 取り組み中の内容 |
|---|---|---|---|
| UIレビュー対応力 | △ 海外レビュアーに伝わりづらい | ◯ ノンバーバルな設計意図の共有 | 英語での意図タグ付け、Figmaコメント実践中 |
| アクセシビリティ対応 | ✕ 経験なし | △ 社内標準に準拠できるレベル | ARIA Roles / Contrast対応の習得中 |
| インタラクション設計 | ◯ 操作フローは設計済み | ◎ アニメーション・状態変化の一貫性設計 | WPF Storyboard応用実装中 |
→ これがあるだけで、「この人は成長を“設計できる”人だ」と伝わる。
🔹“設計者の思考”がポートフォリオの最大の武器になる
重要なのは、「コード」や「見た目」ではなく、“考え方の痕跡”。
僕が意識して加えたのはこんなセクションだった：
- 📌 設計の葛藤：「この機能は外すべきか、残すべきか悩んだ」
- 📌 レビューで揉まれたポイント：「レビュアーに指摘されて直した動線」
- 📌 ユーザー観察による発見：「意図しない操作が多かった理由」
そうした“人間くさい痕跡”が、単なる実績を「信頼できる人柄」に変えてくれる。
🔹「魅せる力」は、海外でこそ差別化ポイントになる
英語が母語でない僕たちにとって、“UIの魅せ方”そのものがコミュニケーション手段になる。
- スライド資料の構成
- Before/Afterの見せ方
- コメントの英語のニュアンス（語彙の少なさを補う構造力）
「コードは読めば分かる」なんて通じない。
だからこそ──UI設計者は、見せ方で勝負できる。
言葉の壁を超えて“設計力”を伝える：評価され続けるUI設計者の歩き方
🔹面談で「説明しすぎない設計」が通じた瞬間
海外面談で「あなたの強みは？」と聞かれるたびに、かつての僕は英語で答えを探していた。
けれどある日、僕は“話す”ことをやめて、あるポートフォリオ画面をただ見せた。
ユーザー登録フォームのUI、WPFで組み上げた簡潔な画面。
そのとき、面談官はこう言った。
“I see. It’s simple, predictable, and clear. That’s design thinking in action.”
そのUIが、僕の代わりに語ってくれた。
🔹“伝わるUI設計”は、言語力よりも「翻訳力」
日本語で通じる表現も、英語では伝わらない。
WPFやMVVMの話は、技術者には通じても、UXリーダーやプロダクトマネージャーには響かない。
だからこそ重要なのは、
- 技術 → ユーザーへの影響への翻訳
- 手段 → 成果への変換
- 「自分がやったこと」→「相手に何が嬉しいか」への視点の転換
設計者が“翻訳者”になったとき、ようやくスキルは価値として伝わるようになる。
🔹「言語化されていない強み」が、一番の武器になる
UI設計者にとって、強みとは“最新トレンド”でも“難解な技術”でもない。
それは、**日々の実装に無意識で織り込んでいる「自分らしさ」**だ。
- 余白にこだわるあなたの習慣
- コンポーネント命名の一貫性への気配り
- レイアウト崩れを0にするための地味な努力
- 表示順やフォーカス移動の「自然さ」への美学
こうした“言語化されてこなかった習慣”が、実はグローバルな現場で最も差がつく部分だった。
🔹“強み”を育てるには、意図的に「見せて・伝えて・磨く」サイクルを回す
1）見せる（Visualize）
→ UIの成果物を「なぜそうしたか」の文脈とともに提示
→ Before/Afterで比較、「設計の選択」を明示する
2）伝える（Articulate）
→ チームやレビューで「設計の意図」を簡潔に共有
→ 英語で伝えることを恐れず、“共感の言語”を試す
3）磨く（Iterate）
→ フィードバックを受けて改善
→ 成果だけでなく、思考プロセスそのものをリファクタリング
このループを回すことで、設計力は**“自分だけのスタイル”から“評価される専門性”へと進化**する。
🔹「成長し続ける設計者」になるために、今日からできること
海外で評価されるUI設計者になるために、僕が実践してよかった“日常の習慣”をいくつか紹介したい。
✅ 英語で「設計意図メモ」を残す
実装前のタイミングで、以下のような1～2行メモを書く習慣を持つ。
// Layout prioritizes primary action for mobile-first context.// This list uses grouping to reduce visual noise.
→ 小さな意図でも、それを言語にする習慣が強みの言語化につながる。
✅ UIレビューに「Before→Why→After」の流れで臨む
「ここを変えました」だけでなく、
- なぜその変更が必要だったか（Why）
- 何が改善されたか（After）
までを丁寧に伝えることで、設計者としての“思考の深さ”が伝わる。
✅ 「自分用設計ログ」をつける
NotionでもScrapboxでも手帳でもいい。
設計中の疑問、トレードオフ、迷った選択肢などをメモしておくと、
- 面談での「語れるネタ」が自然に増える
- 自分の設計観が育つ
- 将来のUIアーキテクトとしての財産になる
🔚 最後に：あなたの“設計の声”は、世界に届く
言葉が完璧じゃなくてもいい。
英語でスラスラ話せなくても、UI設計には“もうひとつの言語”がある。
それは──
- 情報の構造で語る
- 動線で導く
- 配色と余白で信頼を築く
そんな沈黙のUI設計こそ、国境を越える“あなたの声”だ。
コメント