昨年、あるスタートアップでデザインシステムの構築を任された。プロダクトはすでに数万人のユーザーを抱え、デザイナーは3人、エンジニアは15人。誰もが「そろそろ必要だよね」と口にしながら、誰も手をつけられていない状態だった。この記事は、その半年間の記録であり、これから同じ道を歩む人への実践的なメモでもある。
なぜ必要だったのか
きっかけは、チームのスケーリングだった。デザイナーが1人の頃は、その人の頭の中がデザインシステムだった。しかし3人になった瞬間、同じ「プライマリーボタン」が3種類の青で実装され、余白のルールは人によって8pxだったり10pxだったりした。エンジニアからは「どれが正なのか分からない」という声が上がり、レビューのたびに些細なスタイル議論で時間が溶けていった。
つまり問題はデザインの美しさではなく、意思決定のコストだった。システムとは、繰り返される判断を一度だけ済ませるための仕組みだ。そう定義し直したことで、経営層への説明もすんなり通った。
Phase 1 — 監査と棚卸し
最初にやったのは、新しいものを作ることではなく、今あるものを全部並べることだった。プロダクト内の全画面をスクリーンショットに撮り、ボタン、フォーム、カード、モーダルをひたすら切り出してFigmaの一枚のボードに貼っていく。地味で退屈な作業だが、これを飛ばすと必ず後で痛い目を見る。
結果は想像以上にひどかった。ボタンだけで34バリエーション、グレーは22色。しかしこの「惨状の可視化」こそが最大の成果だった。チーム全員が同じ画像を見て、同じ危機感を共有できたからだ。
Phase 2 — Design Tokensから始める
コンポーネントから着手したくなる気持ちを抑えて、まずDesign Tokensを定義した。カラー、タイポグラフィ、スペーシング、角丸、シャドウ。プリミティブな値（blue-500のような原色パレット）と、意味を持つセマンティックトークン（color-action-primaryのような用途名）の二層構造にした。
この二層構造のおかげで、後にブランドカラーを微調整したときも、変更は一箇所で済んだ。トークンはJSONで管理し、FigmaとコードのCSS変数に同期する。デザインと実装が同じ言語を話し始めた瞬間だった。
「完璧なシステムを目指すな。使われるシステムを目指せ。」
これはチームで決めた合言葉だ。網羅性よりも採用率。ドキュメントの美しさよりも、明日のプルリクエストで使われること。優先順位を間違えたシステムは、立派な廃墟になる。
Phase 3 — コンポーネント化
トークンが固まったら、ようやくコンポーネントだ。考え方のベースにはAtomic Designを置いたが、厳格にしすぎないことを最初に決めた。「これはAtomかMoleculeか」という神学論争は時間の無駄でしかない。実際にはAtom、Component、Patternの3階層に簡略化し、迷ったら使用頻度の高い方に寄せるルールにした。
着手順は監査データに基づいて決めた。出現頻度の高いボタン、テキストフィールド、カードの3つから始め、2週間ごとに数個ずつリリースしていく。一気に全部作らない。小さく出して、フィードバックをもらい、直す。プロダクト開発と同じリズムだ。
運用のリアル
システムは作って終わりではない。むしろ作ってからが本番だ。運用で効いたのは次の3つだった。
- 週1回30分の「システム定例」 — 追加・変更の判断をその場で即決し、滞留させない。
- 例外を禁止しない — 例外は記録さえすれば、次のアップデートの種になる。
- エンジニアをオーナーに巻き込む — デザイナーだけのシステムは、コードベースから静かに乖離していく。
正直に言えば、リリース後3ヶ月で一度停滞した。新機能ラッシュでシステム更新が後回しになったのだ。救ったのは仕組みではなく、「壊れたら自分が直す」と言ってくれた一人のエンジニアだった。システムは結局、人が運ぶものだ。
振り返りと学び
半年を振り返って、学びを3つに絞るならこうなる。第一に、監査から始めること。現状の可視化が共通認識をつくる。第二に、トークンという土台に先に投資すること。第三に、完成度よりも採用率を追うこと。
デザインシステムは銀の弾丸ではない。しかし、チームが同じ言葉で話すための辞書にはなる。そして辞書は、使われるほどに育っていく。もしあなたのチームが今まさにスケーリングの痛みを感じているなら、まずはスクリーンショットを全部並べるところから始めてみてほしい。