Designship 2026 登壇レポート｜デザインシステムを手放してみる - AIを信じたマルチブランド開発の再設計
こんにちは！サービスデザイン部シニアデザイナーの大澤です。
先日、10/10(土)・11(日)に開催された「Designship 2026」に登壇する機会をいただきました。貴重な時間に足を運んでくださった皆さま、本当にありがとうございました。
今回のセッションでは、私が働いている「GMOリピータス」というサービスについて、日々抱えている葛藤を交え、デザインシステムを主軸とする開発フローの試行錯誤についてお話しさせていただきました。
この記事では、当日のスライドとともに登壇内容をご紹介します。
※登壇時の原稿をもとに、10分の発表時間に収めるために削った内容を一部加筆しています。
はじめに
私は4年前に新卒でGMOメディアに入社し、今はポイントメディア事業を中心にサービスデザイナーをしています。
このセッションでは、「様々なブランドを1つのプロダクトで運営する私たちの葛藤と試行錯誤」 について、「デザインシステム」を主題にお話しします。
私たちのサービスとデザインシステム
私たちのサービスは「GMOリピータス」というプロダクトです。クライアントに合わせた独自のポイントサイトを構築し、運用まで一体的に行うOEM※型のソリューション事業です。 会員向けのCRM施策やエンゲージメント向上を目的とした多くの企業様に導入いただいています。
OEM：Original Equipment Manufacturingの略。他社が開発したシステムを、自社ブランドとして自社顧客に提供・販売できる仕組みのこと
1つの基盤・1つのチームで様々なブランドのサービスを運営しています。
パートナー企業様それぞれに独自のポイントサイトを提供していることから、共通の基盤を活かしながらも、各ブランドに合わせた高いカスタマイズ性が求められるのが特徴です。
そんな私たちが使っているのが「REPEATAS Design System」というデザインシステムです。
一般的なデザインシステムと同じように、デザイン原則やトークン、コンポーネントなどを定義しています。
もうかれこれ5年以上使っているデザインシステムで、新しいブランドの立ち上げにも、既存ブランドの改善にも欠かせない存在になっています。たくさんあるブランドを今のチーム体制で運営できているのは、間違いなくこのデザインシステムのおかげです。
「速度」と「自由度」のバランスへの悩み
このデザインシステムをチームで手塩にかけて育ててきたわけなのですが、育てれば育てるほど実感してくる問題がありました。
それが、「開発スピード(=速度)」と「ブランド表現の柔軟性(=自由度)」のバランスです。
共通の仕組みが整うほど、ブランドごとの「独自性」や「遊びしろ」が少しずつ失われているのではないか？といった感覚とともに、2つが両立できないことへの葛藤が日に日に大きくなっていきます。
ブランドが違えば、ターゲット・ユーザー層・クライアントの導入目的やKPIも大きく異なります。クライアントさんからは、上記のスライドのようなブランドごとの要望をたくさんいただきます。
しかしこういった要望全てに応えることが難しい場合があります。
一番多いのは「すでに共通化している機能やデザインのカスタマイズ」です。こういった要望には、リソースやコストを考えて「共通の仕組みなので難しいです」と改善を見送ってしまうケースが、非常に多くなっていたのが現状でした。
事業・プロダクト全体を考えれば妥当な判断ではあります。でも、個人的な気持ちとしては、ブランドごとにやるべき改善ができないもどかしさや、デザイナーとして期待に応えられないモヤモヤを強く感じるようになってしまいました。
速度を守るためには、自由度を制限するしかない。 それが現実でした。
自由度のための試行錯誤
とはいえ、この状態は何とかしたいと思い、ここからいろいろな試行錯誤が始まります。
真っ先に行ったのは、シンプルですが「開発速度」の改善です。スピードを上げて、ブランドごとの改善に向き合う時間をつくろうと考えました。そのために、AI活用とデザインシステムの最適化に注力しました。
実際、コードを書く・既存の実装を調べる・ドキュメントを整えるといった、これまで時間がかかっていた作業は、AIで速く進められるようになりましたし、最初はこれでブランドごとの改善に使える余裕が生まれると思っていました。
ところが、開発が速くなった分だけ、求められるスピードも上がっていくもので、開発速度が上がっても、ブランドに向き合う時間がつくれたわけではありませんでした。
さらに、その速度への期待値が上がった分、それに応えるために仕組みを最適化し、デザインシステムをより厳格にして実装速度や品質ラインを担保する──。そんなサイクルに気付けばハマってしまいました。
実装はさらに速くなり、品質ラインも上がっていたものの、ブランドが自由に表現できる余地はさらに小さくなっていました。
この方法では、AIにうまく動いてもらうために、デザインシステムの制約を増やしていたわけです。
ただこの方法、ルールでガチガチにしてAIを動かすスタイルは、ブランドごとの自由度を求める私たちのプロダクトにはあまり合っていない。そう気づき始めました。
ルールを細かく決めないと、AIが意図した通りに動いてくれない場面はまだまだ多いです。ただ、ここまで手取り足取り教え込まなくても、もっといい感じにやってくれるのではないか。
抽象的な話になってしまいますが、
「AIを使っているのに、AIのことを全然信用できていないな」
といった感覚があったんです。
同時に、ここまで速度と自由度をトレードオフ前提のものとして考えてきましたが、仕組みを変えればもう少し両立できるのではないか、とも思いました。
なんとなく今まで諦めてきたし、今の仕組みの中では確かにトレードオフ。
でも、どちらも欲張りたい。
そう思い、別のフローを試してみることにしました。
AIにルールを厳格に守らせて効率化・最適化するためだけに使うのではなく、遊びを許容するために使えないか。それが、この取り組みの出発点です。
デザインシステムを一度手放してみる
ここで一つ大きなトライをしました。
それがデザインシステムを手放すことです。
これまで使ってきたデザインシステムをなくして、デザインフローがどう変わるのかを検証してみたんです。
このように表現してしまうと、デザインシステムそのものを否定しているように捉えられるかもしれません。しかし、デザインシステム自体は非常に優れた仕組みであり、その価値を否定するつもりは一切ありません。
今回の目的は、あくまで「今の私たちプロダクトに合っていない」「自分たちの使い方に問題がある」といった疑念を確かめることであり、一度仕組みをまっさらにして確認してみることが、この取り組みの狙いです。
とはいえ、全部をなくしたわけではありません。
全ブランドで共有するソースコード、共通のコンポーネントライブラリ、共通のスタイルガイドラインなどは無くしつつ、デザイン原則、トークンの構造、アクセシビリティガイドライン、コード規約といったブランドによって変わらない土台だけを残しました。
守るべき土台さえ残しておけば、あとはAIがブランドに合わせてつくってくれる。これで速度を落とさずに自由度を上げられる──と思っていたのですが、結論から言うと、これは大失敗でした。
もちろん、良かった点もあります。当初意図していた、ブランドらしさを反映した柔軟な実装や、ブランド単位での素早い意思決定はできるようになりました。
一方で、次のような問題が出てきました。
「実装の基準」の少なさ：AIは何を守るべきかは分かってくれても、それを具体的にどう実装すればいいのかの基準がなくなってしまい、人もAIもゼロから判断する場面が増えてしまった。
他ブランドへの展開しづらさ：あるブランドで生まれた改善を、ほかのブランドへどう広げるのかが曖昧になってしまった。
レビュー基準の曖昧さ：何をもって「良い実装」とするのかがぼやけてしまった
とにかくデザインや品質がバラバラになってしまい、うまく機能しませんでした。
上のトライで消したものは「実装の基準」を担ってたので、普遍的な原則だけだとやはり全然ダメで、消すにしても代わりの基準はやはり必要だなというのが感触でした。
私たちがデザインシステムに求めていたもの
この失敗を通して改めて、私たちがデザインシステムに求めていたものは何なんだろうと考えました。
一言で言うとそれは、人とAIが「具体的にどう作るか」を判断するときに立ち返れるもの、です。
言ってしまえば、これを「制約」として定義したものが、これまでの私たちのデザインシステムを構成する一部でした。
でも、これを制約にならない形で置いておけたら、私たちのチームならうまく使っていけそうだ。そう考えて、少し考え方を変えてみることにしました。
「ライブラリ型」から「見本型」へ
そこで考えたのが、ルールを細かく定義したこれまでのライブラリの代わりに、良い見本を1つだけ置き、人とAIがその見本を使って判断する形です。
ここでいう見本とは、実際に動くサービスサイトのことです。どのクライアントにも提供せず、開発メンバーだけが自由に触れる架空のブランドサイトをゼロからつくりました。
プロダクトとして担保すべき標準機能やインターフェースは、すべてこの見本ブランドに入っています。これを参照しつつ、表現だけをブランドごとに変えて展開する。そんなフローを目指しました。
AIには、見本のコード、そのブランドごとのトークン・ガイドライン、ブランド共通のデザイン原則を、3つの層にして渡しています。
1. ブランド共通で土台となるデザイン原則、トークン構造、コード規約
2. 見本ブランドのソースコード
3. ブランドごとのトークン・ガイドライン
見本を育てる改善サイクル
こうなると、見本が常にアップデートされる仕組みも必要です。そこで、次のようなサイクルで活用しています。
いろいろなブランドでさまざまな改善をする中で、良いものを人が選び、見本ブランドにAIで自動反映する、という形です。
ただ、すべての改善を入れるわけではありません。
改善には当然良し悪しがあります。また施策によっては、特定のクライアントから開発費をいただいて作り上げた独自の機能もありますので、そういった施策を簡単に他ブランドに展開するわけにはいきません。
そう言った事情も踏まえ、見本に入れるべき変更を人が選んだうえで、反映していきます。
効果や影響
とにかく大切にしたのは、速度と自由度の両立。そして、その両方を続けていくための更新性です。
フロントエンド開発もデザイナーが担い、ブランドごとの自由度が強く求められる私たちにとって、この形はとても合っていました。
その結果、冒頭でお見せしたようなブランドごとの要望にも、ポジティブに答えられる場面が増えました。
加えて、デザイナーの品質に対する考え方にも変化がありました。
これまでは、プロダクトの品質に直結する要素として、コンポーネント設計の精度やルールに対する正確性が強く求められていました。
この厳格さを緩和し、やるべきことを「良い見本を育てること」に集約したことで、品質に対しての指針がシンプルになり、それぞれのブランドらしさを判断することへより意識が向きやすくなったなと感じています。
見本ブランドを、各ブランドで生まれた改善を「集める場所」として機能させるとともに、新しい表現や実装を自由に「試す場所」、新しいブランドの立ち上げの「起点になる場所」として、コンポーネントライブラリの代わりにこれからチームで育てていく場所にしていきたいと思っています。
まとめ
デザインシステムや、それを含むハーネスの仕組みは、今のAI開発の時代では特に整備する価値のあるものだと思います。
私たちもこれまで、世の中で良しとされるデザインシステムのノウハウを忠実に導入してきました。ただデザインシステムの正しい形は一意に定まるものではなく、プロダクトの特性に合わせて見極めなければいけないところです。
今回紹介したように、長く使ってきたデザインシステムの仕組みにこだわりすぎてしまうと、自分たちのプロダクトに合っていない形になり、かえって制約で自分たちの首を絞めてしまいます。
今回の取り組みで特に大きかった意識の変化は2つ。
一つは、プロダクトの特性と向き合い直したこと。
そしてもう一つは、「速度と自由度は、トレードオフである」という前提を疑ったこと。
これによって、自分たちのチームに合ったフローにたどり着けたことがこの取り組みの何よりの成果です。
今回のお話はマルチブランドならではの話でしたが、形は違っても、皆さんのチームにも大なり小なり「仕方がない」と受け入れているトレードオフがあるのではないでしょうか。
AIとの向き合い方を変えて、そこをぜひ欲張ってみると、違う道が見えてくるのではないかなと思います。
以上で発表は終わりです。ありがとうございました。
登壇を終えて
GMOインターネットグループとしてスポンサードさせていただき、GMOメディアサービスデザイン部にこのような機会をいただけたこと、本当に感謝しております。
このセッションの取り組みは、現場ではかなり手探り状態な中で進めたものであり、潮流とは異なる話が主題なこともあり、どんな反応をもらえるか登壇直前まで不安でした。
セッション後に声をかけていただいた方の中には、課題感に共感してくださる方が多く、いろんな意見や感想を聞くことができて、とても良い刺激になりました。
聞きに来てくださった皆さん、そしてDesignship運営の皆さん、本当にありがとうございました！
