Design to Code – 互換性について

デザイナーと開発者をつなぐ「認識合わせの橋」

こんにちは！みんみんです。
今日は実装の体験談をさせていただきたいと思います。

デザイナーが「こんな感じで！」と言ったとき、開発者が「どんな感じ…？」となる。そんな経験、ありませんか?

デザインシステムの価値は、デザインと実装の間に「共通言語」を作ることにあります。
Figmaで作ったデザインが、そのままコードに変換できたら、デザイナーと開発者が同じトークンの名前で会話できたら、そんな世界を実現する方法があるのでしょうか。

デザインシステムの構築を進める中で、デザイナーと開発者の間の「認識合わせ」をスムーズにするために、共通言語としてのデザインシステムをどう構築するかがこの記事の主題です。

なぜ「共通言語」が必要なのか

デザインシステムを作るとき、一番難しいのは技術じゃなくて、人と人との間の「認識のズレ」です。
デザイナーが「プライマリカラー」と言うとき、頭の中には具体的な色があります。
でも開発者が実装するとき、その「プライマリカラー」が何を指しているのか、明確にわからないことがあります。

結果として:

• デザイナーは「なんか違う」と感じる
• 開発者は「どこが違うのかわからない」と困る
• 修正のやりとりで時間がかかる

これは言葉が違うだけなんじゃないかと思いました。
同じ「プライマリカラー」という言葉を使っているのに、Figmaでは Colors/Semantic/brand/primary で、コードでは #3B82F6 だったり var(–primary) だったり。名前も場所も統一されていません。

もし、デザインとコードで同じ名前が使えたら？
そういう世界を作りたいです。

4つの対応関係

FigmaとSCSS（開発者側のスタイルシート）の間には、4つの「対応関係」があると考えています。

この4つは構造的に完全一致するわけではありません。
あくまで抽象度を揃えて整理するためのフレームワークです。（厳密な1:1対応を意味するものではありません）

Variables ⇄ Variables

一番基礎になるのがここでしょうか。
色、スペーシング、フォントサイズなど。これらを「トークン」として定義します。

チームでの流れに沿って、私が試しているのは、階層構造です。
基本の色（Primitive）→ 意味のある色（Semantic）

こうしておくと、「ボタンの色を変えたい」ってなったとき、Semanticの参照先を変えるだけで済むのではないでしょうか。Primitiveはそのままです。
Figmaでも、SCSSでも、同じ構造にすれば、両方で同じ考え方ができるかもしれません。

Styles ⇄ Mixins

FigmaのStyles（とくに Text Style）は、SCSSのMixinと少し似ていますが、厳密には1:1対応ではありません。
Text Style は「フォント設定などのプロパティセット」、Mixin は「ロジックも含めた再利用構造」です。
ただし、命名を揃えておくことで、H1などの共通スタイルを共有する仕組みとして扱うことはできます。

Components ⇄ Modules

FigmaのComponentとSCSSのModuleは、UI構造とスタイルという異なる役割を持ちます。
ただし、「UIを単位ごとに分割する」という運用ルールを揃えることで、デザインとコードの対応を取りやすくなります。

Pages ⇄ Classes

ページレベルでも構造を揃えることは可能ですが、正確にはFigmaのFrame（ページ構造）と、HTMLの構造（class名を含む）を対応させるというイメージが近いです。

トークンの階層構造

デザイントークンは、2階層で考えてみています。

Primitive Tokens（素材）

まず、素材としての色を定義します。

$color-gray-50:  #F9FAFB;
$color-gray-900: #111827;
$color-blue-600: #2563EB;

これは「事実」です（Primitive）。
たとえばグレーの50番が #F9FAFB であるという値そのもの。

Semantic Tokens（意味）

次に、その素材に「意味」をつけます。

$color-background-primary: $color-gray-50;
$color-text-primary:       $color-gray-900;
$color-action-primary:     $color-blue-600;

一方、Semanticは「役割」。
背景のメインカラー、テキストのメインカラーなど、“用途や文脈の名前” を与える層です。

// Light Mode
$color-background-primary: $color-gray-50;

// Dark Mode
$color-background-primary: $color-gray-900;

素材は同じ。意味だけ変わります。

コンポーネントの考え方

コンポーネントは、ファイルで分けてみています。

components/
├── _button.scss
├── _card.scss
└── _input.scss

1つのコンポーネント、1つのファイル。
そして、各ファイルの中では:

// components/_button.scss
@use '../foundation/variables' as *;

.button {
  // 基本スタイル
  
  &-primary {
    // Primaryバリアント
  }
  
  &-secondary {
    // Secondaryバリアント
  }
}

Figmaのバリアントと、SCSSのModifierを対応させています。
デザイナーが「Primaryボタン」と言えば、開発者は .button-primary を使う。同じ言葉で通じるはずです。

自動化への期待

ここまでの構造を作ったら、次は自動化できないだろうか、と考えています。

Variables → SCSS変数 などの部分的な自動変換はすでに可能です。
一方で、Components → SCSS Module のような構造生成は現状まだ完全ではありません。
ただし、構造や命名が整理されているほど、AIによる変換精度は大きく向上します。

Figma Variables → SCSS Variables
Figma Styles → SCSS Mixins
Figma Components → SCSS Modules

デザイナーがFigmaでトークンを更新したら、コマンド一発でSCSSが更新される。
これができたら理想的だと思っています。

ただ、自動化はあくまで「手段」なのかもしれません。
大事なのは、その前の「構造」と「ルール」をちゃんと設計することではないでしょうか。
良い構造があれば、自動化も楽になるはずです。

最後に

デザインシステムは、技術の問題ではないのかもしれません。人の問題なのではないでしょうか。
デザイナーと開発者が、お互いを理解し合うための「言葉」を作ること。それが本質なのではないかと考えています。

Figmaとコードに橋を架けることです。
命名規則を統一すること、トークンを階層化すること、構造を対応させることなどです。そして、自動化します。

1つ1つは小さなことかもしれません。
でも、それが積み重なって、チーム全体の開発体験が変わるのではないでしょうか。
私は、そういうデザインシステムを作りたいと思っています。

私自身も、デザインと実装の双方を試しながら、最適な形を模索している途中です。
これからも改善を続け、よりよいデザインシステムのあり方を探していきたいと思います。