「楽天 GORA」混乱を乗り越えシステムへ:GRXデザインシステム構築を実現するまで

皆さん、こんにちは！ゴルフ場の検索や予約サービスである「楽天 GORA」の UIチームです。

今回は、私たちがゼロから構築したデザインシステム「GRX(Gora ReX - Rakuten Experienceより)」の開発により、学び、達成したことをお話しします。

デザインシステムとは?

デザインシステムとは、企業のすべてのインターフェースのデザインと機能を定義する標準やコンポーネント、共通言語のことです。

ボタン、フォーム、テーブルなど、マージンのデザインを毎回決めるのではなく、明確な使い方の説明書のある既製の「レゴブロック」があると考えていただくとよいでしょう。

具体的には、デザインシステムとは、以下になります。

デザイントークン: すべての製品で共通する基本プロパティ(色、フォント、スペーシングなど)のセット
UIコンポーネント: ボタン、フォーム、テーブル、モーダルウィンドウなど、ユーザーインターフェース (UI) を構成する再利用可能な個々の部品
パターンとルール: コンポーネントの連携方法や、各コンポーネントの使用方法
ドキュメント: 新しくメンバーに加わった人でも、容易に仕組みを理解するための記録

デザインシステムの意義

開発スピード

デザインシステムによって、コンポーネントの準備が完了してテストを行う際に、既存のブロックから追加するだけですみます。そのため、ゼロからコードを書く必要がなくなります。

MVPを素早くローンチしたり、アイデアをテストする際には特に有用です。より完成度の高い製品開発が可能となるからです。

一貫性 = 認知度

一つの製品を利用したユーザーなら、別の製品の使い方も理解しやすくなります。
これにより、以下の効果が期待できます。

・UXの向上
・参入障壁の低減
・問い合わせの減少
・ブランド認知の強化

スケーラビリティ

デザインシステムによって、新しいプロジェクトであっても、ゼロからスタートする必要はなくなります。チームに新しい開発者やデザイナーが参加する際も、共通のシステムがあることで、彼らは各プロジェクトの独自のスタイルを学ぶ必要はなくなります。

負担の削減

プロジェクト毎のコンポーネント管理だったものから、コンポーネントが統一されることで、プロジェクトごとにデザインの更新は不要となり、一ヶ所を変更することで、すべてに反映されます。

品質

各プロジェクト毎にテストされていたコンポーネントが、一度のテストで済むため、バグが出にくく、整合性が高くなります。その結果、より品質の高い製品開発をより速く実施できます。

GRXの開発を実施した理由とその方法

独自のデザインシステムを開発するに至った要因は以下の2点です。

・チームの負担を軽減するため

・チームに一貫性のある成熟したプロセスを実装する必要性があったためデザインシステムは海外ではすでに標準であり、スタートアップではありません。楽天もグローバル企業として、デザインシステムを導入するタイミングがきていました。

初日から製品構築を実施

本プロジェクトでは、プロトタイプではなく、初日から、製品構築を実施することにしました。シンプルなボタンや入力フィールドから、カレンダーやデータテーブルのようなより複雑な要素まで、コンポーネントの完全なセットを計画しました。

GRXはVue 3 + TypeScriptで構築されています。最初から、Storybookでのドキュメント、Vitestでのユニットテスト、そしてビジュアルリグレッションテストなどの完全なインフラを整えました。

これほど本格的なアプローチを行った理由は、デザインシステムは3〜4個程度のコンポーネントのセットでは機能しないからです。少なくとも基本的な要素がカバーされていなければ、インターフェースを構築できず、製品は従来のスタイルのままになり、効果がないのです。

図: Storybookのコンポーネントページの例。開発者とデザイナーがすべてのpropsを確認し、コンポーネントがどのように機能するかの例を見られる、唯一の信頼できる情報源。

開発の状況

当初GRXに取り組んでいた開発者は一人だけでした。そのため、基本的なコンポーネントを含むベータ版がリリースされたのは6ヶ月後でした。モーダル、カレンダー、コンボボックスを含むより完全なシステムの完成は1年後です。

初期バージョンが完成し、概念実証を実施した後、より早く開発することになり、まず開発ローテーションで実装を行いました。各チームメンバーが1〜2ヶ月間手伝うことになり、内部オープンソースプロジェクトのように、少なくともそれぞれ一つのタスクを担当しました。

しかし、この試みでは、期待ほど開発のスピードアップにはつながりませんでした。

それは、メンバーの経験知が異なっていたこと、主要プロジェクトに加えた作業が負担になったこと、新しい製品であるGRXに深く関わることの難しさなどが理由として挙げられました。最終的に、私たちは2人目の専任の担当者を割り当て、問題を解決しました。

この経験から、デザインシステムは専門的な技術を持つ、専任のチームがあたるべきだと考えます。そうなれば、デザインシステムの安定性が担保され、他のプロジェクトの影響を受けずにすむでしょう。一般的に、専任のデザインシステムがあることが、グローバルでは標準なので、当社でもいずれそうなることを願っています。

デザインプロセスの構築

デザインシステムは開発者だけではなく、デザイナーも同じくらい重要な役割を果たすため、この点で新たな課題が生じました。

1年間で、デザイナーが3回交代しましたが、全員がデザインシステムの経験があったわけではなく、徐々に原則を理解し、熟練していく必要がありました。

デザイナーの最大の課題は、従来の思考を変えることです。今まで、デザイナーは特定のタスクのために、任意のコンポーネントを作成してきましたが、今回はシステム的に考える必要があります。既存のソリューションを使用するか、新しいものが必要な理由を説明するかです。

もう一つの課題はFigmaのインターフェースです。Figmaのインターフェースは、システムロジックを変更する必要がある場合でも、通常のプロパティのようにコンポーネントトークンを変更することが可能です。そのため、デザインシステムに慣れていないデザイナーはコンポーネントのpropと同じくらい簡単に変更しようと考えてしまいます。しかし、そうすることで一貫性がなくなるため、コードは機能しなくなります。そのため、モックアップに戻ってやり直さざるを得なくなるでしょう。

これらのデザインの問題点に対して、7年のデザイン経験とデザインシステムでの作業経験を持つ、メインGRX開発者が大きな助けとなりました。彼はデザイナーに技術的な制限を説明し、開発者とデザイナーとの橋渡し役となりました。この働きは、基本的なプロセスの構築と、デザインシステムの理解の確立に非常に役立ちました。

今後、同様の不備を防ぐために、デザインシステムの理解を確立するプロセスを強化し、社内でトレーニングコースを設けることを計画しています。このトレーニングは、デザイナーだけでなく、将来デザインシステム(特にGRX)の使用を検討しているチームにとっても有用です。システマティックなアプローチを簡素化し、新しいプロジェクトでの実装をスムーズにすることがこのトレーニングの目的です。トレーニングに興味がある方は、ぜひお問い合わせください。

図: Figmaのコンポーネントページの例。デザイナーはすべての制限とガイドラインを文書化し、すべてのコンポーネントバリアントを組み立てます。このドキュメントはデザイナーが準備します。

意識改革：GRXはツールではなく、製品である

最も予想外の課題は、技術的なものではなく、私たちの意識でした。

当初は、私たちはGRXを通常のツールであり、各特定のプロジェクトのニーズに合わせて調整できるものと考えていました。例えば、「ここの角を少し変えましょう」とか「このケースでは、このコンポーネントを少し違うものにできますか?」といった感じにです。

しかし、デザインシステムは製品であるため、独自のユーザー(デザイナーと開発者)、独自のロジック、独自の制限とルールがあります。また、その完全性を壊さずに「フィットさせる」ことはできません。ツールはタスクに適応しますが、製品は使用のルールを設定するものだからです。

各チームがニーズに合わせてコンポーネントを修正し始めたら、以前の一貫性のない状態に戻ってしまいます。デザインシステムは、みんなが同じルールで運用されているときにのみ機能します。

意識改革は簡単ではありませんでしたが、GRXを製品として扱い始めたとき(独自のドキュメント、ロードマップ、機能リクエストプロセス、バグ処理を含む)、うまく機能し始めました。もちろん、まだすべての場所で機能するには、さらに時間が必要です。

開発者からのフィードバック

GRXデザインシステムを組み込むことにより、以下の効果が得られました。

・EOLプロジェクトで時間短縮が可能となる

・チームがビジネスロジックに集中できる

しかし、もちろん課題もありました。

初期段階の実装であったため、一部のGRXコンポーネントにバグがあり、開発またはQAフェーズ中に修正する必要がありました。

これは、初期段階で準備しておく必要がある事象です。いくつかの複雑なコンポーネント(Combobox、Calendar、Datepicker)は、プロジェクトと並行して、厳しい締め切りの中で作成されました。そのため、この場で修正しなければならないバグや、不十分な機能が生じてしまいました。理想的ではありませんが、スピード感のある開発を実施するためのトレードオフだと考えています。

また、デザイナーとエンジニアリングチームが、コンポーネントの使い方について見解が違うことがあります。それは、役職によって、コンポーネントを異なる視点で見ているので、当たり前のことです。初期段階でしっかりとコミュニケーションをとり、複雑なコンポーネントの議論にすべての役職(プロダクトマネージャーを含む)を関与させることが解決策となります。

経験を積むことで成長できる

GRXを使用するプロジェクトは初めて実施するので、課題をクリアする経験を積むことで、GRXをより安定的に扱うことができるようになります。

私達は課題を解決することを投資と考えています。最初のプロジェクトは困難が多く、時間がかかりますが、次のプロジェクトは、その分時間も短縮できます。

GRX開発者が、システムを正しく発展させるためには、デザイナーの構造化されたフィードバックが重要です。また、ユニットテストとVRTだけでは不十分でした。そのため、本番環境の前にバグをキャッチできるように統合テストとe2eテストを実施する必要が明らかになりました。

図: Vitepressドキュメントのコンポーネントページの例。開発者が必要とするprops、slots、events、コードスニペット付きの使用例などが含まれる。

制限は機能であり、バグではない

主なフィードバックとして、柔軟性が低くなり、作業が難解になったという指摘もあり、これは事実です。現在では、「好きなように」コンポーネントの新しいバージョンを作成できません。既存のものを使用するか、新しいものが必要な理由を説明しなくてはいけません。

しかし、これが重要な点で、制限は、以下のような理由から、ビジネスのために必要なことなのです。

制限によって、細部についての議論に費やす時間が減る
時間を節約できるため、実際のユーザーの課題解決により集中できる
各ソリューションがすべての製品にスケールする
基盤が準備されているため、新しいプロジェクトが速く始められる

デザインシステムの導入当初は、時間がかかります。しかし、新しいツールの使い方を学ぶときは、どんなものでも同じです。一度導入できれば、その後の開発スピードは何倍も早くなるでしょう。

現在の状況と今後の展望

約1年半で私たちは、50のコンポーネントを開発しました。コンポーネントは、シンプルなボタンから複雑なデータテーブル、カレンダーまでそれぞれにドキュメントとテストがあり、製品として完成されたものです。また、すでにGRXを使用した3つのプロジェクトをリリースしました。
*RBS Lesson、OB Line、Green Trimming Toolなどの社内ツール。

実際にGRXがどのように機能するか、理解していただくために、RBS Lessonのページを以下に提示します。このページはトークンとコンポーネントの両方を実装したもので、タイポグラフィ(タイトル、サブタイトル、コンテンツ)にGRXトークンを使用し、GrxButton、GrxCalendar、GrxSidebar、GrxTableなど、複数のGRXコンポーネントを使用しています。

図: GRXで構築されたRBS Lessonのページ。

これまでのプロジェクトは、まだ始まりに過ぎません。近いうちに、さらに多くのプロジェクトへの展開を計画しています。私たちの直近の計画は以下の通りです。

パターン

コンポーネントに加えて、典型的なシナリオ(ログインフォーム、フィルター付きテーブル、ダッシュボード)のために、既製のソリューションであるパターンを作成します。パターンの作成によって、チームはインターフェースをさらに速く構築できるようになります。

他のプロジェクトやチームへの展開

私たちは、部門内だけではなく、社内の他のチームへのGRXの適応を支援することが可能です。ライブラリにアクセスできるようにするだけではなく、チームのトレーニング、プロセスの設定、テーマ設定の実装を支援しています。

テーマ設定

現時点のGRXは、テーマトークンの変更のみ可能です。しかし、よりスケールアップを図るには、他のチームや製品が個々で設定を変更できるようにする必要があるでしょう。そのため、Tailwind(CSS フレームワークのこと)と同様に、プロジェクトレベルで、よりグローバルなコンポーネント設定を可能にする計画です。

モバイルデバイス

モバイルアプリケーションへのGRXの適応を検討しています。いずれは、すべてのプラットフォームでユーザー体験を一貫させる予定です。

他のフレームワークへの対応

現在、GRXはVueで構築されていますが、チームによって使用する技術が異なることをよく理解しています。私たちにとって重要なのは、どのフレームワークを使用するかではありません。デザインの一貫性を保ち、情報源を一つにまとめることです。

デザインの一貫性を保つための方法は、以下の2つが挙げられます。1つは、ReactやSvelteのような各チームのフレームワークに向けて、GRXを適応させるための支援を実施して、一緒に構築することです。これにより品質と一貫性は保証されますが、継続的なコラボレーションと長期的なコミットメントが必要です。専任のGRXチームが実施すれば、スムーズに実施しやすくなるでしょう。

もう1つは、フレームワークに依存しないアプローチです。デザイン・トークンとガイドラインを提供し、各チームが独自に適応できるようにします。この方法は導入しやすいですが、一貫性が失われるリスクが高く、各チームが同じ問題を何度も自分たちで解決する必要が生じるでしょう。そのため、今のところ、私たちは最初のアプローチがより良いと考えていますが、このことも引き続き議論中です。