デザインシステムとは|『複数プロダクトの一貫性とスケーラビリティ』を支える設計基盤の本質

『デザインシステム』って、ぶっちゃけ何のことか、説明できますか?

株式会社Cameen 西村温裕ことおんゆーです。

近年、SaaS・Webサービス・モバイルアプリの開発現場で、デザインシステムという言葉を聞かない日はないんですよね。Material Design、Carbon Design System、Atlassian Design System、Apple HIG、こういう先進事例がベンチマークとして語られ、自社でも「デザインシステムを作ろう」という機運が高まっています。

でも、いざ「デザインシステムって具体的に何?」「コンポーネントライブラリと何が違う?」「Storybookさえ作ればデザインシステム?」と聞かれると、答えに詰まる方が多いんですよね。「再利用部品の集合」という認識で止まって、デザインシステムの本質的な役割まで理解している人は意外と少ない。これ、自分だけだと思ってませんか?

うちの事業はSaaS企業ではないんですが、おんゆー事業の各サイト(onyou0720.com・cameen.jp・Stylo・CBCマート等)、複数LP、複数ツール、複数管理画面を抱えていて、全プロダクトの一貫性とスケーラビリティを保つために独自のデザインシステム(DESIGN-jp-onyou.md)を構築・運用してきました。クライアント案件でもデザインシステム構築の相談を多数受けてきました。その中で見えてきたのは、デザインシステムは単なる「再利用部品集」ではなく、「複数プロダクト・複数チームの設計判断を統一する組織装置」だということ。部品を作ることが目的ではなく、組織の意思決定を統一することが本質です。

もう1つ繰り返し観察したのは、「コンポーネント作るだけで満足して運用ガバナンスを設計しない組織」が圧倒的に多いという事実。Storybookに100個のコンポーネントを並べても、それを実プロダクトで適用するルールと専任担当者がなければ、半年でデザインシステムは形骸化します。デザインシステムは作るより、運用するほうが10倍難しい領域です。

今回はその「今さら聞けないデザインシステム」を、業界の知見から、3層構造の核心と運用ガバナンスの本質まで深掘りしていきます。読み終わる頃には、自社でデザインシステムを構築するときに、どこから手をつけて、どう運用するべきかが、紙に書き出せるレベルになっているはずです。

結論:デザインシステムの核心は「コンポーネントライブラリ」ではなく「設計判断を統一する組織装置」

デザインシステムの本当の正体は、「複数プロダクト・複数チームの設計判断を統一し、一貫性とスケーラビリティを担保するための組織装置」のことです。単なる部品集ではなく、デザイナーとエンジニアと事業判断者が「同じ言語で意思決定する」ための共通基盤です。

業界の体感として、本格的なデザインシステムは「デザイントークン(色・タイポ・余白の数値定義)」「コンポーネント(Button・Form・Card等の再利用部品)」「パターン・ガイドライン(ユースケース・ベストプラクティス)」、この3層から構成されます。Storybookで見える「コンポーネントライブラリ」は、実は3層構造の中間層にすぎません。

デザインシステムの真の価値は、「色を1箇所変えれば全プロダクトに反映される」「新規プロダクト立ち上げ時の意思決定コストがゼロに近づく」「デザイナー・エンジニアの離職時にも知識が組織に残る」、こうした組織レベルのスケーラビリティです。1個1個のコンポーネントの美しさより、組織の意思決定速度を10倍にする装置、というのがデザインシステムの本質です。

これを理解せずに「Storybookを作ってコンポーネントを並べたからデザインシステム完成」と考えると、半年〜1年で形骸化します。デザインシステムは「作って終わり」のプロジェクトではなく、「組織の意思決定文化そのもの」を変える長期プログラムです。立ち上げと運用ガバナンスを分けて考える視座が必須です。

なぜ「Design System」と名付けられたのか

もう少し深く掘ります。なぜこの仕組みは「デザインシステム」と名付けられたのか。命名の背景を整理します。

「System」は英語で「体系・仕組み」のこと。単発のデザインや個別のコンポーネントではなく、相互に連動する「体系」として設計されている点が、デザインシステムの語源的特徴です。1個1個のパーツの美しさより、パーツ同士の関係性とルールが本質、という発想がここに込められています。

歴史的に見ると、デザインシステムの起源は1968年のNASAグラフィックスタンダードマニュアルにまで遡ります。米航空宇宙局が複数プロジェクト・複数部門で一貫したビジュアル表現を実現するために、徹底した色・タイポ・ロゴ運用ルールを文書化しました。これが現代デザインシステムの原型と言われています。

1990年代には、Sun Microsystemsが「Java Look and Feel Design Guidelines」を発表し、ソフトウェア領域での体系的デザインルールが整備されました。同じ頃、Microsoft・Apple・IBMが自社プロダクトのデザイン規約を厳格化し、企業レベルのデザイン統一が標準化されていきます。

そして2010年代、Atlassian Design System(2014年)、Google Material Design(2014年)、Salesforce Lightning Design System(2015年)、IBM Carbon Design System(2017年)、Airbnb DLS(2016年)、こうした先進事例が一気に登場し、「デザインシステム」という言葉が業界標準として定着しました。SaaS・Webサービスの大型化に伴う必然的進化です。

業界の体感として、2020年以降は「中規模スタートアップでもデザインシステム導入」が標準化しました。10年前は大企業の専売特許でしたが、現在は数十人規模の企業でも、複数プロダクト展開・複数チーム並行開発を前提に、デザインシステムを早期段階から構築する文化が一般化しています。Figmaの台頭がこの普及を加速させました。

日本でも、SmartHR、freee、サイボウズ、メルカリ、こうした主要SaaS企業がそれぞれ独自のデザインシステムを公開しています。SmartHR UIライブラリ、freee VibesDesignSystem、kintone UI Component、メルカリBalance、こうした先行事例が、後発企業の参考軸として機能しています。日本のデザインシステム文化も成熟してきました。

業界の進化として、近年は「デザイントークンの標準化」が大きなトピックです。W3C Design Tokens Community Groupが規格を整備し、Figma・Storybook・各種コーディング環境で「同じ色・余白・タイポを一元管理する」インフラが整いつつあります。デザインシステムが「組織装置」から「業界横断インフラ」へ進化中の段階です。

デザインシステム構築の現場で何が起きているか

デザインシステム構築の現場で、具体的に何が起きているか。5段階で整理します。

ステージ1:既存UIの監査と現状分析

デザインシステム構築の最初のステップは「既存UIの監査(Audit)」です。自社プロダクトで現在使われている色・フォント・ボタン・フォーム・カード、すべてのUI要素を洗い出し、一覧化します。多くの組織で、ここで衝撃的な事実が発覚します。

業界の体感として、監査を実施すると「ブランドカラーが20種類以上の似た色で乱立している」「ボタンスタイルが30種類以上ある」「フォントサイズが15種類以上使われている」、こういう現実が見えてきます。同じ意図のUIに対して、デザイナーごと・プロダクトごとに微妙に異なる実装が並んでいる状態が、ほぼすべての組織で起きています。

監査の目的は「使われているUIを否定する」ではなく「現状を可視化し、何を統一して何を残すかを意思決定するための基礎データを得る」こと。スクリーンショット採取・スプレッドシート整理・Figma上での一覧化、こうした地味な作業を1〜2ヶ月かけて実施します。デザインシステム構築の8割は、この監査フェーズで決まります。

ステージ2:デザイントークンの抽出と定義

監査結果から、デザインシステムの最深層である「デザイントークン」を抽出・定義します。デザイントークンは、色・タイポグラフィ・余白・角丸・影、すべての視覚的属性を数値で定義した最小単位です。

例えば、ブランドカラーを「primary-500: #1A2332」「primary-400: #2A3548」のように、用途別・濃淡別に体系化します。余白も「spacing-1: 4px」「spacing-2: 8px」「spacing-3: 16px」のように4の倍数階段で定義。フォントサイズも「text-sm: 14px」「text-base: 16px」「text-lg: 18px」のように段階化します。

デザイントークンの最大の価値は「変更時の一括反映」です。例えば、ブランドカラーを変更したいとき、token定義1箇所を書き換えれば、全プロダクト・全コンポーネントに即時反映されます。これがコンポーネントレベルの管理だと、数百箇所を1つずつ修正する膨大な作業が発生します。トークン定義は、デザインシステムの最重要層です。

ステージ3:コアコンポーネントの設計と実装

トークン定義が完了したら、その上にコアコンポーネントを構築します。Button、Input、Select、Checkbox、Card、Modal、Table、Pagination、Tooltip、こうした基本UIパーツを、各種バリエーション(プライマリ・セカンダリ・ダンジャー・サイズ大中小)込みで設計・実装します。

業界の標準的な進め方は、まずFigmaで Visual Component を作り、その後 React/Vue/Web Components 等のフレームワークで Code Component を実装、最終的にStorybookで両者を一覧化する流れです。Figma上の見た目とコード上の振る舞いが完全に同期する状態を作るのが、コアコンポーネント層の目標です。

ステージ4:ドキュメント整備とガイドライン化

コンポーネントが揃ったら、それを「いつ・どこで・どう使うか」のガイドラインを整備します。ここで初めて、デザインシステムは「部品集」から「組織装置」へ昇格します。

ガイドラインの典型例は「Primary Buttonは1画面に1個まで」「フォーム送信ボタンは右下に配置」「エラーメッセージは赤系トークン(error-500)で表示」「成功メッセージは緑系トークン(success-500)で表示」、こうした適用ルールの言語化です。これが整っていないと、コンポーネントは存在しても、デザイナーごとに使い方がバラバラになります。

ドキュメントの形式は、Storybook単体ではなく、専用のドキュメントサイト(Notion、Confluence、Docusaurus等)を立てるのが業界標準です。Material Designの公式サイト、Atlassian Design Systemの公式サイトを参考にすると、ドキュメント整備の重要さが理解できます。デザインシステムの「アクセス可能性」を最大化する設計が必須です。

ステージ5:継続運用とガバナンス体制構築

デザインシステムは作って終わりではありません。むしろ、構築完了から「真の戦い」が始まります。継続運用とガバナンス体制の構築が、ステージ5の本質です。

業界の標準的な運用体制は、デザインシステム専任チーム(Design Ops チーム)を設置し、デザインシステムへの追加・変更リクエストを受け付ける窓口を作ります。新規コンポーネントの追加、既存トークンの変更、ガイドラインの更新、すべて専任チームのレビュー経由で進める仕組みです。

運用フェーズで起きる典型的問題は「個別プロダクトチームが独自にコンポーネント追加して、システムから乖離する」「トークンを無視してハードコードする」「ドキュメント更新が追いつかない」、こうした統制の崩壊です。専任チーム不在で、デザインシステムは半年で形骸化します。継続運用に投資できる体制があってこそ、デザインシステムは長期的な価値を生みます。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

大手建設会社の標準仕様書に置き換えてみます。あなたが大手建設会社の現場監督だと仮定します。マンション、オフィスビル、商業施設、住宅、全国で同時並行に数十のプロジェクトが進んでいる。各プロジェクトで使う鉄筋・コンクリート・配管・配線・建具・内装材、すべての規格をプロジェクトごとにゼロから決めていたら、どうなるでしょうか。

答えは明白で、業務が完全に破綻します。プロジェクトごとに材料発注先がバラバラで、品質基準もバラバラで、工事手順もバラバラ。同じグレードのマンションのはずなのに、ある現場と別の現場で内装の質が全く違う。コストも納期も品質も、すべてが管理不能になります。

これを防ぐために、大手建設会社は「標準仕様書」を作ります。「マンション標準グレードでは、鉄筋はSD345・ABC社製を使う」「内装ボードは石膏ボード厚9.5mm・DEF社製を使う」「コンクリート強度は30N/mm²以上」、こういうルールを全社統一で文書化します。これがあるから、全国の現場で品質・コスト・納期の整合性が取れます。

これ、まんまデザインシステムです。「マンション=プロダクト」「鉄筋・コンクリート=デザイントークン」「建具・内装=コンポーネント」「標準仕様書=デザインシステム」。複数プロダクトの一貫性と品質を担保するための共通基盤、というのが標準仕様書とデザインシステムの共通本質です。

もう1つ、レゴブロックを例にすると、さらに分かりやすいです。レゴブロックは数十種類の「基本ブロック」を組み合わせることで、無限の構造物を作れます。基本ブロックの寸法・接続規格が完全に統一されているから、誰が作っても確実に組み合わせられる。これがデザインシステムにおける「コンポーネント+トークン」の関係です。

そしてIKEAの家具も同じ思想です。家具1つ1つは異なるんですが、「ネジ・蝶番・脚の規格」「組み立て手順の文法」「色・素材の組み合わせルール」、こうした「裏側のシステム」が完全に統一されています。だからIKEAは少ない種類のパーツで、膨大なバリエーションの家具を生産できます。デザインシステムが目指す「最小限のパーツで最大限のバリエーション」の理想形が、IKEAに体現されています。

業界の事例として、Material Design・Carbon Design System・Salesforce Lightning Design System、こうした大規模デザインシステムが目指しているのは、まさに「巨大組織における標準仕様書」の役割です。Googleの何万人のエンジニアが、世界中で同時並行にプロダクト開発していても、ユーザーから見て「Googleらしい一貫した体験」になっている理由は、Material Designというデザインシステムが裏側で機能しているからです。

逆に、デザインシステムなしで複数プロダクト・複数チーム並行開発をすると、必ず破綻します。プロダクトごとに微妙に違うボタン・色・余白・タイポ、ユーザーから見ても「同じ会社のサービスとは思えないバラバラ感」が出ます。組織の規模が大きくなるほど、デザインシステムの有無が事業競争力を決定的に左右します。

デザインシステム成功の3層構造