Figmaの「Styles」と「Variables」の境界線：大規模プロダクトを「負債」にしないための設計哲学
こんにちは。プロダクトの命運を握るデザインシステムを構築する際、多くのチームが「StylesとVariables、どっちを優先すべきか？」という霧の中に迷い込みます。
今日は、Figmaの機能をただ使うのではなく、「開発側の実装コスト」と「デザインの拡張性」を最大化するための境界線について、現場の血肉となる知見を共有します。
—
1. 概念の再定義：Stylesは「具象」、Variablesは「抽象」
まず、この2つを機能の優劣で語るのをやめましょう。役割が違います。
- Styles (旧来の主役): プロパティの「プリセット」。色やフォントを名前付きで保存する「定数」。
- Variables (現代の基盤): コンテキスト（文脈）を持つ「値のトークン」。モード切替や計算式を内包できる「ロジック」。
境界線の引き方
- Variablesを使うべきもの:
- 色（Primitive/Semanticトークン）
- スペーシング（Margin, Paddingの体系化）
- 数値（Corner Radius, Stroke Width）
- 文字列（多言語対応のラベル）
- Stylesを使うべきもの:
- タイポグラフィ: 現在のVariablesでは「フォントサイズ」「ウェイト」は管理できても、「Line height」「Letter spacing」を包括したセットにはStylesが適しています。
- エフェクト: Drop ShadowなどはVariablesで個別に管理するより、Stylesで一括管理する方がレンダリングパフォーマンスの観点でも理にかなっています。
—
2. 実践：チーム開発を加速させる「神」設定とツール
絶対入れるべきプラグイン
1. [Variables to JSON](https://www.figma.com/community/plugin/1247072979101683912): VariablesをJSONで書き出し、開発側のコードベース（Tailwind config等）と同期させるための必須ツール。
2. [Clean Document](https://www.figma.com/community/plugin/767376063375005886): 命名規則が崩れたレイヤーを整理。プロトタイプ共有前に必須。
開発速度を爆上げするショートカット
- `Cmd + K` (Quick Actions): 検索窓に「var」と打てばVariablesへ、「sty」でStylesへ即時アクセス。メニューを辿る時間は無駄です。
- `Opt + Cmd + C/V`: プロパティのコピー&ペースト。Variables適用済みの要素から、スタイルだけを抽出し移植する際に最強の効率を誇ります。
—
3. 移行戦略：Variablesへの「段階的」マイグレーション
いきなり全てを変数化してはいけません。以下のステップが最も安全です。
1. フェーズ1：Primitiveトークンの抽出
- `blue-500`のような生の値をVariablesのPrimitive（基底）に移行。
2. フェーズ2：Semanticトークンの構築
- `button-bg-primary`のように「意味」を付与。これが開発とデザインの共通言語になります。
3. フェーズ3：既存Stylesの置き換え
- ここが肝です。「全部一度にやらない」。新規コンポーネントから徐々にVariablesを参照するようにし、旧Stylesは「非推奨」フラグを立てて段階的に排除します。
—
4. エンジニア連携のためのベストプラクティス：JSON構成案
デザインシステムとコードの乖離を防ぐため、Figmaから吐き出したデータを以下のような構造で管理するのがベストです。
{
“colors”: {
“primitive”: {
“blue-500”: “#007AFF”
},
“semantic”: {
“surface-primary”: {
“value”: “{colors.primitive.blue-500}”,
“type”: “color”,
“comment”: “メインアクションボタンの背景色として使用”
}
}
},
“spacing”: {
“base”: 4,
“scale”: {
“xs”: “calc({spacing.base} 1)”,
“md”: “calc({spacing.base} 4)”
}
}
}
※ ポイント: `comment`フィールドを必ず入れ、開発者が「なぜその値なのか」を推測しなくて済むように設計します。
—
5. 最後に：チームへの導入ルール
私が現場で必ず徹底させるのは「命名の民主化」です。
- Designer: 「この色は変数の`bg-surface-secondary`を使って」と指摘する。
- Engineer: コード上で`var(–bg-surface-secondary)`と書く。
この「共通言語」が確立された瞬間、ドキュメントを読み込む時間はゼロになり、コミュニケーションコストは激減します。
Figmaは単なる描画ツールではありません。「プロダクトの設計図をコードに同期させるためのデータベース」です。StylesとVariablesを適切に使い分け、あなたのチームの開発生産性を、次の次元へ押し上げてください。
何か具体的な実装の壁にぶつかったら、また聞きに来てください。技術は常に進化し続けますから。