こんにちは。開発本部でインターンをしている桐澤です。インターンの業務では主にReactにリプレイスされたページのリファクタリングやコンポーネント修正を行ってきました。 今回はReactで実装されたコンポーネントを誰でも簡単に参照できるようにStorybookを導入したので、どのように行ったかを紹介します。
はじめに
PR TIMESではデザインチームを中心に去年からデザインシステムを構築してきました。デザインシステム導入当初からデザインと実装されたコードの連携が構想にあり、今回フロントエンドの開発基盤が整ったタイミングでStorybookの導入を行いました。
Storybookとは？
StorybookとはUIのカタログ作成ツールです。コンポーネントというUIのパーツ単位での挙動が確認でき、開発面ではコンポーネント単体での開発を可能にしてくれます。Storybookでは、以下の画像のようにそれぞれのコンポーネントごとにデザイン・挙動を確認できます。
実際の動作は以下の公式で紹介されているStorybookを参考にしてください。
どのように導入をしたのか
Storybookの導入は、デザインチームとフロントチーム共にメインで行っている業務の合間で行うため小さく導入していく方針になりました。
Storybook導入のゴール設定
最初はデザインで意図されていた挙動と実装されたコンポーネントの挙動に乖離がないかを確認できれば良いとチームで合意したため、「すでに実装されているコンポーネントのみ最低限のストーリーを書くこと」を導入のゴールにしました。
今後、運用フローやコンポーネントが整ってきたタイミングなどでStorybookを活用したテストも行いたいと考えていますが、今回は導入を小さく始めたいのでゴールからは外しました。
Storybook関連のタスクを開発フローに組み込む
PR TIMESの開発本部では、開発作業完了後にレビューやQAをするといった開発フローを明確に定義しています。この開発フローにStorybook関連のタスクをどう組み込んだのか紹介したいと思います。
PR TIMESの開発フローではタスクの種別ごとにレビューやQAがあるかどうかを定義しています。
- 「作業・調査タスク」：ユーザーに影響がないタスクを取り扱う、QAを必要としないタスク
- 「開発タスク」：本番リリースを行いユーザーに影響がある、QAが必要なタスク
この2つのタスク種別のうち、ストーリーファイルの追加と更新のみの変更は、ユーザーへの影響がないと判断し「作業・調査タスク」として行いました。このタスクではフロントチームによるコードレビューのみ行いQAはなしで本番ブランチにマージしてリリースできるようにしました。
ストーリーを追加してみると、デザイン時に意図していた挙動と異なったり、未実装だけどデザインは用意されている差分があることがわかったので、コンポーネント自体を修正する必要が出てきました。
コンポーネントに修正変更があるとユーザーに影響があるため、開発タスクとしてQAありでリリースを行うフローにしました。
これによって、既存の開発フローでStorybook関連のタスクも管理できるようになりました。
導入初期のストーリーはエンジニア＆デザイナーで協力して作成
現状、すでにデザインシステム運用開始から1年以上経っており、デザインと仕様が定義済みのコンポーネントが多く、新しいコンポーネントが増える機会はあまり多くありません。そのため、コンポーネントが増えるたびにストーリーを増やす運用時より、既存のコンポーネントのストーリーを一通り用意する導入時の工数が大きくなることが予測されました。
デザインチームとフロントチームで話し、Storybook導入時の既存コンポーネントのストーリーを量産する際は、フロントチームだけでなくデザインチームもストーリーの作成をする形を取りました。 デザインチームがプロトタイプやLP以外のコードを書くのは初めての試みとなります。
導入時のStorybookの開発フローをまとめると
- 不備がある既存のコンポーネントでもそのままの状態でストーリーを書き、ありのままの実装状態がわかるようにする
- コンポーネント修正が必要と決まった箇所は、デザイナーとエンジニア・QAで協力して修正する
という方法をとっています。
プルリクエスト上でStorybookが見られるようにする
Storybookの基盤を整備した時に工夫した点は、GitHub ActionsによりプルリクエストでもStorybookの変更箇所を確認できるようにしたことです。
今回作ったGitHub Actionsは、.stories ファイルに変更のあるプルリクエストに対して以下の画像のようにキーワードがコメントされると、そのプルリクエストの変更を取り込んだStorybookをAWS S3にアップロードしてURLを返信します。
Storybookによって解決が期待できること
Storybookの導入が進めばコンポーネント単位で実装を確認することができるようになるので、
- コンポーネント単位でスタイルや挙動をデザイン・QAチームが確認できることでUXを向上させる
- フロントエンドエンジニアの車輪の再発明を防ぎ、一貫性のあるUIがスピーディーで確実に作れるようになる
ことを期待しています。
次に解決したい課題
PR TIMESという1つのプロダクトではありますが、現状いくつかのプロジェクトに分かれておりそれぞれのコードベースで作業しています。
今回は小さく導入しStorybookの運用フローを確立していくために「企業ページ」プロジェクトに導入をしました。現在はまだ、プロジェクト間で共通のコンポーネントを再利用する状況にはできていません。今後、フロントエンドの開発基盤を整えてプロジェクト間でコンポーネントを再利用できるようになれば、Storybookによって一貫性のあるUIを高速で作る効果もさらに上がると期待できます。引き続きフロントエンドチームで取り組んでいきたい課題です。
まとめ
今回Storybook導入を通して様々なことに挑戦させていただきました。開発基盤の実装だけでなく、チームを巻き込んでどうやるか考えるところから経験させていただいたことは自身の成長に繋がったと思います。 Storybook自体はまだ導入を始めた段階です。これから一つ一つ進めてプロダクトに良い影響を与えられるようにしていきたいです。
