事業フェーズの変化にどう対応する？GMOリピータスのデザインシステム改修の記録
こんにちは！サービスデザイン部の大澤です。
2022年に新卒で入社し、そこから「GMOリピータス」というソリューション事業のチームでデザイナーをしています。
GMOリピータスでは、「REPEATAS Design System」という独自のデザインシステムを作って運用しています。サービス自体は立ち上げから9年を迎えますが、デザインシステムを導入しはじめたのは6年ほど前のことです。
作ってから月日が流れ、事業フェーズやチームを取り巻く状況、利用できるツールは大きく変化しました。それに伴い、現在必要とされる情報や整備すべきルールにも、当時の定義との「ズレ」が生じています。
そんなタイミングで、今の、そしてこれからのGMOリピータスに最適化させるべく、デザインシステムの中身を抜本的に刷新することにしました。
本記事では、この改修に至った経緯と、具体的な取り組みの内容についてご紹介します。
前提
「GMOリピータス」とは
GMOリピータスは、独自のポイントサイト（ポイントモール）を構築し、運用まで一体的に行うOEM型のソリューション事業です。 会員向けのCRM施策やエンゲージメント向上を目的とした多くの企業様に導入いただいています。パートナー企業様それぞれに独自のポイントサイトを提供していることから、共通の基盤を活かしながらも、各ブランドに合わせた高いカスタマイズ性が求められるのが特徴です。
「REPEATAS Design System」とは
REPEATAS Design Systemは、GMOリピータスにおけるデザインプロセスの共通言語を定めた一連のドキュメントです。運用方法やチームルール、デザイン原則、スタイルガイドライン、マスターページ、コンポーネントライブラリで構成されています。
これまでのデザインシステムとその課題
これまでは、
全サービス全体を包括したデザインルール
サービスごとのスタイルガイドやコンポーネント
という構成でデザインシステムを使っていました。
GMOリピータスを立ち上げて3年ほど経ったタイミングではじめて形になったものですが、当初はサービスごとの違いを明確にするためのドキュメントとして、主にユーザー属性・ポジショニング・スタイルガイドをまとめていました。そこから、基盤デザインのリニューアルや各サービスごとのコンポーネント整備を経て、上記の構成のデザインシステムとなりました。
サービスごとのユーザーの属性やデザインのトンマナが明確になる一方、「GMOリピータス」としての共通のデザイン指針があまりなく、サービスごとにデザインや機能に独自性が出過ぎてしまう要因になっており、デザインシステムを整備し始めたタイミングから運用するサービス数が増えたことで、サービス差分による運用工数の問題が表面化してきていました。また同じタイミングで、AIエージェントを用いたコーディングワークフローが社内で浸透しつつあり、これらの面でも差分が足枷となってしまう場面が多くありました。
これらの背景を踏まえ、サービスに寄らない共通の指針をデザインシステムとして具体的に定め、サービスを横断する業務の負荷を減らすことが必要だと感じ、以下のテーマを掲げてデザインシステムの改修に取り組みました。
改修のテーマ
上記の課題感を踏まえ、「こんなデザインシステムにしたい」といった構想をはじめに定めました。ここで定めたテーマは以下の3つです。
共通アセットを明確に
前述の通り、パートナーごとにカスタマイズしたサイトを運用しているため、サービスごとに機能やデザインの差分が生まれやすい構造です。これを最小限にするため、共通要素をデザインシステムとして具体的に定め、サービスを横断する業務の負荷を減らすことを目指しました。
トンマナは柔軟に
連携するサイトごとにターゲットやトンマナは様々であり、デザインのカスタマイズ要件もサービスごとに大きく異なります。アセットの共通化は意識しつつ、そのようなカスタマイズをある程度許容できるデザインシステムにすることを意識しました。
AIフレンドリーな構成に
AIツールをフル活用したワークフローが定着しつつある現状ですが、デザインシステムが複雑すぎたり、仕様が分散していたりすることで、AIが正しいコンテキストを理解できず、実装工数をかけてしまう場面が多々ありました。これを防ぎ、AIのコード出力制度を担保できるような、比較的シンプルで一貫性のある構成を意識しました。
改修プロセス
1. 改修方針の検討
上記のテーマを踏まえ、デザインシステムの新しい構成案を考えました。
方針の軸は、サービス独自のルールの共通化とこれまで決められていなかったルールの追加の2つです。
それに伴い、元々使っていたFigmaの構成も大きく変わることのなったので、それらの構成も見直して整備しました。プロジェクトの分割、ライブラリ用ファイルの統合、マスターデータの移管などを行っています。
2. デザイントークンの整備
アセット共通化の最初のステップとして、サービスによって定義の仕方が大きく異なっていた「デザイントークン」の見直しをしました。デザイントークンとは、デザインの最小要素（色、余白、フォントサイズなど）に名前をつけた変数です。
既存の定義の棚卸しをしつつ、Figma上に全サービスで使える共通のVariablesを新たに作成し、実際に各サービスのデザインに当てはめてみて定義に問題がないか検証を進めました。
サービスごとの差分はVariablesのmode機能で吸収できるようにしています。
検証ができたら、Figmaの各サービスのマスターデータに反映しつつ、実際のソースコードのリファクタも順次進めていきました。
3. コンポーネントライブラリの整備
デザイントークンの改修が終わった後、サイトを構成する「コンポーネント」の見直しも行いました。
デザイントークンと異なり、コンポーネントは特定のサービスにのみ存在するものやカスタマイズなどで同じ要素でも見た目を若干変えているものなど、すべてを共通化するのが難しいため、「共通化すべきコンポーネント」と「そうでないコンポーネント」に分類し、前者のみをFigmaに新たに定義し直しました。
新たにコンポーネントを作成するときは、
まずは共通コンポーネントにできるか確認
できる場合、そのまま共通コンポーネントにする
できない場合、サービス専用のコンポーネントにする
といったフローを踏むことで、冗長なコンポーネントを生まないようになりました。
マスターページやソースコードへの反映は非常に時間がかかるため、見つけたところから順次行うよう、現在も段階的に進めています。
4. スタイルガイドラインの作成
整備したデザイントークン・コンポーネントをチーム全員で把握するため、使い方やデザインパターンを書いておく「スタイルガイドライン」を作成しました。
コンポーネントの修正が必要なとき、新しくコンポーネントを定義するとき、既存コードのリファクタをする際にチームで利用しています。
5. チームルールや運用方法の整備
定めたデザインシステムをチームで保守していくため、運用ルールを明文化しました。
各ドキュメントの説明、Figmaをはじめとした各種ツールの利用フロー、コンポーネント追加時のルールなどが書かれています。
6. AI用ドキュメントの整備
弊社では、HTMLやCSSなどのコーディングをデザイナーが担っています。コーディング業務に関して、Claude CodeのようなAIコーディングエージェントを主に用いているのですが、これらを使う時のコンテキストとして、上で定めたデザイントークンやコンポーネント、プロダクト開発時に利用する際の制約事項などをMarkdown形式で整理しました。
これらのドキュメントとFigma MCPを用いることで、FIgmaのプロトタイプをかなりの精度でコード出力できるようになっています。詳しくはこちらの記事でまとめているので、ぜひご覧ください。
改修結果
改修を経て、デザインシステムの全体像は以下のようになりました。
「運用方法・チームルール」「デザイン原則」「スタイルガイドライン」「マスターページ」「コンポーネントライブラリ」を全サービス共通のものとして新たに作成し、この共通ルールに当てはまらないもののみをサービス独自のルールとして切り出してまとめています。
例) サービス独自の定義
特定のサービスでのみ運用しているカスタマイズ機能
連携サービスとの兼ね合いで定義している独自のトンマナ
運用年数が長いサービスに残ってしまっている整備前のコンポーネント
運用方法・チームルール
デザインシステムの使い方、ドキュメントをチーム全員で保守していくためのルールなどをまとめたドキュメントです。
デザイン原則
「語調・ライティング」「アクセシビリティ」「デザイン指針」「ブランドアイデンティティ」など、GMOリピータスが提供する価値や守るべき原則をデザインの視点で言語化したものです。
スタイルガイドライン
ブランドのトーン＆マナーを構成する基礎的な視覚要素(デザイントークン)や、UIパーツ(コンポーネント)の使い方・デザインパターンなどをまとめたものです。
下記のUIキットのフォーマットを参考にして作成させていただきました。
マスターページ
GMOリピータスで立ち上げるポイントモールの基本となる構成・ページデザインを定めたものです。
コンポーネントライブラリ
Figma上でデザインコンポーネントをまとめたライブラリです。
振り返り
改修の効果
今回の改修を経て、以下の効果を実感しています。
「共通化」を前提とした議論の活性化
これまでサービスごとにドキュメントやFigmaが分かれていたことで、横断的なルールが暗黙知化していましたが、ノウハウを可視化したことで「これは共通化できるか？」という視点での議論が自然に生まれるようになりました。
チームの「情報拠点」の確立
「何かを決めたらここに書く」「迷ったらまずここを見る」という周知が徹底され、情報の分散が解消されました。また新メンバーのオンボーディングのサポートにもなり、クリエイティブ作成やUI実装のスピードが格段に早まりました。
AIコーディング精度の向上
AIエージェントへのコンテキスト共有がスムーズになり、デザイン作成から実装時間が短縮されました。
運用コストの削減
冗長な差分が減ったことでデザイン・実装工数が減りました。特に、サービス横断で行うような施策や、サイトリニューアルなどの規模の大きな施策で大きな効果が出ています。
課題と展望
大きな効果を実感している一方、実運用を通して見えてきた課題や、今後のアクションもいくつかあります。
ドキュメント管理コストの増大
情報量が増えたことで、メンテナンスの負担も増しています。現在は「とりあえずあると便利そうだよね」と感じた情報を全部盛りにしているため、今後は実際の運用を通じて、本当に必要な情報に絞った「ドキュメントの棚卸し」をしていく予定です。
AI用・人間用ドキュメントの一元管理
現状、AIに読み込ませるコンテキストと人間用のガイドラインを別々に管理してしまっている箇所があります。情報の二重管理を防ぎ、常に最新の状態を保てるよう、フォーマットの最適化を進めていきます。
新規サービス立ち上げ時の影響
今回の取り組みは既存サービスに対するアクションが多く、新規サービスを立ち上げるときに今回のデザインシステムが機能するかはまだ試せていません。
今後はそういった新規立ち上げフローを整備しつつ、立ち上げ時のデザイン工数やコミュニケーションコストを抑え、短時間でより良いアウトプットが提供できるようになることを期待しています。
まとめ
デザインシステムは、一度作って終わりではなく、運用を続ける中で変化し続けていくものです。
また世の中の事例をただ真似すれば良いものでもなく、ビジネスモデル・事業フェーズ・チーム体制・使用技術などの様々なパラメータと向き合い、最適な形を模索していくことが大事だということを改めて実感しました。
これからもこういった取り組みを通して、パートナー企業様やユーザーの皆様により速く、より良い価値を届けられる基盤を育てていきたいと思います。
最後までお読みいただき、ありがとうございました！
