PR TIMES 開発本部フロントエンドエンジニアのすずきゆーだい (@szkyudi) です。
今回は、PR TIMESのフロントエンドリプレイスにおいて、どのようにデザインシステムを活用しているかについてお話ししようと思います。
デザインシステムとは
デザインシステムとは、一貫したデザインや操作性でウェブサイトやアプリを提供するための仕組みのことを指します。
弊社ではこれを「PR TIMES BASIS」と呼び、約2年前から運用されており、新機能開発やリプレイスといったさまざまなプロジェクトで活用されています。
PR TIMES BASISについては以下にまとめられています。
弊社でのデザインシステムの活用方法
まず、以下のような活用をしています。これらはデザインシステムの一般的な活用方法になると思います。
- デザインと開発を効率化する
- 一貫したUIを提供する
また、最近では弊社のデザインシステム内のデザイントークンやコンポーネントが充実してきており、Reactの実装にも反映されてきているため、基本的なUIはデザインシステムに存在する色やコンポーネントを組み合わせることで、実現することができるようになってきました。
そこで、仕様やデザインに大きな変更が加わらない一部のリプレイスプロジェクトでは、デザインファイルを用意せずに仕様書と既存機能をもとにリプレイスを行うフローを採用しています。
どのように開発しているか
現在、メディアリストという機能において、機能追加やリニューアルに備えて技術的な負債を解消する目的でReactへのリプレイスを行っています。
そこで、従来のフローからデザインファイルを作成するフローを省いたフローに変更しました。
既存仕様をもとに仕様書を再定義
8年近く前に開発された機能ということもあり、仕様書が存在していません。そのため、PdMが既存仕様をもとにNotionに以下のような項目を仕様書を書き起こします。
- ユーザーストーリー
- 機能の流れ
- 画面構成や表示項目
- バリデーション
- エラー仕様
- 既存仕様からの変更点
仕様書とデザインシステムを活用して実装
仕様書ができた段階で旧デザインと照らし合わせて、エンジニアが実装を開始します。実装済みのデザイントークンや共通コンポーネントを組み合わせて実装します。
以下はリプレイス前後のページャーになります。ページャーのデザインや挙動に関する仕様はデザインシステムに定義されていて、実装にも反映されているため、見た目が変わっても考慮事項を増やさずに導入できます。
また、実装している中で、不足しているデザインや変更を加える必要がありそうな箇所が見つかれば、都度Slackやデイリーミーティングなどで確認して、デザイン作成の依頼や変更の反映を行います。
進捗を共有しながらPdMやデザイナーにレビュー依頼
実装が完了してからデザインの齟齬が起こらないように、定期的に進捗をSlackやデイリーミーティングでStorybookや開発環境の画面を共有して相談することで、フィードバックをもらったりします。
実際にデザインシステムを適用したときに意図しないデザインが発生したときには、このときに確認して対応方針を決定します。
特に、テーブルのセルの幅やフォームの挙動など、ユーザー入力などによる動的なコンテンツに依存しやすいものは注意して確認を行います。
システムテストを経てリリース
仕様書をもとに作成したテストケースを実行し、問題がなければリリースをします。このとき、チーム内では、デザインシステムを適用した影響で既存機能からデザインの変更があっても、ユーザビリティに問題がなければ許容するという判断をとっています。
このような流れでメディアリスト機能はリプレイスを行なっています。
実際どうだったか
デザインに関わるコストが削減できる
実装前にデザインを用意する必要がないため、デザインを用意して開発するフローに比べて1,2週間早く着手することができます。
開発速度が速いチームやデザイナーが不足しているチームでは着手前のブロッカーが減るのでスムーズに開発を行うことができています。
全員デザインの意識が生まれる
デザイナーが作ったデザインファイルをもとに開発するのではなく、エンジニアが仕様や既存ページからデザインを汲み取って開発を行うため、デザインの妥当性を考えながら実装を行なっていく意識が強くなりました。
また、懸念があるデザインについてはPdMやQAエンジニアと相談することで、チーム全体でより解像度を高めていくことができています。
具体的にはエラーメッセージの文言やフォームの挙動といった仕様に密に関連するデザインについて、チーム全員で考える機会が増えたと感じます。
テストがしづらくなる
このフローにはいいことだけではなくテスト時に正となるデザインが存在しなくなるという問題が発生します。
デザインを先に作成しておくと、その時点からUI/UXの懸念点を検知することができますし、デザインファイルをもとに中間QAを実施しておくと、一定の妥当性が保証された状態で開発することができます。
しかし、このフローの場合、実装時にもテスト時にも新しいデザインのデータは存在しないのでUI/UXに対するテストが難しくなります。
Storybookが中間成果物となる
本格的に運用できているわけではないですが、ロジックを実装する前にコンポーネント駆動開発を行なって、Storybookを作成します。
現在、PR TIMESのフロントエンド開発環境では、Pull RequestごとにStorybookが自動デプロイされるCIが構築されているため、Storybookを容易に共有することができます。
この仕組みを活用して、Storybookを中間成果物としてPdMやQAエンジニアにレビューを依頼することができます。これにより、正となるデザインが存在しない課題を一定程度解決できると感じました。
以下は合計値を300件に固定して各メディア種類の件数を調整できるスライダーです。ロジックを組み込む前にこのStorybookを共有して、PdMやQAエンジニアにレビューしてもらうことで、段階的に品質を保証していきました。
まとめ
今までさまざまなプロジェクトで活用されてきたデザインシステムですが、今回はリプレイスで存分に活用した例を紹介しました。
リプレイスという大きな変更を伴わないプロジェクトにおいて、デザインシステムは大きく活用できるということを実感しました。
もちろん、新機能開発や仕様変更を伴う開発においては引き続きデザインファイルを作成してから開発することになると思いますが、仕様変更を伴わないリプレイスのようなプロジェクトにおいては、デザインファイルを作成しないで実装するフローも視野に入れながら開発していきたいと考えています。
