Storybookをホスティングしてレビューが爆速になった話

こんにちは、エンジニアリングマネージャーの岡村です。
社員全員テレワークの環境にも慣れてきて、ワークフロー改善と共にREADYFORの開発環境も日々改善しております。

概要

StorybookをNetlifyへホスティングすることで、PR単位でデプロイされるためデザインの確認・レビューがとても楽になったので紹介です。

導入の背景

READYFORのアーキテクチャ上もっとも有効だった

f:id:resqnet:20200612113037p:plain

ざっくりREADYFORのフロントエンドアーキテクチャはReact On RailsとElements(UI Library)で構成されており、デザイン手法にAtomicDesignが採用されています。 Elements(UI Library)はDesignSystemの一部として構成され、ドメインに依存しないコンポーネントはElementsへ開発しています。そのため、確認をする際にはElementsのコンポーネント・READYFORのコンポーネントをそれぞれに確認する必要があります。

レビューコストがかかっていた

コンポーネントデザインを同じ粒度で確認できるようにStorybookを導入しています、しかし、デザイナー・PMへのレビューを行うための環境作成コストは負荷がありました。

f:id:resqnet:20200612112853p:plain PRをレビューブランチに反映or画面共有で確認してもらう必要があった。

弊社ではスクラム開発を採用しているため、スプリントレビュー時に都度この工数が発生していた。また、開発中に確認をしてもらうのにその場で画面を見せたり（今だとハングアウト・Zoomなど）していました。

Storybookをホスティングし解決

この問題を解決するためにNetlifyのPR Previewを利用しました。
これによりPR毎にStorybookをbuildすることでPR単位のレビューが安易になりました。

f:id:resqnet:20200612112905p:plain デザイナーはURLを共有することでいつでも確認が可能です。

URLはGitHubのPRにリンクが貼られるためデザイナーからのレビューもPR上で行いやすくなります。

現場デザイナー・PMインタビュー

実際に現場のデザイナー・PMへStorybookについて聞いてみました

PM（江藤さん）

個人的には「レビューが手軽にできるようになった」がメリットだと感じています！もしStorybookがないとすると... テスト環境に上げる工数がかかるテスト環境の数自体が限られているので、同時に複数Issueを進める場合に利用環境の調整コストもかかるので、この2つのコストが抑えられているのがデカイと思います。
上記2つのコストが抑えられた結果として... 「とりあえず動くものを作ってPMに見せちゃおう」となり、 PM-ENG間のコミュニケーション量が増えて、認識の齟齬が早期に解消できるようになったと思います！
デザイナー（今野さん）

Figmaのコンポーネントと名称を統一しているため、コミュニケーションがしやすいです。またボタンのHover, Activeなどトランジションを確認しやすく、検索機能や、リストの階層化などあってFigmaより探しやすいです。拡大機能や、背景色を変更できるので、実装後の気づきを発見しやすくなります！

エンジニア同様、デザイナー・PMさんもエンジニア同様確認するコストが減った印象があるようです。
確認・ブラッシュアップの工数はすごく重要だと思います。このイテレーションが早くなるのは効果的だと思えます。