2022.05.30
「STORES」デザインシステム構築の裏側。ブランド統合時にデザイナーとエンジニアが考えたこと

「STORES」デザインシステム構築の裏側。ブランド統合時にデザイナーとエンジニアが考えたこと

複数の会社・ブランドが統合して生まれた「STORES」。そのプロセスにおいて、どうデザインの指針を立て、サービス開発を進めていったのか。リードデザイナーの井出優太さん、フロントエンドエンジニアの藤井大祐さんが語ったデザインシステム構築の裏側とは?

0 0 0 0

※2022年3月10日に開催された【Frontend Talk 〜デザインシステム構築のリアルな裏側〜】より、「STORES」の井出優太さん(リードデザイナー)と藤井大祐さん(フロントエンドエンジニア)のセッションをお届け。書き起こし形式で編集したものをお届けします。

+++

アジェンダ
【1】デザインシステムの歴史
 └【2】ブランド統合によるデザインのフルリニューアルの話
 └【3】デザインの指針(デザインシステム「スタンド」)を作る話
 └【4】デザインシステム草案ができた後の話 
 └【5】デザインシステムに則ったUIにする話
【6】現状の課題
【7】今やっていること
【8】これからのこと

+++

「お店のデジタル、まるっと。」をコンセプトに、個人・中小企業の方々を中心としたお商売に対してその経済を支える STORES プラットフォーム を提供。具体的にはネットショップ開設サービスやPOSレジ、予約サービス、決済サービスなどを展開している。

【1】デザインシステムの歴史

藤井:
こんにちは、「STORES」というネットショップ開設サービスで、サービス開発に携わっています、フロントエンドの藤井と申します。

私たちは、オンラインオフライン問わずに、お商売すべてを支えるプラットフォームを作ることを目的に、ネットショップ開設サービス、予約サービス、決済サービスなどを展開しています。

そういった中、新規事業としてiPad POSレジ「STORES レジ」が動き出すことになりました。これはネットショップの基盤を拡張して、在庫管理、売上管理、アイテム管理といった運用をオンラインオフライン含めて一括管理できるプロダクトです。

「STORES レジ」では、ネットショップ開設サービス、決済サービスと一緒に使ってもらうことを目指したプロダクトなので、全体の体験をどう一貫性を持たせていくかというところを考えていく必要がありました。

+++

【2】ブランド統合によるデザインのフルリニューアル

藤井:
まず運営しているheyという会社なのですが、もともといくつかの企業に分かれており、社名がバラバラだった経緯があります。2018年頃に「STORES.jp」「Coiney」が統合してヘイ株式会社が誕生しました。

2020年頃、今までそれぞれ別ブランドにあったネットショップ開設サービスの「STORES.jp」と決済サービスの「Coiney」を1つの「STORES」というブランドに統合していく運びとなりました。

私たちの戦略は「1つのブランドの中に、複数の製品をまるっと提供していくことで、より大きな価値を出す」というもの。そのため、まずは象徴としてのブランドを統合しブランドイメージやカラーパレットを統合していました。

2020年頃に決定したカラーパレットを用いて、ネットショップ管理画面のデザインフルリニューアルが行われました。この時に決まったカラーパレットを使って STORES らしいデザインを考えはじめ、デザインシステムの前段になる初期のベースとなっています。

+++

藤井:
約半年かけたフルリニューアルですが、この過程で新たに見えたプロダクトとしての課題感、目指したい方向性を考え始めました。

【3】デザインの指針(デザインシステム「スタンド」)を作る

井出:
じつは2020年の5月当時、クービックという予約サービスをやっていた会社をグループ化して、サービスが増えることに。別の会社で作っていたプロダクトも「STORES」という1つのブランドとして各サービスを併用してもらいたい。そのために考えるべき課題がいくつか上がってきました。

・新しいサービスはどういうデザインにしたらいいのか
・今まであるデザインをそのまま残していくのか
・ブランドとして統合した方がいいんじゃないか

ブランドを統合して、ネットショップはそこに追従するようにリニューアルをしたんですが、それだけじゃダメで。統合したデザインの指針をちゃんと立てていかないといけないよねと。

目指すところは、複数のプロダクトが1人のユーザーに使ってもらえるような状態。例えば「ネットショップを使っているから、レジを使った時も同じような操作感で簡単に使える」という状態を、我々はビジネスとしても目指して行く必要があると考え始めました。

そもそもデザインシステムってどういう所までカバーするものなんだっけ?と考え始めたのは、2020年5月頃。ここから半年くらいかけて11月に草案をまとめました。

それまではデザイナーだけが関わっていたんですけど、「こういう世界観のUIを目指していきたい」というのをまとめて、エンジニアとも話し始めていきました。

+++

デザインシステム「STAND」

井出:
STORESのデザインシステムは「STAND(スタンド)」という名前で作ってます。お商売を支える「スタンドバイ」と、コーヒースタンドのような「小さいお店」。また、商売のデジタル化を支援する「スタンダードのプロダクトになりたい」という意味も込めて、名づけました。

【4】デザインシステム草案ができた後の話 

井出:
草案を実際にどう実装したか。まず、プロダクト自体は別のシステムで作っていて。新しいものも増える段階で、レジ自体は新しいデザインにする、ここは決めていました。

じゃあ、ウェブアプリってこれに沿ってやるんだっけ?という話とか、「でも作ってた会社も違うし、フレームワークも違うしどうやっていくの」という話があって、この辺からフロントエンドのみんなを巻き込みながら話を進めていってましたね。

【5】デザインシステムに則ったUIに 

藤井:
その上で「デザインシステムに則ったUIにしていきたい」というのはありました。ただ、もともと違う会社でそれぞれプロダクトが作られていて、フレームワークも違う。具体的にはネットショップ開設サービスの「STORES」はVue.jsで作られていて、決済と予約のサービスはReactで書かれていました。

今後もプロダクトは増えていく予定だし、どうしよう…みたいな。統一するにしても、もともと別会社だったため、横断的なエンジニア組織がない。そのため、小さく各地で始めていける手段がないか、議論していました。

議論した結果、Tailwind CSSを用いる運びになりました。

ユーティリティファーストCSSフレームワークであるこのTailwind CSSは、カスタマイズ可能なユーティリティクラスのみを吐き出してくれます。jsやHTMLは適用せずに、ユーティリティクラスのみを吐き出してくれるので、Tailwind configだけを設定したリポジトリを作り、configを統一する。そうすることで吐いたユーティリティクラスを各プロダクトで転用し、利用する。そして「いつかは共通のライブラリとして移植できたらいいね」と使用していきました。

これらが固まってきた段階で「STORES プラットフォーム」のログイン基盤になるIDプラットフォームができたのですが、これが初めてのデザインシステムで構築されたプロダクトです。CTOと井出さんとで実装を進めながら、Tailwindでいけるのかこの中で試していました。

2021年に「STORES レジ」のリリースに向け、ネットショップの管理画面の実装も始まりました。

こちらはオンライン・オフラインが統合した体験を持つプロダクト。ネットショップの中でも「STORES レジ」アカウントを開設できるようにしたい。そのための統合的体験が必要になります。そこで、ネットショップの管理画面も改修を検討していたのですが、ネットショップでの既存フローの改修も入ってくると、ID基盤のページと比べ、改修するコンポーネントの数も画面数も多い。開発が差し迫り、「STORES レジ」のリリースも差し迫っている。ただ、デザインシステム自体も、検討中のUIもたくさんある状態。まだまだ検討段階のため、本当にどうしよう…というフェーズにありました。

デザインシステムにどこまで対応するのか。フロントチームの中で議論し、これまでの既存デザインでデザイナーに刷り直してもらうのか、もしくはTailwind CSSは使わず、既存のコンポーネントCSSでデザインだけ「なんちゃってデザイン」みたいに新しくして作っていくのか。もしくはもうハンドルを切ってTailwind CSSで新規にスタンドUIを作るのか。ただ、ここもTailwind  CSSで作らなかったら最終的にはTailwind CSSで作り直すことになる。なので、二度手間も避けたい。やるなら時間を取ってやりたい。そして、必要最低限のコンポーネントに絞って、1からデザインシステムをつくっていくことにしました。

その代わり、かなり愚直な感じですけど、デザイナーとの連携を密に叩き上げ、一番最初に3回ぐらいのミーティングで詰めて、Tailwind configを最低限のところはFIXさせる。あとはエンジニアとデザイナーの昼会を毎日設定し、コンポーネント単位で未決定事項をどんどん実装しながら詰めていく形を取りました。

あとよくあるのですが、コンポーネントごとにステージング環境で見て確認してもらったり。ここが一番愚直だと思うのですが、理想としてはconfigを別リポジトリに、そこからバージョン管理して引っ張ってくる形を取りたいのですが、それだと「STORES レジ」リリースに間に合わない、と。その管理が難しいので、変更が激しいフェーズにおいては、各リポジトリ、各プロダクトに対して愚直に変更差分をコピペしていった背景があります。

こうして2021年の6月に無事に「STORES レジ」がリリースされ、急ピッチで進めたスタイリングも一定完成しました。

今では「STORES レジ」のリリース後にガイドラインを書いたり、UIコンポーネントのアップデートが進んでいたり。Tailwind configを切り離していて、そこからVue.jsについてはコンポーネントライブラリに切り出しが終わっている状態です。

ネットショップ以外のプロダクトは、各プロダクト内にUIコンポーネントライブラリを持っている感じですが、ゆくゆくは統合していこうと各地でがんばっています。ただ、これからの課題もいろいろあります。

【6】現状の課題

井出:
まだ現時点の課題なので、解決策が全部あるわけでは無いのですが、いったんUIを作って進めると「こういう時には使いにくい」といった課題も出てきます。デザイナーとして「本当はこういうUIがいい」と考えもある中で、速さ優先で「でも、既存のUIを組み合わせることもできるじゃん」とそっちが選択されてしまうこともあって。

あとは、UIのコンポーネントができていても、イラストとかビジュアルコミュニケーションをどうプロダクトの中でやっていくか?ここは手が回っておらず、今後どうしていこうか考えています。

作りながら走っているため、ガイドラインがまだ整備できていない部分もあります。また、エンジニアも、デザイナーに聞かないとわからない部分もあるので、そこで工数が発生する。「コンポーネントレベルだと作られているからいいけど、レイアウトレベルになると全然わからない」ということも。

今後アップデートしていきたいのですが、プロダクトごとにエンジニアの組織が分かれており、それぞれ実装していることもあり、どう同期を取っていくか、運用も課題です。

こういった課題を解決するのが事業としても大事ですよね。ただ、それを改善する人たちの目標設定・評価、デザインシステムの価値を見えるようにするのはすごく難しい。

デザイナーはチーム規模感的にもエンジニアに比べると小さいので、同期が取りやすい部分もありますが、「そういうチームを作るにはどうしていくんだっけ?」という部分が課題になっています。

【7】今やっていること

井出:
そういった課題がある中、今やっていることについてお話します。まずUI改善をがんばって進めています。画面の右がアップデートをかけようとしているものです。

+++

井出:
まだ実現されていませんが、このあたりの実装やガイドラインを含めどうしていくか、エンジニアと相談しながらやってます。

並行してドキュメントをどう作っていくか。ここの話も進めています。Webだけじゃなくてモバイルアプリもあります。toB向けに商売できるプロダクトを作っていますが、その先のtoCもある。なので、そういうところもどう作るか。話を整理してドキュメント化している最中です。

【8】これからのこと

井出:
これからどうやっていきたいか?としては、

・デザインシステムを磨き上げていくチーム
・事業側にコミットして、それをもとにデリバリーしていくチーム
・両者をうまく接続して、高い品質の製品を早く届けられるような状態

ここをちゃんと作っていきたいと思っています。

なので、UIデザイナーという意味だと、デザインシステムをバリバリ磨いていくスペシャリストみたいな人がほしいですし、そこをブリッジするデザインエンジニアも、それでデリバリーして行くプロダクトデザイナー、フロントエンドエンジニアもほしい。

また、デザインシステムに関わる部分の、さらにその先のところで、デジタルプロダクトを使いこなして商売や仕事が楽しくなる状態を作っていきたい。そのためには、最近聞くようになってきましたけど、ラーニングエクスペリエンスを担当するデザイナーや、コミュニケーションを担当するデザイナーをもっと増やしたいと思っています。


編集 = CAREER HACK


関連記事

特集記事

お問い合わせ
取材のご依頼やサイトに関する
お問い合わせはこちらから