作るだけのデザインシステムはいらない。「迷わず・速く・高品質」を実現するSSSの設計思想

はじめに：なぜ、クライアントワークにこそ「デザインシステム」が必要なのか

SSSが考えるデザインシステムを一言で表すと、それは「どんなプロジェクトでも、誰が関わっても、一貫したクオリティで成果を出せる“設計の基盤”」です。

私たちは自社サービスを持たず、クライアントワークを主軸としています。プロジェクトごとにクライアントも目的も異なる環境下で、常に高い品質を安定させるためには、以下の2つをセットで持つことが不可欠だと考えています。

1. 「何を良いデザインとするか」という判断基準（共通言語）
2. 「どう再現性高く実行するか」という仕組み（ワークフロー）

前回の記事では、エンジニア視点からフレームワーク「FlonCSS」について触れましたが、今回はデザイナー視点から、この「仕組み」をFigma上でどのように構築・運用しているか、その具体的な中身をお話しします。

デザインの変数化：VariablesとStylesで「共通言語」をつくる

私たちのデザインシステムで最初に行うのが、Design Tokens（デザイントークン）の定義です。具体的には、Figmaの「Variables（バリアブル）」と「Styles（スタイル）」を用いて、色や数値、文字設定を徹底的に管理しています。

なぜ、これが重要なのでしょうか？ 単に「スポイトで色を取る手間を省く」ためだけではありません。最大の目的は、エンジニアとの共通言語を持つことにあります。

SSSの開発現場では、Figmaの変数名と実装コード（CSS変数）が「1対1」で対応しています。 例えば、デザイナーがFigmaで「Color / Primary」という変数を使えば、エンジニアは迷わず --color-primary というコードを書くことができます。

• Variables（バリアブル）： 色（Color）、余白（Spacing）、角丸（Radius）などの数値を管理。

• Styles（スタイル）： タイポグラフィやエフェクト（影など）を管理。

これらを定義せず、デザイナーが感覚的に Hexコード(#333) や px数 を指定してしまうと、実装時に「このグレーとあのグレーは同じ意味なのか？」「余白が2px違うが意図的なのか？」という不毛な確認作業が発生します。 変数を共通化することで、デザインの意図がコードに直結し、実装ブレをゼロに近づけることができるのです。

「運用」を見据えた3つの構造設計

変数を定義しただけでは、システムは機能しません。重要なのは、プロジェクトが動き出した後に「いかに変更に強く、使いやすいか」です。そのために私たちは、Figmaの構造に3つのこだわりを持っています。

1. 「Settings」への集約：メンテナンス性の心臓部

定義したトークンは、無秩序に並べるのではなく「Settings」という概念で一箇所に集約します。 様々な企業のプロジェクトに関わっていると、進行途中で「ブランドカラーを微調整したい」というご要望をいただくことは珍しくありません。その際、各画面の要素を一つひとつ修正するのは非効率であり、ミスのもとです。

「Settings」で大元の数値を管理していれば、たった一箇所を書き換えるだけで、数百の画面デザイン（そして実装コード）へ瞬時に変更が反映されます。これにより、単純作業ではなく「デザインの質の向上」といった本質的な価値提供に時間を割くことができるのです。

2. Componentsの粒度管理：LEGOのような柔軟性

次に、UIパーツである「Components（コンポーネント）」の設計です。 ここでは、あえてガチガチに作り込みすぎず、プロジェクトに応じた柔軟な粒度で管理することを大切にしています。

巨大なコンポーネントを作りすぎると、少しのレイアウト変更で使い物にならなくなります。逆に細かすぎても構築に時間がかかります。 「再利用性」と「カスタマイズ性」のバランスを見極め、LEGOブロックのように組み合わせられる設計にすることで、新規ページ作成のスピードを劇的に向上させています。

3. 作業レイヤーの明確化：Workspace / In review / Fixed

そして、チーム開発で最も重要なのが「どのデータが正解か？」を迷わせない運用ルールです。 私たちはFigma内のページ構成を以下の3つのレイヤー（状態）に明確に分けています。

• Workspace（作業場）： デザイナーが試行錯誤する場所。エンジニアはここを見ません。
• In review（レビュー中）： クオリティチェックやクライアント確認を行う段階。
• Fixed（確定・実装待ち）： 全ての確認が完了し、「実装してOK」となったデータのみを置く聖域。

このルールを徹底することで、「作りかけのデザインが誤って実装される」という事故を防ぎます。 エンジニアは Fixed にあるものだけを見れば良い。この安心感が、手戻りのないスムーズな開発フローを実現しています。

デザインシステムは「育てるもの」

私たちが提供しているのは、単なる「整ったFigmaデータ」ではありません。

「何を良いデザインとするか（判断基準）」と、それを「どう再現性高く実行するか（仕組み）」をセットにした、生きたフレームワークです。

一般的なデザインシステムが「自社製品のために決められた型にはめる仕組み」だとすれば、SSSのデザインシステムフレームワークは「どんなクライアントの課題にも対応できるための土台と、その考え方」です。

仕組みを作って終わりではなく、実務の中でチーム全員が使い倒し、プロジェクトごとに育てていく。 そうすることで、属人化を防ぎ、品質を安定させ、クライアントのビジネス成果に直結するクリエイティブに集中できる時間を作る。

これこそが、SSSが考えるデザインシステムの在り方です。

この「運用しやすいフレームワーク」を使って、私たちと一緒に“迷いのない開発”を体験してみませんか？