こんにちは、リクルートで『SUUMO』をはじめとした住まい領域のプロダクト開発を担当している清水です。

リクルートの住まい領域では、不動産会社様向けプロダクトのフロントエンドアプリケーションにデザインシステムを導入しています。デザインシステムを現場のエンジニア・デザイナー主導でボトムアップに構築する中で、様々な学びがありました。本記事では、デザインシステムの構築に取り組んだ背景とプロセス、それを通して得られた学びとプラクティスを紹介します。

想定読者

本記事は、以下のような方々にぜひ読んでいただきたいと考えています。

• デザインシステムをまだ持っていないが、構築することでプロダクト開発を効率化させたい。
• デザインシステムの効果を説明し、立ち上げを推進したい。

本記事におけるデザインシステムの定義

本記事では、「デザインシステム」と「UIライブラリ」というワードを以下のような意味で使用します。

• デザインシステム: 各プロダクトで利用できるデザイントークンやコンポーネント定義、それらを実装したUIライブラリの総称。
• UIライブラリ: デザインシステムで定義されたコンポーネントの実装。

なぜデザインシステムの構築に取り組んだか

リクルートの住まい領域では、『SUUMO』をはじめとした様々なプロダクトを提供しています。『SUUMO』はすでに多くのユーザーにご利用いただいていますが、ユーザーが住みたい家をより効率的に見つけられるように、私たちは日々新規機能の開発に励んでいます。

新規機能の開発にあたり、いくつかの不動産会社様向けプロダクトの立ち上げを企画していました。私たちは、不動産会社様が日々の業務で頻繁にこれらのプロダクトを使用することを想定していたため、視覚的な華やかさよりも直感的で使いやすいUIを目指していました。

では、「使いやすい」UIはどのようにつくっていくとよいのでしょうか？

デザインシステム導入以前は、使いやすいUIとはなにかをプロダクトごとに議論し、定義し、実装していました。使いやすいUIは、様々な要素が組み合わさってできる複雑なものであるため、そのようにゼロから実装するのは非常に骨の折れる作業です。その一方で、プロダクトごとに似たようなものを実装する、いわば車輪の再発明が行われていた状況でした。また、プロダクトごとに実装が異なり、品質にばらつきが生じる課題もありました。

このような課題を踏まえ、デザインシステムを構築することで、それを導入したプロダクトが高速に高品質な使いやすいUIを開発できることを目指しました。その結果として、削減されたコストをプロダクトごとの価値の追求に活用でき、イノベーションが起こりやすくなる効果を期待できると考えました。

デザインシステムとして確立されるまで

私たちは、導入したプロダクトが自ずと使いやすくなるようなデザインシステムの構築を目指しました。

では、デザインシステムチームがゼロから「使いやすさを徹底的に追求したデザインシステム」を構築し、各プロダクトに導入すれば、この要件は満たせるのでしょうか？

私たちは、この方法で要件を満たすのは非常に困難だと考えています。なぜなら、プロダクトが使いやすいかどうかは、私たち開発者が判断するものではなく、実際にプロダクトを利用するユーザーが判断するものであるためです。この前提に立つと、デザインシステムが使いやすいかどうかは、それをプロダクトに導入しユーザーに実際に使ってもらうまでわからないということになります。使ってもらった結果、もしデザインシステムが使いやすいものではなかった場合、開発者がそれを補うことに時間を取られてしまい、かえってプロダクトの成長を阻害してしまいます。

使いやすさが実装されたデザインシステムを確実に作り上げるため、私たちは以下のプロセスでデザインシステムの構築を進めました。

1. パイロットプロダクトの開発
2. デザインシステムチームの立ち上げ
3. 他プロダクトへの導入

1. パイロットプロダクトの開発

まずはひとつのプロダクト（以下、パイロットプロダクト）の立ち上げを通して、使いやすさを追求し、実績を積みました。プロダクトを実際にユーザーに使ってもらい、フィードバックを集めてプロダクトに反映することを繰り返すことで、ユーザー目線で使いやすいUIであることが担保できました。

このように、いきなりデザインシステムを構築するのではなく、パイロットプロダクトの立ち上げから始めることで、

• デザインシステムを導入したプロダクトの使いやすさを担保できる。
• 利用シーンが明確なコンポーネントを必要十分に開発でき、過剰な作り込みを防止できる。

といったメリットがありました。

2. デザインシステムチームの立ち上げ

パイロットプロダクトをリリースしてしばらくすると、別プロダクト（以下、プロダクトA）の立ち上げの話がありました。パイロットプロダクトを開発していた時点で、将来的にデザインシステムを切り出して他プロダクトに導入することを見据えた議論ができていました。そのため、このタイミングでデザインシステムを構築し、プロダクトAに導入できると判断しました。

デザインシステムの構築にあたり、デザインシステムチームを立ち上げました。メンバーとしては、パイロットプロダクトの開発に携わっていたエンジニア・デザイナー中心に構成し、デザインシステムの立ち位置や設計について議論しました。パイロットプロダクト開発時に、エンジニアとデザイナーの間でデザインシステム構築のイメージを共有できていたため、この立ち上げはスムーズに進みました。

また、デザインシステムを導入するプロダクトAのエンジニア・デザイナーにもチームに加わってもらうことで、デザインシステムを利用する側の観点も取り入れた設計を意識しました。振り返ると、複数プロダクトで効果を発揮するデザインシステムをつくっていくという点において、パイロットプロダクトの開発で得た知見だけではなく、プロダクトAを開発していく中で得た知見もデザインシステムに取り入れられたことが重要だったと考えています。

3. 他プロダクトへの導入

このようにして実装されたデザインシステムを導入して、プロダクトAの開発に取り組みました。住まい領域では、このようにUIライブラリを切り出して提供した実績はなかったため、非常にチャレンジングでした。しかし、開発内部のチャレンジによってプロダクトAの価値提供を阻害するわけにはいかなかったため、

• プロダクト開発チームが問題が発生したときに気軽に報告できる関係性をつくり、デザインシステムチームはそれを迅速に解消すること。
• プロダクト開発を行う上で致命的な問題が発生した場合、UIライブラリを利用することをやめコピペベースで対応すること。

を前提としてプロダクトAの開発に取り組みました。

結果として、プロダクトAではUI実装を高速かつ高品質に行うことができ、UIの障害なくスケジュールどおりにリリースすることができました。また、パイロットプロダクトのエンハンスにおいても、それぞれのコンポーネントのふるまいを議論する必要がなくなったことで、どのような価値を提供するべきかの議論にフォーカスすることができています。

プロダクト開発を加速させるデザインシステムの設計

デザインシステムを導入するプロダクトが高速に使いやすいUIを開発できるようにするためには、デザインシステムがプロダクトの開発者にどれだけの自由度を与えるかが非常に重要であると考えています。具体的には、自由度に過不足があると以下のような課題が発生すると考えています。

私たちのケースでは、コンポーネントの粒度ごとにアジリティを得たいか最適化したいかの適切なバランスが異なると考えました。具体的には、以下のように様々なレイヤーで自由度を設定することで、プロダクト共通の「使いやすさ」を提供しつつ、プロダクト固有の価値の実現を阻害しないように工夫しています。

• UIライブラリ
• プロダクト個別コンポーネント
• UIデザインツール上のポリシー

UIライブラリ

私たちのデザインシステムにおいて、ボタンやリンクなどの小さなコンポーネントはUI実装にあたって頻繁に使用することと、いくつかのスタイルパターンが提供されていればそれ以上最適化したい場面は多くないと考えたことから、自由度を落としてアジリティを得る方がよいと判断しました。UIライブラリは、このねらいを踏まえてデザインシステムが提供するコンポーネントの実装です。プロダクト開発者は、UIライブラリのインターフェースから外れた使い方はできないため、こちらが最も強い制約となります。

実装の工夫として、一般的なUIライブラリ（Chakra UI、Material UIなど）より少しインターフェースの自由度を落とすことで、想定しない用法でコンポーネントを利用できないようにしています。例えば、私たちのボタンコンポーネントは子要素として「左右アイコンと中央のテキストのみ入れられる」というルールとしているため、実装は以下のようになります。（子要素以外の部分は省略しています）

// 私たちのボタンコンポーネントの利用方法
<Button leftIcon={<Icon />} rightIcon={<Icon />} text="ボタン" />

// 一般的なボタンコンポーネントの利用方法
<Button>ボタン</Button>

これにより、各プロダクトはボタンコンポーネントの子要素に何を入れるべきかという検討から解放され、より重要な機能の追求に時間を使えるようになります。

プロダクト個別コンポーネント

UIライブラリの範囲を超えて最適化したいケースは多くないものの、各プロダクトは異なる価値を提供するため、UIライブラリで提供するコンポーネント以外のものを使用したい場面は少なからず出てきます。その場合は、デザインシステムでコンポーネントを実装するのではなく、各プロダクトで実装するようにしています。

このレイヤーは一見するとデザインシステムの設計とは無関係に思えますが、以下の点でデザインシステムとしてこの選択肢を提示することは重要だと考えています。

• 各プロダクトの開発者は、デザインシステムを導入しても自身のプロダクトをコンポーネントレベルで最適化する余地があることを理解できる。
• 各プロダクトの開発者は、プロダクト個別コンポーネントを実装したい場合に、デザイントークンを利用できるなどデザインシステムの恩恵を受けられることを理解できる。
• デザインシステムチームは、各プロダクトがどのような個別コンポーネントを実装しているのか把握することで、共通部分を見出しUIライブラリとしてデザインシステムに取り込む議論ができる。

UIデザインツール上のポリシー

小さなコンポーネントと比較して、複数のコンポーネントを組み合わせた画面レベルの設計ではプロダクトごとに最適化したい場面が多くなると考察し、ある程度自由度を高くして最適化しやすい方がよいという結論に至りました。その結果として、このレイヤーではデザイナーがUIデザインツール（Figmaなど）で画面デザインを作成する際、画面上の操作や配置によってどのようにコンポーネントを利用するかのポリシーを策定しています。各プロダクトは基本的にこのポリシーに準拠して画面をつくることで画面間で統一されたUIが実現できると同時に、最適化したい箇所ではUIデザインツール上で調整するだけで済むため、最適化しやすい状況がつくれています。

例として、一度行うと元に戻せない操作を実行するダイアログでは、破壊的な操作のボタンは赤背景で表示し、安全な操作のボタンは白背景で表示します。また、破壊的な操作のボタンを左に、安全な操作のボタンを右に配置します。このポリシーをプロダクト全体に適用することによって、ユーザーはどの操作も直感的かつ安全に行うことができます。

このように、プロダクトにおけるデザインシステムの使われ方を理解し、UIライブラリだけでなくデザインシステム全体を俯瞰した自由度設計を行うことが重要です。
それを実現するためには、エンジニアとデザイナーが協力して、デザインシステムを利用したプロダクト開発についてフラットに議論できる関係性が重要になってくると考えています。

デザインシステムが効果を発揮し続けるための取り組み

ここまでで紹介したプラクティスにより、デザインシステムを導入したプロダクトが高速に使いやすいUIを開発することが可能になりました。デザインシステムチームとしては、導入するプロダクトが増えたり、各プロダクトがエンハンスを重ねてもこの状態を維持することが重要になります。そのためには、各プロダクトの開発者がデザインシステムに対してフラストレーションを持っていないかに継続的に注意を払わなければいけません。

私たちは、各プロダクトがデザインシステムに対して抱いている課題や改善点を吸い上げ、それを迅速に解消するため、オープンなコミュニケーションを心がけています。主にSlackのパブリックチャンネルを利用して、各プロダクトの開発チームには大小に依らず課題や改善点をポストしてもらいます。デザインシステムチームはそれを常にウォッチし、障害などの緊急度が高い課題の場合はその日のうちに修正してリリースします。各プロダクトの開発チームが「課題をあげればすぐ解決してもらえる」と感じることで、安心してデザインシステムを利用できる状態を保てるのではないかと考えています。

デザインシステムを運用する上で、「デザインシステムをどうつくるか」を議論することももちろん重要ですが、「デザインシステムを用いて各プロダクトの成功にどう貢献するか」を常に念頭に置いておくことはさらに重要なのです。

まとめ

• リクルートの住まい領域では、新規プロダクト立ち上げのために「使いやすさ」を再定義・再実装し、車輪の再発明が行われている状況でした。
• その課題に対するアプローチとして、デザインシステムの構築を推進しました。
• はじめはパイロットプロダクトの使いやすさを突き詰め、その後プロダクトごとに共通の部分を抽出してデザインシステムとして確立することで、確実に使いやすさを提供するものを開発しました。
• デザインシステムを導入したプロダクトでは、高品質なUIを高速に開発することでスケジュールどおりにリリースしたり、どういう価値を提供するべきかの議論にフォーカスしたりできています。
• 様々なレイヤーによる自由度の設計によって、共通的な使いやすさを提供しつつも、各プロダクト固有の価値の追求を阻害しないことを実現しています。
• デザインシステムがそのような価値を発揮し続けるために、各プロダクトの開発チームとのオープンなコミュニケーションを心がけています。