Storybook でデザインのやりとりを円滑に進める

こんにちは、アルダグラムのエンジニアの影山です。

今回、弊社が開発している KANNA に、カンバン機能を追加することになったのですが、UI の確認を素早く回すために、Storybook ベースで開発を進めていました。

やり方としては、

1. コンポーネント（Atoms、Molecules、Organisms）が完成した段階で Storybook に反映する
2. Pages が完成した段階で Storybook に反映する

と、コンポーネントベースから、ページに展開する形で進めました。

実装が終わったタイミングでもデザインチェックは入りますが、それまでにマイルストーン的にデザインチェックを進められたので、都度都度で細かい修正を改修することができました。

結果としては、早いサイクルで 1. Atoms 、 2. Molecules 、 3. Organisms 、 4. Templates 、 5. Pages 、 6.実装が終わって、テスト環境に反映 まで、それぞれエンジニア側でコードレビュー&UIレビューしてから、レビュー完了時点でデザイナーと確認する形で進められました。

この記事では、 私がトライした Storybook ベースでのデザインやりとりの進め方を書いていきます。

1. コンポーネントが完成したタイミングでレビューを挟む

Atoms ~ Organisms ができたタイミングでデザインレビューも挟みます。ここでは、実際にカンバンで使うコンポーネントを作っていました。

イメージで言うと、 JIRA の DONE のみに出したいコンポーネントや、カンバン型のカード等です。

Storybook の管理方法として、アルダグラムはコンポーネントの粒度に応じて分けています。

COMMON-UI：共通コンポーネント
|
|--- atoms
|
|--- molecules
|
|--- organisms

CHATS：チャットのみで使用するコンポーネント（モジュラーモノリスによるもので、今後もこの形は増える予定）
|
|--- atoms
|
|--- molecules

PAGES：各ページごとのUI
|
|--- 404
|
|--- _error
|
|--- etc....

今回は、Atom コンポーネントが１つ、Molecule コンポーネントが１つ、Organism コンポーネントが１つ作成が必要だと分かったので、下記のような状態ができたタイミングで、レビューに出しました。

最終的には、上記のそれぞれをガッチャンコして、一つのカンバンボードになるのですが、僕自身が細かい単位でレビューをして欲しかったため、このような形を取りました。

コンポーネント単位でレビューを挟むことで、修正する側もレビューがしやすいだろう、と踏んでいました。

実際に Storybook 上のコンポーネントを見てレビュワーから「良いっすね」と言われることはモチベーションの継続にもつながりました。

（とりあえず UI だけでも見せたいけど、API 側が詰まってて中々見せられない…）みたいな状況も Storybook ベースで開発している際には起こらなかったため、心理的にも安全でした。

これに関しては、 Mock Service Worker と共に後述します。

2. Pages ができたタイミングでレビューを挟む

コンポーネントが完成したら、次は Page 部分を作っていきます。

とはいえ、コンポーネントがあるため、残りはカラムの調整だったりで、やることは明確で作業量も少ないイメージでした。

問題なのは、API から取得してきたデータ構造を仮 mock して UI を Storybook 上で表示させたい、ということです。これを組み込むかどうか、で後々の修正量が変わってきてしまいます。

そこで登場するのが Mock Service Worker(msw) です。

Mock Service Worker

msw の詳細は割愛しますが、ネットワークレベルで API リクエストを受け取り、それに応じたモックを返してくれるモックシステムを提供してくれるモノです。

これにより、シームレスに、リクエストAに対して、必ずモックBを返してくれます。

KANNA でも、 Storybook と msw を利用しているため、カラム内にある案件のデータは msw を利用します。

今回のカード型の案件データ API に関しては、既存のモック API が存在したため、そちらをそのまま利用しました。

実際に msw で返されてきたモック API を利用した案件を入れてみると、かなりデザインと合致した UI になってきました。

モックAPI自体が既に別画面で用意されていたことで、再度作成する必要も無かったので、表示部分までテキパキと進められました。

まとめ

普段の開発では、

1. API を用意する
2. API ができたタイミングで Web との疎通を図る
3. UI を作成する

のような流れが一般的だと思います。実際に、私もそのようなフローで開発をしてきました。

初めて Storybook と msw ベースで UI から先に実装しましたが、

1. モックAPI を用意する
2. msw を利用して、モックAPI をもとに先に UI を作成する

ことで、 API 側の実装を待たずに、UI の作成を進められることが分かりました。

仕様が固まっていたり、既存の API で賄えることが自明であれば、UI をまるっと実装してからロジックを入れていく形でも個人的に良いな、と思います。

今回のカンバン機能は１ヶ月ほどかかっている機能作成ですが、少なくともそのスパンでの開発では上手くいきました。

ここまでで、Storybook をベースにした開発は終わりとなり、この後は実際にロジックを突っ込んだりしていますが、Storybook ベースでの開発ではここまで出来れば申し分ないと思いました。