伝わらなければ、存在しないのと同じ
「ちゃんと作ったはずなのに、レビューで刺さってない」
「なぜ伝わらないんだろう？」
──そんな違和感を、海外の多国籍チームで働き始めたばかりの頃、何度も味わいました。
僕はWPFを軸にUI設計・開発をしてきた日本のエンジニアです。国内では「設計に強い人」「UIの構造をきちんと組める人」としてある程度の信頼を得ていました。でも、いざグローバルな現場に出てみると、その“スキル”がまるで「見えない」かのように扱われるのです。
もちろん、技術力が落ちたわけではありません。
WPFで構築したMVVM構造も、ユーザー視点を意識したコンポーネント設計も、国が変わっても通用するはずだと思っていました。
でも、現実は違った。
「なぜそのUI構成なのか？」
「ユーザー調査はどのレベルまでやったのか？」
「そのバインディング、チームのスタイルと整合性があるか？」
レビューでは、そうした問いが英語で飛んできます。
しかもその背後には、文化や設計思想の違い、チームの価値観が濃密に絡み合っている。
たとえば、あるチームでは“UIの一貫性”が最重要で、過去の設計とずれているだけでアウト。一方で別の国のチームでは“UXの革新性”が優先され、既存と違うことがむしろ評価される。
言語の壁よりも、「評価軸の違い」が一番厄介だったのです。
さらにやっかいなのは、“設計意図”が伝わらないと、たとえ完璧に近いUIでも「ただ作っただけ」と見なされること。つまり、**「設計者としての思考が見えない＝価値がない」**と判断されるリスクが常にある。
このとき、僕は痛感しました。
日本で評価されてきた“職人的な設計力”は、国際チームの中では**「言語化」「可視化」「対話力」**がなければ埋もれてしまう、ということを。
では、どうやって“技術と言葉の壁”を超えたのか？
WPFという日本語ドメインの技術をどうやって英語圏に翻訳し、設計者として信頼を得ていったのか？
“設計の意図”を見せる技術：文化を越えるコミュニケーション設計術
海外チームで働くようになってから、僕は一つの結論にたどり着きました。
**「設計力とは、説明力である」**ということです。
どれだけ精緻なUI構造を組み上げても、その設計意図がチームに伝わらなければ、単なる“ロジック職人”として扱われてしまいます。ましてや文化も設計思想も異なる多国籍チームにおいては、**「話す」「示す」「比較する」**という三段階の可視化が不可欠です。
🛠 スキル①：話す──設計判断を言語化する力
レビューでいちばん大事なのは、「なぜその構造を選んだか？」を自分の言葉で語れること。
たとえば、ある画面で「ContentControl + DataTemplate による動的UI切替」を使ったとき、英語で以下のように説明しました：
“I chose ContentControl with DataTemplates to isolate view logic from code-behind and support future extensibility. This allows us to plug in new components without rewriting the main view logic.”
これだけで、「未来を見据えて設計している」「責務を分離している」といった意図が一瞬で伝わります。
英語が得意でなくても大丈夫。要は“設計のロジック”を簡潔な因果関係で表現できればよいのです。
🎨 スキル②：示す──図で語る、図で合わせる
国によって「ドキュメントの重み」は異なりますが、図にした設計は万国共通で伝わる力を持っています。
英語が苦手だった初期は、UI設計を必ず下記の形式で共有していました：
- 構成図：View・ViewModel・Model の責務関係とデータフロー
- ステート図：UIの状態遷移（特にダイアログや非同期処理）
- スクリーンマップ：画面間のナビゲーションや階層構造
これらを英語ラベルで整えた図にして、NotionやFigma、Confluenceで共有すると、それだけでレビューがスムーズになりました。
“話す前に、見せる”。これは国際チームで最強の戦術です。
🧭 スキル③：比較する──「なぜAではなくBか？」を設計に添える
「このUI構成にした理由は？」
「それ、MVVMじゃなくてもできたんじゃない？」
──と問われる前に、**“他の選択肢との比較”**を添えておくことで、説得力が劇的に変わります。
たとえば、WPFの開発で「UserControl + DependencyProperty」構成を選んだときは、あえてこう補足しました：
“I considered using DataTemplateSelector, but it didn’t give us enough control for runtime logic. So I went with a modular UserControl approach to encapsulate complex logic with better maintainability.”
これにより、「代替案を検討して選んでいる」というプロ意識が見え、信頼感が生まれます。
こうして僕は、“設計を説明する力”を少しずつ鍛え、言語の壁を超えて評価されるようになっていきました。
でも、それだけでは足りません。
文化の違いによる“期待値”そのものを理解し、対応を変える柔軟性も必要でした。
“設計レビュー”の背景には、その国の価値観がある
多国籍チームで働くということは、単に「英語で話す」ことではありません。
どんなUI設計が“良い”とされるか——その判断基準そのものが、文化や国によって違うという現実に直面します。
たとえば、ある欧州のチームではこんなことがありました。
モジュールごとの責務を明確に分けた画面構成をレビューに出したとき、
「なぜここまで細かく分けてるの？」「もっとシンプルに1画面でやろうよ」と言われたんです。
彼らの重視していたのは、「開発効率」と「ユーザーの一貫した操作体験」。
僕が想定していた“長期保守性”や“再利用性”といった日本的な「丁寧な設計」は、むしろ“やりすぎ”に映っていたわけです。
逆に、ある北米チームではまったく逆の反応が返ってきました。
既存UIとの整合性を保ちながら、新規画面を同じトーンで作ったところ、「なぜ既存と同じ構成なのか？ユーザーが混乱しているUXのパターンを、なぜ踏襲する？」と厳しく突っ込まれたのです。
彼らの関心は、「ユーザーが感じている不満を、新しい設計でどう変えられるか」。
つまり、“設計者としての提案力”が問われていたんですね。
こうした経験から、僕は次のような認識を持つようになりました：
UI設計レビューとは、技術の話に見えて、実は“価値観のすり合わせ”の場である。
🌍 UI設計を伝えるには「文化の翻訳」が必要
これに気づいてから、僕は単にUI構造を説明するのではなく、
**「あなたの文化・価値観にあわせて、どう翻訳して見せるか？」**を意識するようになりました。
たとえば欧州チームとのレビューでは：
- 「保守性」ではなく「生産性」「開発スピード」という言葉を使う
- 複雑な構成には「Why Not Simpler?」という視点から自分でツッコミを入れる
- テスト戦略までを資料に含めて「先を見た設計だ」と理解されるようにする
逆に北米チームとの議論では：
- 「既存のUIとの差異」に焦点をあて、「なぜ変えたか」のストーリーを語る
- UI変更による“ユーザーインパクト”を明確に数字やフィードバックで示す
- 革新性と一貫性のトレードオフについて事前に共有する
このように、「どこを評価されるか」「どんな観点で見られるか」は、文化によってズレがあります。
だからこそ、“設計意図”を翻訳する力が必要なのです。
🧠 翻訳できる設計者＝信頼できる設計者
グローバルなUIレビューの現場では、設計スキルだけでなく、「相手がわかる言葉で話せること」そのものが、設計者としての信頼につながると僕は感じています。
国や言語が違えば、何を「良い」と感じるかも変わる。
それを無視して「自分の設計は正しい」と押し通すのではなく、
相手の文脈で語れる設計者こそが、グローバルで評価される。
“設計は、伝えてはじめて設計になる”：UIアーキテクトとしての第一歩
僕が最初に海外チームで挫折したのは、「技術が伝わらない」ことではなく、
**“設計の考え方そのものが、誰にも見えていない”**という感覚でした。
でも今なら、こう言えます。
設計は、コードではなく対話で評価される。
どんなに正しいMVVM構成を組んでも、どれだけ丁寧にレスポンシブ対応しても、
その背景にある「なぜそれを選んだのか」という設計者の意図が伝わらなければ、
ただの“静かな成果物”でしかありません。
逆に言えば、「意図を伝える設計者」になれたとき、
そのスキルは世界中で通用するのです。
💡 グローバルに通じる“UI設計者の伝え方3原則”
僕が多国籍なチームで、信頼を得てきたなかで見つけた「伝え方」の原則を、最後に共有します。
✅ 1｜設計の「Why」から話し始める
→ “What I did” ではなく、“Why I did it” を。技術ではなく思考を見せる。
✅ 2｜可視化と比較で、文化のズレを埋める
→ 図と選択肢比較は、説明を補強し、文化間の「違和感」を減らしてくれる。
✅ 3｜相手の文化に寄り添い、翻訳する
→ 評価基準が違うなら、そこに合わせて設計の“見せ方”を変えるのがグローバル流。
これらを意識するだけで、同じ設計でも「理解され方」がまったく変わります。
僕は今、WPFで培ったUI設計力を武器にしながら、
その価値を言葉に乗せて届けることを、グローバルでの仕事のコアに置いています。
これは“UIアーキテクト”としての道を歩む上で、確実な一歩になっています。
最後に、これを読んでいるあなたへ。
もしあなたがWPFでUIを突き詰めてきたなら、それは世界に通用する技術です。
でもその技術を“設計者の言葉”で語れるようになれば、
ただのエンジニアではなく、「信頼されるUIの対話者」になれるはずです。
次回Vol.4では、僕がWPF時代に「やっておいてよかった7つのこと」をテーマに、
グローバルキャリアにつながった“技術の選び方・磨き方”を実例ベースでお届けします。
キャリアを越境させる技術習慣、ぜひ一緒に見直してみましょう。
コメント