試し読み：『デザインシステムの育て方』 監訳者まえがき
2024年8月28日刊行の『デザインシステムの育て方：継続的な進化と改善のためのアプローチ』より、本書の監訳者 長谷川恭久氏による「まえがき」を紹介します。スタートアップから大きな組織まで、さまざまな規模でのデザインシステムに携わってきた長谷川さんの視点から、デザインシステムを「作る」のではなく「育てる」ということ、その重要性について示していただきました。ぜひご一読ください。
監訳者まえがき
─長谷川恭久
プロダクトと捉えたときのデザインシステム
デザインシステムを構築するのは容易ではありませんが、それ以上に難しいのは、使い続けてもらうための運用です。そのためデザインシステムは、デジタルプロダクトと同様に扱うべきだという見解があります。デザインシステムを使うデザイナーや開発者にとって、使いやすいデザインシステムになるよう改善を続けていく。このプロセスは、PMF（Product Market Fit）を目指すスタートアップに似ています。
私がかつて携わった組織でも、現場の有志が自発的にデザインシステムを作ったものの、周りに受け入れてもらえず、成果が見えにくいといった理由などから次第に廃れていったことがあります。一部の作り手にとっては納得いくものであっても、プロダクト開発全体の視点から見たときに都合が悪かったり、相反したりする場合があるのです。また、制作効率の向上が必ず事業貢献につながるとは限りません。こういったデザインシステムはある意味、PMFを成し遂げることができなかったプロダクトと捉えることができます。
周りを見渡すと、整備されたUIライブラリや、Reactなどの開発フレームワークと連携された素晴らしいデザインシステムの事例が見つかります。そうしたデザインシステムは憧れの対象になりますが、同じようなものを作ることを目的にすると、使われなくなる可能性が高くなります。私がデザインシステムの支援に関わるときは、まず「憧れ」と「目の前の課題」を分けるところから始めています。
特に中小規模の組織の場合、デザインシステムとは別の手段のほうが効果的なことも少なくありません。たとえデザインシステムを作ることが最適だと判断した場合も、まずCTA（Call to Action）のような小さなコンポーネントから始めるよう勧めることがあります。様々なコンポーネントが揃ったUIライブラリを作ることを目的にしている方には少し驚かれることもありますが、組織という「市場（Market）」に「適応（Fit）」するアプローチを模索しながら進めるためには、まず効果が見える最小単位を選ぶ必要があるのです。
ただデザインシステムを作って運用するのではなく、組織の現状を把握しながら、“自分たちのためのデザインシステム”を少しずつ積み上げていく進め方が必要となるため、デザインシステムはデジタルプロダクトと同じものだと捉える考え方は納得できます。
しかし、デジタルプロダクトのように捉えたからといって成功するとは限りません。およそ90%のスタートアップが事業を閉鎖し、そのうち初年度に閉鎖するのも10%と言われているのと同じように［1］、デザインシステムも長続きせず風化することがあります。成長しているユニコーン企業のなかでも、IPOになるのはおよそ17%と言われています［2］。デザイナーが憧れるデザインシステムも、実はそんなわずかな成功事例に焦点が当たっているだけかもしれません。
ただ、長く険しい道のりとはいえ、短期視点の「プロジェクト」ではなく、中長期を見据えた「プロダクト」として計画、実行、改善を繰り返せば、周りに使ってもらえるだけでなく、事業成長の後押しになるデザインシステムになる可能性はあります。せっかく現場で「作りたい」というモチベーションがあるのですから、その想いを無駄にしないような計画が欠かせません。
脚注：
［1］ Startup Failure Statistics: What Percentage of Startups Fail?
［2］ Traits of Startup Unicorns in 2024
一般論ではない理由を明らかにする
では、どうすればデザインシステムを「プロダクト」として捉え、成功に導くことができるのでしょうか？ そのためには、計画段階で「なぜ（Why）」を深掘りし、チーム全体で共通認識を醸成することが必要です。「なぜデザインシステムが必要か？」という問いに対して、「デザインと実装の連携強化」「リリースサイクルの短縮」といった回答が返ってくることがあります。これらは一般論として正しいですが、組織の具体的な課題に向き合った回答とは言い難いです。
たとえば、デザインシステムで成し遂げようとしている「デザインと実装の連携」がなぜ現在できていないのでしょうか。デザインシステムがないからできていないわけではない可能性があります。デザイナーとエンジニアのコミュニケーション不足という体制の問題や、実装後にデザイン観点の品質チェックが不足している工程の問題が考えられます。デザインシステムは、デザインと実装の乖離をなくす仕組み作りとして有効かもしれませんが、それが最適な手段とは限りません。
リリースサイクルの短縮も同様です。デザインシステムがあれば、A/Bテストや検証がしやすくなり、将来的にはUIの自動生成の可能性もあります。しかし、現在リリースサイクルの高速化ができていない理由は、デザインと開発の作業効率だけではありません。たとえば、PRD（プロダクト要求仕様書）が十分でないために設計が二転三転することや、判断基準が定まっていないために次のステップに進めないことが考えられます。このような状態では、たとえ制作効率を上げてもリリースサイクルは短縮されません。
「デザインと実装の連携強化」「リリースサイクルの短縮」といった一般的な回答が間違っているわけではありませんが、連携ができていない理由やリリースまでの行程が長い理由は組織によって様々です。その理由を追求することが「なぜ（Why）」を深掘りすることです。そして、見つかった問題を解決するために最適な方法が、デザインシステムなのか他の手段の方が適切なのかを見極めることが重要です。また、様々な要素で構成されるデザインシステムの中で、何に優先的に取り組むべきかのヒントも見つかるはずです。
短期視点と長期計画を両立させる
デザインシステムの「Why（なぜ）」を明確に定義することは、単なる形式にとどまりません。これはデザインシステムの存在意義を規定し、チーム全体の共通目標となる重要な要素です。「Why」が明確であれば、デザインシステムは組織内で強固な基盤を築き、困難な局面でも前進する原動力となります。さらに、この明確な目的意識は次のステップの計画立案を容易にし、長期的な戦略の指針となります。
しかし、組織によってはデザインシステムの構築をプロジェクト視点で捉えがちです。UIライブラリの作成やデザイン原則の策定といった具体的な成果物の完成を目指すこのアプローチは、短期的には効果的に見えるかもしれませんが、重大な落とし穴があります。
プロジェクト視点では、成果物の完成自体が目的化しやすく、「なぜ（Why）」の理由が「デザインと実装の連携強化」「リリースサイクルの短縮」といった一般論になりがちです。具体的な課題やその解決による効果を明確にしないまま進めると、作成したUIライブラリやデザイン原則が組織全体に浸透せず、実際には活用されないという事態に陥る可能性があります。これはデザインシステムの形骸化を招き、本来の価値を損なう結果となります。
デザインシステムを使うデザイナーや開発者、そしてそれを取り囲む組織の現状を考慮していない成果物の完成を目指すプロジェクトは、組織のプライオリティとの不一致を招き、デザインシステム活用への抵抗を生む可能性があります。
たとえば、デザインシステムの導入が組織全体の目標達成にどのように貢献するのかが明確でなければ、デザインシステムプロジェクトは組織にとって優先度の低いものと見なされ、十分なリソースが割り当てられないかもしれません。また、デザインシステムの導入が現場のデザイナーや開発者のワークフローにどのような影響を与えるのかを考慮せずにプロジェクトを進めると、彼らがデザインシステムの使用に抵抗を感じ、結果的にデザインシステムの活用が促進されない可能性があります。
人や時間といったリソースの確保が難しい状況下では、デザインシステムの維持・更新が次第に困難になり、徐々に陳腐化していきます。陳腐化したデザインシステムは使い物にならなくなり、数年後には再び新たなデザインシステムプロジェクトが発足するという悪循環に陥る可能性も否定できません。
この問題を解決するためには、冒頭にも述べたようにデザインシステムを「プロダクト」として捉え直す必要があります。プロダクト視点では、デザインシステムを使うデザイナーや開発者、そしてそれを取り囲む組織全体を「ユーザー」として考えます。彼らが抱える課題を広い視点で捉え、最小限の努力で様々な施策を試しながら、ユーザーに最適な課題解決方法を見つけていきます。たとえば、以下のような問いをユーザーにしながら、根本的な課題を明らかにしていきます：
デザイナーや開発者の日々のワークフローはどうなっているか？
組織全体の目標は何か？ プロダクトのロードマップはどうなっているか？
プロダクトの「良さ」をどう判断しているか？ 何か基準はあるか？
これらの問いに答えることで、どのようなデザインシステムを組織で適用すべきかのヒントが見つかるはずです。
成果物の完成自体が目的化しやすいとはいえ、プロジェクト視点を完全に排除する必要はありません。むしろ、プロジェクト視点とプロダクト視点をバランスよく組み合わせることが重要です：
プロジェクト視点：具体的な成果物の完成と短期的な目標達成に有効
プロダクト視点：長期的な価値創出と持続可能性の確保に不可欠
たとえば、新しいコンポーネントの追加はプロジェクトとして計画し、実行します。一方で、その採用率や有用性を継続的に分析・改善する計画も必要です。このように、両視点の両立は重要ですが、長期的な成功のためにはプロダクト視点を常に念頭に置くことが不可欠です。デザインシステム全体として目指すべき長期的な成果について定期的にフィードバックを受けたり議論をしたりしながら、プロダクト視点を常に念頭に置くことが、組織の持続的な成功へとつながります。
現場が求める「成功」とは？
理想的なアプローチを理解することと、それを実践することの間には、しばしば大きな隔たりがあります。現場で実際に起こっている問題を解決できないデザインシステムを作ると、人や時間といったリソースの確保が難しくなり、維持・更新が困難になります。「Why（なぜ）」を明らかにするだけでなく、何から取り組むと効果的か優先順位を考えることや、利用促進のための啓蒙活動など、やるべきことは山積みです。
このような課題に直面したとき、最も効果的なアプローチのひとつはパイロットプロジェクトの立ち上げです。パイロットプロジェクトは、デザインシステムチームが現場の特定のチーム（特に新しいアプローチに前向きな方たち）と密接に協力し、彼らの具体的なニーズや課題を深く理解する機会を提供します。先述した CTA エリアだけ取り組むというアプローチもそのひとつです。パイロットチームにとって即座に必要なコンポーネントのみに焦点を当てます。こうした小さなスコープで始めると、全体との一貫性が不足する場合や、特定のニーズだけに応えてスケールしない懸念も出てきます。そのようなリスクはあるものの、現場のニーズ、つまり現場で働くデザイナーや開発者が活躍できる道具を提供することが何より大切です。
デザインシステムの導入で効率化が見込まれるかもしれませんが、現場にとっては今までの作り方を変えるという苦痛が伴います。それでも試したいという前向きな方たちの期待に応えるためには、少し先の「デザインシステムがある素晴らしい世界」を作るのではなく、彼らが直面している問題を解消することが先決です。そうした活動を通じて、現場の信頼が得られるだけでなく、現場で実際に起こっているプロダクト開発の課題も見つけやすくなります。
他にもワークショップやフィードバックセッションなど、現場と直接コミュニケーションを取る機会を定期的に設けることも、利用されるデザインシステムのための重要な活動です。現場で生まれたカスタムコンポーネントを並べたり、コンポーネントの適応に迷った点を話し合ったりすることで、現場のリアルな課題が見えるだけでなく、プロダクト開発に関わるメンバー同士が共感を持つ良い機会になります。特にリモートワークが増えている現在、つながりを保ち続けないと、すぐに現場との関係性が薄れてしまうことがあります。たとえデザインシステムと直結しないトピックでも、定期的に皆で集まってデザインについて語る場を作ることで、お互いが気軽に声をかけやすくなることもあります。
このようなアプローチを通じて、デザインシステムチームは重要な問いかけを常に念頭に置く必要があります。それは、「デザインシステムをどう作るか」ではなく、「現場の人たちの成功にデザインシステムがどう貢献できるか」という問いです。この視点の転換こそが、デザインシステムの成功への近道となります。
作り方より大事なこと
デザインシステムの導入と運用は、技術的な側面だけでなく、組織的、人的な側面にも深く関わる複雑なプロセスです。しかし、現場との密接な協働と、彼らの成功への貢献を常に念頭に置くことで、価値あるデザインシステムを構築し、組織全体の成長と進化を促進することができるはずです。その実現のための最初のステップは、UIライブラリのような成果物を作ることではないかもしれません。頭の中で描いているデザインシステムの姿をいったん脇に置き、チームが直面している課題は何かという問いと向き合うことで、何をすべきかが少し見えてきます。
デザインシステムはデジタルプロダクトと同様に扱うべきという言葉。それは単にデザインシステムをプロダクトのように作るという意味だけでなく、デザインシステムというプロダクトを使い始めてもらい、使い続けてもらうまでのライフサイクルをどう支援するかというニュアンスも含まれています。長期戦になるからこそ、成果物を作ることを目的としたプロジェクト視点に加え、長期的な価値創出をするための計画と体制が欠かせません。
長く険しい道のりですが、本書『デザインシステムの育て方』には、形骸化しないための様々なアプローチが紹介されています。本書に書かれているアプローチは必ずしも特効薬のような手軽で効果的なものばかりではありません。しかし、著者の経験に基づいた現実的かつ具体的な提案がたくさん盛り込まれています。とりあえずUIライブラリを作ったけれど次に何をしたらよいかわからない、なかなか浸透しなくて困っている、仕切り直しの再スタート時に何に気をつけたらよいか知りたい。本書は、そんなデザインシステム設計・運用の中上級者にとって素晴らしい道標になるはずです。
Amazonページはこちら。Kindle版（リフロー形式）もあります。
原書はこちらです。
https://rosenfeldmedia.com/books/design-that-scales/