デザインシステムのスケーラビリティと組織的制約

デザインシステムはこの10年でプロダクト開発のインフラとして定着した。しかし、初期の熱量と実装コストのわりに、スケール時に期待通り機能しない事例が少なくない。原因の多くはコンポーネントの技術設計そのものではなく、粒度の判断、変更ガバナンス、実装ミラーリングの運用にある。本稿は、デザインシステムのスケーラビリティを技術面と組織面の交点として整理する。

要点

デザインシステムは「共通コンポーネント集」ではなく、意思決定を分散させるためのプラットフォームである。スケールを妨げるのは技術負債よりも、変更ガバナンスの不在と、デザインファイルと実装コードの並行維持の破綻である。組織の意思決定構造に合わないシステムは、技術的に完璧でも使われない。

粒度の判断と分類の限界

Brad Frost の「Atomic Design」（2016）は、原子・分子・組織・テンプレート・ページという階層を提示した。これは初学者にとって思考の枠組みとして有用だが、実プロジェクトでは分類が判定困難になる場面が繰り返し発生する。ボタンとアイコンを合成した「アイコン付きボタン」は分子か原子か。ドロップダウンとフィールドの組み合わせは有機体か分子か。境界の判定に時間を使うほど、システム自体が意思決定コストを増やしてしまう。

Alla Kholmatova の「Design Systems」（2017）は、粒度を分類ではなく「振る舞い（behavior）と外観（appearance）」の二軸で捉え直すことを提案している。振る舞いは共有可能だが、外観は文脈に応じて逸脱を許容する、という運用モデルである。これは、Frost 的な階層的厳密さよりも、実プロジェクトの現実に近い。

もっとも、どちらの理論も「境界の判定を運用ルールに委ねる」という帰結に至る。フレームワークが判定を代わりにしてはくれない。実務で観察されるのは、粒度判定を強い意見のあるデザイナー1〜2人が独占するか、あるいは全員合議で意思決定コストが積み上がるかの両極端である。

トークン層と実装ミラーリング

近年のデザインシステムは、色・タイポグラフィ・スペーシングを「デザイントークン」として抽象化し、Figma・iOS・Android・Web の各実装で同じトークン ID を参照する構成を採る。Salesforce Lightning Design System、Shopify Polaris、GitHub Primer などの公開ドキュメントで参照できるパターンである。W3C の Design Tokens Community Group が標準フォーマット策定を進めている（@tokens-studio 系列や Style Dictionary が実装エコシステム）。

この層構造の恩恵は明確である。ブランドリフレッシュ時にトークンを差し替えれば、複数実装が同時に更新される。しかし運用上の落とし穴もある。以下の三点である。

• 命名衝突： color.primary のような意味付き命名は、初期は分かりやすいが、複数ブランド・複数テーマ運用時に破綻する。Semantic naming と reference naming のどちらを主層とするかの判断が要る。
• Figma と実装の non-round-trip： Figma 側でトークンを更新しても、実装コードへの反映は手動または CI パイプライン依存であることが多い。round-trip が保証されないと、両者の乖離が蓄積する。
• 変更のキャスケード検出： 一つのトークンが多数のコンポーネントに影響する場合、変更前に影響範囲を可視化する仕組みが必要になる。Storybook Chromatic のような視覚回帰テストが代替になるが、運用コストが高い。

ガバナンスモデルの選択

Nathan Curtis や EightShapes のドキュメントで整理されてきた通り、デザインシステムのガバナンスは主に三つのモデルがある。それぞれ組織構造との適合性が異なる。

1. Centralized（中央集権）： 専任のデザインシステムチームが仕様と実装を管理し、プロダクトチームは consumer として利用する。初期立ち上げに向くが、プロダクト数がスケールすると要求が滞留する。
2. Federated（連邦制）： 各プロダクトチームがシステムに contribute でき、コアチームがレビューとマージを担う。オープンソース的な運用が可能だが、貢献インセンティブ設計が難しい。
3. Distributed（分散）： プロダクトごとに独自 fork を許容し、コアは最小限の共通トークンだけを維持する。実質的にはシステムとは呼びにくいが、大企業のブランド横断で採用される場合がある。

組織の意思決定構造がプロダクトチーム主導であれば、Centralized は摩擦を生む。逆に、ブランド一貫性が強く要求される事業では、Distributed は矛盾する。Team Topologies（Skelton & Pais、2019）の「Enabling Team」パターンが Federated の運用モデルとして参照されることが増えている。

スケール限界の兆候

デザインシステムがスケール限界に達しているサインは、次のような形で現れる。

• 新規プロダクトが公式コンポーネントを使わず、独自実装を始める。
• コンポーネントのバリエーション（プロップ）が増え続け、API が肥大化する。
• Storybook のカバレッジが実装コードから乖離する。
• 公式ドキュメントより Slack や口伝で「どのコンポーネントを使うべきか」が伝わるようになる。

これらは技術問題として個別に対処できるが、根本原因は「システムの意思決定速度がプロダクトの要求速度より遅い」という組織問題であることが多い。プログレッシブ・ディスクロージャーの B2B UI ケースで述べる認知負荷の問題も、コンポーネントの粒度と密接に関わる。ただし、コンポーネントの粒度を組織で議論する場を持つこと自体が、システムの健全性の指標だという見方もできる。

結論

デザインシステムのスケーラビリティは、技術的な優雅さではなく、組織の意思決定構造と釣り合っているかどうかで決まる。中央集権モデルは初期に向き、連邦制はスケールに向くが、どちらも運用コストを組織のどこかに配分する必要がある。無コストでスケールするシステムは存在しない。アクセシビリティ規制の強化と連動して、システム側での準拠保証が重要性を増している点は、ダークパターン規制とアクセシビリティ基準の交差を参照されたい。

参照

• Frost, Brad. “Atomic Design.” Brad Frost Web, 2016.
• Kholmatova, Alla. “Design Systems: A Practical Guide.” Smashing Media, 2017.
• Curtis, Nathan. EightShapes 系記事群 — governance モデルの整理。
• Skelton, Matthew, Manuel Pais. “Team Topologies.” IT Revolution Press, 2019.
• W3C Design Tokens Community Group. 継続的な標準化作業、公開ドラフトあり。