はじめに
チームにStorybookを導入する際に、Storybookのメリット・デメリットを客観的に分析する必要がありました。社内共有向けにはじめはまとめたのですが、社外向けにも公開できるように本記事でまとめなおしてみました。
UIコンポーネントとは
Storybook について紹介する前に、UIコンポーネントについて簡単に紹介する必要があると思ったため、紹介させていただきます。なぜなら、 Storybook はUIコンポーネントを用いた開発において生じた問題点を解決するためのひとつの手段であるためです。
UIコンポーネントとは、標準化された、交換可能な UI の構成要素です。これは、UI 部品の外観と機能をカプセル化します。（以下、UIコンポーネントを単に「コンポーネント」と記載します）
例えば、LEGO ブロックを思い浮かべて頂ければイメージが掴みやすいと思います。
LEGO は、城から宇宙船まであらゆるものを作るのに使用できます。作成した宇宙船の一部の LEGO を調整して、帆船も作ることができます。
コンポーネントのメリット・デメリット
コンポーネントには、以下のメリット・デメリットが存在します:
メリット
- 再利用性: 一度作ったコンポーネントを他の画面やプロジェクトでも使える。例えば、ボタンやモーダルを統一すれば、デザインの一貫性が保たれる。
- スピード: コンポーネントライブラリまたはデザインシステムから既存のコンポーネントを再利用することで UI をより速く組み立てることができる。
- 開発の並行化: チーム開発で分担しやすくなります。例えば、Aさんが「ボタンコンポーネント」を作り、Bさんが「フォーム」を作る、などが Conflict を避けて可能。
- 耐久性:コンポーネントレベルでテストすることで、バグを詳細に特定できる。画面をテストするよりも作業が少なく、精度が高くなる。
デメリット
- 増大するコンポーネント： アプリケーションが成長するにつれて、コンポーネントの数も増えます。成熟したプロジェクトには、何千ものバリエーションをもつコンポーネントが存在することがあります。例えば、Viewportの大きさや、ブラウザの種類、コントラストや色やサイズなどです。
- 見た目以外にも関わってくる: コンポーネントは、見た目のバリエーションが多いだけではなく、ビジネスロジックやアプリのコンテキスト等にも関わってくるため、これらが問題をより複雑にしています。
- デバッグが困難: 多くの見た目のバリエーションを持ち、ビジネスロジックを持つようなコンポーネントは、デバッグが困難です。例えば、Webサーバーを起動して手動クリックでそれらの動作を１回１回確認することは大変です。
Storybook とは
Storybook はコンポーネントのメリットを最大限に引き出し、デメリットをできるだけ抑える仕組みを提供します。
具体的には、コンポーネントが持つ複数のバリエーションを「ストーリー」という名前で管理し、それらごとにテストを行うことができます。
そのため、Storybook は開発者が管理する frontend workshop environment として提供されています。
Storybook 導入がプロジェクトに与えるメリット・デメリット
さて、それでは Storybook を プロジェクト に導入することでどのようなメリット・デメリットがあるかについてまとめていきます：
メリット
- コンポーネントごとにデザインを確認できる: 例えば、SaaSの管理画面のボタンやモーダルを想像してください。これらの動作を確認するためには、Backend と Frontend を立ち上げ、ログインをして確認する必要があると思います。しかし、 Storybook があれば、これらをしなくても Storybook サーバーだけを起動すれば確認ができます。
- コンポーネントのドキュメントとして機能する: プロジェクトに新メンバーが加わった際に、「管理画面のデザインを知りたい」や「どんなコンポーネントが用意されているか知りたい」というニーズがあるかもしれません。その時に、新メンバーにコンポーネント一覧と、コンポーネントを使用するべきストーリーを紹介するドキュメントとしてStorybookは機能します。
- コンポーネントの動作テストが容易: コンポーネントのパラメーターを自由にStorybook上で変更し、コンポーネントの動作テストができます。そのため、コンポーネントテストのためにコードを変更する必要がありません。
- デザイナーとの乖離を防げる: コンポーネントごとに、簡単に見た目のバリエーションを紹介できるため、デザイナーとの認識の乖離を防ぐことに役立ちます。
デメリット
- ストーリーを管理するのが難しい: 作成したコンポーネントはどのような場合に表示され、どのような操作がされるのか。コンポーネントはPC表示とスマホ表示でどのように変わるのか。など様々なストーリーを考慮して、管理することがそもそも難しいです。（どれも重要なことなんですけどね…）
- 保守コスト: ストーリーがコンポーネントに追加されたときや、想定していたストーリーが間違っていたなどして変更された場合、Storybookを更新する必要があります。
- 目的: もし、コンポーネントのバリエーションや、コンポーネントが使用されるストーリーなどを把握する必要性がプロジェクト内にないのであれば、導入がデメリットになります。
終わりに
この記事では、Storybook導入のメリット・デメリットをまとめました。
特に、最後のデメリットに関しては「プロジェクトの現状を正しく分析する」という観点も含まれているのでかなり重要な項目であると思います。