第3部まとめ
このページで学ぶこと
Section titled “このページで学ぶこと”- HTML・CSS・JavaScriptからフレームワークまでのつながり
- 技術名ではなく、サイトの性質から構成を選ぶ方法
- レンダリング方式とビルド・ホスティングの関係
- モダン技術を採用する価値と増える運用コスト
- 技術提案をレビューする質問
第3部の全体像
Section titled “第3部の全体像”flowchart TD
REQ[サイト要件]
REQ --> BASE[HTML・CSS・JavaScript]
BASE --> NEED{UI・状態は複雑か}
NEED -->|小さい| SIMPLE[軽量構成・部分JavaScript]
NEED -->|大きい| FW[UIフレームワーク]
FW --> META[アプリケーションフレームワーク]
SIMPLE --> RENDER[レンダリング方式]
META --> RENDER
RENDER --> BUILD[ビルド]
BUILD --> HOST[静的ホスティング・サーバー・サーバーレス]
フレームワークを先に決めず、要件から順に考えます。
この部で学んだ判断軸
Section titled “この部で学んだ判断軸”- コンテンツ中心か、操作中心か
- 再利用部品が多いか
- 状態変化が複雑か
HTMLの生成
Section titled “HTMLの生成”- ブラウザで作るか
- アクセス時にサーバーで作るか
- ビルド時に作るか
- 後からページ単位で再生成するか
- CMS更新は何分で反映するか
- 全体ビルドが必要か
- プレビューはどうするか
- キャッシュをどう更新するか
- ブラウザへ送るJavaScript量
- 初期表示
- 画像・フォント
- API・サーバー応答
- ビルド時間
- 技術を保守できる人
- パッケージ・Node.js更新
- ホスティング
- 障害切り分け
- ロールバック
技術選定の基本フロー
Section titled “技術選定の基本フロー”flowchart TD
A[ページ・機能要件を整理] --> B{操作・状態が複雑か}
B -->|いいえ| C[HTML中心・必要箇所だけJavaScript]
B -->|はい| D[UIライブラリを検討]
C --> E{更新・SEO・個別表示}
D --> E
E --> F[CSR・SSR・SSG・再生成を比較]
F --> G[ビルド・ホスティング・CMSを確認]
G --> H[開発・公開・保守費用を比較]
H --> I[推奨案と不採用理由を文書化]
「モダンな構成」の意味
Section titled “「モダンな構成」の意味”モダンという言葉は曖昧です。次の特徴をまとめて指すことがあります。
- コンポーネント化
- Git・レビュー
- 自動ビルド
- CI/CD
- ヘッドレスCMS
- API連携
- 静的生成
- サーバーレス
- CDN
- テスト自動化
新しい技術を多く使うことが目的ではありません。要件に対し、品質・開発・運用を改善することが適切なモダン化です。
ケーススタディ1：ブランドサイト
Section titled “ケーススタディ1：ブランドサイト”- 約30ページ
- 年数回の更新
- アニメーションが多い
- CMS不要
- 公開期間3年
ReactやNext.jsの全面導入は可能ですが必須ではありません。
- HTML＋CSS＋必要なJavaScript
- Astro等で静的生成
- アニメーションライブラリの部分利用
を比較します。
- アニメーションの性能・アクセシビリティ
- 更新担当がビルドできるか
- 依存ライブラリの更新
- 3年後の改修
ケーススタディ2：施設検索サイト
Section titled “ケーススタディ2：施設検索サイト”- 施設一覧・詳細
- 地図・条件検索
- お気に入り
- CMS更新
- SEOが重要
一覧・詳細はSSG・SSR、検索はCSR、CMS更新は再生成等の組み合わせが考えられます。
技術名より、検索条件URL、APIエラー、詳細ページHTML、更新反映、JavaScript量、将来機能との整合を比較します。
ケーススタディ3：大規模メディア
Section titled “ケーススタディ3：大規模メディア”- 10万記事
- 頻繁な更新
- アクセス集中
- 多言語
- 広告・計測タグ多数
全ページSSGだけではビルド時間が課題になる可能性があります。
- オンデマンド再生成
- 更新記事だけ再生成
- SSR＋キャッシュ
- 静的・動的の混在
を比較します。
フレームワーク以外にCMS API、検索、画像、CDN、広告タグ、プレビュー運用が重要です。
ケーススタディ4：業務管理画面
Section titled “ケーススタディ4：業務管理画面”- ログイン必須
- 操作・入力が多い
- SEO不要
- 複数API
- 権限あり
- 長期継続開発
SPAやWebアプリ向けフレームワークの価値が高い領域です。状態管理、フォーム、権限、エラー、API、E2Eテスト、チーム標準を重視します。
技術提案レビューの質問
Section titled “技術提案レビューの質問”- この技術で何を解決するのか
- 導入しない場合に何が困るのか
- フレームワークなしでは成立しないか
- 他の候補は何か
- 不採用理由は何か
- CSR・SSR・SSGのどれか
- ページごとに違うか
- CMS更新から何分で反映するか
- プレビューはどうするか
- 通常・最大ビルド時間
- 失敗原因と通知
- 以前の版を維持できるか
- 依存パッケージの更新
ホスティング
Section titled “ホスティング”- 静的配信か、実行サーバーが必要か
- 特定サービスへ依存するか
- 月額・従量費用
- 移行可能性
- 経験者・レビュー担当は誰か
- 保守担当は誰か
- メジャー更新を誰が行うか
第3部PMチェックリスト
Section titled “第3部PMチェックリスト”- HTML・CSS・JavaScriptの役割を理解している
- 意味構造を品質対象にしている
- フレームワーク採用目的を説明できる
- フレームワークなしの案と比較している
- UIライブラリとアプリケーションフレームワークを区別している
- レンダリング方式をページごとに把握している
- CMS更新・プレビュー・キャッシュの流れを確認している
- 本番データ量でビルド時間を把握している
- 依存パッケージとNode.jsの更新担当を決めている
- JavaScript量・初期表示を性能要件にしている
- ビルド失敗時に旧版を維持できる
- 技術選定理由と不採用理由を残している
よくある失敗のまとめ
Section titled “よくある失敗のまとめ”技術名から設計を始める
Section titled “技術名から設計を始める”「Next.jsを使う」「React化する」が先に決まり、要件・運用が後回しになります。
開発時の便利さだけを見る
Section titled “開発時の便利さだけを見る”公開時間、ビルド、依存更新、保守人員、ホスティング費用を含めて判断します。
デモデータだけで性能を判断する
Section titled “デモデータだけで性能を判断する”実ページ数、画像、CMS、API、広告タグ等で測定します。
フレームワーク導入を全面リニューアルと同義にする
Section titled “フレームワーク導入を全面リニューアルと同義にする”一部分への段階導入も選択肢です。
「静的」「動的」を単純な二択にする
Section titled “「静的」「動的」を単純な二択にする”ページ・部品単位で混在できます。混在による複雑さも管理します。
理解度チェック
Section titled “理解度チェック”Q1. フレームワーク選定を何から始めますか。
Section titled “Q1. フレームワーク選定を何から始めますか。”回答と解説
コンテンツ量、操作・状態、更新、SEO、性能、チーム、運用期間、ホスティング、費用等の案件条件から始めます。Q2. コーポレートサイトでReactを使うと言われたら何を聞きますか。
Section titled “Q2. コーポレートサイトでReactを使うと言われたら何を聞きますか。”回答と解説
使う範囲、Next.js等との組み合わせ、レンダリング方式、JavaScript量、CMS反映、ビルド、保守体制、採用理由です。Q3. SSG採用時に実データで確認するものは何ですか。
Section titled “Q3. SSG採用時に実データで確認するものは何ですか。”回答と解説
本番相当ページ数・画像・多言語・CMSデータでのビルド時間、失敗、プレビュー、デプロイ、キャッシュ反映です。Q4. 「Astroは高速、Next.jsはSEOに強い」だけで選定できますか。
Section titled “Q4. 「Astroは高速、Next.jsはSEOに強い」だけで選定できますか。”回答と解説
不十分です。生成方式、JavaScript量、CMS、ホスティング、チーム、更新・障害・費用を比較します。Q5. フレームワーク導入で増える長期作業は何ですか。
Section titled “Q5. フレームワーク導入で増える長期作業は何ですか。”回答と解説
依存パッケージ・Node.js更新、メジャーアップグレード、ビルド・CI保守、性能改善、テスト、経験者確保、ホスティング仕様対応です。第4部へ進む前の確認
Section titled “第4部へ進む前の確認”次を説明できれば、第3部の基礎は理解できています。
- HTML・CSS・JavaScriptの役割
- MPAとSPA
- フレームワークが必要になった背景
- UIライブラリとアプリケーションフレームワークの違い
- React・Vue・Angular・Svelteの位置づけ
- Next.js・Nuxt・SvelteKit・Astroの役割
- CSR・SSR・SSG・ISRの生成タイミング
- ビルドとデプロイの違い
- 依存パッケージとNode.jsを更新する理由
- 技術を案件条件で比較する方法
次の第4部では、Webサイトが外部データを受け渡すAPIと、コンテンツを更新するCMSを学びます。