本記事はBill One 開発 Unit ブログリレー2024の第16弾です！！
他の記事もぜひぜひご覧ください！！
こんにちは、技術本部 Bill One Engineering Unitの江川です。
「Bill One」では2023年頃より、Sansan株式会社におけるいくつかのプロダクトをまたいだデザインシステム「One Design System」の取り組みを行っています。
今回は、このOne Design Systemの取り組みのこれまでとこれからについてお話していきたいと思います！
目次
デザインシステムの立ち上げ
急成長するプロダクトで発生した課題
「Bill One」は2020年5月にローンチされたサービスで、これまでT2D3 1 を超えるペースで急成長を続けてきました。
このプロダクトの急成長に伴い組織も急拡大し、ローンチ時は4名程度だった組織が3年ほどが経過した頃には約60名の規模になっていきました。
「Bill One」のフロントエンドではReact+TypeScriptでシンプルなSPAにてアプリケーションを提供しています。また、開発チームはフィーチャーチームで構成され、技術的にはサーバーサイドからフロントエンド、インフラまでフルスタックに開発を行っています。 とはいえ、メンバーごとに特定技術領域に対して明確な強みがあることも多く、必ずしも全員がフロントエンドに精通しているわけではないというのが現状になっています。
そんな急成長する組織で顕在化してきたフロントエンドにおける課題に以下のようなものがありました。
課題1. 色や余白がハードコードされている
ページやコンポーネント毎に微妙に異なるカラーや余白が適用されていることがあり、UIにおけるスタイルの一貫性が欠如していました。
課題2. 似ているが微妙に異なるUIコンポーネントが定義されている
「Bill One」ではコンポーネントライブラリとしてSemantic UI Reactを採用2しており、ライブラリから提供されるコンポーネントに対して微妙に異なるデザインとそれに基づく実装が多く存在していました。 この微妙に異なるコンポーネントが都度実装されることで、デザイン/実装コストがかかり開発効率が低下していました。
課題3. エンジニア・デザイナー間の認識齟齬
組織が拡大していくにつれて、徐々にエンジニア・デザイナー間で共通コンポーネントに対するメンタルモデルがズレていくのを感じていました。 具体的には、「どのコンポーネントが共通で定義・再利用されるべきか」「どういうときにこのコンポーネントを利用するべきか」といった整理がついておらず、プロダクトとして一貫したユーザー体験を提供していくには程遠い状態になっていました。
こうした課題は中長期で開発効率・ユーザー体験を損なうものになり今後大きな負債になっていくと考え、デザインシステムの取り組みを立ち上げていくことにしました。
デザインシステムというアプローチ
デザインシステムを始めるにあたって、まずは自分たちはデザインシステムに何を期待するのかを議論していきました。
議論の結果、「Bill One」でのデザインシステムの構築にあたっては「全ての人が使いやすいBill Oneらしさを、効率よく提供できる触媒」という状態を目指すことにしました。
これは全てのユーザーが使えるBill Oneらしさを提供できる基盤を作り、そしてエンジニア・デザイナーにおける共通言語を作り、コミュニケーションを促進させるといったことを目指しています。
デザインシステムを進める際には、目先の課題をひとつずつ改善していくべく"小さく始める"ことを意識しました。そこで、以下のステップでデザインシステムの立ち上げ・プロダクトへの展開を徐々に進めていきました。
- まずはデザイントークンからはじめる
- デザイン原則について考えてみる
- コンポーネントを整理する
- UIコンポーネントを実装し、利用していく
作成したものから順次プロダクトに適用し、その後改善のサイクルを回すことを意識していました。
Oneプロダクトとしてのデザインシステムへの進化
はじめは「Bill One」というプロダクト単体でのデザインシステムとして始めた取り組みでしたが、Sansanには通称「Oneプロダクト」と呼ばれるプロダクトがいくつかあります。 このOneプロダクトの開発では、デザイナー間の連携によりそれぞれ近しいユーザー体験を設計していくようなデザインプロセスがありました。 そこで「Bill One」でのデザインシステムの活動をきっかけに、「Bill One」だけではなくOne プロダクトとして合流して、改めてデザインシステム「One Design System」を立ち上げていくという動きが始まりました。
One Design Systemの立ち上げやデザイン原則の実践については、デザイナーメンバーが書いた記事もあるのでぜひご覧ください。
デザインシステムの現在地
先日One Design Systemでは主要なコンポーネントの実装が完了し、社内で提供するパッケージとしてv1がリリースされました🎉 v1リリースに際してFigmaとStorybookの公開も行われています。
Bill OneとContract Oneのプロダクトデザインチームで共同で取り組んできた「One Design System」を公開しました。https://t.co/PAn6w8k3z8
— 【公式】Sansan (@SansanJapan) 2024年12月3日
「One Design…
デザインシステムの構成要素
One Design Systemは、現在以下のような構成要素を持っています。
- デザイン原則
- デザイントークン
- アイコン
- コンポーネント
- ガイドライン (WIP)
これらのうち、デザイントークン・アイコン・コンポーネントについてはmonorepoで管理されており、それぞれプライベートなnpmパッケージとして社内に配布されています。
デザイントークン(one-tokens)
Tokens Studioで管理したデザイントークンをStyle Dictionaryを通じてDesign Tokens Format Module形式のTypeScriptファイル/CSSファイルにそれぞれ変換し、変換後のトークンファイルを提供しています。
アイコン(one-icons)
アイコンについてはSVGで管理し、後述のコンポーネントパッケージ側でReactコンポーネントとして提供する形を取っています。 アイコンに更新があった場合は更新反映用のPull Requestが作成されるようなワークフローを用意し、可能な限り自動化をしています。
コンポーネント(one-ui)
コンポーネント実装においては、アクセシビリティ対応のコスト削減をしながら最速でコンポーネント作成を進めるためにもヘッドレスUIコンポーネントライブラリのArk UI を利用し実装しています。 類似のライブラリとして他にもRadix UIやReact Ariaなども検討しましたが、
- 対応コンポーネントの充実性 / デザインシステムで実現したいコンポーネントがカバーされているか
- ヘッドレスUIコンポーネントライブラリ側で実現されているインタラクションが、デザインシステムコンポーネントとして実現したい体験と近いか
- スタイリングを効率的に行い、最速でコンポーネント実装を進められそうかどうか
などの観点から比較検討の上で最終的にArk UIを選定しています。 また、同時にスタイリングライブラリとしてPanda CSSを採用しているため、Park UI を参考に効率的にスタイリングを行うなどの恩恵も受けられているように思います。
コンポーネントライブラリとしてはFigmaに定義されているコンポーネントの他に、BoxやStack、Centerといったレイアウトプリミティブもコンポーネントとして提供する形を取っています。これによりプロダクトチームの実装時に、デザイントークンに準拠したレイアウトが効率的に行えるようになると考えています。
また、コンポーネント実装の際にはStorybookを活用し、さらに Chromaticを活用することでVisual Regression Testの実施やデザイナーによるコンポーネントのレビューなども行っています。
デザインシステムのプロダクトチームへの浸透
現在、デザインシステムに関わるメンバーは、各プロダクトのプロダクトデザイナーとエンジニアから構成されています。デザインシステム専属のメンバーはおらず、普段はそれぞれプロダクトデザイン・開発に従事しているような形です。 このデザインシステムチームとプロダクトチームとのやり取りは以下のような形で行われています。
ドキュメント管理
Notionでは、構成要素であるデザイン原則やトークン、アイコン、コンポーネント、ガイドラインなどが全て確認できるようになっています。 特にコンポーネントについては最新の利用可能なコンポーネントを参照できるようにしており、各コンポーネントページにはFigma/Storybookを埋め込み、仕様やバリエーションをドキュメント上から参照できるようにしています。
コンポーネント一覧はギャラリービューにしてサムネイルを用意することで、今あるコンポーネントとその名前が理解しやすいようなドキュメントづくりを意識しています。
アップデート情報の共有
Slackでニュースチャンネルを作り、リリースやその他アナウンスなどデザインシステムに関する情報の共有を行っています。
フィードバックの収集
こちらも同様にSlackでフィードバックチャンネルを作り、コンポーネント実装/デザインシステムに対する悩みや疑問にデザインシステムチームが常に答えられる状態をつくっています。
この他にも、One Design Systemとして進めていくにあたってロゴコンペを開催し、プロダクト開発メンバーみんなに投票してもらうことでデザインシステムを自分ごととして捉えてもらうような工夫をしたりもしています。
また、個人としてはプロダクトに実装を組み込んでいく段階で「Bill One」におけるすべてのフロントエンドのPull Requestにレビュアーとして入り、「ここはデザインシステムの〇〇コンポーネントに置き換えられます！」といったコメントをつけて回るようなこともやっていました。 「Bill One」には「常に学習し、変化し続ける」という組織文化が根付いていることもあり、こうしたレビューコメントからOne Design Systemに関心を持ち、以降アップデートを追って組み込みを推進してくれるようなメンバーが多くいてとてもありがたかったです。
デザインシステムのこれから
One Design Systemで今後挑戦していきたいこと、さらにはデザインシステムの提供を通じて最大限の価値提供をしていくために考えていることについてお話していきます。
デザイントークン適用の見直し
現状のFigma定義・実装として、Semantic TokenではなくPrimitive Tokenを直接参照しデザインしているケースが多くあります。 これに対して、One Design Systemではデザイントークンの再整理を進めています。 具体的にはPrimitive Token自体の見直し、トークンの命名・Semantic Tokenのバリエーションの再検討を進めており、これに基づきデザインシステムを更に使いやすいものにアップデートしていきたいと考えています。
アクセシビリティガイドライン・ライティングガイドライン等の整備
構成要素のセクションでガイドラインをWIPとして記載しましたが、Oneプロダクトとして満たすべきアクセシビリティ要件の整理を改めて行い、それに準じた実装を行っていきたいと思います。 更にはライティングガイドラインとそのルールセットを実装したtextlintルールの配布などを行っていきたいと考えています。
レイアウトパターンのサンプル実装の提供
コンポーネントが一通り揃ってくると、コンポーネントの組み合わせでよくあるパターンを効率的にデザイン・実装したいというニーズが生まれてきます。 今後はこうしたよくあるレイアウトパターンを、デザインシステムのコンポーネントを利用したコードスニペットとして提供していきたいと考えています。
AIによる自動生成の活用
これについては十分な検証ができていないので妄想の話も含みますが、個人的にデザインシステムと生成AIの相性はかなり良いと考えています。 Figma Config 2024でFigma AIが発表されていたように、今後デザイン・プロトタイピングでもより多くのシーンで生成AIが活用されていくと思います。 このとき、デザインシステムが存在することで一貫したスタイルのプロトタイプを高速に生成していけるようになり、 さらにCode Connectを活用することでデザインに対応する実装も同様に高速に生成していけるようになると考えています。 こうした未来に備えるべく、Code Connect を活用したデザインとコードの統合についても考えていきたいと思ってます。
おわりに
今回はSansanにおけるOneプロダクトのデザインシステム「One Design System」のこれまでとこれからについてお話しました。 One Design System v1リリースをしたという内容を書きましたが、デザインシステムは作って終わりではなく、作ってからが本当の始まりだと考えています。なのでこれからも「全ての人が使いやすいOneらしさを、効率よく提供できる触媒」になるべく、デザインシステムというプロダクトを成長させ続けていきたいと考えています。
Bill One開発Unitブログリレー2024もいよいよ次回でラストとなりました！！
今後の投稿についても引き続きXアカウント@SansanTechにて発信しています。ぜひフォローよろしくお願いします！！
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途・新卒採用向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話します。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
- T2D3とは、PMF（プロダクトマーケットフィット）の後に、3倍, 3倍, 2倍, 2倍, 2倍 (Triple, Triple, Double, Double, Double) でARRを毎年伸ばしていくことを指します。これはSaaSプロダクトの事業成長におけるベンチマークとされることが多いです。↩
- 当時の技術選定については「新規事業開発での技術選定の意思と意図 (フロントエンド編)」から確認できます。↩
