組織の文脈を置き去りにしたデザインシステムの罠
デザインシステムの成功は手段の選択に大きく左右されるわけではなく、実際には計画の不備が失敗の原因となることが多いです。
書籍「デザインシステムの育て方 継続的な進化と改善のためのアプローチ」の監修機会をいただいたことから、相談を受けたり、イベントに登壇する機会が増えました。最近は下記の２つのイベントに参加しました。
Wantedly主催のイベントは少人数だったこともあり、参加者全員で悩みを共有するという緩やかな形式でした。一方、SmartHR主催のイベントは、会社の活動内容をしっかり深掘りしながら議論を進める内容でした。どちらも異なる視点からデザインシステムの育て方について話し合いましたが、共通するテーマがありました。それを一言で表すなら、「デザインシステムという言葉自体に潜む解釈の罠」です。
言葉がもたらす思考の制約
「デザインシステム」という言葉自体が、私たちの考え方を特定の枠組みに縛りつけていると感じることがあります。「デザイン」という言葉は自然とデザイナー視点に偏る傾向を生み、「システム」という言葉は機械的なアプローチへの依存を助長します。その結果、より自由であるべき発想が特定の方向性に限定させ、本来デザインシステムという手段で成し遂げるべき課題解決から遠ざかることがあります。たとえば、UIライブラリを作ったものの前進できない、連携の仕組みを整えたものの浸透しないといった課題は、「デザインシステム」という言葉が引き起こす、ボトムアップ的活動の限界として捉えています。
見た目の統一性や実装の一貫性といった表層的な目標に囚われるあまり、プロダクトが本当に解決すべき課題への注目が薄れていきます。さらに、システム化への過度な期待は、柔軟性を失わせ、イノベーションの機会を逃す原因にもなっています。
デザインシステムの構築には、表向きの理由と隠れた動機が入り混じっています。一貫性や効率化という建前の背後には、デザイナーが自身の専門性を発揮したいという欲求や、技術的な理想を追求したいという感情的な動機が潜んでいることが多いです。また、業界の成功事例に対する憧れが、自社のデザインシステムに関する意思決定に影響を与えている場合もあります。こうした隠れた動機が、小さく始めるという行動の妨げになり、結果として組織的な反発や実装の複雑化を引き起こしやすい状況を生み出しています。
デザインシステムへの潜在的な憧れや理想は、しばしば私たちを「完璧な解決策」の追求へと導きます。この無意識の志向性は、段階的なアプローチや実験的な試みを「不十分」なものと感じさせ、より包括的で大規模なソリューションを目指させてしまい、結果として負のスパイラルに繋がります。
潜在的な憧れや理想を否定すべきではありませんし、大きな目標を掲げるのも良いことです。しかし、デザインシステムが事業課題の何を解決し、どのような効果をもたすのかといった認識が共有されずに進むと、ステークホルダーとの間に深刻な溝を生じる可能性があります。理想しているデザインシステムを目指すあまり、プロダクトの本質的な価値や、事業の成長に応じた柔軟な対応といった重要な要素が抜け落ちてしまうことも少なくありません。
組織の成長に伴う課題の変質
小規模な組織では、デザインシステムの構築者とプロダクト設計者が同一人物であることも多く、ガバナンスの課題は比較的軽微です。しかし、組織が成長し、複数のプロダクトや開発チームを抱えるようになると、状況は一変します。
統一された基準の必要性が高まる一方で、その実現と維持は著しく困難になっていきます。チーム間の優先順位の違いが顕在化し、個々のプロダクトの特性が失われるリスクも増大します。こうした状況下で、デザインシステムという言葉が持つ「完全な統一」という含意は、かえって現実的な解決を遠ざけてしまいます。
デザインシステムという名の『成果物』を作ることをせず、本当に重要な何かという厳しい問いをしながら少しずつ整備していく姿勢こそが、デザインシステムが育つ環境には欠かせません。この愚直な視点で取り組む際には、他社事例や「デザインシステム」という言葉が生み出す先入観が妨げになることもあるため、それを意識的に排除する姿勢が求められることもあります。また、自社のデザインシステムが、どのような事業効果や品質を保証するのかを明確にすることは重要です。「一貫性」や「効率化」といった表現だけでは解釈が広がりすぎるため、具体的にどの部分で一貫性を保つことが事業やお客様にとってメリットとなるのかを示す必要があります。また、何を保証することで効率化が実現するのかについても、合意を得ることが欠かせません。
強制力の行使においても、全体的な統一を目指すのではなく、より選択的なアプローチが求められます。セキュリティやパフォーマンスといった重要な基盤部分では厳格な統一を図りつつ、個々のプロダクトの特性に応じた柔軟な適用を認めていくといったプローチが必要になりますし、それを行使したりサポートする体制も欠かせません。
手段より計画
デザイナーが主導で進めると、多くの場合、UIコンポーネントを集めたFigmaライブラリが作成されます。しかし、この取り組みがデザイナーの一部の業務の生産性を向上させているだけのように見えることから、周囲の反発を招いたり、目に見える効果が感じられないことがあります。ただし、Figmaで UI ライブラリの作成から始めること自体が悪いわけではありません。一見すると、UI ライブラリを作るという手段が失敗を招いたように見えますが、実際の原因は、目標設定やその後の計画の欠如であることが多いのです。
例えば、デザインシステムに過度な期待を寄せたり、解釈が曖昧なまま作り始めると、一見完成度の高いUIライブラリができたとしても、誰にも使われない結果になりかねません。また、ライブラリ作成後の計画が「フィードバックを受けながら少しずつ成長させる」といった漠然とした状態だと、その場しのぎの対応に終始し、デザインシステムの成長が停滞してしまう恐れがあります。
私がデザインシステムについて相談を受ける際には、プロダクトがリリースされるまでのプロセスや意思決定のメカニズムについて質問します。UIライブラリや開発連携の仕組みを作りたいと考える方には、一見突拍子もない質問に思えるかもしれません。しかし、組織のシステムが理解できていないと、どの程度の粒度で手段を試すべきか判断することができませんし、デザインシステムをどのように育てていくかといった計画を立てるのも難しくなります。
ツールやフレームワークといった手段は何を選んでも構いません。デザインシステムの成功は手段の選択に大きく左右されるわけではなく、実際には計画の不備が失敗の原因となることが多いです。特に、初期段階で達成すべきスコープの設定と、その後の明確なアクションプランの欠如が失敗につながる主な要因です。デザインシステムを作ってみたいと考えている方は、「こういうものを作りたい」という完成図を思い描く前に、「自分が属する事業のボトルネックは何だろう？」という視点で調査を始めてください。
さいごに
元 Material Designのリーダーをしていた Itai Vonshak さんの「The Broken Promises of Design Systems」という記事も、デザインシステムへの過度な期待への警告と読み取ることもできます。以前、ポッドキャストにも出演していただいた佐藤伸哉さんが翻訳記事を公開しています。否定的な意見と読み取ってしまうかもしれませんが、改めて「自社に本当に必要なものは何だろう？」と問いかけるキッカケになるはずです。
Nobuya Sato
Yasuhisa Hasegawa
Web やアプリのデザインを専門しているデザイナー。現在は組織でより良いデザインができるようプロセスや仕組の改善に力を入れています。ブログやポッドキャストなどのコンテンツ配信や講師業もしています。