Jamstackで制作はどう変わる？　「削減できるもの」と「必要になるもの」

ヘッドレスCMSを採用した「Jamstack構成のサイト構築」は制作者にとってどんな利点と課題があるのでしょうか。microCMSなどの採用実績を持つ株式会社トルクに聞きました。

 

 

 

オウンドメディアに強いJamstackの特徴

ヘッドレスCMSとは、画面表示（ヘッド）の機能を持たず、コンテンツの編集・管理・出力に特化したタイプのCMSです。Webサイト、アプリ、サイネージなどマルチデバイスでのデータ利用が進んだことでも注目されています。私たちの場合は、「Jamstack」なサイト構築に欠かせない要素としてヘッドレスCMSを採用しています。

Jamstackは、ヘッドレスCMSから登録されたコンテンツをAPIで取得し、静的ページを生成して、静的サイトホスティングサービスに展開するアーキテクチャです。通常なら長大な冗長化・負荷分散が必要になるWebサイトと同規模のものを、非常にシンプルな構成で実現できます。静的ページがCDNから配信されるため、閲覧者にとっても快適です。こうした点から、特にオウンドメディアのようなWebサイトを構築するなら現時点でJamstackがベストだと考えています。

また、中規模以下の企業のコーポレートサイトにも向いているでしょう。営業、人事、経営企画部などの非エンジニア部門が主管であっても、構造的にセキュリティや技術面のハードルが低く済む点が有利です。

ただし、大規模なWebサイトにはあまり向いていません。先に述べたようにページの生成にはAPIから取得したコンテンツが必要ですが、作成できるAPIの数は通常CMSベンダー側から制限が設けられています。例えばmicroCMSなら10～30個（プランによる。別料金で追加可）で、大規模サイトでは足りなくなる恐れがあります。

更新頻度の低いページ（いわゆる固定ページ）が多いサイトとも相性が良くありません。APIで更新する部分以外のコンテンツをCMSの管理画面から直接編集できないからです。開発側にとっては触られたくない部分を触られてページが崩れてしまう心配がない反面、クライアントによっては微小な修正でも制作会社へ依頼する必要があることを不安視される場合があります。

 

開発の自由度が向上課題はエンジニアの採用・育成

制作側にとって従来と大きく異なるのは、バックエンドの開発が必要なくなることです。Ruby、PHPなどの言語でプログラムを書いていたものが、CMSの管理画面から、フロントエンドエンジニアだけでできるからです。そのため、インフラエンジニアがいない小さなチームでもそれなりの規模の開発が可能です。

工数でいえば、案件にもよりますが2～3割程度の削減につながり、その分を他のクオリティアップに充てることができます。私たち制作者は「器」としてのWebサイトのみならず、コンテンツのクオリティにもコミットしていく必要があると考えています。その意味で、フロントエンドエンジニアがAPIを作成・管理することでバックエンドとの間の調整にかかる労力が削減され、コンテンツ設計をブラッシュアップする猶予ができたのは利点と言えます。

また、デザイン面でもより自由度の高い表現が可能になります。フロントがCMSと完全に分離していることにより、公開後も機敏に改善を回していく運用にも適しています。

ただし、それだけ求められる技術レベルが高いのも事実で、エンジニアの採用・育成は常に課題になっています。単にデザイン案を形にするだけでなく、初期段階からデザイナーと一緒に考えていくデザイン視点も持ってほしいと考えています。

近年、企業のWebサイト（特にコーポレートサイト）は、広告宣伝費ではなくソフトウェア資産・無形固定資産として計上される予算規模のプロダクトになっています。この減価償却には5年かかります。つまり、制作にあたり最低5年は使い続けられるものにする必要があるのです。以前はWordPressも使っていましたが、インフラの冗長化に対応するコアのカスタマイズや、プラグイン管理の煩雑化を伴うと、数年後に自分たちの保証できない部分でリスクが発生する恐れがある、という教訓を私たちは過去に得ました。

世界的にトラフィックが増加し続ける昨今、安全なサーバ構築・維持管理にかかるコストも企業側の大きな負担になっています。これらを解決する意味でも、Jamstackは非常に適した手段であると考えています。