この記事はDeveloper＆Designer Advent Calendar 2024の13日目の記事です🎄
# はじめに
この記事では『デザインシステムの育て方』の紹介と読んでみての感想や考察などを述べていきたいと思います。
※ この本です
小さなデザインシステム設計のナレッジシェア
以下から試し読みも可能だったりします。
試し読み：『デザインシステムの育て方』 監訳者まえがき｜BNN
あと、本の内容は割と人を選ぶ内容かと思います。
デザインシステムを作ったことがある人や、現在運用している人むけの本になります。 デザインシステム興味ない方は、終わりの方の「Chapter10 伝道に終わりはない」まで読み飛ばしてもらっても大丈夫です。
こちらの章は割と多くの人向けの内容になるかと思います。
## 自己紹介と挨拶
挨拶が遅れました。
PERSOL_MIRAIZ部 MIRAIZエンジニアリンググループでエンジニアをしている kanekoです。
役割：アプリ系 iOS Swift Android Kotlin Flutter dart Vue React
現在、GCP やら React やらに挑戦中
UX DIGチームとしても活動中
# ことの発端
以前の記事でも触れておりますが、担当しているmiraiz pjでもある程度のデザインシステムを構築しながら進めていました。
ただ、プロジェクトが大きくなるにつれて以下のような課題が発生してきました。
- 開発に貢献しているとは思うのだけど具体的な数字やKPIに落とし込めていない
- これにより、PJからの【お墨付き】をもらえない状況が発生
- そうなるとデザインシステムに工数が払えず、野晒しみたいな状況になってしまう
最初は「エンジニア側でよしなにやってOK」くらいの話だったのですが、それなりの工数をかけていくとなるとプロジェクトやサービスオーナーからの【お墨付き】が必要になってきます。
そこで、上記の課題を解決するために参考にしたのが『デザインシステムの育て方』です。
# 本の概略
この本では、デザインシステムの必要性やメリットをどうやって他の人に説明するかなどが記されています。
実例に即したアドバイスや想定される課題（コンプラとの調整とかそうゆう文脈での課題）などがメインで記載されており、私にとっては非常に参考になりました。
デザインシステムの技術的な仕組みを解説する内容はメインではなく、それよりも一段階俯瞰した位置でのアドバイスや実戦のガイドになると言えます。
なので、デザインシステムの「何でやるのか」「進めるためにはどうするのか」などが詳細に紹介されており、デザインシステムの「障害」はそういったレイヤーで発生することがほとんどであると書いてあることもとても印象的でした。
本の中にも技術的な部分はWebで調べたほうが良いとまで書いてあり、またデザインシステムがうまく機能しなくなる理由のほとんどが、技術的な部分よりもこういったレイヤーでの「障害」が原因であるとまで書いてありました。
## 余談と所感
自分がよくデザインシステムを他のものに例えるときに「橋」に例えるときがあります。
デザイナーとエンジニアの異なる職能の架け橋になるような、共通の言語や共通のプロトコルをイメージしてます。
橋がなくても川を渡ることができる人はいますが、それはある意味で限られた人間なのかもしれません。
公共事業は往々にして予算の確保が難しいところまでそっくりです（ここは似なくてよかった）。
この本は、橋の作り方というよりインフラとしての橋の建設の進め方（周囲の説得とか役所への手続き方法や予算の取り方のノウハウなど）をメインに伝えていると言い換えることが可能かと思っています。
最近はトンネルや橋の老朽化もニュースになっていますが、予算の確保は非常に難しそうに見えます。
上記も、老朽化して事故などが発生してからの対応となってしまいました。
早急に対応すれば、コスト面でもメリットはあったはずです。
しかし、問題が発生してからじゃないと問題を認識することが出来ないのは人の習性として仕方ない部分なのかもしれません。
# 作り方より大事なこと
先ほども引用した、監訳者まえがきの中にありますが、以下の文章がこの本の特徴を表しているかと思います。
デザインシステムの導入と運用は、技術的な側面だけでなく、組織的、人的な側面にも深く関わる複雑なプロセスです。しかし、現場との密接な協働と、彼らの成功への貢献を常に念頭に置くことで、価値あるデザインシステムを構築し、組織全体の成長と進化を促進することができるはずです。
その実現のための最初のステップは、UIライブラリのような成果物を作ることではないかもしれません。頭の中で描いているデザインシステムの姿をいったん脇に置き、チームが直面している課題は何かという問いと向き合うことで、何をすべきかが少し見えてきます。
「何のためのデザインシステムか」。
この本の最初の1章目でも触れられていますが、それは決して「エンドユーザーのためだけではない」ということです。
開発に取り組む、企画やデザイナーやエンジニアなどの協業体制をより良くしていくことはデザインシステムの価値の一つであり、それは間接的ではありますがエンドユーザーへの価値提供に繋がります。
しかし、それを様々な職能は背景を持っている人に伝わるようにすること、また持続させることには困難が伴います。
間接的であるが故に、数字のインパクトが少なくなってしまうと言えます。
デザインシステムは直接的に売上やROIに貢献するものではありません。
セキュリティなんかもそうですが、ROIに直接貢献しない事柄で予算を取ることは「数字の説得力」を付けることが出来ないケースが多く、非常に難しいと言えます。
この本ではそういった課題に向き合ってきた著者のノウハウや、他にも同じ課題に向き合ってきた人のインタビューなども多く掲載されています。
同じような悩みを持っている方は是非読んでみてください。
# Chapter10 伝道に終わりはない（本題）
いきなり飛ばしてChapter10の話をしますが、この本の最終章ではデザインシステムをいかに魅力的に伝えるについて述べています。
先に述べたように、デザインシステムには継続的な取り組みが必要になってきます。
※ このことはデザインシステムに限った話ではなく、セキュリティなども直接ユーザーへ価値を届けたりしませんが重要な取り組みだと言えます
序盤にも述べていますが、そうなると予算を持っている人の承認や【お墨付き】をもらわないといけません。
そのためには、「数字で説得する」「権限を持っている人と仲良くなる」などの方法や、それら全てのコミュニケーションを諦めて「黙ってやってしまう」など、様々な方法が考えられるかと思います。
筆者としては、どんな方法であれ会社に貢献するのであればそれは正しいことだと思います（決して私利私欲のためにやってはいけません）。
ですが、可能な限りコミュニケーションを諦めたくないのも自分の中の真実です。
周りの理解を得ないと評価もされないですし、そうなるとシステムの持続可能性は下がってしまいそうです。
デザインシステムは言うなれば社内システムの一つではありますが、普通の外向けのプロダクトと同様に「その魅力を伝え」「選んでもらい」「使ってもらう」ことの重要性を説き、その方法がChapter10で紹介されています。
## あなたの組織やプロダクトにとっての「ミレニアムファルコン」は何か
魅力を伝えて選んでもらうためには、第一印象は非常に重要だと言えます。
ここで、ちょっとした問いかけをしたいと思います。
問題は以下のとおりです。
問: あなたはレゴショップの店長です。店頭に置くのにふさわしいのはどっちでしょうか？
直感的に、右のミレニアムファルコンの方が食いつきが良さそうであることがわかるかと思います。
レゴのホームページを見てもわかるかと思いますが、完成品のレゴが多く並んでおりとても魅力的に写っているのがわかるかと思います。
※ お子様がいる家庭では閲覧に注意してください。余計なクリスマスプレゼントを購入することになる恐れがあります
これはレゴに限ったことではなく、デザインシステムやプロダクト、さまざまな活動にも言えることかと思います。
自分のプロダクトややりたいことを伝えるときに、ただ単に機能を伝えるだけではその魅力は伝わりません。
トークンの一覧を出すよりも「これはなんなのか」「このプロダクトを通してあなたにどんなメリットがあるか」を伝えることで大きく見え方は変わると言えます。
言うなれば、商品を見るまではユーザーは期待していないが、実際に提供目の前に出された時に「こんな商品が欲しかった」と思わせるもの"インサイト"を提示することが大事だと言うことができるかと思います。
※ インサイトに関しては以下の動画が参考になりました
- YouTube 「売れる企画には必ずある」博報堂役員が最重要視する「本物のインサイト」とは
デザインシステムに限らず、ROIに間接的に貢献するものは多いはずです（セキュリティもそうですしコミュニケーションコストを減らす施策なども）
この記事を読んでくださった方の、数字に見えないけれども大事なことや一つでも実現に近づくことを祈りつつ、この記事を終了したいと思います。
金子 広大 Kodai Kaneko
はたらく未来図構想統括部 PERSOL_MIRAIZ部 MIRAIZエンジニアリンググループ リードエンジニア
iPhoneとAndroidのネィティブアプリで、 アプリの企画 -> デザイン -> 開発 -> リリース -> グロースまでの経験を生かして、活動中。現在、React Next TypeScriptにも挑戦中。
※2024年12月現在の情報です。
