《綿貫佳祐のFigma思考ラボ｜Vol.3》コンポーネントはどこまで作り込むべきか？ 〜デザインとコードの狭間で考える設計思考〜

Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はどう活用しているのだろう」と感じている方も多いのではないでしょうか。

本連載では、Figmaの使い方や、Figmaを軸にしたワークフローを紹介します。ただし、単なる機能解説ではありません。各機能をどう捉え、どんな思考で使いこなしていくのか–––––その“思考”に焦点を当ててお届けします。ときには1人のUIデザイナーとして、ときにはチームの一員として、私がどのようにFigmaと向き合っているのかを共有していきます。

第3回は、コンポーネント設計の考え方について深掘りしてみましょう。

はじめに：コンポーネント設計をめぐる温度差

Figmaでコンポーネントを作成する際、「どこまで作り込むべきか」で悩んだことはないでしょうか。

私自身、長年この問題と向き合ってきました。デザイナーとして視覚的なクオリティを追求したい気持ちと、実装を見据えた構造的な設計の必要性。この2つのバランスをどう取るかは、常に判断が求められるポイントです。

前回の記事では、オートレイアウトについて「誰のための機能か」という視点から考察しましたが、コンポーネント設計においても状況は同じです。どこまで作り込むのか、どのように構造化するのか、バリエーションをどう整理するのか、そして長く使える形にするにはどうすればよいのか──判断に迷う場面は多いのではないでしょうか。

この記事では、デザインツールにおけるコンポーネントの立ち位置を整理しつつ、チームとしてコンポーネントを最大限活用するための設計の考え方を掘り下げていきます。

デザインツールのコンポーネントとコードのコンポーネント

コンポーネントという概念の誕生

フロントエンド開発の世界では、2010年代半ばからReactをはじめとするコンポーネントベースのフレームワークが急速に普及しました。UIを独立した部品として管理し、再利用可能にする考え方は、開発の効率性と保守性を大きく向上させてきました。

デザインツールも、こうした流れに追従する形でコンポーネント機能を強化してきました。Figmaのコンポーネントやバリアント機能も、この文脈の中で理解する必要があります。

デザインツールならではのコンポーネント

ただし、ここで押さえておきたいのは、デザインツールにおけるコンポーネントが、コードとしてのコンポーネントと完全に1対1で対応するわけではない、という点です。

デザイナーは、視覚的な要素を起点にデータを作ることが多いため、「何度も繰り返し表示される要素」という単位でコンポーネントを作りがちです。頻繁に登場し、コピー＆ペーストすることが多い要素を、作業効率化のためにコンポーネント化する、という発想です。

この考え方自体は決して悪いものではありません。デザイン作業の効率化という観点では、非常に合理的だと言えます。

よくある「デザインツール特有」のコンポーネント

1. 見た目が似ているだけで役割が異なるUIを1つのコンポーネントにまとめる
   • ボタンのような見た目の<button>要素と<a>要素を同じコンポーネントとして登録する
   • 実装上はまったく異なる要素だが、デザイン上は同じスタイルとして扱いたいケース
2. 特定の使用場面に特化したコンポーネントセットを作る
   • 「記事一覧ページ用のカード型リンク10件セット」のように、特定の文脈でしか使わないコンポーネントを作る
   • コピー&ペーストの手間は減るが、汎用性は低い
3. 微妙なバリエーションごとに別コンポーネントを作る
   • 配置される場所によって微妙にサイズや余白が違うため、それぞれを別のコンポーネントとして管理する
   • 見た目の完璧さは保てるが、管理コストが高い

これらは「デザインツール上での作業効率」を最適化したコンポーネントです。 意図を持って制作し、コードと対応するコンポーネントとは分けて管理しないと、実装時に乖離が生まれてしまいます。

視覚優先のコンポーネント設計が生む課題

バリエーションの爆発

視覚的なクオリティを優先していくと、同じUIであっても多くのバリエーションが欲しくなります。ちょっとしたサイズの違い、余白の微調整、フォントサイズの変更などです。

しかし、そうした理由でコンポーネント数を増やしたり、ハック的にバリアントを作成していくと、後々大きな問題を引き起こすことになります。

具体的には以下のようなケースです。

1. コンテキスト依存の別コンポーネント化
   • 周辺要素が大きめのページと小さめのページで、配置したときの印象が違うという理由でフォントサイズの異なるコンポーネントを2つ用意する
   • まったく同じ要素で構成されているのに、使用場面が違うだけで別コンポーネントになってしまう
2. 細かすぎる条件分岐
   • アバターの有無しか違いがないカード要素なのに「アバターがあるときの余白は20px、ないときは16px」と細かすぎる調整がされている
   • 実装時にはこうした微調整すべてを再現しなければならず、CSSが複雑化する
3. 例外対応の積み重ね
   • 基本コンポーネントがあるのに、特定のページ専用の微調整版が3個も5個も存在する
   • どれが正解か分からなくなり、結果的にどのコンポーネントも使われなくなる

実装と改修での苦労

こうしたコンポーネント設計は、実装時と改修時に大きな負担を生みます。

実装時の問題

• デザイン上は別コンポーネントだが、コード上は同じコンポーネントとして実装すべきケースの判断が難しい
• 細かなバリエーション違いをすべて実装すると、コードが複雑になりメンテナンス性が下がる
• 「このバリエーションは本当に必要なのか」という確認コミュニケーションが頻発する

改修時の問題

• デザイン変更時に、どのコンポーネントを更新すればよいのかわからない
• 似たようなコンポーネントが複数あり、どれを使うべきか判断できない
• 一箇所の変更のはずが、5個のコンポーネントを更新する必要が出てくる

根本的な問題

細かな調整がユーザーの印象や使用感を左右するのは確かです。 しかし多くの場合、こうした状況は基礎的な設計に不備があり、場当たり的に種類を増やしている結果として発生しています。

数が少なければよいというものではありませんが、同じ役割・要素なのにたくさんの種類があるときは、何かおかしいかもと疑う必要があります。

コードを意識したコンポーネント設計

基本的な考え方

では、どうすればよいのでしょうか。 おおまかには以下の2つを意識することで、デザインとコードの乖離を減らせます。

1.　フロントエンドのコンポーネント単位と揃える

実装では大抵1ファイルが1コンポーネントとして管理されています。 Figmaのコンポーネントも、この単位に合わせて作ると、デザイナーとエンジニアの認識が一致しやすくなります。

また、コンポーネントに渡すデータ（実装側では「props」と呼ばれるもの）の種類や名前も揃えられるとベストです。 例えば、実装側でvariantというpropsを使っているなら、Figmaのバリアント名もvariantにするといった具合です。

2.　1つのコンポーネントで多様な状態を表現できるようにする

「New」などのバッジ、「続きを見る」などのリンク、ホバー状態、選択状態など、初めから様々な要素や状態を入れ込んでおき、ブーリアン型のバリアントプロパティですべて制御できるようにします。

これにより「このケースでは使えない」という状況を減らせます。 実装側も条件分岐で表示を切り替えるため、デザインデータの構造が実装の構造と対応しやすくなります。

具体的な実践例

例えば、記事カードコンポーネントを設計する場合を考えてみましょう。

この設計なら、実装側も同じ構造でコンポーネントを作れます。

デザイナーだけでは難しい

ただし、こうした設計をデザイナーだけで完璧に考え切るのは、現実的には難しいものです。

私自身、ある程度フロントエンドを書くこともありますが、それでも一人ですべてを最適に設計するのは困難だと感じています。特に、複雑なインタラクションや状態管理が絡む場合には、実装側の知見が不可欠です。

重要なのは、デザイナーとエンジニアが協力することです。

設計の初期段階から実装者を巻き込み、たとえば次のような会話ができる状態を目指すのが理想だと思います。

• 「このコンポーネントは実装上どう分けるべきか」
• 「このバリエーションは別プロパティにすべきか、別の値として扱うべきか」
• 「この状態管理はどうなっているか」

こうした対話を通じて、デザインとコードの両方にとって最適な設計を見つけていくことができます。

実践：コンポーネント設計の判断フロー

設計時の3つの質問

コンポーネントを作るとき、以下の質問を自分に投げかけてみてください。

1.　このコンポーネントは実装上も1つのコンポーネントとして扱われるか？

• YESなら → Figmaでも1つのコンポーネントにする
• NOなら → 見た目が似ていても別コンポーネントにするか、実装者と相談する

2.　このバリエーションは機能や要素構成の違いか、それとも見た目の微調整か？

• 機能や要素構成が違う → バリアントプロパティとして表現する
• 見た目の微調整のみ → オートレイアウトやパディング調整で吸収できないか検討する

3.　実装者はこのコンポーネント構造を理解して使えるか？

• YESなら → そのまま進める
• NOなら → 命名や構造を見直す、またはドキュメントを充実させる

バリアント設計のベストプラクティス

バリアントプロパティを設計する際のポイントは、以下の通りです。

プロパティ名はコードと揃える

• 実装側でsizevariant disabledといったprops名を使うなら、Figmaでも同じ名前にする
• キャメルケースなど、命名規則も合わせる

ブーリアン型を活用する

• ON/OFFで切り替わる要素は、それぞれ独立したブーリアン型プロパティにする
• 例えば、バッジ・著者情報・サムネイルという3つの要素があるなら、「バッジ・著者情報・サムネイルがすべて揃った状態」を1つのバリアントにするのではなく、showBadgeshowAuthorshowThumbnailという3つのブーリアン型プロパティを用意する
• こうすることで、8通り（2^3）の組み合わせを柔軟に表現できる

状態と見た目を分離する

• disabled loading errorなどの状態を表すプロパティ
• primary,secondaryなどの見た目のバリエーションを表すプロパティ
• これらは別のプロパティとして管理すると、組み合わせを作りやすい

チームでの運用方法

コンポーネントライブラリをチームで運用する場合、以下のような体制が効果的です。

定期的なレビュー会

• デザイナーとエンジニアが集まり、コンポーネントの構造を確認する
• 新規コンポーネントを追加する前に、既存のもので対応できないか議論する
• 使われていないコンポーネントや重複を整理する

ドキュメント整備

• 各コンポーネントの用途、プロパティの意味、使用例を記載する
• FigmaのdescriptionやGitHubのWikiなどを活用する

段階的な改善

• 最初から完璧を目指さず、まずは主要なコンポーネントから整備する
• 使いながら改善していく姿勢を持つ

AI時代のコンポーネント設計

構造化されたデザインデータの価値

前回の記事でも触れましたが、AI活用の文脈において、構造化されたデザインデータの価値はますます高まっています。

オートレイアウトと同様、コンポーネントとバリアントが適切に設計されていると、AIがその構造を理解しやすくなります。 結果として、より正確なコード生成が可能になるのです。

Figma Variables との連携

Figma Variablesが登場したことで、デザイントークンをFigma上で管理できるようになりました。 これをコンポーネントと組み合わせることで、デザインシステム全体の一貫性を保ちやすくなります。

コンポーネントのプロパティとVariablesを連携させることで、以下のような管理が可能になります。

• 色の一括変更（プライマリカラーの変更など）
• 余白やサイズの統一的な調整
• 複数パターンのスタイル切り替え（通常版と強調版など）

こうした仕組みを整えておくと、実装側でもデザイントークンを活用したコンポーネント設計がしやすくなります。

これからのデザインシステム

デザインシステムの構築と運用は、もはや一人の仕事ではありません。 デザイナー、エンジニア、プロダクトマネージャーなど、多様な役割の人が協力して作り上げていくものです。

Figmaのコンポーネントとバリアントは、その協働の基盤となるツールです。 だからこそ、「自分が使いやすい」だけでなく、「チーム全体が活用しやすい」設計を心がける必要があります。

まとめ：コンポーネント設計は対話から生まれる

この記事では、コンポーネントとバリアントの設計について、デザインツール特有の視点とコードを意識した視点から考察してきました。

重要なポイント

• デザインツールのコンポーネントとコードのコンポーネントは完全に1:1対応しない
• 見た目優先の設計は作業効率を上げるが、実装や改修で課題を生みやすい
• コードを意識した設計には、フロントエンドの単位との整合性が重要
• デザイナーだけで完璧な設計は難しく、エンジニアとの協働が不可欠

実践のために

コンポーネント設計に正解はありません。 プロジェクトの規模、チームの体制、プロダクトの性質によって最適解は変わります。

大切なのは、どこまで作り込むか、どのように構造化するか、バリエーションをどう整理するかという判断を、チームで対話を重ねながら行っていくことです。

前回のオートレイアウトの話と似ていますが、コンポーネントも「チームとして重視するポイントを理解した上で、適切な作り込みの程度を選択する」という姿勢が、長く使える設計につながります。

今回触れたVariablesについては、別の記事で詳しく取り上げる予定です。 コンポーネントとの連携や、デザイントークンとしての活用方法など、実践的な内容をお届けします。

文：綿貫佳祐