リクルート サービスデザイン室 住まい領域デザインマネジメントユニットの高橋智江子と申します。

リクルートのサービス領域は多岐にわたり、数多くのプロダクトを展開しています。近年は特に、住まい領域の中でも「賃貸」「売買」「注文」「引越し」など複数の住宅カテゴリにおいて、クライアント業務支援プロダクトの立ち上げの機会が増えています。今後も多くの案件が計画されるなか、私たち住まい領域ではプロダクトのクオリティを担保しながら、少しでも効率よく開発を進めるためのデザインシステム「Terra」の構築に取り組んでいます。

今回は、そのデザインシステムをデザイナーとエンジニアが協働で立ち上げた背景と、システム構築までのプロセス、現時点での成果や活用事例、そして、システムを形骸化させないための運用の工夫などについて紹介したいと思います。

なぜ「デザインシステム」が必要だったのか？

今回お伝えしたいのは、主に以下の3つのポイントです。

（1）「デザインシステムTerraの立ち上げ構築プロセス」
（2）「デザインシステムを形骸化させないための運用の工夫」
（3）「デザインシステムTerra自体の特徴と活用事例（Figma MCPを活用したフロントコーディング）」

特に、「デザインシステムでプロダクト開発を効率化させたい」、「デザインシステムの効果を周囲にしっかり説明して、立ち上げを推進したい」と考えている人にとって、参考になるポイントが多いのではないかと思います。

ちなみに、今回の取り組みは、今回の取り組みは住まい領域のデザインマネジメントユニットグループマネージャー（GM）である私（高橋）と、プロダクトマネージャー・大塚悠貴、エンジニアの清水駿太郎という3名が主導で進めています。
高橋からは（1）「デザインシステムTerraの立ち上げ構築プロセス」について、（2）（3）については、大塚、清水からご紹介します。

前置きが長くなりましたが、まずは背景です。そもそもなぜ、私たちがデザインシステムを構築しようと考えたのか。それはデザインチームにおいて未来の効率化を考えたところから始まりました。

住まい領域におけるクライアント向け業務支援プロダクト開発では、案件の度にゼロからデザインのトンマナを作成し、ボタンやフォームといった汎用的なコンポーネントもその都度、設計、デザイン、実装していました。今後も同様の開発案件が増えていくことが想定されるなかで、現状のやり方は非常にコストが高く、効率も悪い。それに、クライアント業務支援プロダクトはその性質上、情緒的価値よりも機能的価値に重きを置いて、シンプルで分かりやすいものを素早くリリースし、ユーザーフィードバックを得ながら磨き込むことが大事です。そのためには、最短で品質を高められるような仕組みの構築が急務であると考えていました。

そうした悩みをミーティングの場で、プロダクトマネージャーの大塚、エンジニアの清水に相談したところ、2人も同じことを考えていたようで、すぐに新しいデザインシステムを作るプロジェクトがスタート。私たちはこれを「Terra」と名付けました。住まいを支える土台 = 大地、地球 = Terra (ラテン語)。住まい領域のデザインの土台となるという意味を込めました。

当時、私たちが目指していたのは、今後の開発の土台となるデザインシステムを構築し、これまでのようにコンポーネントを再定義、再発明するコストを削減すること。そして、本質的なプロダクト価値の追求や、素早く価値を届けることにリソースを投入できる状態をつくることでした。

開発からプロダクト導入までのステップ

デザインシステム開発から実際のプロダクトへの導入までの流れを、大きく2つのステップに分けて紹介します。

＜ステップ1：パイロットプロダクトの開発＞

はじめに、あるプロダクト開発をパイロットプロダクトと位置付けて、その中で使うコンポーネントから汎用性の高いものを用いてデザインシステムを構築していきました。

世の中にあるデザインシステムを見ていると、どのコンポーネントライブラリーも美しく、数もびっしり揃っていたりして、自分たちもそういうものを作りたいと思ってしまいます。特に初期は情熱とやる気に満ちているため、なおさらそうなりがちですが、初期リリースでいきなり「最強のデザインシステム」を目指す必要はありません。まずはパイロットプロダクトをベースに、実際に利用するコンポーネントから汎用性を踏まえて構築していくことが重要です。実際に利用することでベースの使いやすさを検証・担保することもできますし、過剰な作り込みも防止できます。

最初から「もしかすると、こんな風に使うかもしれない」などと考え始めてもキリがありません。深みにはまって過剰に作り込んでしまうよりは、最低限でもリリースしてからブラッシュアップしていったほうがいい。ここは非常に重要なポイントです。

＜ステップ2＞利用する側の観点を設計に取り入れ、ブラッシュアップする

多くのプロダクトで活用されるデザインシステムを作っていくためには、複数プロダクトの開発者にメンバーとして参画してもらい、視点を出し合うことが重要です。パイロットプロダクトの開発は少数の初期メンバーのみで行い、Terraの立ち位置の議論やコンポーネント設計、運用、実装を行ってパッケージ化し、その上で導入してくれるプロダクトを探しました。

そして、1つ目の導入プロダクトが決まった後、そのプロダクトの開発メンバーにもTerraのチームに参画してもらい、利用する側の観点を設計に取り入れながらどんどんブラッシュアップしていきました。

気になる成果ですが、デザインシステムを導入してくれたプロダクトでは、コンポーネントベースの認識統一によって、デザイン開発のコミュニケーションコストが格段に低くなりました。結果、認識齟齬による手戻りや誤実装がほとんどなくなっています。

チームの意思決定のスピードも向上し、フロントエンドのテスト工数の削減につながっています。振り返り会など、さまざまな場で喜びの声も非常に多くいただき、現時点ではかなりの手応えを感じています。

デザインシステムを形骸化させないための運用

次にTerraの運用について、大塚悠貴から紹介します。
私たちの目的は、デザインシステムを導入してもらうことではなく、その後も使われ続けること。そして、このシステムが育ち続けることが大事だと考えています。そのために、継続的なアップデートや使いやすさの追求、丁寧な導入支援など、「使われ続ける仕組み」を構築しながら運用してきました。

ここでは、せっかく作ったシステムを形骸化させないための運用の工夫を3つ紹介したいと思います。

＜運用の工夫1：継続的なアップデートと共有＞

Terraでは主に3つの場を通じて、デザインシステムを育てています。
Terraの利用者はいつでもSlackの相談チャンネルにおいて、要望や質問を投稿できます。
私たちはここで要望を吸い上げ、週1回の定例会でデザインシステムの課題や要望の議論、優先順位やロードマップの議論を行っています。
ここで決まった内容をFigmaやUIライブラリーに反映し、そのアップデート内容を月一回のアップデート共有会で共有します。ここでは新機能や変更点の説明、プロダクトロードマップの共有を行っています。ちなみに、共有会には必ずプロダクト側から1人、窓口担当者として出席してもらっています。

このようにフィードバックサイクルを回すことでTerraを育て、使ってもらえる環境を作っています。

＜運用の工夫2：使われるための取り組み＞

2つ目は、使われるための取り組みです。まず、ドキュメンテーションはかなり力を入れて取り組んでいます。Figmaではデザインや表示パターンだけではなく、「そのデザインがどういう状況で使われることを想定しているか」なども詳しく記載しています。
一方、実装面では、Storybookを用いて、各コンポーネントが実際にどのような挙動をするのかをデザイナー、エンジニアともに確認できる状態にし、さらに実装の仕方も丁寧に説明しています。

＜運用の工夫3：過度な「独自実装」を防ぐ＞

次に、「独自実装」の扱いです。デザインシステムが形骸化する大きな要因の一つに、独自実装が増えてデザインシステムを徐々に使わなくなっていくことが挙げられます。
Terraの場合、独自実装そのものは禁止していません。各プロダクトにおいてTerra内にある既存のコンポーネントがフィットしない場合は、独自実装を許容しています。しかし、独自実装が「過度に生まれる状況」は防ぐようにしています。

具体的には、デザイナーが既存コンポーネントに対して独自仕様を付けたり、新規コンポーネントを作りたいとなった場合はまず、デザインシステムの定例会議で「既存コンポーネントで同様の意図が表現できないか」について議論したりします。そこで既存コンポーネントで十分に表現できるという結論が出れば既存のものを使ってもらいますし、厳しそうな場合は、「その独自仕様や新たに作るコンポーネントが、他のプロダクトでも利用できそうか」を確認します。汎用性が認められた場合はTerraをエンハンスし、認められない場合は独自実装を許容する。そんなプロセスで、独自実装を取り扱っています。

ただし、独自実装を認める場合も常にTerraチームでモニタリングを続け、他プロダクトでも同じようなコンポーネントや仕様が使われていると認められたタイミングで改めて汎用性を確認し、Terraとして実装することもあります。

＜運用の工夫4：導入支援＞

最後に導入支援です。利用プロダクトを増やして多くのフィードバックを得ることで、デザインシステムを育てることを意識しています。組織内で新規プロダクトが立ち上がる際や、技術が合致するプロダクトがすでにあるという場合には、積極的にコミュニケーションを取りながら導入を勧めています。

「各プロダクトを支える土台」を作るための設計

清水駿太郎です。最後に私から、Terraの内部設計について少しだけお伝えしたいと思います。

はじめに、繰り返しになりますが、Terraは「各プロダクトを支える土台」を目指しています。もう少し詳しく言うと、「UI開発において汎用性の高いコンポーネント」を提供しながら、Terraを利用することで一定の統一性を担保しやすくなるようにしつつ、「利用者のクリエイティビティの発揮」も支えられるように設計しています。

具体的なポイントをいくつか紹介します。まず、Terraの利用自体は任意となっています。また、仮にTerraを利用する場合でも、必ずしもUIライブラリーまで利用しなければいけないわけではなく、たとえばFigmaのコンポーネントのみ利用するなど、グラデーションのある選択肢を提示しています。

次に、「利用者のクリエイティビティの発揮」、つまり「自由度をどうやって設計するか」についてです。Terraは利用者がUI開発を爆速で進めることで、よりプロダクト固有の価値や機能の追求に時間を使えるようにしたいという狙いがあります。そのためには、利用者に与える自由度を落として、プロダクトごとに考慮することを減らすこと。それによりアジリティを高めることが重要だと考えています。一方で、レールから逸れることが難しいとプロダクトごとの個別最適化が難しくなり、クリエイティビティの発揮を阻害してしまいます。

そこで、Terraでは「コンポーネントの大小によって自由度を変える」という設計をとっています。

具体的に言うと、ボタンなどの小さくて、アプリケーションを開発する上でよく使うコンポーネントに関しては、自由度を多少減らしたとしてもアジリティを得られた方が全体的な効率性に寄与すると考えて、UIライブラリー上で提供しています。一方で、モーダルウィンドウなどの大きいもの、アプリケーションごとに工夫したい場面が多くなるようなコンポーネントは、Figma上でポリシーを提供することでベースとなるパターンは提示しつつ、個別最適化したい場合は、Figma上でアレンジするだけで済むという仕立てにしています。

AIエージェントを活用し、Terraを進化。さらにアジリティを高める

最後に、今後の展望についても少し触れたいと思います。

Terraのさらなる発展系として、現在は「MCPサーバー(※)を用いたAIエージェントによる開発」を進めています。Figma MCPと、Terraチームで独自開発したTerra UI MCPを組み合わせて、AIエージェントがTerraをベースとしてUI開発を自律的に行うというもの。プロダクトでTerraを採用した場合のアジリティを、より高める効果があると考えています。
※MCPサーバーとは：https://zenn.dev/tomo0108/articles/6b472b4c9cacfa

現在では、すでに開発業務にこれらを導入し、AIエージェントがドライバーとなってUIを開発する手法実用段階に入りつつあります。今はまだ元々UIを開発するケイパビリティを持つエンジニアの開発業務を効率化することが主な用途ですが、今後の展望として、プランナーやデザイナーがUI検討段階で「ちょっと試しに動くものを作ってみる」ことを簡単に行えるようになる可能性もあると考えています。