Storybookにてアニメーション実装時のコミュニケーションを効率化する
株式会社くふうカンパニー(くふうカンパニーグループ) / 小汀頌子
メンバー / バックエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2025年6月 | B to B B to C |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2025年6月 |
| 事業形態 | B to B B to C |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
UIアニメーションの実装における関係者間のコミュニケーションに課題があった。
アニメーションは言葉での伝達が難しく、完成までに複数回のコミュニケーションラリーが必要だった。
アニメーションの速度やタイミング等はデザイナー・エンジニアなどの関係者間で膝を突き合わせて調整するのが一番早く、手間を感じていた。
チームにはオフィス出社のメンバーとリモートワークのメンバーが混在しており、なるべく非同期でコミュニケーションできる仕組みの必要性を感じていた。
どのような状態を目指していたか
エンジニア・デザイナー・PdMなど主要な開発関係者間でストレスの少ないコミュニケーションができる状態。
選定理由
- 画面上でUIのプロパティを自由に編集することができ、エンジニア以外でもパターン確認が容易だったこと
- Reactとの相性が良いこと
導入の成果
改善したかった課題はどれくらい解決されたか
アニメーションを実装してデザイナーにレビューを依頼した際に、Storybook上でアニメーション速度やオブジェクトの個数を修正したものをスクリーンショットで返してくれるようになった。

導入までは、アニメーションの仮実装から調整完了まで2,3回のラリーや修正を行うことが普通だったが、デザイナー自身がStorybook上で数値を調整して最適なタイミングを調整してもらえるようになったことで、ほとんど1ラリーでコミュニケーションが完了するようになった。
どのような成果が得られたか
開発スピードが向上した。アニメーションは前述のとおりだが、複数人での並行開発も楽になった。 ページや機能単位ではなくコンポーネント単位でレビューできるようになったことで、部品だけ先行して作成し、ページは別の人が組み立てて後ほどマージするという戦略が取れるようになった。 hoverやclick時の挙動といった、インタラクション表現のすり合わせや考慮漏れの検討などもより早く気付けるようになった。
導入時の苦労・悩み
デザイナー、PdMなど実装者以外も簡単に最新の状態を閲覧できる状態にしたかったため、Storybookをどこに構築するかは検討が必要だった。
Development環境のみで運用すると、普段開発環境を構築しないメンバーが都度最新情報を取得して確認する負担が大きい。一方、Production環境に展開する場合は、社外への意図しない情報露出を防ぐため認可等の対策が必要になる。
今回は対象サービスがNext.jsをVercelで運用されていたため、Vercelのプロジェクトに関係者を招待し、Preview環境で確認できるよう設定した。
VercelのPreviewデプロイフローに乗せるためにpackage.jsonへ設定を追加するだけで実現でき、運用上のメンテナンスコストを抑えつつ、社内に閉じた形で実装者以外も確認しやすい環境を構築できた。
導入に向けた社内への説明
上長・チームへの説明
チームでの検討
チームのデザイナーがNotionでデザインシステムを構築していたタイミングで提案した。 当初は「Storybookは小さいシステムには過剰かも」という意見もあったが、以下の点を伝えて導入を進めた。
- 実装と切り離されたドキュメントはメンテナンス負荷がデザイナーに偏りやすい
- コードと連動する形であれば陳腐化しにくい
- アニメーションのすり合わせ効率化はエンジニア側にもメリットがある
上長への説明
- コミュニケーションコスト削減によるデザイナー・エンジニア双方の工数削減が見込まれる点を説明
- Vercelのシート追加費用(1人月額20ドル)は有料だったが、関係者が少ないプロジェクトだったこと、新規のトライやツール導入に積極的な社風もあり承諾を得られた。
活用方法
主に実装前のSandboxとして活用している。
アニメーションの動きや個別のコンポーネント追加時に、Storyファイルを実装してPullRequestを提出し、Vercel上に作成されるPreviewのURLをデザイナーやPdM等にシェアしてフィードバックをもらい、修正するようにしている。
よく使う機能
@storybook/addon-docs
ツールの良い点
- hoverやclick、アニメーションなどインタラクション表現の確認が可能
- 実際のUIComponentをimportしてStoryデータを作成するため、そのComponentを使う限り実装との差分が発生しない
- Reactの場合Componentに渡すPropsがそのまま変更可能なパラメーターとしてドキュメント登録できるため、可変部分のパターンを自由に試すことができる
- GUI上でパラメーターを変更してUIのパターンを複数検証可能で、エンジニア以外でもスムーズに使いやすい
ツールの課題点
Storyデータは実際の実装に加えて作成する必要があるため、対象パーツや作成のタイミングなどのフローを定義して運用しないと、Storybookがセッティングされているだけになりやすいと感じた。今プロジェクトの場合は、新規の動的なComponentを追加する際は、パーツから実装してデザイナー確認のフローを通すことで、Storybookを有効活用できるよう進めている。このやり方であれば、早いし手戻りが少ないと実感したゆえの運用なのでノウハウとして残しておくことが大事だと考えている。
今後の展望
Figma MCPやStorybook MCPなどを連携させた開発効率化。実装とStorybookの同期は取れる環境を作ったので、Figmaとも連携できるようにしたい。
株式会社くふうカンパニー(くふうカンパニーグループ) / 小汀頌子
メンバー / バックエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
株式会社くふうカンパニー(くふうカンパニーグループ) / 小汀頌子
メンバー / バックエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名


