Storybookで変わる静的サイト開発〜HTML/CSSコンポーネントの効率的な管理手法〜

あなたはHTML/CSSで静的サイトを制作していますか？サイトの規模が大きくなるにつれ、同じようなパーツの管理や修正が徐々に難しくなってきた経験はありませんか？

「Reactのようなフレームワークを導入するほどでもないけど、もう少し効率的に開発したい…」

そんなフロントエンド開発者の方に、StorybookでのHTML/CSSコンポーネント管理をご提案します。

実際の現場は、最初はプレーンなHTMLとCSSとJSで作ってそこからwordpressにしたり、VueやReactのフレームワークにしたりすることも意外と多いです。

Figmaで作ったデザインからコンポーネントを抽出するような作業もあるので、静的サイトでコンポーネント管理ができるのは時間を使ってもそれなりの結構なメリットだと思っています。

静的サイト開発でよくある課題
Storybookによる解決策
本記事の構成
さいごに
次回予告：Storybookで変わる静的サイト開発 [環境構築編]

静的サイト開発でよくある課題

デザインの一貫性

ボタンやカードのデザインがページごとに微妙に異なる
「このページのボタンデザインを使おう」というコピペ開発
色やサイズの指定が統一されていない

デザインの一貫性が失われる原因は、多くの場合「コピー&ペースト」の開発手法にあります。最初は同じデザインでも、ページごとに少しずつ変更が加えられ、いつの間にか統一感が失われていきます。

運用を続けていくと、ほぼ同じデザインなのに微妙に違う（例えば、角丸が8pxだったり6pxだったり、線の太さが1pxだったり2pxだったり・・・）ものが大量発生しているんですよね。コーダーだけの理由ではなくて。

メンテナンスの難しさ

ヘッダーのデザインを変更するために全ページを修正
CSSの影響範囲が把握できず、修正が怖い
新規ページ制作の度に過去のコードを参照

「ヘッダーを少し修正しただけなのに、なぜか他のページのレイアウトが崩れる…」

こんな経験をしたことはありませんか？HTMLとCSSが密結合した従来の開発手法では、小さな変更でも影響範囲の特定が難しく、修正に多くの時間を要します。

チーム開発での課題

設計意図が伝わらない
コーディングルールの統一が難しい
新メンバーの教育に時間がかかる

「このクラス名はどういう意図で付けられているんだろう？」「このマークアップ構造には何か理由があるのかな？」

ドキュメントが不足していると、チームメンバー間で認識の齟齬が生まれやすく、結果として非効率な開発につながります。

Storybookによる解決策

Storybookを導入することで、これらの課題を以下のように解決できます：

1. コンポーネントベースの開発

HTML

<!-- button.stories.js -->
export default {
  title: 'Components/Button',
};

export const Primary = () => `
  <button class="btn btn-primary">Primary Button</button>
`;

パーツをコンポーネントとして切り出して管理することで：

慣れるとすごく楽なんですが、ページ単位の構築をコンポーネントベースの構築に変更するって、結構な考え方の違いになるところは難しいと思います。はい。

デザインの一貫性が保ちやすい
変更の影響範囲が明確
再利用が容易

2. ビジュアルでの確認

Storybookの特徴的な機能として、コンポーネントを視覚的に確認できる開発環境を提供します：

状態（hover, active, disabled）の一括確認
レスポンシブデザインのプレビュー
アクセシビリティのチェック

3. 自動ドキュメント生成

HTML

// button.stories.js
export default {
  title: 'Components/Button',
  parameters: {
    docs: {
      description: {
        component: 'プライマリーアクション用のボタンコンポーネント'
      }
    }
  }
};

コードと一緒にドキュメントを管理できるため：