Storybookの再構築を始めています - devlog [開発部門ブログ]

記事概要

こんにちは、ネットオン開発Sec.のサイトーさんです。

今回はネットオン社内の個人的な活動として行っているStorybookの再構築について書いてみようと思います。

そもそもStorybookとは

StorybookとはReactやVue、Angular などで作成されたコンポーネントを手軽にブラウザでチェックできるようにするためのUIコンポーネントカタログを作るモジュールです。Storybookを利用して開発を進めていくと以下のメリットがあります。

コンポーネント単位でUIのテストができる
backendの準備ができていなくてもUIだけで先に作ることができる

なぜ再構築しているのか

以前、採用係長をモダンな技術へ移行するプロジェクトに携わっていました。このプロジェクトの中で、デザイナーチーム主導でStorybookを利用してみようという活動がありました。内容としては、エンジニアチームがページのロジック実装を担当し、デザイナーチームがStorybook付きのページコンポーネントを作成するという協力体制を試しました。

しかし、デザイナーチームで作成してもらったデザイン案とエンジニアチームで作成したロジック実装で問題が発生してしまい、Storybookの利用がなくなっていきました。その後、採用係長の新規機能開発を進めていくにつれてコンポーネントの数も増えてゆき利用状況が不透明になっていきました。そこで、再びStorybookを導入し、コンポーネントの再構築を検討することになりました。

Storybookが使われなくなった原因

Storybookを再構築する上でなぜ利用が少なくなっていったのか当時の状況を踏まえ、原因としては以下の事柄があったのではないかと考えています。

1．小さなコンポーネントの実装状況がエンジニアチームに伝わりづらかった

採用係長ではフロントの実装ではReactが利用されており、画面のコンポーネントをAtomic Designに準拠して作成を進めていました。ところが、Storybookを利用して作成された画面デザインは当時エンジニアチームで実装していたコンポーネントを再利用せずに実装していました。

そのため、アイコンやボタンなどの小さなコンポーネントを再利用する際に、どれがすでに実装されているかを判断することが難しくなりました。

２．複数のデザイン分岐が統合されたストーリーが解釈を困難にしている

Storybookにおいて、複数のデザインパターンが一つの画面デザイン内に統合されて実装されていました。その結果、エンジニアチームが実装する際に、どのスタイルがどのデザイン分岐に適用されるのかを判断することが難しくなっていました。

３．画面の変更に伴うStorybookのアップデート作業が追いつかなかった問題

エンジニアチームが実装を完了したStorybookの画面デザインは、当時の作業状況からくるメンテナンスの困難さにより、追加の修正が必要な場合、修正案をStorybookを経由せずにチャットなどで共有することが一般的でした。

これら問題の根本的な原因は、エンジニアとデザイナーのチーム間で十分なコミュニケーションが取れていなかったこと、採用係長の技術移行スケジュールにStorybookの運営をする余裕がなかったことにあります。しかし、現時点では技術移行は完了しており、時間に余裕が生まれたため、Storybookの運営やエンジニアとデザイナーのチーム間でコミュニケーションを強化することが可能です。

再構築作業ではどのようなことをしているのか

現在はStorybookを再構築するために以下の活動を行っています。

Storybookなどのモジュールのバージョンアップ作業

採用係長の技術移行後、私たちは利用しているライブラリの大規模なバージョンアップを実施しました。その結果、以前に稼働していたStorybookをそのまま利用することができなくなりました。そのため、現在は最新のバージョンにアップグレードし、スムーズに利用できるように整備を行っています。

小さなコンポーネントの実装状況を明確にするためのカタログ用のコンポーネントの作成(アイコンリスト等)

以前、エンジニアチームが直面していた問題の一つは、「小さなコンポーネントの実装状況がわかりにくい」ということでした。

この課題に対処するために、我々はカタログ用のコンポーネントを作成する取り組みを行っています。Atomic Designの原則に従い、Atomsに相当するコンポーネントを複数のカテゴリに分け、一覧表示できるようなコンポーネントを開発しています。Atomic Designでの他のレイヤーであるmolecules、 organisms、 templates については要望があれば作成する予定です。これにより、小さなコンポーネントの実装状況を明確に把握しやすくすることを目指しています。