← エピソード一覧に戻る Episode 187 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 部品が揃っても、なぜ開発は遅くなるのか
タカシ
今日は SaaS デザインのデザインシステムです。名前だけ聞くとボタンやフォームの部品集に見えますが、実際はもっと経営に近い話です。ここが弱い会社は、画面を揃えているつもりでも開発が遅く、品質もばらつきやすくなります。
ミカ
デザインシステムって、正直ちょっとおしゃれな整理整頓の話かなと思っていました。でも SaaS だと、そこが経営に近いんですね。見た目を揃えるだけじゃなくて、開発速度まで変わるんですか。
タカシ
変わります。Figma の社内チームは、色管理を変数ベースへ移したとき、古い情報に由来する差分を 280 件超も見つけました。つまり設計の正本が分かれているだけで、静かに品質コストが積み上がるわけです。
ミカ
280 件超は怖いですね。誰もサボっていないのに、Figma とコードと資料が少しずつズレていく。しかもそのズレって、リリース直前か運用中にしか見つからないから、地味に一番厄介なやつです。
Chapter 2 原則 ― デザインシステムは部品ではなく、判断の再利用
タカシ
デザインシステムの本質は、見た目の再利用ではなく判断の再利用です。色、余白、状態表現、文言、アクセシビリティ、コード実装まで、チームが毎回ゼロから決めなくていいようにする。だから経営的には、迷いを減らす仕組みなんです。
ミカ
なるほど。ボタンの形を統一するのが目的じゃなくて、『こういう場面ではこれを使う』という判断基準を揃えるわけですね。見た目が同じでも、使い方がバラバラなら結局レビューで止まりそうです。
タカシ
その通りです。Atlassian は design tokens を設計判断の single source of truth と定義し、色や余白を横断で標準化しています。良いシステムは『好きな緑を選ぶ』ではなく『成功状態はこの token を使う』まで決めるんですね。
ミカ
好きな緑を選ぶ会議、たしかに時間が溶けそうです。しかも SaaS って画面数が多いから、一回の迷いが何十画面にも増殖しますよね。判断を揃えるって、想像以上に利益率の話かもしれません。
Chapter 3 実務 ― GitLabとAtlassianに学ぶ、基盤とガバナンス
タカシ
GitLab の Pajamas は、基盤の作り方が分かりやすいです。全コンポーネントを 8px ベースの spacing system に載せ、関連要素は 8px、無関係要素は 16px という使い分けまで公開しています。余白にすら判断基準があるわけです。
ミカ
余白を感覚で決めないんですね。『なんとなく 12px 足しておこう』が減るだけでも、デザイナーとエンジニアの往復はかなり減りそうです。見えないけれど、確実に効くルールですね。
タカシ
さらに GitLab は、Pajamas を育てた結果、2021 年時点で 75%超のデザイナーが非常に有用と答えています。live-coded components や usage documentation が整うと、使い方の確認質問が減り、設計と実装の往復コストが落ちるんです。
ミカ
つまり、デザインシステムの ROI って『見た目がきれい』ではなく、『質問が減る』『差し戻しが減る』『速く作れる』なんですね。この切り口なら経営会議でも話しやすそうです。
タカシ
Atlassian はガバナンスの設計が参考になります。components と foundations に Early Access、Beta、General Availability の release phase を明示し、『今使ってよいか』『将来の破壊的変更リスクはどれくらいか』を見える化しています。
ミカ
それは大きいですね。使っていい部品かどうか毎回 Slack で聞く会社って、実はかなり遅いですもんね。部品の品質だけじゃなく、採用判断の不安を減らすのもシステムの仕事だと分かります。
Chapter 4 拡張 ― ShopifyとFigmaが示す、同期と展開の強さ
タカシ
Shopify の Polaris は、SaaS エコシステム全体へどう広げるかの好例です。2025 年に GA となり、App Home、Checkout、Customer Account、POS まで一貫した基盤を提供しました。採用側は Shopify らしい体験を各面で揃えやすくなります。
ミカ
面ごとに別の部品を覚えなくていいのは大きいですね。しかも CDN から最新を読み込むなら、個別アプリが全部 UI の保守を抱え込まなくて済む。プラットフォーム企業らしい勝ち筋です。
タカシ
Figma の事例も重要です。Dev Mode で Storybook や GitHub の実装へ直結させ、変数を CSS の token として参照できるようにしたことで、開発者が raw value を直書きするミスを減らしています。設計とコードの同期が、運用コストを左右するんです。
ミカ
結局そこですよね。『Figma にはあるけどコードにない』『コードにはあるけど誰も知らない』が一番つらい。リンクと変数の同期だけで、チームのストレスがかなり減りそうです。
タカシ
さらに Razorpay は、新機能では設計作業の 70%、既存製品では 50% をシステムでカバーする目標を置き、設計者と開発者の 80% が生産性向上を感じたと紹介されています。つまり adoption を測る設計まで含めて、ようやく経営資産になります。
Chapter 5 まとめ ― デザインシステムは、美談ではなく経営基盤
ミカ
今日の失敗パターンをまとめると、コンポーネントだけ作って原則や運用がない、Figma とコードの正本が分かれる、ドキュメントと教育が弱い、ROI を追わない、アクセシビリティを後付けにする、このあたりですね。
タカシ
ええ。zeroheight の 2026 年調査では onboarding materials を提供しているチームは 34% にとどまりました。まずは自社システムを tokens、components、documentation、governance、code sync の五層で棚卸しし、採用率や質問件数まで追ってください。
ミカ
デザインシステムって、きれいな UI の裏方だと思っていましたけど、実際は『迷いを減らして、速く安全に作る仕組み』なんですね。皆さんの SaaS でも、部品の数より判断の揃い方をぜひ見直してみてください。
タカシ
SaaS は画面数が増えるほど、設計のズレがそのままコストになります。だからデザインシステムはデザイン部門だけの道具ではなく、事業をスケールさせる共通基盤です。まずは『正本は一つか』から確認してみてください。