あなたのWebサイト開発、こんな「非効率」に陥っていませんか？
企業のWebサイトは、今やビジネスの中核を担う重要な資産です。しかし、その裏側にある開発プロセスには、いまだに多くの非効率や課題が潜んでいます。特に、従来のデザインカンプ（静止画）を基点としたウォーターフォール型の開発では、以下のような問題が頻発していないでしょうか。
問題1：デザインカンプと「実際の動き」が違う
静的なデザインカンプは完璧に見えても、実際のブラウザで操作した際の「動き」（ホバーエフェクト、アニメーション、レスポンシブ対応）までは表現しきれません。開発終盤になって「イメージと違う」「この操作感が悪い」といったフィードバックが発生し、UIの調整に膨大な時間が費やされます。
問題2：開発終盤での「手戻り」とコミュニケーションコスト
「カンプと違う」問題は、必然的に「手戻り」を発生させます。エンジニアは実装したコードを修正し、デザイナーは意図を再度説明し、プロジェクトマネージャーはスケジュール調整に追われる。このコミュニケーションコストと手戻りの連鎖が、プロジェクトの品質と士気を著しく低下させるのです。
問題3：バックエンド（API）待ちで開発がストップする
多くのWebサイトでは、CMS（WordPressなど）や外部システムからデータを取得（API連携）して情報を表示します。しかし、従来の開発フローでは、そのAPIが完成するまでフロントエンド（見た目）の開発が進められない「API待ち」状態が発生しがちです。これにより、フロントエンドエンジニアが手待ちになり、プロジェクト全体のスケジュールが遅延します。
その開発プロセス、「機会損失」と「技術的負債」を生み続けています
これらの問題を「開発とはそういうものだ」と放置してしまうと、ビジネスに深刻な影響を与えかねません。
スピードの遅れがビジネスの足かせに
市場のニーズは日々変化しています。手戻りやAPI待ちで開発スピードが遅れれば、競合他社に先を越され、貴重なビジネスチャンスを逃すこと（機会損失）につながります。
「作って終わり」のサイトは”腐っていく”
場当たり的な修正と複雑な依存関係で構築されたWebサイトは、「技術的負債」の塊となります。結果として、「軽微な修正にも多大な工数がかかる」「セキュリティが脆弱になる」「新しい機能を追加できない」といった、”腐った”状態に陥り、将来的な成長を阻害します。
解決策は「UI先行開発」と「モダンな技術スタック」の融合
私たちは、これらの課題を根本から解決するために、技術スタックと開発プロセスをゼロから見直しました。その答えが、「Next.js」と「StorybookによるUI先行開発」の組み合わせです。
Next.jsがもたらす「圧倒的な表示速度」と「優れた開発体験」
Next.jsは、現代のWeb開発におけるデファクトスタンダードとも言えるフレームワークです。
- サーバーサイドレンダリング（SSR）と静的サイト生成（SSG）:
サーバー側でページを生成することで、ユーザーへの初期表示速度を劇的に高速化します。これは、Googleが重要視するCore Web
Vitals（コアウェブバイタル）のスコア向上、すなわちSEO評価の向上に直結します。 - 画像最適化:
next/imageコンポーネントが、画像を自動的に次世代フォーマット（WebPなど）に変換し、デバイスサイズに合わせた最適化を行うため、パフォーマンスが向上します。 - 優れた開発体験（DX）:
ルーティングの自動化、高速なリロード機能（Fast Refresh）など、開発者がストレスなく開発に集中できる環境を提供します。
Storybookが実現する「UIの分離」と「品質担保」
Storybookは、UIコンポーネント（ボタン、カード、ヘッダーなど）をアプリケーション本体から「分離」して開発・管理・テストするためのツールです。
Storybookを活用することで、以下が可能になります。
- UIのカタログ化:
サイト内で使用する全コンポーネントを一覧化し、どのような状態（例：通常時、ホバー時、エラー時、データが空の場合）があるかを可視化できます。 - 並行開発の実現:
APIが未完成でも、ダミーデータを使ってUIコンポーネントの開発を先行できます。デザイナーやディレクターは、開発中のコンポーネントをStorybook上で直接確認し、フィードバックを行えます。 - 品質の担保:
コンポーネント単位でビジュアルリグレッションテスト（見た目の崩れを自動検知するテスト）を行うことで、意図しないデザイン崩れを防ぎます。
「UI先行開発」が最強である理由：スピードと品質の両立
Next.jsとStorybookを組み合わせた「UI先行開発」とは、「まずUIコンポーネントをStorybookで完璧に作り、それをNext.jsのページに組み込んでいく」開発手法です。
この手法により、従来の開発が抱えていた問題が次のように解決されます。
【課題】カンプと動きが違う
【解決】Storybook上で「動くコンポーネント」をレビューするため、「イメージと違う」が開発初期に解消される。
【課題】API待ちで開発がストップ
【解決】StorybookとダミーデータでUI開発を先行。API完成後は繋ぎ込むだけで良いため、手戻りなく並行作業が可能になる。
【課題】終盤の手戻りと品質低下
【解決】UIの品質はStorybookで担保済み。Next.js側は機能連携に集中でき、開発スピードと品質が両立する。
全貌公開：次世代基盤「tosakaworks-nextjs」の開発ポリシー
私たちは、この「Next.js + Storybook」の思想をさらに昇華させ、将来の品質担保までを見据えた開発基盤「tosakaworks-nextjs」を構築しました。この基盤は、単なる技術の寄せ集めではなく、堅牢な開発プロセスを実現するための「設計思想」そのものです。
なぜこの技術スタックを選んだのか？（選定理由）
私たちの基盤は、実績があり、かつ将来性のある技術を厳選しています。
技術・ライブラリ | 選定理由 |
|---|---|
Next.js | ルーティング、画像最適化、ISRなどモダンなWeb機能の活用。圧倒的なパフォーマンスとSEO基盤。 |
Storybook | UIコンポーネントの分離開発、ドキュメント生成、インタラクションテストの基盤。 |
SCSS (CSS Modules) + FLOCSS | FLOCSSという設計規律とCSS Modulesによるスコープの封じ込め。再現性が高くスケールしやすいスタイリングを実現。 |
next-sitemap | サイトマップ/robots.txtの自動生成によるSEO基盤の強化。 |
DOMPurify | ヘッドレスCMS（WordPress等）から取得したHTMLを安全に表示（`dangerouslySetInnerHTML`）するためのXSS対策（サニタイズ）。 |
Resend + reCAPTCHA v3 | お問い合わせフォームのモダンなメール送信（Resend）と、ユーザー体験を損なわないスパム対策（reCAPTCHA v3）の実現。 |
JSON-LD構造化データ | Schema.orgに準拠した構造化データを実装し、検索エンジンへの情報伝達を最適化。 |
理想的な開発フロー：StorybookからVercelデプロイまで
「tosakaworks-nextjs」では、開発フローをVercelとGitHubによって高度に自動化・効率化しています。
- ① StorybookでのUI開発 (ローカル):
エンジニアはまずStorybook上でUIコンポーネントを開発します。 - ② 作業ブランチのPush:
開発した内容をGitHubの作業ブランチ（例:feature/new-button）にPushします。 - ③ Vercelによるプレビューデプロイ (自動):
Pushをトリガーに、Vercelが自動でプレビュー環境を構築します。関係者は実際のURLにアクセスし、本番とほぼ同じ環境で動作確認ができます。 - ④ レビューとマージ:
プレビュー環境で問題がないことを確認し、`main`ブランチにコードをマージ（統合）します。 - ⑤ Vercelによる本番デプロイ (自動):
`main`ブランチへのマージをトリガーに、Vercelが自動で本番環境へのビルドとデプロイを実行します。
このフローにより、「`main`ブランチ = 常に正常に動作する本番環境」という安定性を保ちつつ、迅速なプレビューとデプロイが可能になります。
将来を見据えた「品質担保戦略」（CI/CDとテスト）
開発基盤は、リリース時がゴールではありません。私たちは、将来的な機能拡張やメンテナンスに耐えうる「品質担保戦略」を初期設計に組み込んでいます。
CI/CD (継続的インテグレーション/継続的デリバリー)
現在はVercelによるCD（デリバリー）が有効ですが、将来的にはCI（インテグレーション）を強化します。GitHub
Actionsを利用し、`main`ブランチへのマージ前に「lint（構文チェック）」「typecheck（型チェック）」「test（自動テスト）」を必須化。品質基準を満たさないコードが本番にデプロイされることを防ぎます。
- 型安全 (Zod):
APIから取得するデータが想定通りの形式（型）であるかをZodライブラリで検証。予期せぬデータによるエラーを防ぎます。 - 自動テスト (Vitest/Jest):
コンポーネントやロジックが正しく動作するかをコードでテスト。手動での確認漏れをなくし、機能改修時の「デグレード（既存機能の破壊）」を恐れずに開発を続けられます。
このような拡張性をあらかじめ設計に組み込むことで、「tosakaworks-nextjs」はビジネスの成長に合わせてスケールし続けることが可能です。
