こんにちは！ICTチームのデザイナー、moco（@moco_megane）です。
前回の記事「プロダクト横断デザインシステム導入のあゆみ／（１）輪読会で共通認識を作る篇 - SEN PRODUCT BLOG」では、関係者でデザインシステムというものの共通認識を作る部分をクローズアップしました。 productblog.sencorp.co.jp
が、実はそれ以前から共通スタイルガイドの策定・特定プロダクトでのデザインシステム構築は始まっていたのです……！
今回は、それらをリードしたプロダクトデザイナーKさんと・フロントエンドエンジニアdaitasuさんへのインタビューをもとにした記事です。
一筋縄ではいかないデザインシステムの導入の、正直なところを聞いてみました！
- 🎯プロダクトのリプレイス・リニューアルを機にデザインシステムを導入
- 🎨共通スタイルガイドを策定、実際に使ってみる
- 🛠️コンポーネント設計をしながらの画面デザイン
- ✅やったこと、やらなかったこと
- 💬デザイナー目線での感想
- これからデザインシステム導入に挑戦するに人へ向けてメッセージを！
- インタビューを終えて&次回予告
🎯プロダクトのリプレイス・リニューアルを機にデザインシステムを導入
はいチーズ！の複数あるプロダクトのうち、「撮影事業者向けプロダクト」の開発を担当するKさんとdaitasuさん。
デザインシステム構築経験のあるdaitasuさんがEMとして入社したのは2024年4月。当時の目下の課題は「レガシープロダクトのUI・データ構成含めた全面システムリプレイス」でした。
どうしてデザインシステムを導入しようと思ったのですか？
daitasu：
入社した当初から、デザイナーの数もフロントエンドに知見があるエンジニアの数も不足していました。各プロダクトそれぞれで事業部が別れていて、それぞれに施策を回してきたという過去があります。
そのため、UIを含めたユーザー体験が統一されておらずユーザーに混乱を生みやすい状態でした。
また、社内の特定の人だけが知っているオペレーションなども各プロダクトに多く、ハックなユーザーフローなども多数あったため、全体的な一貫性、ルール統一の必要性を感じていました。
最初から大きな共通のデザインシステムを作るのは現実的ではありませんが、まずはこのプロダクトから土台となるものを作ることで、ユーザー体験の統合、開発・デザイン生産性の向上を目指したいと考えました。
Kさんは初めてのデザインシステム構築経験でしたが、最初どう思いましたか？
K：
正直すごくドキドキしました。自分にできるだろうかという不安はありましたが、daitasuさんに「仕上がりは4割でいい。作って壊す前提で作ってほしい」と言われて安心したのを覚えています。私としてもいきなり横断のデザインシステムを作る自信はなかったので、まずは自分の担当するプロダクトで使えるものを小さく作ろうと思いました。daitasuさんについていきます！の気持ちでした（笑）
🎨共通スタイルガイドを策定、実際に使ってみる
スタイルガイドはすでにあったのですか？
daitasu：
当時のデザイナーリーダーの方から、いま作成を進めているところだがどのように作ったらよいかという相談を受けていました。まずはエンジニアとデザイナーの共通言語を作りたかったので、自身がイメージしやすい TailwindCSS を採用したいという思いがありました。
そのため、Tailwind config に転用できるスタイルガイドの土台を作るところからやりましょうとと伝えましたね。コンポーネント単位で揃えるのは難しいので、カラー、マージン、フォントサイズなどを揃えるところからでした。リーダーにたたきを作ってもらい、僕がそれに対して「この項目も作ってください！」とリクエストするようなやりとりがありました。
そのスタイルガイドを使ったのもKさんが初めてだと思いますが、使う中で困ったことはありますか？
K：
たとえばカラーについては、はいチーズ！のブランドカラーであるオレンジの使い方で悩みました。ブランドカラーをボタンなどにそのまま使おうとすると、WCAG2.0のAAの基準を満たさないコントラスト比になってしまうからです。撮影事業者向けプロダクトのユーザーには年配の方も多く、私としてはAAの基準は満たしたものを提供したいとかねてから思っていました。
mocoさんや他のプロダクトデザイナーのみんなとも相談しましたが、結果的にdark寄りのオレンジを使うことで基準を満たすとして進めました。しかし、今後共通のセマンティックカラーを決める際はさらに検討するべきだと思っています。
🛠️コンポーネント設計をしながらの画面デザイン
具体的にどう進めましたか？
K：
情報設計をしワイヤーフレームを作った上で、画面に必要なコンポーネントを洗い出していきました。最初はボタン、ラジオ、チェックボックスなどフォームで必要な部品から作りましたね。画面を作るためにコンポーネントを作り、それを画面に当てこんで違和感がないかを確認し、ブラッシュアップを繰り返していきました。
daitasuさんからは「コンポーネントはなるべく少ない方がいい」とアドバイスをもらい、ついパターンが増えがちなコンポーネントも相談の上で削っていきましたね。ひたすら「これとこれの違いは？」と問われ続けるので（笑）、自分としてもデザインの意図を強く意識するようになっていきました。
daitasu：
その点ではKさんはとても大変だったと思います…。なぜ減らすべきかというと、コンポーネントの数が多ければ多いほど、「認識を揃えて使う」ことが難しくなるからです。たとえばボタンが10個あれば、いつどんな時にこれらを使い分けるのかが複雑でわかりにくくなります。極端に言ってしまうと、1つしかなければ誰でも迷わずに使うことができますよね。デザインシステムはデザイナー間、デザイナー・エンジニア間でのコミュニケーションをスムーズにするためのものでもあるので、「これってどう使うの？」と毎回疑問が発生する状態は避けなければいけません。Kさんには「役割的には一緒に見えるけど、なぜわけたんですか？」を何度も問い、確認しました。デザインの意図を確認した上で、コンポーネントの統廃合を進めましたね。
密なコミュニケーションが発生したんですね。やりとりはどこで行いましたか？
daitasu：
毎朝、チームの朝会で行いました。今回は1チームで完結するスコープだったためそれでよかったのですが、今後横断で動く際は定例ミーティングを設計していきたいと考えています。関係者やプロダクトが多くなるほど、議論のポイントも多くなっていきますね。
✅やったこと、やらなかったこと
デザインシステムを構成するものはいくつかあると思います。何をどこまで作りましたか？
ここまで話してきた部分でいうと、「デザインコンセプト」「スタイルガイド」「コンポーネントライブラリ」「ワークフロー」「アセット」は必要なものを用意しました。
しかし、個別のプロダクトのさらに上位概念である「“はいチーズ！”全体でのデザイン原理・原則」のようなものは今回作りませんでした。これは当時、しっかりとしたプロダクトビジョンやデザインのビジョンを決められる人がいなかったためです。輪読会で読んだ「つくって、みなおす、デザインシステム」にも記載がありましたが、まずは目の前の業務を効率化するという目的でボトムアップで作り、後から原理・原則の部分を取り込むフローとしました。
daitasu：
ワークフローについてエンジニア目線でいうと、「デザインデータのどこにいつ変更が入ったかわからない」という問題が発生しがちで、「実装とデザインがあっていない」「差異が気づかぬうちに拡がっていた」という事態が起きたりします。
そのため、KさんにはFigma のバージョン管理と、Github Issue への変更メモの記載をお願いしました。これらをSlack 通知と連携することで、エンジニアのメンバーたちが変更差分に気づけたり、よりシームレスなやり取りをできるようにしました。
K：
デザインデータはFigmaのバージョン履歴機能で管理しています。私の感覚だとデザインの完了を決めるのになかなか時間がかかり、どこでバージョンを刻むかの見極めが難しいです。正直、今までは自分のデザインデータを細かく全部見ている人なんていない…と思っていましたが（笑）、チームのエンジニアさんがちゃんと見てくれていることがわかり「これはきちんと管理しなければ！」と思いました。
💬デザイナー目線での感想
どんなところが難しかったですか？
K：
プロダクト内で最適化したUIを作らなければいけないと考えた時に、さまざまなユースケースを抽象化してデザインを作っていくということが難しかったです。今まで、UIの状態や種類について深く考えてこなかったなと気づきました。
また、エンジニアと密にコミュニケーションをとりながらデザインを進めるのが初めてだったので、最初は自分がどこまで何をしたらいいかわからず戸惑いました。実装のこともデザインのこともわかるdaitasuさんに相談が集中してしまいがちでしたが、やりとりを重ねるごとに、軽い相談もチーム内でできるようになっていきました。時間はかかりましたが、デザインの意図を言語化し自分から相談できるようになったのは手応えを感じました。
もっとこうしたかった！と悔しい部分ありますか？
K：
全くないです！というのも、自分だけではこれだけのものを作ることはできなかったと思うからです。daitasuさんはもちろん、チームのみんなの意見が詰まっているものなので、私としては自分の力以上のものができたと感じています。みんなで「それいいね！」と言いながら進めていけたことで、独りよがりなデザインにならなかったのがよかったです。
やってみて面白かったことは？
K：
UIって道具なんだ！と思えたことです。素直に面白いと感じ、道具としてのUIに関心が高まりました。もちろん悩むことも多かったですが、自分の悩みを解消するという目的でプロダクトデザイナーでの「UI勉強会」も主宰しました。デザイナーのみんなの意見や見解を知ることで、今回はどの選択肢を選ぶべきかという自分の意思決定に生かすことができました。今まではそれぞれ担当のプロダクトで頑張ってきましたが、一緒に同じUIを見ながら学ぶことで「こんな考え方があるのか」と勉強になりました。
UIをもっと知りたいと思うようになり、ウェブ上に限らず、日常生活でふと出会った「インジケーター」のスタイルや仕様について改めて調べたこともありましたね。
これからデザインシステム導入に挑戦するに人へ向けてメッセージを！
K：
デザイナーだけでデザインシステムを作ることはできません。今回だと、フロントエンドエンジニアであるdaitasuさんの計画・実行力があったからこそできました。まずはそうやって協力できる人を見つけてきましょう！
daitasu：
デザインシステムは完成を求めない方がいいです！取り扱うプロダクトが増えるなど、ビジネス要件が変わったら必要なデザインシステムも変わってしまうからです。まずはやれるところからやる、でやっていきましょう。エンジニアもそうですが、特にデザイナーさんはクリエイターとして妥協を許さず、質の高いアウトプットを求めるところがあると思っています。ただ、デザインシステムは「作って壊す」を繰り返すものです。その前提を持っておくことをおすすめします！
インタビューを終えて&次回予告
私は巷で公開されている完成度の高いデザインシステムを見ると、つい「すごい！こんなもの作ってみたい！」という憧れの気持ちが湧きます。しかし同時に「こんなに緻密に設計されたシステム、一体どれだけの人がどれだけの工数をかけて作っているんだろう…」と愕然ともします。
輪読会でも学びましたが、組織の体制やプロダクトのフェーズによっては、必ずしもデザインシステムを導入することが最適解ではない場合もあります。Kさんとdaitasuさんが実際に社内で取り組んだお話を聞いて、よりいっそう「めちゃめちゃ大変じゃん！！」の思いが増したものの、とはいえ一度作って導入した後はやはり便利ですし、何より実際にプロダクトの画面を操作した時のインターフェース・インタラクションの一貫性は気持ちが良いと感じました。
次回は、個別のプロダクトから複数プロダクトへの共通ルールを策定していく、七転八倒プロセスをご紹介します🧙
この記事を読んで、千のプロダクトデザインやデザインシステムに興味を持っていただけた方はぜひお気軽にカジュアル面談いたしましょう！
お待ちしてます👋
