こんにちは、クライアント開発チームの石岡です。やっと暑さが落ち着いてサウナに入って外気浴も気持ちいい季節になり始めて嬉しさを感じています。 私が所属するチームが開発しているクライアントポータルというプロダクトでは、フロントエンド開発の技術にnuxt, vue3 デザイナーとの連携ツールにstorybookを導入しています。 バージョン クライアントポータルはリニューアルから1年が経過しましたが、開発現場ではstorybookがUIカタログとして十分に活用されていないのが現状でした。 これらにより、スタイルの再利用やデザインの一貫性が保ちにくいことや、テストの工数などもかかり、開発プロセスの効率が低下が懸念されます。 デザインツールはFigmaを利用しており、Figma上もコンポーネントを作成しており、それを元に実装上のコンポーネントが作成されています。 細かいですが、実装上のコンポーネントの定義は props の定義名もFigmaと同様の名称になるようにしています。コミュニケーション時の名称のズレにより齟齬を生まないためです。
また、それぞれのコンポーネントのstoryはstorybookを見ることで仕様を把握しやすい様に、パターンとそのコンポーネントが持つ状態を網羅できるように作成しています。
コンポーネントだけではなくセマンティックトークンも見える化できるようにstorybookにトークン用のページを用意し、可視化しました。 これにより実装を確認することなく、実装上に定義を確認することが可能になりました。また、ドキュメントとしての役割も担っているので、開発側もトークンの意図を把握できるようになり、より実装上の定義もデザインと連携されていることを意識し、実装とデザインとの乖離を抑制できることも期待しています。
unocssとscssで定義しているセマンティックトークンを定義しているので、実装者がルールを厳密に意識しなくてもルールに準拠したものを実装しやすくするため linter(stylelint) を導入し定義可能なスタイルを制限しています。
これで複数人で開発しても属人化を防ぎコードの統一が図れるようになります。 現在、クライアントポータルのstorybookは一部のコンポーネントに限られており、具体性の高いコンポーネントについては手動でのテストに依存しています。これにより、実装に変更が加えられた際にはデザイン側でのテストコストが増加し、開発側でもテストケースの作成に時間と労力がかかっています。 これらの課題を踏まえ、今後はstorybookをどう活用していくかを検討しつつ、保守コストとのバランスを取ることが求められます。効率的にコンポーネントの検証やテストを行える仕組みを作ることで、デザインと実装の一貫性を保ちながら、最適化を図っていくか考えていきたいと思っています。 今回は、陽の目を浴びていないstorybookをどうにか価値を見い出したいと思い取り組みましたが、残念ながらプロダクトが置かれている状況や、コストの関係もあり中々思うような改善には至りませんでした。（コードの統一とデザインと実装の認識のずれを無くすといった部分では一定の効果があると思っています） 地道な改善を尽くしながらプロダクト開発に関わる人が少しでも快適に仕事ができる様になればと思い、今後も取り組んでいきたいです。 ビザスクではエンジニアの仲間を募集しています！
少しでもビザスク開発組織にご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
developer-recruit.visasq.works
はじめに
今回は、クライアントポータルの開発プロセスで、デザイン側とより連携しやすく開発しやすくするためにどうstorybookを活用していくかを考え、今回行ったことと今後の課題についてお話しできればと思います。
背景と課題
また、今までデザインで定義しているセマンティックトークンの利用はプロダクトとして、利用を推奨事項に留めていた経緯もあり、最終的な利用の判断は各実装者に委ねられていました。なので、どの場面でどのトークンを使うべきかが不明確となり、結果としてコードの可読性や保守性が低下しています。
storybookをうまく活用できていないので、デザイナーが実装を確認する手段は、開発環境で実際にできた画面を確認してもらう形になっていますが、網羅的に確認するにはコストが高い状況になりますし、また、確認コストが高い分デザイナーと開発者の間に認識のずれが生まれやすく、コンポーネントの仕様のズレを生んでしまう原因にもなり得るかと思います。
こうした課題を解決するために、デザインと実装のギャップを埋めるツールとしてstorybookをより有効に活用し、デザイン側も実装側も明確なルールを定義して守っていく必要があると考えています。今回やったこと
コンポーネントの整備
セマンティックトークンを見える化
実装上の制限
今後の課題
今後、より具体性の高いコンポーネントも含めてstorybook上に整備し、利用可能なパターンを定義して網羅性を担保することで、デザインと実装の整合性を保ちやすくなり、コラボレーションの質を向上させることが期待できます。
しかし、それに伴いstorybookの保守コストも増加することが懸念されており、特にコンポーネントの追加や変更に合わせた更新作業の負担も大きくなります。最後に
ですが、状況を見極めて利用できればstorybook自体は多様な可能性を秘めるツールであることは間違いないと思っています。
