それぞれの役割のチーム内で、それぞれの原則が存在し、1つの製品の「表層」を統一的に設計するデザインシステムを指します。
デザイナーがデザイナー側で使用するデザインシステムを持ち、エンジニアはエンジニア側で構築した開発ツールを用いて作成されたデザインデータに対し実装を行います。デザイン・実装が表層上でのみ対応し、内部的には連動しない状態です。

デザインシステムの構築要素例

デザイン原則（上位概念）の定義
このデザイン原則は、1つの製品に対して定義しますが、あるブランド内で複数の製品が存在する場合はそれらを包括したさらなる上位概念の定義を行い、各製品に適用することで、同一ブランド間の各製品で体験の統一を図ることもあります。
デザイン原則に従ったデザイン要素の体系化
デザインツール上で構造化されたスタイル・コンポーネント資材の構築
デザインを実現するための開発ツールの整備（③を見据えた実装の調整ができるとなお良い）

導入メリット（解決できる課題）

デザインにおける属人性の解消
製品内で最低限統一された体験・品質の提供
デザイナーの作業効率化・デザインコストの削減
デザインシステム適用箇所における変更対応の容易化
エンジニアの開発コスト・メンテナンスコストの削減

運用上の課題

デザインシステムのメンテナンスコスト増・メンテナンス担当者の決定
新規開発時都度の画面・パーツ作成における検討コスト
デザイン・実装それぞれのツールの非同期性によるコミュニケーションコスト
より好ましい体験・品質を構築するための、画面・パーツにおけるベストプラクティスの不在

参考調査

この段階のデザインシステム導入は、主に「デザイナーの作業効率化・デザインコストの削減」に大きく貢献します。
参考となる調査がありますので紹介します。

We found that when participants had access to a design system they completed their objective 34% faster than without a design system.
（中略）
Figma has 7 Product Designers and based on their calendars they each get about 20 hours of focused design time per week, for a total of 140 design hours per week.
（中略）
However, if every task they’re working on has a relevant design system, they are able to do 34% more design work in that 140 hours, giving them 212 design hours. That’s equivalent to adding another 3.5 designers to the team each week!
－Measuring the value of design systems / Figma社

実験調査では、デザインシステムを用いてデザインタスクを処理した場合、デザインシステムがない場合に比べて34％早くタスクを処理することができたという結果が出ています。
7名のプロダクトデザイナーが存在し、各デザイナーのデザイン作業時間が週あたり20時間としたとき、デザイナーの作業時間数は１週間あたり140時間。34％作業スピードが速くなる場合、3.5人分のデザイナーを追加したことに相当すると述べています。

この調査を参考に計算すると、チームに単価月70万円の10人のデザイナーが存在する場合、この段階のデザインシステムを導入すると年間で約2,856万円のコストが削減できるということになります。
※34％を再投資しない単純な計算（10人×70万円×12カ月×34％）

③：統制化されたデザインシステム

デザインと実装が連携し、1つの製品を統制的に設計するデザインシステムを指します。
デザイナーとエンジニアとで共通化されたデザインシステムが存在している状態です。

なお、モバイルアプリケーションを新規に開発する場合、初期からプラットフォームが提供しているデザインシステムを採用したほうが導入コストを大きく抑えられる可能性があります。

デザインシステムの構築要素例
（②の要素に加え）

デザインと実装とが1対1で対応した、デザインツールと実装ツールの同質化
ex.命名規則の統一、デザイントークンの1対1対応・コンポーネントライブラリの共通化、デザインシステム構造の共通化、など

導入メリット（解決できる課題）
（②の要素に加え）

実装コードが整理されることで読み込み速度が上がるなどの品質向上
チーム内でのコミュニケーションコストの削減
エンジニアの開発コスト・メンテナンスコストの削減

運用上の課題

プラットフォーム個別の要求と実現したいデザインとの衝突
より好ましい体験・品質を構築するための、画面・パーツにおけるベストプラクティスの不在

④：プラットフォームで最適化されたデザインシステム

デザインと実装が連携し、1つの製品を1つのプラットフォーム上で統一的に設計するデザインシステムを指します。

デザイナーとエンジニアとで共通化されたデザインシステムが存在し、1つのデザインシステムが1つのプラットフォームにおいて最適に対応している状態です。(「1つのプラットフォーム上」というのは、WebであればWebに対応したデザインシステム、AndroidであればAndroidに対応したデザインシステムが存在することを指します。)

この段階からデザインシステムは、デザイナーとエンジニアそれぞれの専門的観点を元にした綿密な設計が求められていきます。

デザインシステムの構築要素例
（②③の要素に加え）

1つのプラットフォームを前提とした各画面・パーツへのベストプラクティス・使用規則の採用、ないしは構築
・（モバイルアプリケーションの場合）iOSであればHuman Interface Guidelines、AndroidであればMaterial Designなどの各プラットフォームを前提としたデザインシステムのガイドラインを正しく採用している。もしくは自前で構築している。
・WEBの場合は、プラットフォーム側から提供されるデザインシステムが存在しないため、デザインシステムの構築は開発者の倫理性と裁量に任される（アクセシビリティガイドラインを正しく採用するなど）

導入メリット（解決できる課題）
（②③の要素に加え）

新規画面・パーツ作成における根拠の確立
それぞれのプラットフォームで最適化された一貫した体験の提供
チーム内でのコミュニケーションコストの削減
エンジニアの開発コスト・メンテナンスコストのさらなる削減

運用上の課題

デザインシステムの緻密化による、メンテナンス時の専門的知識の要求
プラットフォームごとに異なる仕様の管理
最適化されたデザインシステムをそれぞれのプラットフォームごとに用意するのではなく、1つのデザインシステムで完結させ、デザイン・実装を行いたい

参考調査

この段階から、デザインシステムが大きくエンジニアの開発コストに影響していきます。
参考となる調査がありますので紹介します。

Using a design system made a simple form page 47% faster to develop versus coding it from scratch. The median time for the scratch submissions was 4.2 hours compared to the 2 hour median time for Carbon submissions. The Carbon timing included the time the developers spent familiarizing themselves with the design system.
（中略）
Using a design system helped our developers produce code that was more visually consistent with the design. In fact, only one of the eight developers built a form from scratch that ranked higher in visual consistency than the form they built using Carbon.
－Yes, Design Systems Do Improve Developer Efficiency and Design Consistency / Sparkbox（Forge社）

この調査では、シンプルなフォームページの開発を、デザインシステムを用いて開発した場合とそうでない場合とで比較を行っています。
その結果、デザインシステムを使用した場合、ゼロからコーディングする場合に比べて 47％高速化されたと述べています。
また、デザインシステムを使用した場合、成果物のクオリティも高く、視覚的一貫性やアクセシビリティの評価が高くなったとも述べています。

これもまた単純な計算ではありますが、この調査を元に計算すると、チームに単価月70万円の10人のエンジニアが存在する場合、デザインシステムを導入すると年間で約3,948万円のコストが削減できるということになります。
※47％を再投資しない単純な計算（10人×70万円×12カ月×47％）

補足

さらにもう少し、具体的に補足します。

この段階のデザインシステムは、プラットフォームの特性やベストプラクティス・ユーザー状況などのUXを加味し、デザインに適用します。
iOSであればHuman Interface Guidelines、AndroidであればMaterial Designをデザインシステムに導入するか、それらを部分的に採用しプロダクトで実現したいデザインを融合するか、自前で全てを用意するのか、といったイメージです。

モバイルアプリケーションの場合、iOSであればHuman Interface Guidelines、AndroidであればMaterial Designに基づいてデザインがなされることで、エンジニアはそれらから提供される標準パーツやコンポーネントを用いてデザインを実装できます。
それらのコンポーネントは、アクセシビリティ対応や端末操作性など含めたUX体験を担保してくれる他、プラットフォームのアップデート・機能対応をシステム側が対応してくれるため、大きく開発・メンテナンスコストが下がります。

また、デザイン設計がプラットフォームに最適化されることで、プロダクトを使うユーザーはアプリケーションごとにインタラクションを覚え直す必要がなくなり、一貫した体験を実現できます。

⑤：クロスプラットフォームで最適化されたデザインシステム

1つのデザインシステムに従って、1つの製品を複数のプラットフォーム上で統一的に設計します。

複数のプラットフォームの最適化を1つのデザインシステムによって実現するという点でさらに高度となるデザインシステムの段階です。
この段階のデザインシステムは、クロスプラットフォーム開発を想定した開発ツールを導入するか否かによって大きく有用性が異なります。

デザインシステムの構築要素例
（②③④の要素に加え）

各画面・パーツがそれぞれのプラットフォーム上で、どのようなUI UXとして機能するのか定義されている
例えば、1つのダイアログUIをデザインしたときに、iOSの場合はどのようなダイアログデザインになり、Androidはどのようなダイアログデザインになるのか、Webの場合はどのようなダイアログデザインになるのか定義されている
クロスプラットフォーム開発のフレームワーク・開発ツールを採用するなどし、1つのデザインで、それぞれのプラットフォームの製品を実装できる環境の構築
Flutter・React Nativeなど

導入メリット（解決できる課題）
（②③④の要素に加え）

プラットフォームごとの開発におけるコミュニケーションコストの削減
プラットフォームごとの実装コストの大幅な削減

運用上の課題

各プラットフォーム固有の不具合発生時に、対応難易度の上昇
さらなる専門的知識の要求

クロスプラットフォーム開発とは、同じ環境・同じ言語で異なるプラットフォームの開発を行うことを指します。
iOS／Androidそれぞれで開発を行う体制と比較して、クロスプラットフォーム開発の場合、それぞれの専門知識を持つエンジニアを配置しなくて良い・1つの仕様変更に対してiOS／Androidで1回の修正で済む、など開発工数が大幅に少なく済むため、近年、注目されている開発手法です。

クロスプラットフォーム開発の強みを最大限に生かすためには、クロスプラットフォームを前提としたデザインシステムの構築・導入が重要となります。

ポイント2.プロダクト・チームが抱える課題を検討する

デザインシステムの段階とメリットについて把握したら、次はプロダクトやチームがどのような課題を持っているのか検討すべきでしょう。

導入・運用にコストがかかる以上、「作業が早くなるから」「デザインの一貫性を担保できるから」「コミュニケーションを減らしたい」などのなんとなくの理由では、デザインシステムの導入に対して、決裁者の承認や、能動的な職種間の連携を獲得することが難しいはずです。

プロダクトやチームがどのような課題を抱えていて、どのようなデザインシステムが必要なのか、明らかにする必要があります。これらをどのように明らかにするのか、以下で解説していきます。

課題と仮説を元にデザインシステムの影響を定量化する

多くのデザイナーやエンジニアが頭を抱えるポイントとして、デザインシステムの導入によって解決できる課題や期待できる効果を事前に予測しづらいという悩みをよく聞きます。

しかし、難しく考える必要はありません。
普段我々が行っているプロダクト開発の考え方と同じように、デザインシステムの導入を捉えれば良いのです。

プロダクトの開発では、過去のデータや他社事例を参考にして、経験に基づいた推測を行い、仮説的に施策を検討します。
ABテストを行って改良するのと同じように、数字を使って同じことを行えば良いのです。

デザインシステムはデザイナー・エンジニアが主体となって運用されるツールのため、デザイナー・エンジニアからボトムアップで推進していくことがほとんどです。
定量的に推測することを得意としない方は、マネジャーやデータアナリストなどそれを得意とする役割の人とコミュニケーションを取ることも視野に入れても良いでしょう。

まずは、プロダクトあるいはチームがどのような課題を抱えているのかを検討しましょう。
アクセシビリティスコアが低い、期待する案件総量に対してリソースが追いついていない、デザイン・実装の根拠となる資材を発見するのに手間をかけている、など、プロダクトや開発チームの現状から課題を挙げ出します。定量で可視化できるとなお良いでしょう。
チームとしてのKPTであったり、ヒューリスティック分析やユーザーインタビュー・データモニタリングであったりなど、課題分析にはさまざまなアプローチが考えられます。

そして、それらが改善されるとどのような効果をもたらすのか仮説を立てます。
過去の成功事例、データや他社事例、調査、あらゆるものが手助けとなるはずです。前章で述べたようなFigma社の調査やSparkbox（Forge社）の調査を元にしたコスト削減効果を推測したり、あるいは、煩雑なコードをデザインシステムによって整理し、読み込みパフォーマンスを改善する仮説を推測したりするのであれば、読み込みパフォーマンスが31％改善すると売り上げが8％増加したとするHubSpot社の調査なども参考になるかもしれません。