この記事はenechain Advent Calendar 2024の5日目の記事です。
はじめに
enechainでフロントエンドエンジニアをしている@Shunya078です！
enechainは、日本最大のエネルギー卸取引マーケットプレイスを運営するスタートアップです。我々ソフトウェアエンジニアは日々、プロダクトを通じてエネルギー市場に貢献しています。
社内には10を超えるプロダクトが存在しており、各プロダクト共通で利用されるデザインシステムが存在します。自分はこのデザインシステムに、チームをリードする立場として関わっています。
去年、なぜ我々はデザインシステムを創るのか？という記事でデザインシステムの生い立ちについて執筆しました。背景などについては是非そちらをご一読ください！
今回は、今年一年間のアップデート内容を振り返るととともに、現時点における我々のデザインシステムがどういうフェーズにあるのか、また今後どういった取り組みを行っていくのかをご紹介します。
JSConf スポンサーブースでの限定公開とLT
今年のJSConfにenechainはPremium Sponsorとして協賛しました。
スポンサーブースの展示として、デザインシステムの限定公開を行いました。 展示物としては、FigmaとStorybook、そして実際のコードと社内で使用しているスタイルガイドを選びました。
これまでデザインシステムのアウトプットを外部に公開したことは無かったので、初めてたくさんの方に見ていただける機会となりました。 スタイルガイドに関しては「参考にしたい！」という声や、Figmaの使い方に関してフィードバックをいただくこともでき、とても良かったです。
また自分自身もスポンサーLTとして5分のLTに登壇してきました。 先日リリースされたChakra UIのメジャーバージョンアップデートと、それに追従する意思決定をした内容をまとめて発表しました。
一年間のアップデート
ダークモード
enechainは2024年10月に、電力の卸取引をリアルタイムで実現するプロダクト「eSquare Live」をローンチしました。 enechainでは初めてダークモード対応したプロダクトになりましたが、一貫したUIを提供するためにデザインシステム側でもダークモードを機能として実装することになりました。
ダークモードを実装するにあたっては、デザインシステムとして提供しているコンポーネント単位での修正、またプロダクト側に入れた後での調整を何度も繰り返し行いました。
ギリギリまでデザイナーチームによるカラートークンの調整が必要だったものの、無事デザインシステムとしてのダークモード対応を目標としていた対応期日までにリリースできました。
具体的な背景や詳細は下記ブログに綴られています。
アクセシビリティ
ダークモード対応と同時期に、デザインシステムが提供するコンポーネントのアクセシビリティ対応も行いました。 チームの中に強くオーナーシップを持ってくれるメンバーがいてくれたおかけで、そのメンバーを中心に進めることができました。
守るべきアクセシビリティ項目のガイドラインを作成し、チェックリストとして該当項目が守られているかどうかを確認しました。 対象範囲としては、デザインシステムが持つコンポーネント全てとし、無事完遂できました。
enechainが提供するプロダクトでは開発要件としてアクセシビリティ対応が必要になったケースは未だありません。 しかし、プロダクト側はデザインシステムのコンポーネントを使うことで、一定のアクセシビリティ要件を守ることができるようになりました。
省庁や自治体の情報システムやウェブサイトは公共性が求められます。また、国の制度利用など代替のきかないものが多く、 できる限り多くの利用者がシステムを使ったり情報を取得したりできるようにすることが不可欠です
引用：ウェブアクセシビリティ導入ガイドブック | 1.1 背景と課題
今後enechainが提供するプロダクトはより多くの企業、多くのユーザーへ届けられることになります。デジタル庁のウェブアクセシビリティ導入ガイドブックにもありますが、デザインシステムレベルで一定のアクセシビリティ要件を達成しておくことによって、利用者により正しい情報を届けられると考えています。
そのため、「eSquare Live」がリリースされる前の段階でこの対応を終えられたのは、デザインシステムにとって大きなマイルストーン達成だったと考えています。
コンポーネントのデザイン/実装の乖離
日々の運用では逐次、社内で使用している「目安箱(目安箱についてはこちらの記事にて紹介)」からコンポーネントのアップデート依頼が届くようになっています。
課題に応じて実装、デザイン共にアップデートするのですが、自主参加の兼任メンバーを中心に構成されたチームであることや、メンバーのリソースの問題でアップデート自体が非同期になることがありました。
また、デザインシステムから提供されているコンポーネント数が増えることに比例して、デザインと実装の乖離が見られる箇所は多くなっていきました。
そういった課題に対して、「乖離」とは何であるかを定義し、どの程度の「乖離」であれば許容し、どうやって運用として回避するべきなのかについて議論しました。 議論の際にはデザイナーメンバーと、エンジニアメンバーとして自分が参加する週次の会議体を設定し、どう進めていくかを議論しました。
当時の意思決定やプロセス等は以下のブログに残っています。
やはり、運用フェーズに入ったプロダクトはどこかしらに綻び、健全ではない「負債」となる部分が発生します。 それはデザインシステムも同じで、常にプロダクト側が進化をするたびに完全であり続けることはできないと考えています。
乖離についての議論の時のように、我々は常に課題となる部分に真っ直ぐに向き合い、改善するべく動き続けています。
i18n
デザインシステムが提供するコンポーネントには少なからず「テキスト」を持っている場合があります。
例えばですが、内製して提供しているDatePickerには曜日などのテキストが含まれています。
プロダクト側の言語設定に合わせて、デザインシステムから提供しているコンポーネントもテキストを出し分ける必要があったため、i18nの対応を実施しました。
当初の想定では表示するテキストをプロダクト側から全て受け取るようにしてもいいのでは？というアイデアもあったのですが、
- プロダクト側の引数宣言が増えてしまう
- コンポーネント側で単語を持つケースが複数あった
という点を理由に、デザインシステム側でi18n対応を進める意思決定をしました。
なるべくプロダクト側でデザインシステムマターになる依存パッケージを増やさないように、そして機構としてはシンプルなI/Fで済ませるため、i18nの対応は内製しました。
また、Storybookで言語設定を出し分けた表示を確認できるようにもなっています。これにより、プロダクト側のメンバーやデザイナーにとってもテキストの表示を切り替えた際のUIがわかりやすくなっています。
eslint rule
デザインシステムのリポジトリではチーム内外問わずコントリビュートを歓迎しています。 詳細は下記ブログにまとめられていますが、実装時、コードレビュー時の迷いを極力減らすためにeslint pluginを利用することで、機械的に統制を取っています。
暗黙的なコード規則はチーム外からのコントリビュートが難しくなること、また明文化されていても認知不可が上がってしまうことから、それらを回避するために、デザインシステムチームでは積極的にカスタムルールを定義するようにしています。
デザインシステムの開発者体験向上の試みのブログは2024年6月の段階で執筆されたものですが、新たなルールもそれ以降追加されました。
今回はその中でも本ブログに関連したルールを2つほど紹介します。
- ダークモード対応時にデザイントークンの使用を強制
- 特定のpropsにデザイントークン以外の値は渡さないように
- i18n対応時に単語を宣言するファイルのルールを追加
- 全てのnamespace(en, ja, etc...)で特定のkeyの値が抜け漏れていないか
- 単語の宣言が抜け漏れているコンポーネントがないか
それぞれのルールは機能追加のタイミングで同時に導入されました。 実装時に悩んだ箇所や、運用観点で抜け漏れが発生しそうな箇所に関しては都度チーム内で相談し、ルールを導入する形を取っています。
バレルファイルの自動生成
以前まで、デザインシステムから提供するコンポーネントをexportする際は、作成されているコンポーネントをバレルファイルに逐一記載して配布していました。
しかし、この形式だと「A Componentを追加したけど、バレルファイル側に記載を忘れていた」という事象が度々発生していました。
もちろん、レビューの段階でexport漏れを防ぐように確認することはしていましたが、デザインシステムチーム側の開発運用方針として、ヒューマンエラーを極力防ぎ、仕組みに寄せるように考えることを大事にしています。
そのため、バレルファイルの手運用をやめ、リポジトリ内でexportされている定数・関数を収集し、バレルファイルを作成するスクリプトを用意しました。
これによって、実装者の記載漏れ、レビュー時の指摘漏れを防ぐことができ、運用を開始して以降は同様の課題が発生することは無くなりました。
また、現状のディレクトリ構成の都合上、プロダクト側には提供しない関数などもexportを付けることが発生します。その場合はignoreExportをJSDocの形式で記載することにより、バレルファイルへのexportは防ぐようにしています。
/** * @ignoreExport */ export const FooterComponent: React.FC<Props> = ({
component countの計測
enechainのデザインシステムはChakra UIをラップする形で作られています。しかし、プロダクト側から直接Chakra UIのコンポーネントを使用するケースもあります。
プロダクトからChakra UIのコンポーネントを直接参照した場合は、デザインシステム側が想定していない使用方法であったり、意図しないデザイントークンの渡し方が可能となってしまいます。それはUI/UXの共通化という側面では許可できない形です。
そのため、デザインシステムチームではプロダクト側で使用されているデザインシステムのコンポーネント数、また直接Chakra UIのコンポーネントを呼び出している回数の計測を開始しました。
component-rate = (デザインシステムのコンポーネント使用数) / (Chakra UI含めた同名コンポーネントの使用数)
直近(2024年11月末)計測を開始したばかりになるので、まだプロダクト側への改善活動には繋げられていないですが、この数値を元に、より「使われている」デザインシステムにしていく活動を進めていくことを計画しています。
現在のフェーズを分析
ここまでは直近のアップデート内容などを振り返りながら、まとめていきました。 ここからは、現状のデザインシステムのフェーズを自分なりの理解でまとめていこうと思います。
リリース頻度は落ち着いてきた
今年に入ってから、9月末頃までは毎週2~3回ずつのペースでリリース作業が行われてきました。
そのため、9ヶ月でおよそ100近いリリースが行われ、アップデートを重ねてきました。
commit回数になるので、あくまで参考程度にはなりますが、おおよそアップデート頻度に見合ったグラフの動きになっていると感じます。
しかし、上述した「eSquare Live」のリリースがあった10月前半を節目に、社内における新規機能開発がやや落ち着いてきたことに伴って、デザインシステム側のアップデート頻度も少なくなってきています。
これは上記のグラフにも数字として明確に表れているように見えます。
自分から見て、デザインシステムが提供しているコンポーネント数も一定数を超え、デザイントークンの整備も一定完了した、ということがリリース頻度と相関を持っていると考えています。
All Handsでも取り上げられるように
「All Hands」と呼ばれている全社員参加の会議の中で、有志で進めている我々のデザインシステムが取り上げられました。
自分達からの発信以外で話に上がる、紹介されてロードマップに組み込まれる、ということは今までありませんでした。チームで度々話に上がっていた、「会社としてデザインシステムを自分ごと化してもらう」ことに少しでも近づいたことを実感し、とても嬉しい反響であったと感じました。
これから
「育てる」のフェーズへ
現状を鑑みると、運用から正式に一年半弱が経過して、我々のデザインシステムは「創る」フェーズを脱却しつつあるのかな、と自分は考えています。
去年のブログでは
プロジェクトとして目指したいのは 「我々のデザインシステムを使えば、誰でも迅速に届けたい価値を提供出来る」 ことでした。
と記載しましたが、このスタンスは全く変化のないものです。
ですが、明確に一年前からの変化と言えるのは「できないことをできるようにする」価値の創出の仕方から、「長く向き合っていく」ための価値を考えるようになったことです。
我々デザインシステムが向き合うべきユーザーはプロダクトの開発者であり、さらにはそのプロダクトを使用する真のユーザーです。
ユーザーへ価値提供することをプロダクトの本質であると考えると、デザインシステムというプロダクトは、プロダクトに使われている状態は当たり前にあるべき。その先に、プロダクトのフェーズに寄り添った提案ができる、また価値を実現するために互いに会話できること、がより重要であると思います。
プロジェクト発足から今までの期間で我々のデザインシステムは、社内ほぼ全てのプロダクトに導入してもらい、「まず使われる」ことを実現してきました。
では、今後我々がさらなる価値を生み出すために考えていかなければならないことは何か。それは、どうやって使われているプロダクトと向き合い続けていくか、どうやって「長く向き合っていくか」だと思います。
では向き合い続けるためには何ができるのか？プロジェクトとしてどう動かし、どう進化させていくのが良いのか？を自分は最近考え続けています。フェーズは変われど、やることはまだまだありますし、やりたいこともたくさん残っているので、1年経っても自分はワクワクしていると改めて強く感じています。
おわりに
今回の記事では、我々が作っているデザインシステムのアップデートと今後どうしていくのかを紹介しました。
最後のこれからの章では自分自身が考えていることをやや冗長になりながらも記載しました。昨今のパラダイムシフトとして、世界に様々なデザインシステムが確立されている中で自分達のデザインシステムがどうありたいのか、について自分の考えをそのままに書き出しました。
本ブログの内容が、デザインシステムという名前のプロダクトにおける進め方であったり、考え方の助けに少しでもなれば幸いです。
enechainでは、共にプロダクトを共創していく仲間を募集しています。要項は以下からご確認ください！
