こんにちは、カイポケ開発部の城内と、株式会社グッドパッチUIデザイナーの乗田拳斗です。
現在、エス・エム・エスはグッドパッチと介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトを行っています。今回は本リニューアルプロジェクトにて行っているエンジニアとデザイナーの連携についてご紹介します。
エス・エム・エスとグッドパッチの取り組みについてはこちらのブログもご覧ください。
背景
カイポケは15年以上の歴史の中で介護事業のさまざまなサービス種類に対応を進め、現在は4万を超える事業所へサービスを提供しています。
高齢化が進む日本社会では、介護領域の制度改正やそれに伴う現場対応など、目まぐるしい変化が起こり続けており、こういった介護業界の変化や数年に一度行われる法改正へ対応していくことが求められます。
カイポケはモノリシックなアプリケーションとして構築されてきたので、拡張に次ぐ拡張でさまざまな機能が複雑に絡み合う大きなプロダクトになっています。今のカイポケは現在の介護事業を支えるプロダクトになっていますが、長期的なタイムスパンでこれらの法改正などの要望に応えていくことを考えた場合に、より良いシステムのアーキテクチャにすべく改善プロジェクトのチームで検討を重ねてきました。
これらの背景から、システムを改修する際の修正範囲の局所化と新しいサービス種類への対応などといった拡張性の担保、生産性向上のための並列性の確保を目的にマイクロサービスアーキテクチャへ移行を進める「カイポケリニューアルプロジェクト」を取り組んでいます。
カイポケリニューアルプロジェクトの詳細やフロントエンドチームの技術選定についてはこちらのページと記事をご覧ください。
デザインシステム
現在のカイポケは1000ページ以上ある大規模なプロダクトです。長年の機能追加によって改修の影響範囲が見えにくくなり、部分的な改修が続いた結果、全体的に一貫性が損なわれ、少しずつ機能が異なる同じようなページが増えていきました。
今回の改善プロジェクトではこの1000ページ以上のユースケースを整理し、プロダクトの構造を再設計しながらページ数を削減する作業を行いました。
一方、現在のカイポケと同様に機能追加によってページが増えることが想定されるため、さまざまな変更が行われても一貫したUIを維持するための仕組みを構築する必要がありました。
そこで、今回のリニューアルプロジェクトは大規模なプロダクトを円滑に開発し、将来の運用コストも下げるために「デザインシステム」を構築しながら行いました。
プロジェクトチームではデザインシステムがチームとプロダクトの利用者の双方に価値をもたらすために、デザインシステムを構築・運用する目的を3つ設定しました。
- 作業の効率化
- 意思決定の効率化
- 価値の最大化
これらの目的を達成するために、まずは最も多くのメンバーに価値をもたらすプロダクトのコンポーネントライブラリから構築を開始しました。
デザインシステムの構成や方針については、こちらの記事もご覧ください。
Figmaライブラリ
コンポーネントライブラリを用意するに際して、従来からUIデザインに使用していたFigma上でライブラリの構築を開始しました。
まずはデザインとフロントエンドとの連携を強化し、作業と意思決定の効率化を達成することを目的に、基盤に据えるフロントエンドライブラリの選定からスタートしました。後述する選定プロセスの結果、フロントエンドライブラリにChakra UIを選定しました。
実際にコンポーネントを設計するフェーズでは、Chakra UIのAPI仕様書やソースコードを参照しながら、チームで用意したいコンポーネントがChakra UIで提供されている場合はそのコンポーネントのプロパティ名やエレメント名に準拠したり、フロントエンドエンジニアと議論を重ねながら構築を行いました。
テーマ（デザイントークン）についてもコンポーネントと同様に、Chakra UIのテーマの構成を参照しながら、カイポケのブランドに沿ってカラーやタイポグラフィ、Border Radiusなどの定義を行いました。
デザイナーがフロントエンドライブラリを確認して、その内容に合わせながらFigmaライブラリを構築するプロセスは決して簡単なものではありませんでした。
一方でその成果として、フロントエンド側との連携が強固なFigmaライブラリを構築することができました。エンジニアと共創する際には共通のコンポーネント名やそのプロパティ名を使用して齟齬なく会話ができる他、UIデザインを実装したり、その成果物をレビューする際にも要素を読み替えることなく連携できるため、作業と意思決定の効率がリニューアル前に比べて格段に向上しました。
Chakra UIの選定
デザインシステムのフロントエンドの開発は2022年から開始しました。デザインシステムを実装するにあたり、0から自分たちでコンポーネントを実装する方法もありましたが、開発効率と品質向上のため、既存のUIライブラリを活用する方針を選びました。その中で、UIの一貫性とアクセシビリティ、広く使われていて開発速度を優先するという当時の要件に最もマッチしていたことから、Chakra UIを選定しました。
※この記事執筆現在、Chakra UIはv3系がリリースされていますが、選定当時はv2系でしたので、これから記載する内容はv2系を前提としたものになります。
主な理由としては以下の点が挙げられます。
- 標準でモーダルやテーブル、レイアウト系のコンポーネントが整っている
- カラーやタイポグラフィ、スペーシングの値などのデザインルールが定義されている
- アクセシビリティが考慮されている
- Propsでスタイルを記述できて、拡張が容易
- Figmaが提供されている
特に優れていると感じたのは、Propsでスタイルを直接指定できる点と、テーマの管理や拡張が非常に簡単でスマートな点です。この機能により、デザインの一貫性を維持しつつ、開発スピードが大幅に向上しました。
Chakra UIの各コンポーネントは、デフォルトのスタイルを持ったUIライブラリですが、このデフォルトスタイルは、Themeを使用して上書きすることが可能です。各コンポーネントの構造（Anatomy）が定義されており、それぞれのパーツに対してスタイルを柔軟に上書きできるようになっています。
Chakra UIの選定の際には、デザイナーがFigmaでデザインしたUIを Chakra UIでプロトタイプ実装をして、Chakra UIのThemeのカスタマイズで対応できることを確認しました。
また、Chakra UIのコンポーネントはアクセシビリティが考慮された設計がされています。例えば、モーダルやドロップダウンといったインタラクティブなコンポーネントは、キーボード操作に対応しており、適切にフォーカスが移動します。特にモーダルでは、フォーカスがモーダル内に留まる「フォーカストラップ」が実装されており、キーボード操作で誤ってモーダル外部にフォーカスが移動してしまうことを防ぎます。これにより、アクセシビリティが向上し、UI操作が一層スムーズになります。
こうしたアクセシビリティ機能を自前で実装すると大きな工数がかかりますが、Chakra UIを利用することで、これらを簡単に取り入れることができ、開発リソースをサービス固有の提供価値につながる開発に集中させることができました。
デザインと同期したコンポーネントの実装
前述の通りChakra UIはThemeという構造を持っていて、コンポーネントごとのスタイルだけでなく、デザインシステムで利用されるカラーやタイポグラフィ、スペーシングといったグローバルトークンやセマンティックトークンを定義することも可能です。
今回のプロジェクトでは、デザインシステムの構築にこのThemeの機能を利用しています。Themeとして定義できるプロパティはStyled Systemの仕様に定義されていて、この仕様にあるプロパティであれば、デザインシステムに合わせた値を設定することができるようになっています。
ここで定義したトークンがエディタ上で補完されると便利です。Chakra UIはThemeから補完するための型定義ファイルを作成するCLIを提供しています。
このCLIをnpm scripts等で実行することで、補完に利用できる型定義ファイルを作成してくれます。
// package.json { ... "scripts": { ... "theme": "chakra-cli tokens path/to/theme.ts", "theme:watch": "chakra-cli tokens path/to/theme.ts --watch", }, ... }
また、コンポーネントのPropsの名前や値はFigmaのComponent Propertiesと揃えています。
これにより、フロントエンドエンジニアはFigmaで参照したComponent PropertiesをコンポーネントのPropsに設定することで、Figmaと同じ見た目のコンポーネントを実装できる状態になっています。
StorybookとChromaticを活用したUI変更の自動検知
デザインシステムのコンポーネントは、見た目の変更がアプリケーション全体に波及するため、コンポーネントを変更した際の影響範囲を把握することが重要です。そこで、今回のプロジェクトではChromaticを活用してVisual Regression Test（以下VRT）を自動化しています。
ChromaticはStorybookをベースにしたUIテストのサービスです。
Storybookで作成したUIコンポーネントのVRT、UIのレビュー、GitHubやFigmaとの統合などができるようになります。Chromaticと連携するとStorybookのホスティングもやってくれるので便利です。今回のプロジェクトでは、ChromaticとGitHubを連携させてVRTとStorybookのホスティング環境として利用しています。
Chromaticは、Storybookに登録されたコンポーネントをレンダリングして、ベースブランチとの見た目の差分を検出して画像として表示してくれます。
今回のプロジェクトでは、Storybookをすでに導入していて、デザインシステムのコンポーネントはもちろん、アプリケーションを開発しているフロントエンドエンジニアも機能開発中に利用しており、ページやUIのカタログ化とデザイナーやPdMがUIの挙動を確認する際に利用しています。既に構築されているStorybookの資産をそのままChromaticに活用することで、デザインシステムのVisual Regression Test用の実装コストを最小化しています。
GitHubでプルリクエストを作成するタイミングでChromaticのVRTを実施するようにしていて、プルリクエストで発生したコードの差分が、UIとしてどのような差分を発生させるかを確認できるようにしています。開発の規模が大きくなってくるとコンポーネントの依存関係が複雑になってくるので、そのような変更をキャッチしてくれるのは安心です。特にデザインシステムのコンポーネントの修正は、それを利用しているアプリケーション全体に影響が発生する可能性があるため、ChromaticのVisual Regression Testがあることで、意図しない変更が発生した場合に気づくことができるので、リファクタリングを行う際にも非常に有用で心理的なハードルも下げてくれます。
こうした運用により、デザインシステムの改修がアプリケーション全体に与える影響を素早く検知し、視覚的な変更点をチーム全体で確認することが可能な構成をとっています。デザインシステムがアプリケーションの中心的な役割を果たすようになるにつれ、こうした可視化・検証プロセスは、品質を維持するために欠かせないものとなっています。
おわりに
今回紹介したデザインシステムをプロダクト開発に活用した結果、「作業の効率化」「意思決定の効率化」「価値の最大化」というデザインシステム構築時に目的として定めた3つの効果をチームで享受できました。
しかし、依然として解消したいチームの課題は多く残っている状態です。デザインシステム構築前と比較すると作業効率は格段に向上しましたが、その一方で、私たちが達成したい目標と現在の状態を比較するとまだ大きなギャップが存在します。
現在は開発しているプロダクトの良い体験をチームの誰もが簡単に再現するための仕組み作りや、今よりも更に効率的にプロダクトをデザイン・開発し、ユーザーへ最速で価値を提供するための仕組みを構築することに着手しています。
エス・エム・エスではデザインシステムに興味がある開発メンバーを募集しています。カイポケでのデザインや開発に興味を持ったり、チャレンジしてみたいという方がいれば、ぜひこちらも覗いてみてください。またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちらのページよりお気軽にご連絡ください！
