Zenn
レバテック開発部
⚡

レバテックのデザインシステム「VoLT」が爆誕しました

かわうそ
2024/04/15に公開
Figma
Storybook
デザイン
デザインシステム
デザイントークン
idea

はじめに

レバテックCTO室でテックリードを担当しているかわうそ(河村)です。

今回は レバテックのデザインシステムとして「VoLT」 が爆誕したので、構築した背景や目的、どのようにデザインシステムを構築したのかについてお話しようと思います。

ただし、レバテック規模のデザインシステムを作るのには様々な努力、工夫が必要であり、
本記事のみですべてをお伝えするのは難しいので、すごーーーく簡単にお伝えします笑

これから「VoLT」に関わる記事はたくさん出てくると思うので楽しみにしていてください✨

※ レバテックのデザインシステムである「VoLT」は現在も絶賛構築中です！
※ 今回はある程度の基盤まで完成したので、その情報の共有です！

追記（2024/05/10）

記事作成後にレバテックデザインシステム「VoLT」が公開されました✨
https://note.com/leverages_design/n/n5e2a397602ba
https://www.figma.com/community/file/1369568511902711961/voltlevtech-design-system

「VoLT」とは

「VoLT」とはレバテックにおけるデザインシステムの名称です。

「VoLT」とは

【命名理由】

  • 電気が通ると機械が動くように、レバテックを前進させる力になる
  • 名前に「LT（LevTech）」が含まれている
  • 読みやすい覚えやすい

こんな感じで命名も社内で募集して決めました（8千億件近い何件かの応募がありました）

なぜ、デザインシステム構築を進めたか？

レバテックの大きな課題として以下のような課題があります。

  • 各サービス・プロダクトで構築しているデザインがバラバラの状態
    • ユーザーはサービス・プロダクトの構造や機能をその都度理解する必要がある
    • そのため、必要な情報を得たりアクションを行うのに時間がかかる
  • デザインや開発の更新に手間のかかる状態
    • 同じデザインのコンポーネントをサービスを跨いで複数作成
    • 対象のコンポーネント(ロゴやフッターなど)をまとめて更新しようと思ってもすべてのサービスと関係者と調整が必要

まとめると、
効率性/一貫性が低く、それに伴い関係者とのコミュニケーションコストが高いという状態でした。

そこで、以下のデジタル庁のデザインシステムを参考に目的を掲げて、デザインシステムの構築を行いました。
（デザインシステムを構築していく上でめちゃくちゃ参考にさせてもらってます🙏）

デジタル庁のデザインシステムより抜粋

レバテックにおけるデザインシステムの難しさ

マルチプロダクト

現在、レバテックはITエンジニアのフリーランス・転職を中心に様々なサービス・プロダクトを展開しています。

事業ポートフォリオ

複数のサービス・プロダクトの基盤となるデザインシステムを作るにはとてもコストがかかるものです。
その要因として挙げられるのが以下になります。

  • 一貫性の維持
    • 複数のサービス・プロダクトで一貫性のあるデザインを提供することは容易ではない
    • 各プロダクトが異なるユーザー体験やデザインのニーズを持つ場合、それらを調整して一貫性を確保する必要がある
  • 拡張性の担保
    • デザインシステムは、サービス・プロダクトが成長するにつれて拡張性も必要
    • 新しい機能や要素が追加されるたびに、デザインシステムもそれに対応できるように設計する必要がある
  • ステークホルダーの調整
    • デザインシステムを構築する際には、複数のチームやデザイナーとの協力が必要
    • 異なるチームや個人の間でのコミュニケーションや調整が必要
  • リソース
    • デザインシステムを構築するには、十分なリソースと時間が必要
    • それぞれのサービス・プロダクトのニーズに合わせるため、十分なリソースを投入する必要がある

構築がある程度、進んできたからわかりましたが、一貫性と拡張性のバランスを取るのは本当に難しいなと思いました。

拡張性を優先するために「このコンポーネントの要素を外から変更できるようにしたい」「でもそうすると一貫性がなくなる可能性があるからできれば変更できないようにしたい」みたいなことはたくさん発生しました。

そこで設けたのが 「インスタンスガイドライン」 です。デザイナーとエンジニアでコンポーネントごとにインスタンスガイドラインをすり合わせながら進めています。
（あるコンポーネントのインスタンスガイドラインの一例をチラ見せします）

インスタンスガイドラインの一例

マルチフレームワーク

レバテックでは、フロントエンドにおいて以下の技術スタックを採用しています。

まったく実装方法が異なるライブラリ・フレームワークをサービス・プロダクトごとでそれぞれ採用しているため、どちらにも対応させるデザインシステムを作ることはとても大変です。
（巷ではVue.jsはJavaScriptフレームワーク、ReactはJavaScriptライブラリみたいですね）

Headless UIのようなスタイルを持たないUIコンポーネントを提供する形にできれば、たしかにハイブリッドな運用は可能かもしれませんが、今回は機能とアクセシビリティだけでなくデザインの一貫性を担保する必要があったため、採用しませんでした。

結果的には、Vue.js × React × Monorepoの構成で作成しており、共通のスタイル部分は共通パッケージを参照するようにしています。少しでも開発コストを削減できるようMonorepoを採用しました。

（この辺のお話はまた別の機会でお話します📝）

どうやって、デザインシステム構築を進めたか？

1. 関係者を集める

まずはレバテック全体のデザインとシステムを把握できているメンバーを集めました。
なにより進められる体制を作らないと進まないのがレバテック規模におけるデザインシステムなので、とにかく関係者を最初に集めるを優先しました。

その上で重要視していたのがデザインシステムの必要性を肌で実感している人です。つまり、デザインシステムを構築することにモチベーションが高い人です。この規模でデザインシステムを構築するのはあまりにも大変なプロジェクトでもあるのでモチベがないとやっぱりきついと思いましたw
（現在は違いますが、所属しているサービス・プロダクトと兼任で入ってもらったのでそりゃもう...ｗw）

2. 土台をしっかり固める

この規模のデザインシステムで目指す世界観や方向性がぶれてしまうと、全くユーザー（デザインシステムの利用者）から使われなくなってしまう可能性もありますし、まったく効果が得られない可能性があります。なので、土台をまずはしっかり固めるというところはかなり力を入れました。

例えば、以下のような部分です。

  • デザインシステムの目指す世界観
  • デザインシステムの原理・原則
  • デザインシステムのベースとなるデザイントークン
  • デザインシステム化する場合のガイドライン

知っている方々も多いと思いますが、Tokens Studio(Figma Tokens)を使えば、Figmaだけでは実現が難しいColorやBorderの管理がサクッとできちゃいます。また、色、タイポグラフィなどをデザイントークンとして定義して使用できて、JSONベースで吐き出すこともできるので、めちゃくちゃ便利です。
（参考：Tokens Studio(Figma Tokens) で小さくはじめるデザインシステム）

また、token-transformerとstyle-dictionaryを利用することで、システム側でも使いやすい状態に変換することができます。JS(cjs,esm) / TS(d.ts) / SCSSの形式に変換することができるので、これだけでも十分にデザイナー・エンジニア双方にメリットがあるなと感じました。
（参考：【Figma Tokens × Style Dictionary】デザインシステムはじめの一歩）

さらに、style-dictionaryは以下のように変換時の拡張も可能なので、よりデザイントークンを使いやすい状態にすることもできたので、とても助かりました。
（【Style Dictionary】Transforms / Formats まとめ）

style-dictionary.config.js
...
StyleDictionary.registerTransform({
  name: "shadow/scss",
  type: "value",
  matcher: (prop) => {
    return prop.path[0] === "boxShadow";
  },
  transformer: (prop) => {
    const [
      { x: x1, y: y1, blur: blur1, spread: spread1, color: color1 },
      { x: x2, y: y2, blur: blur2, spread: spread2, color: color2 },
    ] = prop.original.value;
    const rgbColor1 = tinycolor(color1).toRgbString();
    const rgbColor2 = tinycolor(color2).toRgbString();
    return `${x1}px ${y1}px ${blur1}px ${spread1}px ${rgbColor1}, ${x2}px ${y2}px ${blur2}px ${spread2}px ${rgbColor2}`;
  },
});
...

（この辺もまた別の機会でお話します📝）

3. キックオフをやる

この規模のデザインシステムで次に重要となるのが協力者をとにかく増やすことです。デザインシステムを構築してもサービス・プロダクト側で利用されなかったら元も子もないです笑

そこで、大々的にキックオフをやりました。キックオフを通して多くの人にデザインシステムの必要性を伝えるとともに実現できたときの世界観を伝えてモチベーションを少しでも上げてもらえるように頑張りました。

デザインシステムキックオフ

4. オンボーディングをやる

協力者をとにかく増やすから利用してくれる人を増やすためにデザイナー向けと開発者向けのオンボーディングをそれぞれ実施しました。

どれだけ便利になったのかを伝えるとともに、ユーザー(デザインシステムの利用者)からのフィードバックを速く得るためにも実施しました。

やっぱり、ユーザー(デザインシステムの利用者)に対して共有してみると、「デザイントークンにないカラーを使いたいときはどうすればいいですかー？」や「このコンポーネントを追加したいときはどうするんですかー？」などの声も聞こえたり、いまいち運用に乗せていないのでピンと来ない方々もいたので、まだまだ課題はあるなと感じることができました。

デザイナー向けオンボーディングの概要

これからどうしていくのか？

2024年度のロードマップ作成

1年後の2025年4月までに「今の半分のコストで機能・施策がリリースできる」 状態を目指して動き始めています。そのために、各サービス・プロダクトでどういう状態であったら可能か、そのために何やるべきかの定義を進めていきます。
（まだまだ未確定なところが多いのでこの辺はさらっと流します笑）

デザイントークンの精査とコンポーネントの拡充

まだまだ運用に乗せていくにはデザイントークンも精査する必要がありますし、足りないコンポーネントはどんどん追加していかないと、ユーザー(デザインシステムの利用者)の満足度は全然挙げられません。

現時点でもすでにカラーシステムの刷新を行っています。共通カラー部分の命名が誤解を招く構造になっていたり、カラーの種類が多すぎて使いづらいといった問題があり、改善を行っています。
（やっぱり、いざ使ってみるとなんだかんだうまくいきませんね笑）

また、コンポーネントは全然足りません笑
ここから少しづつ必要なものをコンポーネント化していく予定ですが、重要となるのは優先度かなと思っています。ユーザー(デザインシステムの利用者)に全然利用される頻度が低いコンポーネントを作成していっても効果は少なくなってしまうので、デザイナーとエンジニア双方で相談しながら優先度を決めています。

実際に今あるコンポーネントはこれぐらいしかありません😢（まあこれからですｗ）

Storybook上にある現在のコンポーネント

サービス・プロダクトに反映して仮説検証を回す

デザインシステムは構築したものの、サービス・プロダクトにはまったく反映できていないので、"ここからが勝負"だと思っています。

サービス・プロダクトに反映したら（しようと思ったら）たくさんの課題が出てくるはずです。

だからこそ、必要最低限で少しでも使ってもらえる機会を増やして、早く理想のデザインシステムに近づけるよう進めていきたいなと考えています。

外部公開できるものから進めていく

SmartHRのSmartHR Design SystemやAmebaのSpindle、デジタル庁のデザインシステムなどなど、ほとんどのデザインシステムが外部に公開されています。

もちろん、技術広報的な目的もあると思いますが、世の中のユーザーからもフィードバックを得られると考えたら外部公開するのはめちゃくちゃ大事なことだと思っています。

レバテックもデザインシステムを外部公開するため、順次FigmaやStorybookから公開していく予定です。

副次的な効果

実際、デザインシステムを構築してみて、目的にはなかったけど良かったこともあるので、雑になりますが残しておきます。

  • 現状のデザインがどこでどのように管理されているか把握することができた
    • 全体を整理を進める中で「このサービスのデザインってどうなってるっけ？」など
    • （ずさんな管理になってしまっていたものとちゃんと向き合うことも大事です）
  • 普段、関わることのないメンバーの交流が進んだ
    • サービス・プロダクトごとにデザイナー・エンジニアは分かれているので、今まで接点がなかった
    • 今回のデザインシステム構築PJに伴い、デザイナー・エンジニアの交流が進んだ
  • デザインシステム構築PJに伴い、レバテックに関わるデザインとシステムを統括するチームができた
    • これにより、デザインやシステムの要望や相談を一箇所に集めることができた
    • また、デザインの管理方法やシステム側の設計方針などの統制もできるようになった

（困ったらここに頼ってができる体制ってやっぱ大事だなと改めて感じました😇）

さいごに

今回はレバテックのデザインシステムとして「VoLT」が誕生したので、構築した背景や目的、どのように構築したのかについてお話しました。

ここまでたくさんの努力と苦労がありましたが、「VoLT」はこれからが勝負です。実際にサービス・プロダクトに反映していく中で出てくる課題と向き合いながら、理想のデザインシステムを追い求めて頑張っていこうと思います。

またこの記事をきっかけに他社のデザインシステム化もより進んで、いろんな取り組みや事例が増えてくれるといいなって思っています。この辺を進めるにあたって情報が足りないな〜と思うことが多々ありました。

自分たちも世の中のデザインシステムで困っている人たちのためにも、貢献できたらなと思っています！
この記事でふれられなかったことがたーくさんあるので、今後、様々な取り組みや事例を紹介していく予定です！

裏話

実はというところで、最後に裏話だけ残しておきますｗ

  • レバテックの共通コンポーネント(今でいうデザインシステム)を作りたいという思いは3年前ぐらいからあった
    • ちょうど自分が転職してきた時点でデザインとシステムの連携部分にたくさんの課題があった
  • この規模でデザインシステムを作るのは相当な労力が必要だとわかっていて、現実逃避してきた
    • いやこれ絶対大変だよなぁという想いから、現実から目を逸らしてきたｗ
  • ただ今なら進められると思った
    • デザイナーとエンジニアの協力体制
    • 双方のデザイン/システム理解
    • スキルの高いメンバーの増加
  • これらが揃った今ならできると思い、デザイナーのリーダーと相談して進めました😊
レバテック開発部
レバテック開発部

レバテック開発部の公式テックブログです！ レバテック開発部 Advent Calendar 2024 実施中: qiita.com/advent-calendar/2024/levtech

Discussion