はじめに
Storybookは、WebフロントエンドのUIコンポーネントカタログを作成する強力なツールです。しかし、どんなツールであっても、これを運用し、継続的にメンテナンスしていくのには作業コストが発生します。
Storybookの運用に関わる人は、このツールから得られる恩恵と、得られないものを適切に認識しておく必要があるでしょう。
この記事では、Storybookの具体的な書き方ではなく、その前提となるマインドセットについて、私見を述べていきます。もちろんここで書かれることはコミュニティの公式見解などではなく、あくまで私個人の一意見として受け取っていただけると幸いです。
なお、ここではあくまでStorybookを前提に話を進めますが、マインドセットとしては、flutterのmonarch運用などにも通ずるものがあるかもしれません。
Storybookがもたらす恩恵
Storybook公式には次のコピーが掲げられています。
Storybook is an open source tool for building UI components and pages in isolation. It streamlines UI development, testing, and documentation.
https://storybook.js.org/
拙訳：StorybookはUIコンポーネントおよびページを分離して構築することで、UI開発、テスト、およびドキュメンテーションを合理化するオープンソースツールです。
ここから、Storybookの目的には3つの要素があることがわかります。
- UI開発時のプレビュー用途
- UIのテスト用途
- UIのドキュメンテーション
これらは既に目的でもありますが、さらに大きな目的への手段でもあると言えるでしょう。
- なぜプレビューするのか？→UI開発の高速化
- なぜテストするのか？→アプリケーションの品質向上（バグ低減）
- なぜドキュメンテーションするのか？→コミュニケーションコストの低減
以上の恩恵を、「インタラクティブなUIコンポーネントカタログ」という形で実現しているのが、Storybookの利点であり価値です。これらのメリットがあるということを、まずは認識しましょう。
とはいえ、メンテナンスは大変
上記のメリットをすべて享受することができるのがStorybookの強みではありますが、実際にはどこにフォーカスするのかを決めておいたほうが、メンバーがStorybookをメンテナンスするモチベーションにつながると思われます。
たとえば、UIの実装に当たって、ローカルでのサーバ立ち上げと実際の画面上での実装に慣れているメンバーからすれば、1のメリットはさほど大きく映らないでしょう。
ドキュメンテーションに関しては、「誰向けのドキュメントなのか」ということを意識する必要がありそうです。たとえば、デザイナーとのコミュニケーションにコンポーネント名という共通言語を使用する目的であれば、有効に働きそうです。
API仕様書のようにStorybookを作ることももちろん可能ですが、これはデザインシステムを作る際には便利であるものの、手元で参照できるアプリケーションコードがあるのであれば、TypeScriptの型情報を見る方が早かったりするでしょう。
Storybookが提供しないもの
Storybookを利用するメリットがわかったところで、この優秀なツールが提供しないものについても認識しておきましょう。
最終的な品質担保にはならない
Storybookは、あくまで「所与のパラメータに対して任意のUIコンポーネントがどのようなレンダリング結果を返すか」を確認する道具です。
ですから、これによってアプリケーションの振る舞いや、外の世界（≒バックエンド）とのやり取り結果を測ることはできません。
やはり、アプリケーションとしての品質を担保するには、別途E2Eテストが必要となるでしょう。テストとしてのStorybookは、すなわちUIの静的な単体テストであると捉えましょう。
デリバリーされるものではない＝ユーザ体験の直接的な向上には寄与しない
当たり前の話ですが、Storybookはあくまで開発補助ツールです。最終成果物ではありません。
ユーザへの価値提供を第一とするWebサービスにおいては、体験そのものにはつながらない、あくまで補助的な役割を果たすのみであると認識しましょう。
プラグインについて
Storybookにはさまざまなプラグインが用意されいますが、これらを導入する際は、メンテナンスコストや得意なこと・苦手なことについて意識するようにしましょう。
たとえば、StoryshotとJestを組み合わせれば、Storybookによるレンダリング結果を用いてスナップショットテストを実行できるでしょう。しかし、ドキュメンテーションとしての役割を重視するのであれば、余計な差分がスナップショットファイルの中に含まれてしまう可能性が大きくなります。
controlsくらいは当たり前に入れてもいいんじゃないか、という向きもあるかもしれません。しかしこれにしたって、「宣言的UIに与えるパラメータをインタラクティブにすること」がどれだけ効果を発揮するかを考えたほうが良いはずです。Storybookのファイル作成手続きが面倒になると、次第にメンテナンスされなくなる可能性が高まっていきます。十分に気をつけましょう。
おわりに
Storybookは、メリットも多いですが、メンテナンスが大変なツールです。あなたたちの組織が、Storybookがもたらすどのメリットを欲して導入しているのかが定まれば、自然に書き方も定まっていくでしょう。
私の意見ですが、大切なのはルールを決めすぎないこと、PRに含まれているすべてのコンポーネントに対して精密なStorybookを作成することを求めないことかもしれません。
Storybookを書くのは楽しいですし、きれいに表現できると気持ちいいですが、運用担当者はしっかりとメリット・デメリットを認識した上で導入・運用していきましょう。最後までお読みくださりありがとうございました。