どこまで作り込む？事業や会社の規模にあわせたデザインシステムの考え方

概要

2025年4月11日にFriends of Figma Osaka #07 w/ FoF Nagoyaというイベントがあり、そこでお話しました。

以降は実際の登壇で使用した台本と、スライドのスクリーンショットです。

また録画もYouTubeに上がっています。
良ければこちらもご覧ください。

---

導入

では早速「規模にあわせたデザインシステムの考え方」についてお話します。
みなさん日頃デザインシステムの事例を色々調べますよね？

その際見つかる事例って、隅々まで作り込まれたものばかりですよね？
GoogleやAtlassianのようなビッグテックのものはもちろん、日本企業でもSmartHRやユビーなどの事例を見ると「真似したい」という気持ちと「こんなに網羅的に作るなんて途方も無い」という気持ちが同時に湧いてくると思います。

ところで、ビッグテックと同レベルの細かさや網羅性があることが、常に最善の選択なのでしょうか？

そうでもありません。
まだ小さいプロダクトや成熟していない組織に、細かく網羅的過ぎるデザインシステムを適用しても、逆に上手くワークしないことが多いです。

というわけで、ここからは具体的な事業・会社の規模別に、どこまで作るのをお勧めするかを紹介します。

注意

なんですが、先に一点だけ注意です。

話を分かりやすくするために、一番ポピュラーな言葉である「デザインシステム」をタイトルに使っていますが、実態としてはコンポーネントライブラリやトークンライブラリに閉じていることも多いです。
デザイン原則やユビキタス言語の定義、あるいはコードとFigmaデータとの同期などもデザインシステムを語る上では外せませんが、Friends of Figmaのイベントであることを踏まえても今日はFigma内の話に焦点を当てます。

具体例

では、具体的な例を見ていきましょう。
事業や会社の規模に応じて、どのようにデザインシステムを構築していくべきか、いくつかの観点から説明します。

事業のフェーズ

「ローンチ前・直後」「成長期」「成熟期」の3つのフェーズに分けてお話します。

ローンチ前・直後

まず、サービスをローンチする前や直後の段階では、あまり細かく作り込む必要はありません。
この時期は、コーポレートカラーやブランドカラーなど、本当に重要なもの以外は、世の中にある既存のアセットをそのまま使うことをお勧めします。

例えば、Tailwind CSSやPanda CSSなどで定義されている色をそのまま使っても問題ありません。
アイコンやイラストなどを内製しようとすると、途轍もなく時間がかかってしまいます。
この時期は、グローバルトークンだけを定義しておけば十分です。
なぜなら、まだ何をエイリアストークンにすべきか、何がどれくらいの粒度で必要になるかを見極めることが難しいからです。

今さらっとグローバルトークン、エイリアストークンという話をしました。
簡単にだけ説明すると、RGBやHEXの値に名前をRedとかBlueとかの名前をつけたのがグローバルトークンで、Grayの800はテキストの色、Redの500はボタンの色などといったように、それぞれの色に名前をつけたのがエイリアストークンです。

成長期

サービスが成長してくると、より細かい定義が必要になってきます。

この時期には、エイリアストークンを定義していきましょう。
なぜなら、そろそろどこで何をどれくらい使っているかが見えてくるはずだからです。

また、頻繁に使うものを見極めて、細かく定義していくことが重要です。
よく変更するものは変更しやすいように、バリエーションが必要なものは、バリアントとして定義するのか、独立した別のコンポーネントとして定義するのかなどを考えていきましょう。

一方で、普段触らないものにはあまり手を入れないようにしましょう。
「念の為」で作るものは、使用頻度が少ないだけでなく、将来に禍根を残す原因にすらなります。
使ってもいないものを更新・修正する作業の虚無感ったらないですからね。

成熟期

サービスが成熟してくると、また違った課題が出てきます。

成長に伴い、齟齬が出てきている部分を直していく必要があります。
ただし、ある程度成熟するまでは、問題があってもすぐに手を入れない方が良いです。
その都度その都度修正すると、後から見たら無駄な作業だったり、筋の悪い選択をしてしまったりすることが多いからです。

この時期は、トークンやコンポーネントそのものより、ドキュメントの整備と日々の更新が重要になってきます。
事業が成熟している場合、人の追加や入れ替えが起きることも多いです。
属人化していて解消が難しい場合、「この事業は売上が大きいからすぐに対応が必要」となって、せっかくのデザインシステムを無視した運用になることもあります。

どれだけ丁寧に育ててきても、崩れるときは一瞬です。そうならないためにも、ドキュメントをしっかり整備しておくことが大切です。

SBU数（≒ 事業数、≠ プロダクト数）

次にSBU数にあわせたデザインシステムの構築についてお話します。
ただ、耳慣れない言葉かもしれませんのでSBUについて簡単にだけ説明します。

SBU（Strategic Business Unit）というのは、簡単に言うと「独立した事業単位」のことです。
例えば、同じ会社内で「ECサイト」「SaaS」「メディア」など、異なる事業を展開している場合、それぞれが1つのSBUとなります。
また、同じ業態でも、ターゲット層や運営方針が大きく異なる場合は、別のSBUとして扱うこともあります。
例えば、同じECサイトでも「一般消費者向け」「法人向け」「中古品専門」など、異なるSBUとして扱うケースもあります。
プロダクトの数ではなく、このSBUの数で判断する方が、デザインシステムの構築には効果的です。

1つ

SBUが1つだけなら、大抵の場合1つのデザインシステムを作ればOKです。
ただしデザインシステムは1つながらトークンライブラリは複数、というパターンはあるかもしれません。

2~3つ

SBUが2〜3つある場合、2つのパターンが考えられます。

1つ目は、複数のデザインシステムを持つパターンです。
それぞれのシステム内で完全に独立したトークンやコンポーネントを扱います。

2つ目は、1つのデザインシステムを共通で使用するパターンです。
この場合、共通のトークンライブラリと固有のトークンライブラリ、共通のコンポーネントライブラリと固有のコンポーネントライブラリを組み合わせて運用します。

複数のSBUで、明確に共通化した方が効率よくなる場合は共通化するのが良いでしょう。
ただし、自信がない場合は下手に共通化せず、固有のデザインシステムを用意しておく方が良いです。

例えば見た目は似ていても、SBU固有のバリエーションが後から後から必要になる場合、共通化されていると分岐量が非常に多くなってしまいます。

4つ~

SBUがたくさん、おおむね4つ以上になると、より複雑な構成が必要になってきます。

この規模になると、メインのサービス群とサブのサービス群に分かれることが多くなります。
メインのサービス群は同じ名前・ブランドを冠するプロダクトの細かなバリエーションで、サブのサービス群はあえて名前を分けたくて生まれたものや、まだ本流のプロダクト群に入れるには早い未成熟なものが含まれます。

この場合、すべてを同じルールで共通化するのは難しいです。
メインのサービス群で1つのデザインシステム、サブのサービスはサービス1つにつき1つのデザインシステム、などと単位が分かれることもあります。

紋切り型に進めず、今後の会社の戦略も踏まえて考える必要があります。

提供先

toCやtoBなど1つだけ

提供先が1つだけの場合、シンプルです。

toCかつ社内向けなど複数

提供先が複数ある場合、少し複雑になります。

同じプロダクト・ブランドでも、コンポーネントライブラリを分ける方がいいことも多いです。
ここで注意してほしいのは、コンポーネントライブラリを分けることは、デザインシステムを分けることとは異なるということです。

toCで必要なコンポーネントはプロモーション的な役割が多いものの、クライアント向けや社内管理画面などの場合「余分な装飾はいいからとにかく情報をたくさん並べた方が良い」ということが多いです。

このとき、同じコンポーネントライブラリだとコンポーネントの数が多くなりすぎてしまいます。また、コンポーネント名が「toCButton」「toBHeader」といったようなものになりがちな上に、うっかりtoCコンポーネントをtoBのUIで使ってしまったりすると、後々ややこしくなってしまいます。

実演

では、ここまでの話を踏まえて、デザインシステムを作ったり、更新したりする様子を実演していきます。

よくある構成を意識しつつ、今日の内容をうまく説明できるように、以下の設定で進めます。

フェーズ1 立ち上げ

1. FigmaコミュニティでTailwind CSSを検索
2. ブランドカラーを追加
   1. あらかじめライブラリとビジュアルには追加しておく
   2. ビジュアル側は、最初は非表示状態
   3. 追加の実演にあわせて表示する
3. トークンライブラリとしてpublish
   1. データとしてはpublish済みなので、そういう説明をする
4. toC, 社内向けコンポーネントライブラリを作成
   1. toCはヘッダー、フッター、ページネーションだけ
   2. 社内向けはヘッダーだけ
5. toC, 社内向けモックアップを作成
   1. 作成と言いつつ、すでに完成しているものを見せるだけ
   2. この時点では背景色や文字色がブレている

フェーズ2 運用安定

1. 使用ルールが揺れているものを整理
   1. 説明に使うのはtoCだけ
   2. 背景色がzincの200と300、文字色がzincの800と900
   3. それぞれ200と900に統一
2. 登場頻度が高いトークンを整理してエイリアス化
   1. toCと社内向けでエイリアス化する内容を変える
      1. テキストのbodyとheading、それぞれbase, 2xlとxs, smに
   2. コンポーネントはグローバルトークンを直接参照しない
3. ドキュメントの整備

フェーズ3 姉妹サービス登場

1. トークンライブラリは共通
2. コンポーネントライブラリはそれぞれのサービス独自
3. 新たなモックアップの作成

まとめ

最後にまとめです。

ご清聴ありがとうございました。