こんにちは。CTOの十川です。
この記事では、エンジニア視点でデザインシステムについて書いてみたいと思います。
NCDCでは、Storybookというソフトウェアを活用してデザインシステムを構築した実績があるので、Storybookを使ったデザインシステムの構築例を中心に、導入のメリットや管理方法を紹介します。
目次
デザインシステムとは？
デザインシステムとは、デザインの概念、原則などをまとめたドキュメント、それらを具体的なデザインに落とし込むためのスタイルガイド、コンポーネント集、そしてその管理・運用ルールや、コード化されたコンポーネントの管理に用いるツールなど、さまざまな構成要素で成り立つ仕組みです。
デザインシステムの活用により一貫したUIデザインを短期間に実装できるようになるため、大規模なWEBサイト・システムの構築などのプロジェクトでは多くのメリットが得られます。
（詳細は別の記事「デザインシステムとは？ メリット・デメリット・具体例を解説」で紹介しているので、併せてご覧ください）
Storybookとは？
Storybookとは、UIコンポーネント開発環境を提供するオープンソースのツールでReact、Vue、Angular、などのJavaScriptフレームワークをサポートしています。
Learn Storybook（開発者向けのWEBサイト）には下記の記述があります。
Storybook is the most popular UI component development tool for React, Vue, and Angular.”
https://www.learnstorybook.com/intro-to-storybook/
Storybook は開発時にアプリケーションと並行して動きます。Storybook を使用することで、UI コンポーネントをビジネスロジックやコンテキストから切り離して開発できるようになります。
https://www.learnstorybook.com/intro-to-storybook/react/ja/get-started/
上記の「Storybook は開発時にアプリケーションと並行して動きます。」という文言をもう少し詳しく解説すると、「アプリケーション本体とは別の独立した環境でStorybook（UIコンポーネント）を運用し、両者の開発に並行して取り組むことができる」と表現できます。
Storybookでできること
つまり、アプリケーション開発時に、ボタンや入力フォーム、ヘッダーなどのUIコンポーネント（部品）だけを切り離してStorybook側で構築・管理するという使い方ができます（アプリケーション側からは必要な時に部品を取り込んで使うことができます）。
もう少し具体的に説明すると、UIコンポーネントをアプリケーション本体とは別に管理することで、次のようなメリットが得られます。
- アプリケーションとは独立した開発環境に構築できるため、UIコンポーネントを先行して開発、挙動のテストなどを行える
- UIコンポーネントをカタログのように一覧で管理できる
- UIコンポーネントの使用方法などもStorybook上に記載できるため、ガイドラインをUIコンポーネントと一緒に提供できる
- UIコンポーネントをアプリケーションから共通利用できるため、同じようなUIコンポーネントを複数の人が作ったり、似ているが微妙に違うUIコンポーネントが乱立したりするのを防げる
Storybookを利用したデザインシステム
上記のLearn Storybookに「Storybook is the most popular UI component development tool」という表現がありましたが、実際にStorybook がどのように使われているかというと、Uber, Airbnb, IBM, GitHubなどのデザインシステムに利用されているようです。
Storybook powers the design systems for Uber, Airbnb, IBM, GitHub, and hundreds more companies.
https://www.learnstorybook.com/design-systems-for-developers/react/en/introduction/
前述した通り、デザインシステムは「一貫したUIデザインを短期間に実装できる」ことが求められるため、UIコンポーネントの開発・管理を楽にできるStorybookが採用されていると考えられます。
Storybookを使用したデザインシステムの構築例
Uber、Airbnbほどの規模ではありませんが、NCDCでもStorybookの活用事例があるので、次に実際にStorybookを使用したデザインシステムの構築例を紹介します。
ポイントは以下の３点です。
- フロントエンドの開発に用いるフレームワークは、コンポーネント志向（ソフトウエアを機能ごとに部品化して、必要に応じて組み合わせて使う考え方）で画面を開発できるReact、Vueなどを採用
- Storybook用のGitリポジトリをアプリのリポジトリとは分けて作成
- アプリのリポジトリ（ファイルや変更履歴の保管場所）からはStorybookのリポジトリを参照し、UIコンポーネントをImportして使用
下の図ではstorybook管理する共通UIコンポーネントをアプリケーション側でどう利用するのか、ソースコードはどう管理するのかを簡単に示しています。
共通UIコンポーネントのバージョン管理
Storybookに限らず、デザインシステムを運用する場合はさまざまな場所で利用されている共通UIコンポーネントの修正にどのように対応するかという課題が出てきます。
基本的な考え方はソフトウェアの共通ライブラリのバージョンアップと同様です。強制的にバージョンアップするのではなく、UIコンポーネント自体をバージョン管理し、アプリケーションごとにどのバージョンを使用するか選択できるのが望ましいです。
上記の「Storybookを使用したデザインシステムの構築例」はこの点もカバーしています。
共通UIコンポーネントはGitのタグ等でバージョンを管理することで、UIコンポーネント自体をversion1, version2…というように複数バージョン保持した運用が可能になります。
運用の例
- 新規に開発するアプリはUIコンポーネントversion2を採用
- 既存のアプリは次の改修タイミングまでUIコンポーネントversion1を使い続ける
Storybookでデザインシステムを構築するメリット
Storybookで何ができるか説明してきましたが、あらためて「デザインシステムをStorybookで構築するメリット」は何か？を整理したいと思います。
一貫したUIを実装するための手段としては、以前からスタイルガイドやUIキットの提供、CSSの共有などさまざまな方法がとられていました。
しかし、これらの方法はいずれもUIコンポーネント自体はそれぞれエンジニアが開発・管理する必要があり、複数のアプリケーションで共通のUIを使うようなケースでの効率化や一貫性の保持には限界があります。
一方、アプリケーションから独立した環境でUIコンポーネントを構築・管理できるStorybookを使用した場合、UIコンポーネント自体を共有できるので、アプリケーション側はImportするだけでUIを実装できるようになります。複数のアプリケーションで共通のUIを使うようなケースでは大きなメリットがあることはすぐに想像できると思います。
また、以前からある画面単位でHTMLを作成するような方法ではなく、近年増えてきたReactやVueのようなコンポーネント指向のフレームワークを使う場合、Storybookは相性がとても良いです。
このように一貫したUIを実現するとともに、従来はエンジニア側でUIの開発・管理にかかっていた工数が大幅に削減される点がデザインシステムをStorybookで構築する大きなメリットだと考えています。
Storybookベースのデザインシステムの向き・不向き
この記事ではStorybookベースのデザインシステムをお勧めしていますが、もちろんこれが万能な仕組みというわけではありません。
導入の検討をする場合、この方法が適しているかどうかを判断する必要があります。
メリットが大きいもの、適しているもの
ざっくり説明すると「それなりの規模のUIコンポーネントが必要であり、継続的にデザインを管理する必要があるプロジェクト」には適していると言えます。
デザインシステムを導入することで長期的なメリットは得られますが、デザインシステムの構築・管理自体にはもちろん工数がかかるので、初期にその工数を掛けてでもつくる必要があるかどうかという点で判断が必要です。
Storybookベースのデザインシステムが適しているものの具体例としては下記のものが挙げられます。
- 社内ユーザー向けのアプリ群など、おなじユーザーのグループに対して複数のアプリを提供する
- 同一ブランドでサービスページ、サポートページなど複数のWEBサイトを運用する
- １つのアプリだけど、継続的にリリースしていく
メリットが小さいもの、適していないもの
簡単に言えば「規模が小さいプロジェクト」「継続的にデザインを管理する必要がないプロジェクト」はわざわざStorybookでデザインシステム を構築する必要はありません。
- デザインの統一性が重要ではないもの
- 一度作れば終わりで継続的にUIを管理する必要がないもの
- 当たり前ですがStorybookがサポートしていないプラットフォームのもの（SwiftやKotlinで開発するなど）
Storybookを用いたデザインシステムをお勧めする理由
繰り返しになりますが、Storybookでデザインシステムを構築する最大のメリットは「アプリケーションの実装言語、フレームワークを使ってUIコンポーネントを独立して開発、管理できる」ことにあります。
UIコンポーネント自体を共通化することで、デザインの統一、実装の効率化の２点において優れた環境を構築することができます。
デザインシステムの運用にはデザイナーもエンジニアも関わる必要がありますが、エンジニア視点ではStorybookを採用するのはとても良い方法だと思います。
一方、逆説的になりますが、実装がばらばらな環境ではこの方法を適用できません。
例えば、Swiftで開発するiOSネイティブアプリと、Webアプリがあるような場合は、WebアプリだけしかStorybookでサポートできません。
このような場合は、SketchやXDで作成したものから、CSSやSwiftのスタイルの定義を取り出すことができますので、別の仕組みでデザインシステムを構築した方が良いかも知れません。
UX/UIデザインからデザインシステム の構築まで
NCDCではデジタルプロダクトのデザインから開発まで、一貫してサービスを提供しています。
プロジェクトの規模に応じて、UX/UIデザインの支援から、こうしたデザインシステム の構築支援まで幅広く対応可能なので、「デザインの共通化によってUXの改善を図りたい」「UIの管理方法を改善してシステム構築の効率をよくしたい」といった考えをお持ちの方はぜひご相談ください。
