Figmaのデザインシステムを整理する「ローカルコンポーネント戦略」｜現場で使える実践テクニック

#Figma #コンポーネント設計 #チーム運用 #デザインシステム #効率化
C
クリオ
Web制作ディレクター / フロントエンジニア

こんにちは！

今日は「Figmaのデザインシステムを整理する『ローカルコンポーネント戦略』」について解説します。

ローカルコンポーネントが散らかるのはなぜ？

Figmaを使い始めたばかりの頃、僕もめっちゃハマった問題があるんですよ。
それが「ローカルコンポーネント（ファイル内だけで使用するコンポーネント）が増殖して、どれがどれやら分からなくなる」という状況です。

プロジェクト初期は良いんです。
ボタン、カード、ヘッダーくらいシンプルなコンポーネントだけだから。
でも プロジェクトが進むにつれて、派生版が増えるんですよ。

  • ボタン（通常）
  • ボタン（大きいサイズ）
  • ボタン（小さいサイズ）
  • ボタン（ホバー状態）
  • ボタン（テキストのみ）
  • ボタン（アイコン付き）

あ、これ見ててもカオスですやん。
「ボタン」で検索しても30個くらい出てきて、どれを使えばいいのか後輩も混乱します。

現場でよく見るのは「必要なコンポーネントが見つからなくて、新しくコンポーネントを作る→実は同じものがあった」という二度手間。
これめっちゃ時間のムダになるんですよ。

「親→子→孫」の階層設計で整理する

そこで僕がオススメしたいのが「階層的なコンポーネント設計」です。
Figmaのコンポーネント機能を使って、マスターコンポーネント → インスタンス → さらに細かいインスタンス という流れを意識するんですよ。

具体的に説明しますね。

ステップ1：親コンポーネントを作る

まず「Button」という基本のマスターコンポーネントを1つ作ります。
これが親です。
プロパティとしては以下のものを持たせます。

  • Size（small / medium / large）
  • Type（primary / secondary / tertiary）
  • State（default / hover / active / disabled）
  • Icon（true / false）

ここまで一気にやるのが大切なんですよ。
後から「あ、アイコン対応してなかった」ってなるのが現場あるあるです。

ステップ2：子コンポーネント（バリアント）を活用する

Figmaの「バリアント」機能を使うと、1つの親コンポーネントから複数の派生パターンを作れます。
このバリアントこそが「子」にあたります。

例えば「Button / primary / medium / default」というバリアントと「Button / secondary / small / hover」というバリアントは、すべて同じ親「Button」の子なんです。

メリットはめっちゃあります。

  • 親を編集すると、すべての子が自動更新される
  • コンポーネントパネルの整理がシンプルになる
  • デザイナーが「どのバリアントを使うべき」か判断しやすくなる

ステップ3：複合コンポーネント（孫）で実装パターンを表現する

さらに進むと「Button Group」みたいな複合コンポーネントが出てくるんですよ。
これは子のButtonコンポーネントを複数組み合わせたもの。
つまり「孫」ですね。

この時点で、階層構造がこんな感じになってます。

  • Button（親）
  • ├ Button / primary / medium / default（子=バリアント）
  • ├ Button / secondary / small / hover（子=バリアント）
  • └ Button Group（孫=複合コンポーネント）
  • 　 ├ Button Group / horizontal（孫の子）
  • 　 └ Button Group / vertical（孫の子）

ほんま、このくらい整理されていると、後輩が使う時にも迷わないんですよ。

命名規則を統一してチーム全体で迷わない

階層設計ができても、命名がバラバラだと意味がないんですよ。
僕も過去に痛い目に遭いました。

あるプロジェクトで、ボタンのコンポーネントが以下みたいにバラバラに名付けられてたんです。

  • Button
  • btn_primary
  • Button - Small
  • PrimaryButton
  • button_secondary_lg

これぜんぜん検索できないし、統一感ないし、エンジニアも「なんやこれ？」ってなるわけです。

統一した命名規則のテンプレート

チーム全体で使える命名規則を、フィグマのドキュメントに書いておくといいですよ。
僕が現場で使ってるテンプレートは以下のような形です。

パターン：コンポーネント種別 / 用途 / サイズ / 状態

  • Button / Primary / Medium / Default
  • Button / Secondary / Small / Hover
  • Card / Article / Default / Default
  • TextField / Standard / Large / Focused

ルールとしては以下の点を抑えるといいですよ。

  • 大文字で始める（PascalCase）
  • /でレベルを分ける
  • 日本語は使わない（エンジニアも見るから）
  • 「Default」「Normal」「Standard」みたいに統一する
  • 「状態」が不要な場合は省略してOK

ドキュメントを「Figmaファイル内に作る」が大事

これ、めっちゃ大事なんですよ。
命名規則をスプレッドシートや別ドキュメントに書くのは避けてください。
Figmaファイルの中に「Design System」みたいなページを作って、そこに命名規則と使用例を書いておくんです。

そうすると、新しいメンバーがFigmaを開いた時に「あ、このコンポーネントはこういう仕組みなんだ」ってすぐに理解できるんですよ。

ほんま、これをやるだけで「コンポーネント、どれ使えばいいですか？」という質問が80%減ります。

まとめ

Figmaのローカルコンポーネントを整理するコツは以下の3点です。