デザインシステムは、組織全体で一貫した体験を実現し、コードの再利用によってエンジニアリングチームの効率化を図るための、体系化されたパターンやプラクティスの集合を定義するのに役立ちます。組織にそのメリットを納得させ、複数のチームでの採用を促した後は、システムを長期的に管理・拡張・改善していく上で多くの課題に直面します。

リソースの確保

最初の課題の一つは、システムのためのリソースを確保することです。デザインシステムは、アプリケーション間でのパターンやコードの再利用を実現したいと考える情熱的なエンジニアやデザイナーによって、有機的に成長し始めることがあります。このグループが「コアチーム」となり、共有ライブラリ群のビジョンについて定期的に議論し、何をライブラリに追加すべきか、APIをどのように設計すべきかといった意思決定を行い、システムの開発を牽引していきます。

しかし、この保守や計画はそれ自体がフルタイムの仕事です。このプロセスの管理を本業の片手間でこなそうとしても、すぐに手に負えなくなります。コンポーネントのAPI間で不整合が生じたり、実装方針をめぐる意見の相違からコードレビューが滞ったりして、開発者のフラストレーションを招くことになります。

この課題を解決するには、このシステムの開発に責任を持ち、コントリビューションのプロセスを整備するプラットフォームチームを結成することが有効です。システムの長期的な健全性に専念するエンジニアがいることで、一貫性が保たれ、デザインシステムへの追加プロセスも明確になります。

ライフサイクルプロセスの定義

Atomic Designにヒントを得て、パターンへの変更に関する明確なプロセスを定めておくと役立ちます。検討すべき代表的な問いとしては、次のようなものがあります。

• 新しいコンポーネントを追加すべきか、既存のものを拡張すべきかをどう判断するか。その判断にはどのような情報が必要か。
• コンポーネントの成熟度をどのように定義し、利用者にどう伝えるか。新しいコンポーネントを追加した際に、すぐに本番環境で広く使われても問題ないか。
• API設計の思想は何か。柔軟性を重視するのか、制約の強い設計にするのか。
• 非互換となるAPI変更や、コンポーネントの非推奨化・削除をどのように管理するか。利用者にどのような事前通知を行うか。チームが計画を立てられるようにメジャーリリースのスケジュールを設けているか。

品質の確保

デザインシステムが他のエンジニアリングチームに約束する重要な価値の一つは、作業負荷の軽減です。事前に用意されたコンポーネントを使えば、自分たちで一から作る手間が省けます！ しかし、変更のたびにアプリケーションでのコンポーネントの使われ方が壊れるようでは、予期せぬデバッグ作業がそれらのチームに降りかかり、すぐに不満につながってしまいます。

Storybookを使えば、アプリケーションのチームがコンポーネントを利用するあらゆる方法をテストするための、さまざまな「ストーリー」を作成できます。ストーリーは機能的・視覚的なテストケースを表し、すべてのユースケースがストーリーでカバーされていることを保証することで、利用者側での不具合発生を防ぐのに役立ちます。StorybookとChromaticを組み合わせれば、ビジュアルリグレッションテストを追加できるほか、レビュー段階でデザイナーを巻き込みやすくなります。ユーザー操作を伴うケースについては、Storybookのplay functionsでカバーできます。

react-testing-libraryを使って単体テストを書くことは、保守しやすいテストを作成すると同時に、アクセシブルなコンポーネントの作成を促す良い方法です。

ドッグフーディングも、デザインシステムの問題を利用者側で発見される前に捉える有効な方法です。デザインシステム内でさまざまなmoleculesやorganismsを維持しておくことで、atomレベルの問題をより早期に発見できます。

フィードバックを得て今後の可能性を探る

デザインシステムの管理者として、「デザインシステムはいつ完成するのか」と聞かれることがあるかもしれません。実際には、組織が新しいアプリケーションを構築し、新たなユースケースやパターンが生まれるにつれて、デザインシステムは進化し続けます。リブランディングやデザインチームの方針転換も、システムに大きな変動をもたらすことがあります。

ユーザーであるエンジニアリングチーム、デザイナー、プロダクトマネージャー、そしてエンドユーザーから定期的にフィードバックを得る必要があります。デザインシステムも一つのプロダクトであり、すべてのユーザーにとって課題を解決し続け、正しい方向に進んでいることを確実にするために、誰かがプロダクトオーナーの役割を担う必要があります。