デザインシステム運用の裏側：使う側から作る側へ

この記事は、CYBOZU SUMMER BLOG FES '24 (Design Stage) DAY 8の記事です。

こんにちは、kintone Design Systemチームでkintone Design Systemというデザインシステムを開発している中川遼太郎です。
私はこれまでkintone開発チームでアプリケーションエンジニアとして機能開発に携わってきました。その中で、デザインシステムを活用する側として日々開発をしてきました。しかし、今年に入ってからそのデザインシステムを開発・運用する側に立場が変わりました。この変化を通じて、私は多くのことを学び、デザインシステムの重要性を理解しました。

今回は立場の変化を経験したことで見えてきた視点や学び、そしてデザインシステムを活用することによって見えてくる世界についてお伝えしたいと思います。

デザインシステムを使う側だった時の話

デザインシステムとの出会い

当時kintone開発チームでフロントエンド刷新のために既存画面の改修を行っており、その時にkintone Design Systemを活用して新しいデザインを適用してほしいという要望がデザイナーからありました。kintone Design Systemを活用することによってUIの開発コストを削減しつつ、提供しているコンポーネントライブラリ (以下kintone-ui) で管理している共通コンポーネントの拡充ができるとの説明がありました。

当時kintone Design Systemやデザインシステム自体について何も知らなかった私はこの話を聞いて、Material UIとか世の中にはフロントエンド開発をより楽にするためのコンポーネントライブラリとかあるなと思い、kintone Design Systemもそういうコンポーネントライブラリなのかなぐらいの認識でした。

実際にその当時kintone Design Systemを活用した時もkintone-uiをimportして用意されてるコンポーネントを使って、kintone-uiにない画面独自のコンポーネントは自前で開発して画面の構築を行いました。その後、構築した画面を「いつものように」デザイナーに見せて細かな色や余白の調整を行って開発をしました。特にいつもと変わり映えのない一連の流れで開発をしましたが、先に説明を受けた「UIの開発コストを削減」というところがどうしても掴みきれませんでした。

メリットは結局何？

Material UIなどコンポーネントライブラリに関して中途半端な知識があった私は、用意されてるコンポーネントをうまく活用できるのであればコンポーネントを配置するだけで楽に画面構築ができるイメージはありました。
ですが、

• 活用できるコンポーネントがなく独自で用意しないといけない

• 似てるコンポーネントはあるけど少し役割が違う

など結局コンポーネントライブラリがフルで活用できないのであれば考慮するポイントが増えるだけなので結果として開発コストが大きくなるだけなのではと思ってしまいました。

kintone Design Systemをただのコンポーネントライブラリとしか理解していなかった私は、これらの思い込みによってkintone Design Systemもといデザインシステムを活用することによるメリットよりもデメリットしか見えていませんでした。

デザインシステムを作る側になって

kintone Design Systemチームに参加

そんなこんなあってkintone Design Systemチームに参加することになったのですが、まず最初に開発するkintone Design Systemに対する理解を深める必要がありました。

体形的な学習から始め、デザインシステムそのものに対する理解を深めていき、チームが向かっていきたい理想について話しあっているうちに少しずつですがわかってきたところが増えていきました。特に、開発を進めていきながらデザイナーやエンジニアとお話しをしていくうちに、kintone Design Systemチームがデザインシステムを通してコミュニケーションの課題を解決していきたいことがわかりました。

スクラムをやっていないチームでスクラムマスターとして振る舞ってみた - Cybozu Inside Out | サイボウズエンジニアのブログ

デザイナーの思い

kintone Design Systemチームで話をしていく中でデザイナーがクリエイティブなことに時間を割くことができないという話題が多々挙がりました。

なぜそんなことが起きているのか聞いてみると、開発の中でエンジニアとのコミュニケーションに時間がかかりすぎていることがわかりました。
その中でも、

• padding や margin といった余白の確認

• 背景色の確認

• 文字の大きさの確認

のように確認ごとが特に多く、デザイナーとしてこのあたりはエンジニアで判断してよしなにやってほしいという気持ちがありました。思い返してみると私もエンジニアとして同じような確認をしてきました。

デザインシステムの理解

エンジニアとして開発していた頃になぜこのような確認ごとが多かったのか振り返ってみると、自身に十分な判断材料がなかったことが主な理由でした。見た目の話ですしきっとデザイナーがこのあたりを判断してくれるだろうと考えた末の行動でした。このようなデザイナーとエンジニア間で発生するコミュニケーションの課題がお互いに本来やりたかったことを阻害していることがわかった私は、kintone Design Systemチームがこういったところを解決していきたいのだと理解しました。

よくよく考えれば一つのプロダクトを開発しているのに、画面によってデザインが変わりすぎることはなく基本的には一貫性を保っていてほしいです。ですがこれまではこの一貫性が十分に保てていなく、そこがエンジニアとして判断材料が持てなかったところなのかなと私は感じました。デザインシステムを活用することによって一貫性が保てるようになって効率的な開発に繋がり、デザイナーとエンジニア間の必要以上なコミュニケーションが減っていく世界が見えてきました。

現在の思い

ハードルの高さ

デザインシステムに限らず、今まで触れてこなかったものを活用するハードルは高いです。kintone Design Systemで初めてデザインシステムに触れた私としてはものすごく理解できます。ただ長期的な目線で継続的な開発をし続けるためには苦しいなと思っているところを改善する必要があります。今はその中でも特にデザイナーとエンジニア間のコミュニケーションというところがあり、kintone Design Systemはきっとこれを良い方向に導く糸口になると思います。

共通の目標

kintone開発チームは現在フロントエンドの刷新を行っています。その中で少しずつkintone Design Systemを活用していただいているのですが、日に日に「kintone Design Systemを活用すると早く開発できる！」という声が増えてきました。そんな声に対して喜びを噛み締めながらkintone Design Systemチームはより良い方向に導くために日々開発・運用、利用者のサポート、デザインシステムの啓発活動をしていきます！