Blog

最近、知り合いに「WEBサイトを作りたいんだけど何を勉強したらいい？」と聞かれました。

「HTMLとCSSとJavaScript」と明確に答えたにも関わらず、ネットで調べたらいろんな情報が出てきて、「PHPは？」「人気のプログラム言語はこれらしいけど」と、これだけでサイトが作れることがなかなか信じられなかったみたいでした。

WEBアプリケーション制作に向いた情報、WEBサイトに向いた情報が少なからずあると思いますが、あまり区別なくJSやその他の言語、ツールが語られることがほとんどです。

そんなことがあったので、WEBサイトを制作し始めてから何年も経ちますが、いろいろと考えてることや考えてたことをまとめて記事にしました。 あくまで個人的な見解ですが、「WEBサイト」の制作にスポットを当てたものになります。

WEBサイト制作現場の変化

WEBサイト制作は、時代とともに大きく変化しました。
一番最初に出会ったのは、テーブルコーディングと言われるもので、まだCSSが現れる前、レイアウトを全てtableタグでやるというもの。装飾も機能も最小限でした。

CSSが登場し、HTMLタグも種類が増え、スマホの時代が到来してレスポンシブが必須になり、 WEBサイト制作と親和性のあるJavaScript実行環境のNode.jsが出てきたことによって、Web制作の現場にもSassやビルドツールが使われるようになりました。

またCMSは、手軽に組み込めるかつ無料のWordPressが、最初はブログ用だったのがどんどんWEBサイト用に改良され、プラグインも増えて色々な機能が使えるようになり、主流となりました。

クライアントサイドの処理のみならず、かなりたくさんのことをJavaScriptができるようになってきたこと、 アニメーション技術も発達し、単一ページでコンテンツの切り替えを行うSPAのサイトが出てきたことなどで、WEBサイトに関わる技術や制作者に求められる技術は、昔に比べると比べ物にならないほど多いです。

かつては、デザインを担当する「WEBデザイナー」と、コーディングを担当する「コーダー」、JSを担当する「プログラマー」で担当がわかれていたことも多く、特にHTML/CSSコーディングとプログラム実装の間には見えない壁があり、WEBデザインとコーディングをどちらもできる人は多いが、プログラムはプログラマーが実装ということも多かった気がします。逆に「コーディング＋JS実装」はできるけど、デザインとの間に壁がある人もいました。

とにかくこの頃は、WEBサイト制作に求められる技術は今ほど多くなかったので、比較的、制作方法も各制作会社ごとに環境が全然違うということがなかったように思います。

「WEB制作」の情報に対する違和感（を持ってた時期）

WEBサイトを作り続けている立場からみて、なんとなく複雑な感じになってきたと感じ始めたのは、Node.jsやフレームワークが普及し始めたころからです。

いつだったかというのは具体的には覚えてないですが、急速にいろんな技術が顔を見せ始めた時期がありました。 それまで、「WordPressなどのおかげでCMSが手軽に導入できるようになった」程度だったのが、「あれが便利」「今時はこれ」みたいなツールをたくさん見るようになりました。

混乱した理由の一つは、WEBサイト制作とWEBアプリケーション制作が「WEB制作」とまとめて表記されるものがあることだと思っています。現在は、WEBサイトは「WEB制作」、WEBアプリは「WEB開発」と区別されていますが、WEBサイトのなかにもインタラクティブな表現をするものがあったり、フォームや制作過程の技術選定でバックエンドの知識が必要だったりと、蓋を開けてみると技術的には同じものを使用した部分もあります。そのため、WEB開発をルーツに持つ人たちの記事が情報がネット上にたくさんあり、それらがサイト作りのどのあたりに便利なのかがわからないまま、なんだか便利なんだな、使った方がいいのかな？と知識だけ蓄える時期がありました。

「フロントエンドエンジニア」の言葉の意味も、いまだに曖昧だと感じてます。WEBサイトを制作するならば、コーディング＋JSでの動的部分の実装＋アニメーションができればフロント側の仕事は完了です。でもWordpressをやる人もいるし（WordPressはフロントエンド側の仕事と見られることがほとんどだという印象）、逆に「それはフロントエンドエンジニアというよりコーダーでは？」という見方もあります。

CSSフレームワークで気づいた、WEBサイトとWEBアプリケーションの違い

結構ミーハーなので、あれこれ試してみたり調べてみたりするのですが、例えばBootstrapなんかは、当初なぜこれがいいと言われるのかわかりませんでした。

クラスをつけるだけでレスポンシブ対応のレイアウトができるということは理解できる… でも、デザインとちょっと違ったら上書きしないといけないし、クラスをある程度覚えないといけないその手間と、「スタイル当てるのが簡単」だというメリットが自分の中では釣り合わない。

それは当然のことで、Bootstrapは、最初から練りに練られたデザインがあるWEBサイト制作向けのものではなく、どちらかというと、CSSフレームワークありきのデザインであるWEBアプリ向け、もしくは量産型のWEBサイトのときに力を発揮するフレームワークだからです。

お客さんのイメージに合わせてカラーを決め、ここは斜めカットで画像を配置、トップページはメインビジュアルもレイアウトも下層とはガラッと変えて、ここのボタンは同じ色だとバランス悪いからちょっと変えて、メインコピーのフォントサイズもいろいろあって…みたいな、緻密に計算されたデザインの、いわば広告＆看板目的のWEBサイトに、CSSフレームワークを使うのは逆に辛いです。そもそも、「コンポーネント」が形を変えてでてくることも多く、似てるからといってCSSを流用した結果、使い回すためにどこを共通にしたのか思い出す方が大変だったりします。

制作過程でツールの選択肢を増やしたいという思いもありましたが、何を作ろうとしているのか、そのために何が必要なのかを考えたとき、自分の中で「WEBサイト制作」からCSSフレームワークが選択肢から外れました。

同じように、Gitやビルドツール、クライアントサイドフレームワークもWEBサイトに取り入れることができますが、「あった方が便利か？」「取り入れることが一般的か？」と言われると、なんとも言えません。 私は、世に出てたくさんの人が使っているものをWEBサイト制作に「いらない」「使えない」と否定したり、逆に新しいからといって使わないといけないとも思いません。「用途に合ったもの」を使うことが大事だと思っています。

HTMLとCSSだけではもう制作できない

コーディング自体は、特に難しいことをしなくても、HTMLとCSSさえ知っていればまるまる１サイトコーディング可能だということは昔から変わらないですが、CSSプリプロセッサを使わずコーディングをしている人はもうあまりいないと思います。 スマホやタブレットの普及でレスポンシブが当たり前になった背景から、どれだけ保守的なコーダーも、SassやLESSは取り入れざるを得ないような状況になりました。

これらを導入するにはコンパイルエンジンが必要です。PreprosのようなGUIコンパイラもありますが、コマンドラインを使ったコンパイルが一般的です。ここでビルドツールを使うかどうかで、WEBサイト制作に携わる人々の制作環境に違いが出てきたように思います。

ビルドツールの必要性

Gulp.jsやwebpackなどのビルドツールを使うと、Sassのコンパイルだけでなく、様々なことが保存一発でできるようになります。これは大きなメリットです。
ベンダープレフィックスを自動で付与したり、画像やJS、CSSファイルの最適化をしたり、 ローカルサーバーを立ち上げて自動リロードするようにすれば、ブラウザ更新の手間すらなくなり、制作時間をかなり短縮できるようになりました。

その一方で、ビルドツールを導入するための知識が必要になり、エラーが出た時の対処、メンテナンス、設定ファイルの作成更新など、どちらかというとプログラミングに片足を突っ込んだような作業をする必要が出てきました。HTMLとCSSが書ければとりあえずWEBサイトはできるという常識が、これらによって通用しなくなってきました。

webpackはWEB制作に必要か

WEB制作周りのツールは、ほかにもたくさんあります。
webpackは、複数のモジュールを一つにまとめたファイル出力するツールで、今まで用途ごとに読み込んでいたjsファイルを一つにまとめることができます。

利点は、コードが読みやすくなる、保守性が高くなるなどが挙げられますが、WEBサイト制作に必要かといえば必要とまでは言えません。それでも私は（かなり）個人的な理由で使うメリットがあるので使っていますが、正直、WEBサイトを作るにあたってJavaScriptは<script>タグで読み込むだけで充分であることがほとんどです。

というのも、WEB制作に必要なJavaScriptコードはそこまで多くなく、ファイルの管理一つとっても、モジュールごとに分けるよりも一枚のjsファイルで管理できるくらいの量だったりします。

オリジナルでコードを書く必要すらない場合もあります。スライダーのプラグインを読み込む、実行するのに何行か追加する、みたいなやり方で事足ります。

そもそも、WEBアプリケーションの場合はプログラミング（JavaScript）が中心で、それプラスHTMLとCSSを書くという構造（というか考え方？）に対し、WEBサイトはHTMLとCSSがまずあって、そのなかにJavaScriptを組み込むという考え方になります。WEBサイトにとって、JavaScriptはプラスアルファです。そう考えるとWEBサイトの場合は、webpackでのバンドルまでは一般的にいるだろうか…という感じです。

GitはWEB制作に必要か

結論から言うと、あった方が便利です。厳密なバージョン管理のためというより、バックアップとして使ったり、差分の確認が簡単にできるのがすごく便利です。

WEBサイトは、アップデートしていくものではないのでバージョン管理は必要ないですが、バックアップ的な意味で「トップページ静的コーディング完了」「下層○○のページが完了」などのコミットメッセージを積み上げていくのはありだと思います。複数人で作業する場合はファイルをうまくマージしてくれるので、Gitがなかったころに比べると先祖返りの可能性もほとんどなく、安心して作業が進められます。

また、制作現場で意外にあることだと思うのですが、納品後にお客様や代理店側でHTMLやCSSの微調整を行うことがあります。本来ならばそのような運用は避けたいところですが、HTMLやCSSは初心者でも扱える人が多いので、クライアントによってはこのようなことが公開前に発生しやすいのです。
そのあとに先方で対応できない修正をこちらに投げてこられて、「最新ファイルは仮環境サーバーに上がっているものです」と言われるようなケースでは、ローカルにあるSassファイルやHTMLの元となったファイルに反映されず、ファイル管理に神経をすり減らすことがよくありました。

Gitがあれば、ローカルにそのファイルをコピーしてきてGitで差分を確認することができます。その結果、手持ちの元ファイルを修正することができます。差分を確認できたり、その時の状態を記録しておくことができるというのは非常に便利です。

ほかにも、WEBサイトで使いたいJSのプラグインをGitで管理しているものも多く、バージョンを指定してインストールして使うことも珍しくありません。WEBサイト制作においてもGitの知識はある程度必要だと言えます。

クライアントサイドフレームワーク

SPA（シングルページアプリケーション）が注目され始め、Angular、React、Vue.jsなどのフレームワークがWEBサイト制作にも取り入れられるようになりました。

現在はReact、Vue.jsが決着つかずで強い印象です。Reactが少し人気度高めになってきた気がする…？という程度です（特に根拠ありません。普段のネットサーフィンの結果。）

WEBサイト制作では、そもそもこれらのフレームワーク（Reactはライブラリ）を使う必要があるのか？というと、SPA、SSR（サーバーサイドレンダリング）のような、アプリケーション形式のWEBサイトを選択しない限りは特に必要ではないです。 WEBサイトにおいてこれらを選択するメリットは、「読み込みが速い」「ページ遷移が滑らか」「アニメーションが活きる」などが挙げられます。その反面、WordPressで低コスト（費用面）でできていた機能が使えず別に実装が必要になったり、SPAならではのデメリット（初回ロードが重い、OGP設定できない）を解消するため、SSRを検討する必要性が出てきます。

WEBサイト制作において、JavaScriptがメインとなるSPAやSSRのサイトは難易度が高いですが、その割に需要が少ないということも事実です。実際、何も知らないお客さんがSPAのサイトとそれ以外を見て、明らかに違いがわかるかどうかも疑問です。SPAではページアニメーションが実装しやすいので、その辺りで「なんだかかっこいいね」という感想を持つ人がいるかもしれません。

しかし、「なんだかかっこいいね」のためだけに、実装側は結構な工数と学習コスト、経験値が必要です。当然費用面でコストが上がりますが、それでも「こっちのほうがいい」といってくれるお客さんがどれだけいるかというと、そんなにいないんじゃないかという感じがします。

また、アニメーションをメインとしたサイトを想定した場合、レガシーブラウザとの兼ね合いもあります。
アニメーションを全てIE11で表現するのは難しいと判断したとしても、最低限、代わりに静的の画像を表示する、大きなレイアウトは崩れないようにする、エラーによる妨げをなくすなどの対策が必要です。
いろいろ対応しようとするとそれなりの知識を要します。もうそろそろ完全に切り捨てたいところではありますが、閲覧が目的のWEBサイトでは、まだギリギリ完全放棄とまでいかないのが悲しいところです。
（…といいながら、このサイトはIE11対応してないですが）

とはいえ、SPAやSSRは、WEBサイト制作現場に降ってきた面白い素材の一つです。必要か必要でないかは別として、「こんなサイトが制作可能である」という点で、ないがしろにするのはもったいないです。

今後、WEBアプリケーションとWEBサイトは、目的こそ違えど制作過程は似てくるかもしれません。学習コストを払ってでも、WEBサイト制作に取り入れてみる価値はあると思います。

Jamstack

Jamstackは、静的なHTMLをベースに、APIを通じて動的なコンテンツを扱うWEBアプリ・WEBサイトのアーキテクチャのことです。動的なコンテンツ部分もHTMLに埋め込まれています。

こう聞くと、そもそもWEBサイトは静的なもので、お知らせなどの更新も、WordPressが流行る前は手作業で静的HTMLを更新してたじゃないか…原点回帰？
と思うかもしれないですが（私は最初思いました）、Jamstackにはそのほかにも特徴があります。

• CDN/ADNで配信（…できる静的なHTMLであること ）
• 動的部分はJavaScriptによりAPIで取得

JAMは、JavaScript、API、Markupのことです。
「CDN/ADNで配信する」ことが条件なのかと思いましたが、明確に書いてるのを見つけられませんでした…が、Jamstackを提唱したのがNetlifyの創設者なので、前提としてCDN/ADN配信があるのだと思われます。

それまで、動的な部分はHTMLを直接触らず更新可能にしたい、という願いを叶えるためにWordPressなどのCMSが登場しましたが、読み込みが遅い、セキュリティ面での心配などがありました。

個人的には、WordPressが他と比べてセキュリティがあまいということはなく、静的と比べてサーバー管理が必要なWEBサイトは一般的にそうであるというだけの話だと思いますが、「動作が遅くなる」というのはどうしても気になるところではありました。

ならば動的部分を全部HTMLに埋め込んで作ってしまえばいい→Jamstackという選択肢　というわけで最近注目されています。

動的部分の静的HTMLを作るときくと、Movable Typeを思い浮かべましたが、JamstackはCDN/ADN配信が基本となっていること、動的部分をJSのAPI機能で取得することが違います。（Movable TypeにもオプションでCDNサービスはあります） Movable Typeは7になってからお客様の要望で使用して構築した経験がありますが、トップページが爆速でした。地下の電波の悪い状況でもサクサク動きます。静的HTMLのパワーを改めて感じた瞬間でした。

話がそれましたがJamstackは、CMSサービスではなくアーキテクチャの名称なので、API通信でデータを取得したら、あとは自分でごにょごにょ頑張って好きなように表示してくださいね。もちろんデータベースも自分でちゃんと用意してください。ということになります。技術面で頑張る必要があります。

サイトジェネレーターにはNext.js、Hugo、Gatsby、Nuxt、Gridsome、Jekyllなどがあります。WEBサイト制作でJamstackを採用するにあたり、どれがオススメみたいなものはまだないように思います。個人的には、Reactから派生したものよりはVue寄りのものが好みです（HTMLを変形せず制作しやすいという点で）

実際にWEBサイトにJamstackを導入するということを考えると、今までWordPressでできていたことをいくつか諦める、もしくは代替案を探すということしなければなりません。Headless CMSはお客さんが直にさわる部分になるので、慎重に検討する必要があります。WordPressもRest APIを備えているので、Headless CMSとして使うことが可能です。これも有力な選択肢だと思います。

結局のところ、求められているものが「お知らせ更新」程度のものであれば、いろんなCMS提案ができそうです。でも、商品登録をしたい、画像とキャプションを任意に何枚か登録したい、お客様の声をニュースとは別に作りたい、さらにそれを投稿した商品と紐づけたい、投稿前にプレビューが見たい、など、実際は色んな要望があり、それら全てを叶えられるCMSの選定には時間がかかります。「WordPress一強」のようなものが、Headless CMSにはまだないからです。

新しいものゆえに、学習コストの上に技術選定の手間がかかるので、今現在必要な技術かというと、そうとは言えないですが、これもクライアントサイドフレームワークと同じく、徐々に試していく価値はあるように思います。何より「表示が早い」というのは、とにかく強いです。わかりやすく良さをお客さんに感じてもらえる上、SEO上もメリットがあります。

まとめ

何だか上から目線のような文章が長々続きましたが、全くそんなつもりはありません。すみません。

WEBサイト制作に必要なもの、必要とされるものを考えながら、これからも作り続けていこうと思います。