―海外エンジニアとして学んだデザインシステムの第一歩―
海外でエンジニアとして働きはじめた頃、僕にとって一番のカルチャーショックは「UIデザインの考え方」でした。日本ではC#のWPFを使って、機能優先のUIを作るのが日常。もちろん見た目や使いやすさも気にはしていたけれど、どちらかというと「要件どおり動けば合格」という空気が強かったんです。
ところが、海外のチームに飛び込んでみると、最初のレビューでいきなり言われました。
「ボタンのマージンが不揃いだね。ユーザーに違和感を与えるから直そう」
「このコンポーネントは再利用できるように切り出そう。個別に書くのはNGだよ」
正直、その時は頭の中が「？？？」でした。
だって、動いてるんです。要件どおりに。日本でなら合格ラインを余裕で超えている仕上がりです。
でも彼らはそれで満足しない。なぜなら、UIはただの「動く画面」ではなく、ユーザー体験を積み上げていく“システム”だから。目の前のボタン1つでさえ、アプリ全体の印象を変えてしまうし、他の画面で同じように配置されなければ「不統一」になってユーザーが迷ってしまう。
そこで初めて、彼らの言う「Design System（デザインシステム）」という言葉の意味を本気で考えるようになったんです。
デザインシステムって、何者？
ざっくり言えば「UIの設計図と辞書をセットにした仕組み」です。
ボタンのサイズや色、マージンといったスタイルガイドはもちろん、使い方のルールや再利用可能なコンポーネントのコードまで含めて、一つの「生きた資産」としてまとめていく。
WPFのプロジェクトでも、「UserControlやResourceDictionaryをどうまとめるか」という話に似ています。でも海外チームではもっと徹底していて、単なる再利用パーツ集ではなく、プロダクトを横断する共通の言語として扱っていました。
例えば、社内の別プロジェクトでも同じデザインシステムを適用できるようにしておく。そうすると、ユーザーはどのアプリを使っても同じ操作感を得られるし、エンジニアはゼロから作る必要がなくなる。結果として開発速度も上がり、レビューの観点も「仕様どおり動くか？」だけでなく「システム全体の一貫性が保たれているか？」に広がっていくんです。
最初にぶつかった壁
僕にとって、このデザインシステム文化は最初の大きな壁でした。
WPFのXAMLで「とりあえず画面を作る」ことには慣れていたけれど、彼らのレビューは全然違う方向から飛んできます。
- 「このコントロール、Atomic Designで言う“Atom”なの？それとも“Molecule”？」
- 「そのスタイルはシステムに定義されてる？独自に書くのは避けた方がいいよ」
- 「もし別のチームメンバーが触ったら、ルールに従って簡単に理解できる？」
正直、英語でのコミュニケーションにも苦労していたので、「Atomic Design？Molecule？何の話だ…？」と心の中で焦っていました。
それでも分かったのは、彼らは常に「長期的な再利用性」と「一貫性」を重視しているということです。
これは僕にとって衝撃でした。なぜなら、日本にいた頃は「再利用性」という言葉はよく耳にしていたけれど、実際には「コピペして少し変えれば早いじゃん」と済ませてしまうことが多かったからです。
小さな気づきから変わったこと
ある日、プロジェクトで検索画面を作ることになりました。僕は従来通り、XAMLにTextBoxとButtonを並べてサクッと書いたんです。動作的には問題なし。でもレビューで指摘されました。
「SearchBarコンポーネントを使わなかったの？」
よく見たら、デザインシステムのライブラリにすでに用意されていたんです。
しかも、そのコンポーネントにはAIによるコード補完とフィードバック機能が組み込まれていて、ユーザーが入力するケースに合わせたベストプラクティスまで提示してくれる。
そのとき僕は、「あぁ、こうやって“知識”をシステムに埋め込んでいくのか」と納得しました。単に「再利用しろ」ではなく、「システムを使えばより賢い選択肢が手に入る」ように設計されている。これこそが、海外の現場で感じたデザインシステムの真髄でした。
―海外エンジニアとして学んだデザインシステムの奮闘記（承）―
「起」で触れたように、僕は最初、海外の現場で“デザインシステム文化”にぶつかり大きな壁を感じました。
今回はその壁をどうやって乗り越えていったか、そして実際にAtomic Designを理解しながら実践に落とし込んだプロセスについてお話しします。
Atomic Designとの初遭遇
僕が初めて「Atomic Design」を聞いたのは、プロジェクトのUIレビューのときでした。
リードデザイナーがホワイトボードに図を書きながらこう言ったんです。
「UIは分子モデルみたいに分解できるんだよ。Atoms（原子）、Molecules（分子）、Organisms（有機体）、Templates、Pages。それぞれのレベルで管理するんだ」
正直、この説明だけではピンときませんでした。僕の頭の中は「原子？分子？化学の授業？」と混乱状態（笑）。
でも彼はさらに例を出してくれました。
- Atom（原子） = ボタン、ラベル、入力フィールド
- Molecule（分子） = 入力フィールド + ボタンで構成される検索バー
- Organism（有機体） = 検索バー + 結果リストをまとめた検索パネル
- Template = ページのレイアウト枠
- Page = 実際のコンテンツを流し込んだ完成ページ
これを聞いてようやく、「あ、これってWPFで言うなら Button や TextBox をAtomにして、UserControlで組み合わせたものがMolecule、さらに大きな画面単位がOrganismやTemplateにあたるのか！」とイメージが湧いてきました。
最初の失敗：中途半端な理解で組んでしまった画面
理解したつもりで挑戦したのが、とある「ユーザー管理画面」でした。
WPFでDataGridやFormを組み合わせ、ログイン管理も加えた複雑な画面。
当時の僕は「Atomic Designに従えばいいんでしょ」と安易に考えて、無理やりAtomやMoleculeに分けて作っていったんです。
ところが、レビューではボコボコにされました。
- 「Atomにロジックを入れてはいけない。純粋なUI部品に留めるべき」
- 「Moleculeの定義が曖昧。チーム全体で再利用できる単位を意識しないと意味がない」
- 「Organismの責務が大きすぎる。もっと小さな単位で組み替え可能にしてほしい」
結果、僕が作った画面は「Atomic Design風の自己流UI」でしかなく、システム全体にフィットしない状態になっていたんです。
学び：チームで共通言語を持つことの大切さ
この失敗を通じて痛感したのは、Atomic Designは“正解”を求めるものじゃなく、“共通言語”を作る仕組みだということです。
「これはAtom？Molecule？」と悩む時間は無駄じゃない。むしろその議論を通じて、チームが同じ方向を向いていくことに意味があるんです。
海外の現場ではこの「議論」がすごく活発でした。SlackやTeamsで毎日のように「この新しい部品はMolecule？それともOrganism？」とやりとりが続く。最初は「そんな細かいことで時間を使うのか？」と驚きましたが、今では納得しています。
なぜなら、これを徹底することで後から入ったメンバーでもすぐに理解できるし、チーム外の人も迷わず使えるからです。
AIの力を借りたブレークスルー
さらに面白かったのは、AIを活用したデザインシステム支援ツールの存在でした。
僕たちが使っていたプラットフォームには、こんな仕組みがありました：
- 新しいコンポーネントを作るとき、AIが既存のライブラリを検索して「似たものがあるよ」と提案してくれる。
- XAMLを書くと、自動で「これはAtomに分類されるはず。Moleculeにするならこんな組み合わせが適切」とアドバイスしてくれる。
- デザインガイドラインに反したコードを書くと、その場で警告が出る。
これに救われました。
なぜなら、僕はまだAtomic Designを完全に理解していなかったから。
でもAIが「それ、ルール違反だよ」と指摘してくれるおかげで、少しずつ正しい形に矯正されていったんです。
特にありがたかったのは、言語の壁を越えて「設計思想」を補ってくれたこと。英語で議論しても理解に時間がかかる部分を、AIの短いフィードバックがすぐ補足してくれる。これは、海外で働くエンジニアにとって心強い支援でした。
コミュニティ化するチーム文化
もう一つ印象的だったのは、デザインシステムの運用ルールです。
単に「使いましょう」ではなく、きちんとバージョン管理や貢献ルールが整備されていました。
- Gitのリポジトリに「Design System専用プロジェクト」があり、Pull Requestを出して承認を得ることで新しいコンポーネントを追加できる。
- コードレビューでは「デザインガイドライン」と「Atomic Designのレベル分け」を必ずチェック。
- 使い方や議論はWikiに残し、誰でも参照できるようにする。
つまり、これは単なるプロジェクトの一部ではなく、**チーム全体で育てていく“コミュニティ”**だったんです。
この文化に触れてから、僕の意識は大きく変わりました。
「ただ動けばいいUI」から「みんなで守り、みんなで進化させるシステム」へ。
小さな成功体験
そんな中、僕にとってのターニングポイントは「既存のSearchBarコンポーネントを改善するPull Request」を出したときでした。
ちょっとした変更だったんですが、レビューで「Nice improvement!」「これでより柔軟になったね」とコメントをもらえた。
この時、初めて「自分もデザインシステムに貢献できた」と感じました。
その小さな一歩が、自分にとって大きな自信になったんです。
―海外エンジニアとして学んだデザインシステムの葛藤と突破口（転）―
「起」ではカルチャーショックを受け、「承」ではAtomic DesignやAI、コミュニティ文化に馴染んでいった話をしました。
でも当然ながら、すべてがスムーズに進んだわけではありません。むしろ**海外ならではの“壁”**がここから本格的に現れます。
言語の壁：レビューで誤解が生まれる
海外のチームにいると、英語での議論は日常茶飯事です。
でも、デザインシステムの議論って専門用語が多くて、しかも人によって解釈が微妙に違うんですよね。
例えばある日、僕がPull Requestに対して「このコンポーネントはMoleculeとして再利用可能だ」と説明したとき、レビューコメントでこう返されました。
「これはOrganismに近いと思う。Moleculeにしては責務が重すぎる」
さらに別のメンバーはこう言いました。
「いや、むしろAtomの拡張版じゃない？」
結局、議論が平行線に。
僕としては「じゃあ正解はどれなんだよ！」と心の中で叫んでいました（笑）。
ここで難しかったのは、英語でニュアンスを正確に伝えることです。
日本語なら「このコンポーネントは単一責務だけど、再利用単位が大きいからMoleculeだと思う」とサクッと説明できる。でも英語だと “single responsibility” とか “granularity” とか、咄嗟に出てこない。
その結果、意図が伝わらず「hiroはAtomic Designを理解していないのでは？」と思われることもありました。これがかなり悔しかったですね。
文化の壁：正解が一つじゃない
さらに厄介だったのは、文化的な価値観の違いでした。
日本では「ルールは守るもの」という意識が強いですが、海外の同僚は意外と柔軟です。
「ガイドラインはあくまで指針。必要なら壊してもいい」と平気で言うんです。
例えば、あるイギリス人のデザイナーが「この画面だけは特殊な要件だから、Atomic Designの階層は無視していい」と言い出しました。
僕は「そんなことしていいの？」と不安になりましたが、彼らは「最終的にユーザーが迷わなければOK」と割り切っている。
ここで僕は、日本で染みついた「完璧にルールを守らなければならない」という感覚と、海外流の「実用的に運用する」考え方のギャップに直面しました。
結果、**デザインシステムは“聖典”ではなく、“進化するルールブック”**だと理解するようになりました。
ルールを守るだけではなく、状況に応じて“更新する勇気”も必要なんです。
ユーザーの壁：多言語・多文化対応
もう一つ忘れられない課題は、ユーザー層の多様性でした。
日本で開発していたときは、日本人ユーザーを対象にしたアプリが多かったので「右から左に読む」「フォントは明朝かゴシック」くらいしか考えませんでした。
でも海外の現場では、対象ユーザーがヨーロッパ、中東、アジアまで広がります。
- アラビア語のように右から左へ読むUI
- 中国語・韓国語で文字幅が変わるUI
- 色彩感覚が文化によって全然違うUI
あるとき、僕が作った画面がレビューで指摘されました。
「その配色だと中東のユーザーにとって不吉な色の組み合わせになる」
まさかUIの色にまで文化的背景が影響するとは思っていませんでした。
こういうときに役立ったのが、**デザインシステムの“揺らぎの許容”**でした。
つまり、Atomic Designの階層やスタイルガイドは維持しつつも、ローカライズ用のバリエーションを公式に認めるんです。
AIもここで力を発揮しました。過去の文化別デザイン事例を学習していて、「この配色は特定地域では避けた方がいい」とアラートを出してくれる。これには本当に助けられました。
チームの壁：合意形成の難しさ
ここまでで「言語」「文化」「ユーザー」の壁を話しましたが、最後に待っていたのはチーム内の合意形成でした。
デザインシステムはチーム全員で守るもの。
でも、バックエンドエンジニアからは「UIの細かいルールに従うのは面倒だ」と不満が出るし、デザイナーからは「もっと自由に作りたい」という声が上がる。
あるときなんて、会議で2時間以上「このボタンはPrimaryかSecondaryか？」という議論が続いたこともあります（笑）。
そんなとき役立ったのは、バージョン管理とガイドラインの仕組みでした。
Gitで明確にバージョンを区切り、リリースごとに「これがその時点での正解」という形を記録する。次のリリースで変えたいなら、正式にPull Requestを出す。
この“仕組み化”によって、感情的な議論が少しずつ減っていきました。
要するに、「個人の好み」で争うのではなく、「システムの進化」として合意を取れるようになったんです。
自分なりの突破口
僕自身も、最初は「どうしてこんなに複雑なんだ」と思っていました。
でも壁を一つずつ超えていくうちに、次第に海外チームで戦うためのマインドセットが見えてきました。
- 言語の壁 → 完璧に伝えなくても、AIやドキュメントを味方にする
- 文化の壁 → ルールは守るものではなく、進化させるものと捉える
- ユーザーの壁 → ローカライズの多様性をデザインシステムに組み込む
- チームの壁 → ガイドラインを“仕組み化”して感情論を避ける
こうやって振り返ると、デザインシステムって単なる「UIのルール集」ではなく、人と文化の違いを橋渡しする仕組みなんだと気づきました。
壁を武器に変える、海外エンジニアとしての成長
振り返ってみると、海外でのUI開発における最大の壁は、技術そのものではなく、言語・文化・ユーザー・チームの壁でした。
- 言語の壁では、完璧な英語ではなくても「意図が通じる表現」に集中しました。専門用語を武器にし、図やプロトタイプを駆使することで、誤解を減らせることを学びました。
- 文化の壁では、「当たり前が通じない」ことを前提にしました。日本的な“調和重視”と、欧米的な“議論重視”の違いに苦しみましたが、やがて「どちらの視点も交えて考えられる自分」が強みになると気づきました。
- ユーザーの壁では、「正しさより納得感」を重視する姿勢に切り替えました。技術的にベストでなくても、ユーザーが安心して受け入れられる設計こそが価値になるのです。
- チームの壁では、意見の衝突を「分断」ではなく「多様性」と捉えるようにしました。日本流の“聞く力”と、海外流の“主張する力”を使い分けることで、議論を建設的に進められるようになりました。
こうした経験を通じて、私は次第に「壁は障害ではなく、自分を鍛える負荷」であると理解するようになりました。むしろ、その壁があったからこそ、日本と海外、両方の視点を橋渡しできるエンジニアとしての価値を築けたのです。
これから海外で働くエンジニアへの実践的アドバイス
- 言語に完璧を求めない
単語や文法の正確さより、「伝える工夫」に時間をかけましょう。絵、図、コード、例え話――どれも立派な言語です。 - 文化の違いを「武器」にする
日本的な“気配り”は、海外の現場で意外に重宝されます。同時に、意見をはっきり言える勇気も磨いてください。両方を持ち合わせることで、チームの潤滑油になれます。 - ユーザーに寄り添う勇気を持つ
技術の正解を押し付けるのではなく、「この人にとっての正解は何か」を探す姿勢を忘れないでください。 - チームで勝つ発想を持つ
自分のアイデアを通すより、「チーム全体が納得できる形」に持ち込むスキルが重要です。それが結果的に、自分の信頼を積み上げます。
UI進化の最前線に立つと、常に新しい壁に直面します。ですが、その壁を越えた先で得られる学びこそが、海外エンジニアとしての最大の財産になります。
「壁を恐れるのではなく、壁を武器に変える」――これが、今の私だからこそ伝えられる、未来の仲間へのメッセージです。
コメント