Storybook導入を振り返る

ツール導入前の課題

• UIコンポーネント単体での動作確認が困難
  • コンポーネントをリファクタリングする際、デザイン崩れがないかを確認するには実際のアプリを立ち上げるしかなく、「基本的にほとんどはコードベースでしか変更を確認できていない状況」であった。
• 手動確認への依存と確認コストの増大
  • 「見た目で確認できるし、動いているからOK」という手動確認に依存していた。仕様が複雑化するにつれて確認すべきパターンが増加し、テストデータの再現にも手間がかかるようになっていた。
• PRレビュアーへの負担
  • レビュアーがコンポーネントの見た目・挙動を確認するには、ローカルで立ち上げる手間がかかっていた。
• デグレ検知の仕組みがない
  • VRTやスナップショットテストが存在せず、リファクタリング後の見た目のデグレを自動検知する手段がなかった。
• デザイナーなど他職種がUIを確認できない
  • デザインシステム構築を見据えたとき、エンジニア以外がUIコンポーネントの実態を確認できる共通の場所がなかった。

どのような状態を目指していたか

• 短期：コンポーネント単体での効率的な動作確認
  • propsの変更（String / Number / Boolean）、インタラクション（clickイベントなど）をGUI上で確認できる。
  • Viewport・背景色・多言語切り替えなどのエンハンス機能も活用できる。
  • コンポーネントを変更する際のテンポラリーな確認ツールとしても使用できる。
• 中期：手動確認をコードで置き換えるテスト基盤
  • Play Functionを使い、UIの振る舞い（フォーム入力・ボタンクリック・モーダル開閉など）を自動再現してテストできる。
  • MSWと@graphql-codegen/typescript-mswを組み合わせてGraphQLレスポンスをネットワーク層でモックし、バックエンドなしで統合テストを実行できる。
  • PRごとにStorybookをデプロイしてURLをコメントすることでレビュアーの確認コストを下げる。
• 長期：デザインシステムの合意形成基盤
  • デザイナーもブラウザ越しにUIを確認できる環境（V2でAzure Static Web Appsにホスティング・Azure AD認証でGitHubアカウント不要でアクセス可能）を整備する。
  • コンポーネントカタログを他職種との合意形成の場として活用し、デザインシステム化を推進する。

改善したかった課題はどれくらい解決されたか

• UIコンポーネント単体での動作確認が可能になった。
• Play Functionを活用した統合テストを実装し、手動確認に依存していたUIの振る舞いの一部をコードで保証できるようになった。
• Storybookをホスティングすることで、PRのレビューアー、PdM、デザイナーがローカルにアプリケーションを立ち上げる手間なくブラウザ越しにUIを確認できるようになった。