急成⻑プロダクトで⼩さく始めたデザインシステムの取り組み

■イベント
プロダクトの急成長を支えるフロントエンド改善の取り組みhttps://sansan.connpass.com/event/305970/

■登壇概要
タイトル：急成⻑プロダクトで⼩さく始めたデザインシステムの取り組み
登壇者：技術本部 Bill One Engineering Unit　江川 綾

■Bill One エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

Transcript

1. Sansan株式会社 部署 名前 急成⻑プロダクトで⼩さく始めた デザインシステムの取り組み Sansan技術本部 Sansan技術本部 Bill One Engineering Unit 江川 綾
2. 写真が入ります 江川 綾 Sansan株式会社 技術本部 Bill One Engineering Unit 2021年 Sansan新卒⼊社。 ⼊社以来、Webアプリケーション開発エンジニアとして インボイス管理サービス「Bill One」の開発に従事。 現在は、Bill Oneにおけるインボイスネットワークの拡⼤に向けた 開発に加えて、フロントエンドの技術的な改善をリードしている。 @er11161 @erm1116
3. アジェンダ - Bill One開発組織と急成⻑の中で⽣まれたフロントエンドの課題 - デザインシステムを⼩さく始める - ⼩さく始めたデザインシステムのこれから - まとめ
4. Bill One開発組織と 急成⻑の中で⽣まれたフロントエンドの課題
5. Bill Oneは、Sansan株式会社が提供するインボイス管理サービスです。 郵送やメールといったさまざまな⽅法・形式で届く請求書をオンラインで⼀括受領し、素早く正確にデータ化。請求書を クラウド上で⼀元管理することで、アナログで⾮効率な請求書業務をデジタル化します。インボイス制度や電⼦帳簿保存法にも対応し、⽉次決算業務 を効率化することで、企業経営における意思決定のスピードを加速します。 ※⽉次決算業務 毎⽉の営業成績、財政状況を明らかにするために⾏われる業務。経理担当者が⾏う業務で、毎⽉の数字の締め処理作業として発⽣します。
6. - T2D3 (Triple, Triple, Double, Double, Double) というベンチマークを意識 し、今期末に ARR75 億円越えを⽬指す プロダクトの急成⻑ 5 ⽬標値
7. - PMFまでは約5名 - PMF後は3年で約10倍の開発組織に成⻑ Bill One開発組織の成⻑
8. - React + TypeScriptでシンプルなSPA - 開発チームはフィーチャーチームで構成されている - 基本的にメンバーはサーバーサイド〜フロントエンド、インフラまで開発 - メンバーは必ずしもフロントエンドに精通しているわけではない Bill One開発組織におけるフロントエンド
9. - 採⽤していたコンポーネントライブラリのスタイリングにおける課題 - ライブラリで提供されているコンポーネントにおいて、 詳細度⾼いCSSがあたっておりカスタマイズしづらい - 意図したスタイル適⽤のために !important や詳細度上げるハックが 使われていたりする - カラーコードやスペーシングなどがハードコードされている - ページやコンポーネントごとに微妙に異なるカラーが利⽤されていたりする - エンジニア・デザイナーの間で認識齟齬が発⽣ - 両者間で共通コンポーネントへの理解がずれており、 どのコンポーネントを共通とするのか・再利⽤すれば良いのかが判断がつき づらい 急成⻑する組織で⽣まれてきた課題
10. まとめると - UIにおけるスタイルの⼀貫性がなくなりつつあった - 開発に関わるメンバー増加により、 共通コンポーネントの定義やスタイリング⽅法に関するコミュニケーシ ョンコストが増⼤し、開発効率の低下が問題になってきた 急成⻑する組織で⽣まれてきた課題
11. デザインシステムを⼩さく始める
12. 必要な「デザインシステム」はプロダクトや組織によって異なる まずはデザインシステムへの期待値を明確にし、 重要度の⾼い部分からはじめて、徐々にプロダクトに適⽤していく デザインシステムを⼩さく始める デザインシステム デザイン原則 ブランドアイデンティティなど 機能パターン コンポーネント実装など 認知パターン スタイルガイドなど 共通⾔語 ⽤語・ボイス＆トーンなど
13. 1. 「デザインシステム」への⽬線を揃える 2. まずはデザイントークンからはじめる 3. デザイン原則について考えてみる 4. コンポーネントを整理する 5. UIコンポーネントを実装し、利⽤していく ⼩さく始めるためのステップ
14. 1. 「デザインシステム」への⽬線を揃える 2. まずはデザイントークンからはじめる 3. デザイン原則について考えてみる 4. コンポーネントを整理する 5. UIコンポーネントを実装し、利⽤していく ⼩さく始めるためのステップ
15. まずは前提知識と共通⾔語を揃える⽬的で「Design Systems」読書会を実施 - プロダクトにおける 機能パターン・認知パターンについて考える - プロダクトの「らしさ」を考えることの重要性 これを踏まえて 「デザインシステム」への期待値を定める 「デザインシステム」への⽬線を揃える Design Systems デジタルプロダクトのためのデザインシステム実践ガイド
16. 「デザインシステム」への期待値 全ての⼈が使いやすい「Bill Oneらしさ」を、 効率よく提供できる触媒となる 全てのユーザーが使えるBill Oneらしさを提供できる基盤を作る エンジニア・デザイナーにおける共通⾔語を作り、コミュニケーションを促進させる
17. - プロダクト開発で、 - 開発/デザイン速度向上・効率化 - コミュニケーション・共通⾔語の定義 - ユーザーに対して、 - ユーザビリティ・アクセシビリティの担保 - ブランドの表現（らしさを表現する） - デザイン・体験の⼀貫性を提供 「デザインシステム」への期待値
18. 1. 「デザインシステム」への⽬線を揃える 2. まずはデザイントークンからはじめる 3. デザイン原則について考えてみる 4. コンポーネントを整理する 5. UIコンポーネントを実装し、利⽤していく ⼩さく始めるためのステップ
19. - デザイントークンは各コンポーネントで利⽤される＆ 共通コンポーネント以外でも利⽤される - 明確な課題もあったのでまずはデザイントークンからはじめた - Token Studio for Figma (Figma Tokens) でトークンを定義し、 Style Dictionaryで実装側で利⽤できる形に変換 - 各種トークンについて、Primitive TokenとSemantic Tokenを定義 - 実装側はJSONで出⼒されたトークンを参照する まずはデザイントークンからはじめる Style Dictionary Tokens Studio for Figma デザイントークンを Figma上で作成・管理・使⽤ デザイントークンを SassのVariablesに変換
20. 1. 「デザインシステム」への⽬線を揃える 2. まずはデザイントークンからはじめる 3. デザイン原則について考えてみる 4. コンポーネントを整理する 5. UIコンポーネントを実装し、利⽤していく ⼩さく始めるためのステップ
21. Bill Oneというプロダクトの「らし さ」について話し合った - エンジニア・デザイナー・PdM・ BXのメンバーで議論を実施 - ブランド・アイデンティティ・プ リズムを利⽤ - 誰に何を提供するプロダクトなの か？ - プロダクトはユーザーにどういう 関わり⽅をするのか？ （どういう体験を提供するのか） デザイン原則について考えてみる
22. ⼩さく始めるためのステップ 1. 「デザインシステム」への⽬線を揃える 2. まずはデザイントークンからはじめる 3. デザイン原則について考えてみる 4. コンポーネントを整理する 5. UIコンポーネントを実装し、利⽤していく
23. プロダクトで既に利⽤されている機能パターンを抽出し整理 改めて共通で定義するパターンについて以下を定義 - 名前 - パターンの役割 - 仕様（構成するパーツやバリエーションなど） - 利⽤時のガイドライン（アクセシビリティ上の注意点なども含む） - …etc コンポーネントを整理する
24. 1. 「デザインシステム」への⽬線を揃える 2. まずはデザイントークンからはじめる 3. デザイン原則について考えてみる 4. コンポーネントを整理する 5. UIコンポーネントを実装し、利⽤していく ⼩さく始めるためのステップ
25. - UIコンポーネントをnpmパッケージで配布 - コンポーネントは Chromatic にて確認できる状態になっており、 実装時にはデザイナーレビューも⼊ってもらっている - 各コンポーネントではインタラクションテスト/VRT/a11yテストを実施 - 今回の主題でないので割愛するが、Panda CSS + Ark UIで実装している UIコンポーネントを実装し、利⽤していく
26. ⼩さく始めたデザインシステムのこれから
27. - Sansanには One と名のつくプロダクトが複数ある - もともとBill Oneのデザインシステムとしてスタートしたが、 改めてOneプロダクトとして合流し、⼀緒にデザインシステムを作っている - 各プロダクトで使えるデザインシステムづくりをやっていく - デザイン原則の⾒直しもやっていく - コンポーネントの運⽤周りは課題 - 今はデザシス開発チームが横串で開発している - 今後は各プロダクトチームも⼀緒にデザシス改善をしていけるようにしたい ⼩さく始めたデザインシステムのこれから
28. まとめ
29. - プロダクトの成⻑に伴い、 UI/UXの⼀貫性・フロントエンドの開発効率において課題が⽣まれてきた - 使いやすいところから作っていく。 Bill Oneの場合はデザイントークンから整備していった - 今後は複数をプロダクトまたいで利⽤されるデザインシステムづくりに 向き合っていく まとめ