HTML / CSS / JavaScript と CMS — 「人物」シリーズで丸ごと理解する
この記事でわかること
ここまでで、ドメイン・サーバ・SSL という「土台」の話が終わりました。 この Lesson からは、サイトの「中身」の話に入ります。 HTML・CSS・JavaScript・CMS — このあたりの言葉が、業者との会話で必ず飛び交います。 細部のコードを書けるようになる必要はありません。 「何のためにあって、何ができて、何ができないか」を、例え話でしっかり押さえましょう。
1. このガイドブックの例えシリーズ — 「Web サイト=人物」
本書では、Web サイトを 「人物」 に例えて説明していきます。 一度この例えが腑に落ちると、後の章でも繰り返しこの世界観が出てきます。 覚えやすいので、ぜひ自分の中に取り込んでください。
- HTML=その人自身(中身・骨格)
- CSS=服装(見た目)
- JavaScript=特技(動き)
- CMS=「その人が自分で着替えたり、新しい芸を覚えたりできる仕組み」
この後の H2-2 から H2-4 で、それぞれを順に「人物」になぞらえて説明します。 第 4 章のデザインの話、第 5 章のコンテンツの話、第 8 章の運用の話 — 至るところで「この服装で…」「この特技は…」という表現で戻ってきます。 例え話なので、厳密には少しずれるところもあります。 でも、業者との会話で意思疎通を図る目的なら、これで十分です。
2. HTML — その人「自身」、サイトの中身
2-1. HTML の役割
HTML(HyperText Markup Language)は、サイトの 中身 を作る言語です。 具体的には、文章のどこが「見出し」で、どこが「段落」で、どこに「画像」が入るか、を構造化します。 タグと呼ばれる印を付けて、ブラウザに「これは見出しですよ」「これは画像ですよ」と伝えるイメージです。 HTML が無ければ、サイトの中身そのものが存在しません。
2-2. 「人(=HTML)」を見れば、その人がどんな人か分かる
人物に置き換えるとわかりやすいです。 服装(CSS)を着替えても、特技(JS)を披露しなくても、その人自身は変わりません。 HTML はその「変わらない中身」です。 サイトの主張、提供する情報、構造的な意味 — これらはすべて HTML に記述されています。 つまり、HTML を見れば、そのサイトが何のために存在するかが本質的にわかる、ということです。
2-3. 担当者が見抜けるべきポイント
HTML を自分で書ける必要はありません。 でも、業者から「H1 タグを最適化しています」「見出し構造を整えました」と言われたとき、何を意味するかは分かったほうがいいです。 特に 見出しタグ(H1〜H6)が適切に使われているか は、SEO とアクセシビリティに直結します。 Lesson 6-3 で詳しく扱いますが、見出しの階層がぐちゃぐちゃのサイトは、検索エンジンにも読み上げソフトにも伝わりません。 担当者の役は「適切な見出し構造になっているかを業者に確認させる」ところまでです。
3. CSS — 「服装」、見た目を整える
3-1. CSS の役割
CSS(Cascading Style Sheets)は、サイトの 見た目 を決める言語です。 文字の色、余白、文字の大きさ、要素の並び方、レイアウト、装飾 — このあたりを担当します。 HTML が中身、CSS が見た目、と覚えてください。
3-2. 「同じ人でも、服装で印象が変わる」
人物に例えると、CSS は服装です。 同じ人でも、スーツを着るのとカジュアルな服を着るのでは、第一印象が全然違いますよね。 Web サイトでも同じことが起きます。 WordPress を使っていれば、テーマ(=デザインのセット)を変えるだけで、同じ記事が別のサイトのように見えます。 中身(HTML)は同じなのに、見た目(CSS)で印象が変わる。 この「中身と見た目を分けられる」のが、Web の強みです。
3-3. 担当者ができる範囲とできない範囲
色の調整やテーマ選びくらいなら、担当者が CMS の管理画面からできます。 でも、レイアウトの大幅な改造、複雑なアニメーション、複数デバイスへの最適化は、業者領域です。 Lesson 1-1 でも書いたとおり、ここを担当者が自分で頑張ると、本業が止まります。 「色の変更」「画像の差し替え」までを自分で、それ以上は業者に依頼、というのが現実的な線引きです。
4. JavaScript — 「特技」、動きを与える
4-1. JavaScript の役割
JavaScript(JS)は、サイトに 動き を加える言語です。 画像のスライダー、フォームの入力チェック、ハンバーガーメニューの開閉、チャットボット、ポップアップ — このあたりは全部 JS が動かしています。 HTML(中身)と CSS(見た目)の上に、JS(動き)が乗る、というイメージです。
4-2. 「特技が多すぎる人は会うのに疲れる」
人物の例えに戻ります。 JS は「特技」に相当します。 特技がいくつかある人は魅力的ですが、初対面で全部の特技を披露されると相手は疲れますよね。 Web サイトでも同じです。 JS を盛り込みすぎると、ページの読み込みが重くなり、特にスマホで遅くなります。 結果として、訪問者は読み込みを待ちきれずに離脱します。 Lesson 1-6 でレスポンシブと UX の話を深掘りしますが、「特技多すぎ問題」は、そこで何度も登場します。
4-3. 必要最低限の特技で勝負する
JS の使い方の基本姿勢は「派手な動きより、目的を達成する動きを」です。 たとえばコーポレートサイトのトップに、スライダー(画像が次々と切り替わる動き)を入れることがよくあります。 華やかに見える反面、訪問者がどの画像も読み切れずに離脱しがちです。 「動かさない」という選択肢が正解のケースは、実は多いのです。
5. CMS=「自分で着替えと芸を更新できる」仕組み
5-1. CMS とは
CMS(Content Management System)は、サイトの中身を 管理画面から更新できる 仕組みです。 HTML を直接書かなくても、ブログ記事を投稿するように、テキストや画像を更新できます。 人物の例えで言うと、その人が 自分で着替えたり、新しい特技を覚えたりできる仕組み です。 業者を介さずに、社内で更新できるようになる、というのが大きな売りです。
5-2. 代表例
- WordPress:世界・国内ともに最も普及している CMS。プラグインで機能拡張できる柔軟性が強み。
- MovableType:国内企業サイトで根強い人気。セキュリティ重視。
- Drupal:大規模・高機能向け。海外で多用。
- ヘッドレス CMS(microCMS、Contentful 等):管理画面と表示部分が分離した新しい形。
- SaaS 型(STUDIO、Wix、Shopify など):サーバを意識せず、SaaS としてサイト構築・運用できる。
5-3. CMS の本来のメリット
CMS の魅力は、大きく言うと 2 つです。 第 1 に、業者を介さずに自社で更新できるので、コンテンツ更新のスピードが速い。 第 2 に、管理画面が用意されているので、HTML を書けない人でも投稿できる。 「お知らせをすぐ出したい」「ブログを毎週更新したい」という現場では、この機動力が効きます。
6. ここが核心 — 「なんでも CMS 化」には反対です
本書からの独自視点が、ここからの話です。 Web 業界では「これからは CMS で運用しましょう」「自社で更新できるようにしましょう」という提案が広く出回っています。 でも、それを 無条件に受け入れるのは間違い です。 CMS には、見えにくいコストとデメリットが必ず存在します。
6-1. CMS 化で自由度が削がれる
CMS は、その仕様の枠内でしか動きません。 用意されているテンプレートやプラグインの範囲なら自由に作れますが、その枠を超えるカスタマイズには追加コストがかかります。 デザインに強いこだわりがある場合、独自の表現を CMS の中に押し込もうとして、結局静的サイトより高くなる、ということがよく起きます。
6-2. 自社で更新できる=利益ではない
「自社で更新できるので便利」と説明されますが、これは「本来プロがやる仕事を、自社で背負う」ことの裏返しでもあります。 掲載表現の最適化、SEO 戦略、リンク設計、画像選定 — これらはプロが時間をかけて磨いてきた領域です。 社内で適当に更新した結果、SEO 評価が落ちる、誤情報が出る、ブランドが薄まる、というケースは現場でよく見ます。 自社更新が、必ずしも会社の利益になるとは限らないのです。
6-3. 外部依頼の場合、CMS 化が安くなるとは限らない
意外と知られていない事実です。 業者にコンテンツ更新を依頼する場合、HTML 直接更新のほうが速いことがあります。 CMS は管理画面の操作工程があり、そこで時間がかかるケースもあるのです。 「CMS にしておけば後で安くなる」と言われたら、本当にそうなのか、業者に試算をもらってください。
6-4. CMS で「何ができなくなるか」を必ず見極める
CMS 導入を検討するときは、「何ができるか」よりも「何ができなくなるか」を確認してください。 プラグイン頼みの構造、カスタマイズが高額になる予感、独自表現の制限、将来の乗り換えコスト — このあたりが、CMS の見えにくいコストです。 「自由に作れます」と言われる場面が多いのですが、実態は「CMS の枠内でしか自由ではない」というのが正確です。
6-5. CMS が向くケース / 向かないケース
判断の目安はシンプルです。
- 向くケース:更新頻度が週 1 以上、複数人で更新、ブログ型のコンテンツが主体
- 向かないケース:更新頻度が月 1 未満、デザインや表現に強いこだわりあり、業者に保守を任せる予定
6-6. CMS の運用統制面のメリットを過大評価しない
一般論で「CMS のメリット」として語られがちな 承認フロー / 履歴管理 / 権限分離 / 複数人運用 は、実は CMS 固有のメリットではありません。 どれも、CMS 以外の仕組みで実現できます。
- 承認フロー:社内ワークフローツール、Slack/Teams での承認、業者との運用契約で代替可能
- 履歴管理:Git・バージョン管理、ファイル管理ツール、ステージング環境での差分確認で代替可能
- 権限分離:サーバ側のアクセス権限管理、業者契約での担当範囲明示で代替可能
- 複数人運用:業者と社内の役割分担(Lesson 1-3 H2-6 の 5 権限、Lesson 1-1 H2-4 の 4 役)で実現可能
「これらをCMSで機械化したいからCMSを導入する、という判断」は、運用が小規模なら 過剰投資 になります。 むしろ CMS 化することで 融通が利かないシステム になるリスクが上回ることがあります。 テーマ・プラグインの制約で要件外のカスタマイズが困難になり、カスタマイズコストが積み重なり、バージョンアップごとに動作確認に追われる。
CMS が本当に 固有の価値を発揮するのは「記事コンテンツ系」 です。 メタデータ・タグ・カテゴリ・絞り込み・関連記事レコメンド・公開期間管理、大量記事の検索・並び替え・運用効率化 — これらが必要な場面、つまりオウンドメディア・ニュース・ブログ・商品データベースなどです。 それでも、コーポレートサイトのお知らせが月数件なら、静的更新で十分。 メタデータやタグ管理の機能は活用しきれません。
本書全体では、承認フローや履歴管理は CMS の機能ではなく 業務プロセスとして 実現する方針で設計しています。 Lesson 8-1 の「承認には責任が伴う」や Lesson 8-5 の「継ぎ接ぎ化との戦い」は、その視点で読み進めてください。
7. 「うちは CMS が必要?静的サイトでいい?」の判断軸
実務で必要になる判断は、次の 5 軸でスコアリングするとシンプルになります。
- 軸 1:更新頻度(週何回?月何回?)
- 軸 2:更新者数(担当者 1 名?複数人?業者経由?)
- 軸 3:予算(初期構築 + 月額保守の合計)
- 軸 4:セキュリティ許容度(CMS は脆弱性更新の運用が必須)
- 軸 5:表現自由度(独自デザインの希望度)
月に数回しか更新しないコーポレートサイトなら、静的サイトのほうが向きます。 管理画面のメンテナンスもプラグインの更新も不要、セキュリティリスクも下がります。 一方、毎週ブログを公開するメディア型なら、CMS が圧倒的に楽です。 両極端の中間で迷ったら、「3 年運用したときの総コスト」を出して比較してください。 初期費用だけ見ると CMS が安く見えますが、運用費を含めるとひっくり返ることもあります。
テンプレ DL:CMS 要否判定シート(5 軸版)(本書のテンプレ集に収録予定)
8. 担当者の現場用語ミニ辞書(コード語彙 + 作業語彙)
最後に、業者との会話で出てくる用語を 2 系統に分けて整理します。 コード語彙(サイトの中身の用語)と 作業語彙(運用作業の用語)。 両方を押さえると、業者との初打ち合わせで「話の通じる人だ」と思ってもらえるはずです。
8-1. コード語彙
- ソース:HTML/CSS/JS のコード本体のこと
- テーマ:CMS のデザイン・レイアウトのセット(着せ替え)
- プラグイン:CMS に機能を追加する小型ソフト(着替えや特技の追加)
- テンプレート:ページのひな型ファイル
- ヘッダー / フッター:ページ上部・下部の共通領域
- グローバルナビ:全ページ共通のメインメニュー
- サイドバー:本文の横に並ぶ補助領域
- ファーストビュー:ページを開いた瞬間に画面に見える領域(スクロール前)
- OGP:SNS でシェアされた時に表示される画像・タイトル(Open Graph Protocol)
8-2. 作業語彙
- ステージング:本番にデプロイする前に動作確認する練習環境
- 本番:訪問者が実際に見る公開環境
- デプロイ:ステージングや手元の環境から本番に反映する作業
- ロールバック:デプロイ後に問題が出たとき、前の状態に戻す作業
- バックアップ:データを別の場所にコピーして保管する作業
- リリース:新機能やコンテンツを公開すること
- マージ:複数の変更を 1 つにまとめる作業
- 公開フラグ:ページが公開状態か非公開状態かを切り替える設定
8-3. 使用シーン付き例文
実際の打ち合わせでは、こういう言い方が飛んできます。
- 「ステージングで確認していただいて、問題なければ本番デプロイします」 → 練習環境で見てから、本番に反映するという意味
- 「テーマカスタマイズで対応可能ですが、子テーマで作業します」 → CMS の見た目を、元のテーマを壊さずに改造するという意味
- 「OGP の設定が抜けていたので、改めて適用しました」 → SNS でシェアされる時の画像とタイトルを整えたという意味
- 「リリース後に問題が出たので、ロールバックして調査します」 → 公開した後で不具合が出たので、いったん前の状態に戻すという意味
テンプレ DL:現場用語ミニ辞書(印刷可)(本書のテンプレ集に収録予定)