はじめに

西日本テクノロジー＆イノベーション室の山田です。

現在私が所属しているプロジェクトでStorybookを導入しました。
導入前に期待していた利点のほかにも、導入してはじめて気づいたStorybookの良さがありました。
また、導入して気づいた点をもとにStorybookの導入に向いているプロジェクトの特徴を考えました。 本記事ではその2点の紹介をします。

Storybookの概要

StorybookはUIのコンポーネントをアプリケーションに組み込まず独立して開発できるツールです。

ReactなどのUIを構築するライブラリを使用してアプリケーション開発を行う場合、コンポーネントを画面に組み込み、画面全体の動作を確認しながら開発を進めていきます。
それに対し、Storybookを使用することで個別のコンポーネント単体の動作・UIの確認ができます。

Storybookを起動すると以下のような画面が表示され、指定したコンポーネントの動作を確認できます。

導入したプロジェクト概要と目的

プロジェクトの概要

本題へ入る前に今回Storybookを導入したプロジェクトの概要を紹介します。 私が所属しているプロジェクトには以下のような特徴がありました。

  • 既存サービスのリプレース案件（既存の画面を踏襲することが多い）
  • 開発規模はあまり大きくないサービス
  • チームに在籍するエンジニアは現在4名、デザイナーは3名
  • SPAとして開発する
  • SPA（とくにフロントエンド）の開発に慣れていないエンジニアが多い
  • 主なフロントエンドの使用技術
    • React
    • TypeScript
    • css-modules

Storybookを導入しようと思った目的

1. 開発者の分業をしやすくする

チームに所属しているエンジニアはフロントエンドの開発経験が少ない状況でした。 効率的に作業するため、開発経験を積むためにもできるだけ担当できる範囲を多くしたいという要望がありました。
Storybookでは業務ロジックを含まないコンポーネントを表示するストーリー（コンポーネントがレンダリングされたうちの1つの状態）を作成します。 Storybookに対応するプレゼンテーショナルコンポーネント（見た目のコンポーネント）だけを作るのであれば、フロントエンドをコーディングする難易度が比較的低くなるのではないかと考えました。
そのためにStorybookを導入したというのが大きな狙いの1つでした。

2. デザイナーとのやり取りを簡潔に行う

デザイナーが作成した成果物の種類によっては、エンジニアの判断でHTMLタグやCSSを指定する必要が出てきます。 また、画面サイズに応じた見た目の変更やボタンを押したときなどの動作の詳細までは指定しきれない部分があります。

ストーリーを作成した段階でデザイナーにUIを確認してもらうことで、詳細部分の認識の齟齬をなくしつつ開発を進めたい、という狙いがありました。

Storybookの良い点

実際にStorybookを導入してみて、導入前から期待していた良かった点、導入前には見えていなかった良かった点が複数ありました。 その中でとくに良かったと思った箇所に関して紹介します。

導入前から期待していた良かった点

1. コンポーネントを確認しながら実装を進められる

Storybookを導入しなかった場合、見た目やUIの挙動の不備を修正するためには、原因の切り分けから始める必要があります。

それに対し、以下の項目を確認しながら開発を進められることが、Storybookの良さであると感じました。

  • レイアウトのずれ、データの不足などの原因部分の切り分けが容易である
    今回のプロジェクトではUIライブラリ（ Material UI, Ant Designなど）を使用せず、アプリケーションの見た目はCSSを書いて指定しています。Storybookを導入することで各コンポーネントごとに見た目を表示できるため、コンポーネントごとにCSSが正しく設定できることを確認できます。それによって、ページにコンポーネントを組み込んだ時にレイアウトがずれた場合はページ全体に指定しているCSSが原因である、等の切り分けが容易でした。
  • propsとしてふさわしい項目の確認ができる
    ストーリーを作成することで、コンポーネントに必要なpropsが抜けているなどのpropsの項目の不備を見つけることもやりやすかったように思っています。

2. テストの導入が容易である

公式アドオンのStoryshotsを導入するだけで、スナップショットテストが自動ででき上がります。スナップショットテストとはソースコード変更前後のスナップショット（レンダリング結果）を比較し、差分を検出するテストのことです。

今回のプロジェクトでは現状、ほかのUIテストツール（enzymeなど）の導入は行っていません。Storyshotsを導入によって変更点の確認ができるだけでも、アプリケーションのリグレッションを防ぐことができるため、導入のメリットは大きいです。

ほかのUIテストツールを導入している場合は、その役割が重複してしまうことが考えられます。

導入前には期待していなかったけど良かった点

1. 自然とコンポーネントの分割ができる

Storybookのストーリーは、プレゼンテーショナルコンポーネントでなければ動かしづらいという特徴があります。プレゼンテーショナルコンポーネントにすることで、副作用なく見た目の制御を行うことができます。

そのため、Storybookを導入することでプレゼンテーショナルコンポーネントからボトムアップで作り始める、というReactの流儀に沿ったコンポーネントの作成ができました。

今回はフロントエンドの実務経験がない中で開発を始めましたが、あまり迷うことなくコンポーネントの分割ができました。

2. 副作用のある関数を外部化するアイデアの手掛かりとなった

今回のアプリケーションでは、サーバサイドと通信してデータを取得する関数を使用していました。 Storybookとサーバサイドの通信は行えないため、Storybookでコンポーネントを動作させているときは通信を発生させたくありません。

そこで、 通信を行う関数を注入できるように変更しました。Storybookでコンポーネントを動作させているときにはモックが動作し、ダミーデータを取得するようにしています。 通信するコンポーネントを外部化する発想はStorybookを導入したからこそ考えられたと思っています。Storybookを使っていての嬉しい誤算でした。

Storybookの難しさ・期待と異なった点

Storybookにはさまざまな良い点がありましたが、導入前には想定していなかった難しさや期待と異なっていた点もいくつかありました。 その点に関して紹介します。

導入前に想定していなかった難しさ

1. Storyが重複する

複数のコンポーネントを呼び出すコンポーネントのストーリーを作成する場合、子にあたるコンポーネントのデータもすべて指定する必要があります。 子コンポーネントのストーリーをすでに作成しているうえに、データの指定の必要があり冗長に感じられました。

全ページをストーリー化するのではなく一部のコンポーネントのみをストーリーにする、もしくは効率のデータ指定の方法を考えるなどの必要があると思っています。

また、子コンポーネントに閉じた内容の確認はその子コンポーネントのストーリー内ですべて完結するなど、一般的なテスト設計と同じ考え方をすることで効率よくコンポーネントの確認ができると考えています。

当初の期待と異なった点

1. 当初の目的：開発者の分業にはほとんど影響がなかった。

当初は、フロントエンドの開発に慣れていないメンバーでもHTMLやCSSの知識があればストーリーの開発が可能ではないか、と考えていました。

しかし、プレゼンテーショナルコンポーネントのみの開発であっても、実際には前提として必要な知識・技術の必要量がそれほど減りませんでした。

想定レベルと実際に必要だった知識レベルの差は、以下のような状態でした。

  • 想定：HTMLのモックアップ作成レベル
  • 実際：React, TypeScriptの理解は必須

現在は、フロントエンドの開発に比較的慣れたメンバーがStorybookを含めたフロントエンドの開発を行っています。

2. 当初の目的：UIのカタログとして使える

当初、デザイナーとのやり取りにもStorybookを使用したい、という狙いがありました。 しかし、今回のプロジェクトは既存の画面のデザインを踏襲することが多いため、現在はデザインの確認という用途には使用していません。

新規の画面の作成の際にはUIのカタログとしても役立ってくれるのではないかと期待しています。

Storybookを効果的に生かせるプロジェクトの考察

Storybookをプロジェクトに導入してみて良かったところ、生かしきれなかったところを上げてみました。以上の情報から、Storybookの特徴を生かすためには以下の項目が重要だと考えました。

項目 特徴 理由
デザイナーとの確認作業 多い UIカタログとして使用することで、手戻りが少なく、簡単にレイアウトの確認ができる。
UIライブラリ 使用しない 独立したコンポーネントの確認ができる点が生かされる。UIライブラリを導入している場合、小さな粒度のコンポーネントはレイアウトの確認を行う必要性が薄い。
UIテストツールの導入 していない Storyshotsの導入の意味がある。

おわりに

自身が所属しているプロジェクトにStorybookを導入して使ってみた経験から、導入してはじめて気づいたStorybookの良さの紹介をしてきました。また、Storybookの導入に向いているプロジェクトの特徴を考えました。
Storybookの導入を考えている方のご参考になれば幸いです。

本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。