Storybook 駆動開発で実現する持続可能な Vue コンポーネント設計 #vuefes

2025年10月25日（土）に開催された「Vue Fes Japan 2025」での発表資料です。

セッションタイトル： Storybook 駆動開発で実現する持続可能な Vue コンポーネント設計
https://vuefes.jp/2025/sponsors/uniquevision#ryutaro-yako

1. Storybook 駆動開発 持続可能な Vue コンポーネント設計 Vue Fes Japan 2025 2025 年 10 月 25 日 矢光 隆太郎
2. 自己紹介 Profile 名前: 矢光 隆太郎 所属: ユニークビジョン株式会社 役割: エンジニア Experience チーム: 7 名のエンジニアが所属するチーム プロジェクト: 業務系 Web アプリ開発で Storybook 駆動を実践
5. 今日お話しすること 1. Storybook 駆動開発とは何か 2. なぜ Storybook から始めるのか 3. 1 年間の実践で得た知見 4. チームでの運用方法 5. まとめと次の一歩
6. フロントエンド開発での課題 手戻りと認識のずれ 実装忘れや開発者間でボールが落ちる、みたいなことが発生しがち 品質の後回し 品質が悪いまま開発完了し、後工程が大変なことになる アドホックな作り変え 設計せずに場当たり的に開発してコード設計が悪化
7. Storybook 駆動開発とは アプローチ Story を先に書いてから実装する開発手法 明確化する内容 コンポーネントの見た目 どんな props を渡すとどんな見た目になるのか コンポーネントの振る舞い どんなインタラクションをするとどんな反応をする のか 開発フロー Story で期待値定義 その通りになるように実装
8. Storybook 駆動ワークフロー 2 ステップアプローチ 設計フェーズ コンポーネント一覧を設計 コンポーザブル一覧を設計 Story を作成 実装フェーズ Story に沿って実装とテストを整備 // コンポーネント - 設計時は props だけ定義 defineProps<{ items: CartItem[]; update: (id: string, quantity: number) => void; }>(); // Story - インタラクションも記述 export const CartWithItems: Story = { play: async ({ canvasElement, args }) => { const canvas = within(canvasElement); const button = canvas.getByRole("button", { name: "Add 1" }); await userEvent.click(button); await expect(args.update) .toHaveBeenCalledWith("item-1", 2); }, };
9. なぜ Storybook から始めるのか 実装忘れと認識ずれを防ぐ 従来のアプローチ 実装 → Story → テスト 手戻りが後から発覚 Storybook 駆動アプローチ Story でテストケースをコード化 実装忘れや認識ずれが減少 既存の開発フローとの適合 社内でもともと Story 作成が推奨されていたため、前フェーズに移動しても無駄な作業が発生しない 別の仕様書を作るとメンテナンス対象が増加するが、Story なら既存フローに適合
10. props ファースト設計が促すもの 整理された設計 インターフェイス定義が最初に固まる → 依存関係や責務が整理される 問題の早期発見 Story を書く段階で曖昧な props 設計や責務の混在に気付きやすい 関心の分離 複雑なコンポーネントでも「表に出す情報」と「裏で処理するロジック」を区別して考えられる
11. 1 年間の実践で得た知見 新規開発ケーススタディ 理解しやすい開発フロー 先に Story を書く → 開発時に自動テストを通すというフローが分かりやすく、すぐにチームに浸透した 書きやすさの改善 チーム内に Story 作成の知見があまりなかったが、汎用的なモック作成・ユーティリティ関数整備・お手本 となる書き方の決定により、抵抗感を解消した
12. チームでの運用方法 Story 作成ベストプラクティスの共有 チーム内で Story の書き方のベストプラクティスを定めたうえで、以下のものを共有している ドキュメント Story 作成のガイドラインやルールを文書化 コードスニペット 効率的な Story 作成のための VSCode Snippet プロンプト AI を活用した Story 作成支援のためのプロンプト集
13. Storybook 駆動導入で変わったこと 実装前の共通認識 コンポーネントの役割の認識が揃った状態で実装に入れるようになった 開発完了時の品質安定 正常系が通らない状態で開発完了してしまうことはなくなった 問題の振り返りやすさ issue 完了条件が明確化したため、バグなど問題が発生したときにどのフェーズで問題があったのかの振り 返りがしやすくなった
14. 開発効率への影響 見積り通りの開発遂行 設計時の見積りに対する実工数の比率で 1.0 以上を維持 見積り通りに開発を遂行する力が向上 総合的な効果 直接的な計測ができていないが、安定した開発サイクルの維持に寄与している実感がある
15. それでも残っている課題 テストパターンの漏れ 各パターンを自動テスト化できていると思いきや、確認できていないパターンがあるときに UI バグが発生 Story作成コスト 開発の 1/4 程度の時間を Story 作成にかけている実績があり、コストは決して軽くない UI がリッチなほど、そのインタラクションを模倣するのに時間がかかる 実装がない状態で Story を書くため、要素の取得方法などを想像で書く必要がある
16. まとめ Storybook 駆動の効果 Story を先に書くことで実装忘れや認識ずれを防ぎ、開発完了時の品質が安定した チーム文化への定着 開発フローがわかりやすくチームに浸透し、ベストプラクティス共有により抵抗感も解消できた コストと効果のバランス 開発の 1/4 の時間を Story 作成にかけるが、見積り通りの開発遂行を実現できた
17. Next Step: LLM フレンドリー化 現状 LLM が Story を参照する方法が限られており、自律的にフィードバックしながらコードを改修させることが できていない 目指す方向性 AI 支援による開発効率の向上を目指したい
18. ご清聴ありがとうございました Powered by