多機能・高機能でシステムを選ぶ時代は終わりました。
CMS（コンテンツ・マネージメント・システム）も、選定する上で重要なのは、必須条件がクリアでき、拡張性の高いベースがしっかりしたシンプルなものを選ぶべきです。
シンプルにすることで、システムもスピードが出て、リーズナブルに運用できます。
本記事では、ITツールの選定に関わる非エンジニアの方や、Webマーケターが知るべき、エンジニア情報を、わかりやすく解説していきます。
第一回目は、CMS選定をされる立場の方が多いため、モダン開発と紐付けて、選択肢の一つになっているであろう、ヘッドレスCMSの概要をご説明します。
Web担当者がモダン開発を理解する必要性について
3〜5年に一回は、CMS選定やサーバ選定をされてことが多いと思います。
企業担当者は、経営陣から中長期の予算をかけるプロジェクトとして、Web課題を解決できる新しいシステムアーキテクチャを求められるはずです。
その際に、下記の3つが必ず話題になるのではないでしょうか？
- セキュリティの堅牢性を保ちたい
- サイトの表示速度を早くしたい
- 新しいアーキテクチャにして、ランニング費用を下げたい
※今回は、従来のCMSとモダン開発のCMSとの比較のため、CMSが持っているコンテンツ運用チームの負担改善についての言及は、要件から省きます。運用の要件により優劣が変わる、もしくは、優劣がつかないためです。同様に、MA機能を含めたCMS比較も、MAの要件により優劣が変わる、もしくは、優劣がつかないため省きます。
モダン開発は、そういった課題をシンプルに解決しますが、アーキテクチャの根本に関わるため、サーバ選定＝モダン開発ができるかどうかの重要な要になります。
そのため、しっかりサーバを含めたアーキテクチャの概要を理解していきましょう。
そこで、相談先として横断的に進められるベンダーの存在に期待したいのですが、実態は、インフラベンダーは開発手法に関与せず、システムベンダーは現環境を見てLAMP環境（後述で簡単に解説します）で開発手法を進めます。運用ベンダーは全体工数ではなく運用メンバーを過剰に心配し、運用フローの変更が少ない現環境と変わらない運用を求めます。
結果的に、レガシー環境のため根本解決ができなくなり、未来になればなるほど、運用工数は増加し、セキュリティ保守費用が高額になります。
せっかく新しいシステムを入れようとしているにもかかわらず、予定よりも早くシステムの再検討することも多いようです。
そういった状況から、アーキテクチャは、社内で概要を理解して、最適なものを取捨選択する指針を打ち出し、社内で推進していく人が必要です。
当社では、横断的な視点で、CMS選定のお手伝いをしておりますので、お気軽にご相談ください。
⇨ お問い合わせ
では、アーキテクチャの概要を理解することは、そんなに難しいことなのでしょうか？
ヘッドレスCMSとは
ここ数年で聞かれることも多くなりました、ヘッドレスCMSですが、従来のCMSとの違いは、20秒で理解できます。
上記（図1）は、いろいろ省いた簡略図にはなりますが、
▼従来のCMS
閲覧者が閲覧するたびに、サーバが閲覧するファイルをいちいち生成され出力します。
▼モダン開発のヘッドレスCMS
閲覧者が閲覧すると、そのまま出力されます。
ヘッドレスCMSとは、つまり、いちいち生成しない（＝ヘッドレス）ということだけなのです。
簡単に理解できたと思いますが、いかがでしょうか。
※「モダン開発のヘッドレスCMSの図が静的ファイルと変わらない」「CMSを更新する管理者側の構造がどうなっているかわからない」については、後述に簡単に記載しています。
※静的ファイルのみの説明だと、例えば、SSGであるMovable TypeもヘッドレスCMSになってしまうという、ビューやAPIの話は一旦、省かせていただきます。
ヘッドレスCMSの表示スピードが早い理由
こちらも非エンジニアでも簡単に理解できます。
上記（図2）を料理に例えると、下記（図3）のようになります。
▼従来のCMS
コックが料理を作り（生成出力）、それが出来上がってからウェイターがお客様に運びます。
▼モダン開発のヘッドレスCMS
料理されているものをそのまま出力、ウェイターがお客様に運びます。
また、このことから、コックという人件費に当たるものが、実際にサーバ処理しないため、その処理をしない分、サーバ費用も安くなることがわかります。
スピードが早くて、サーバ費用も安い、ヘッドレスCMSは、そんな素敵なCMSです。
コックがいないと、スペシャルな料理が食べられないのでは？とお考えになられた方もおられるでしょう。
ITでもその点は否めない点もありますが、料理もコックだけではなく、食材やレシピ、メニューの豊富さなど、いろいろな要素があって、料理全体が評価されるはずです。
また、ジュースを飲むのに、レストランに行かずに、コンビニや自動販売機で買うことが多いと思いますが、それは、コンビニや自動販売機を皆さんは知っているから、選択肢として選べます。
そのため、企業の皆様は、知らないのではなく、選択肢を持つことが、重要になるかと思います。
ヘッドレスCMSがセキュリティに強い理由
こちらも非エンジニアでも簡単に理解できます。
▼従来のCMS
動的に出力するため、攻撃者が攻撃する対象が多いです。
▼モダン開発のヘッドレスCMS
誰でも閲覧できるものしか置いていないため、攻撃者が攻撃する対象が少ないです。
※上記は、大枠の比較説明ですが、ヘッドレスCMSも攻撃する対象がないようにするためのインフラ作業など、セキュリティ対策は取る必要があります。
前段落でも、余計な処理をしない分、サーバ費用が安いとお伝えしましたが、セキュリティの部分でも必要最低限で済むため、ランニング費用も安くなることがほとんどです。
セキュリティが担保しやすく、サーバ費用も安い、ヘッドレスCMSは、そんな素敵なCMSです。
その他、静的ページを吐き出しているのみのため、従来のCMSより、部分的にCMS（たとえば、ニュースページのみCMS）にし、それ以外はCMS管理外にすることができます。そのため、より簡単に導入できます。
貴社サイトがヘッドレスCMSの導入に適しているかは、下記をダウンロードしていただき、ご確認ください。
ここまでで、必ず最初の話題に上る、セキュリティの堅牢性を保ちたい、サイトの表示速度を早くしたい、新しいアーキテクチャにして、ランニング費用を下げたい、という3つの課題をモダン開発はクリアしてくれましたが、デメリットはあるのでしょうか。
モダン開発のデメリットについて
サイト閲覧者側の視点では、ご紹介しているモダン開発は、デメリットがありません。
サイト運営側の視点では、向いていないプロジェクトがあることは確かです。しかし現在、欧米の有名なITサービスは、APIファーストなモダン開発をしているサービスが主導権を得ています。
そのためCMSも、ご紹介しているモダン開発が主流になっていくでしょう。
ただし、日本においては、下記3点がネックになるかと思います。
- 従来のサーバ環境から大きく変更できない
- モダン開発をするに当たってエンジニアが不足している
- システムベンダーがモダン開発を理解していない
1については、次の段落にてご説明します。
2と3に関しては、Web業界の話のため、飛ばしていただいて構いませんが、簡単に記載しておきます。
※わからない単語が出てきても、今は飛ばしていただいて構いません。
大きな理由は、Webエンジニアリングの分野としては日本が後進国になっており、モダン開発の土壌が会社として作れていないことが多いためです。
現場エンジニアが遅れてしまっていて、なおかつ、その上のマネージャーはさらに情報が遅れておることが、大きな原因です。
その理由としてエンジニアの情報の多くが、英語で書かれており、英語が不得意な日本人エンジニアは英語圏の外国人エンジニアに比べて情報が遅いことは否めません。
それに拍車をかけて、Webのモダン開発では、APIファーストになっており、フロントエンドエンジニアがバックエンド領域を理解し、インフラ領域も理解しないといけない状況で、フロントエンドエンジニアの業務範囲が拡大し、忙しさが倍増し、需要と供給のバランスが崩れて、人員単価も高額になっています。
また、システムベンダーは、バックエンド領域から広げずに、従来システムを提供することが多いようです。
海外では、バックエンドエンジニアが、フロントエンドエンジニアにコンバートすることが多くなっていますが、日本ではまだまだ少なく感じています。
バックエンドエンジニアの進化は、マーケティングでのデータを扱う分野としては、さらなる発展がありますし、AI進化にともない仕事は増えるでしょう。それにAPIファーストでBFFを作るのがフロントエンドエンジニアの仕事になったとはいえ、それでもその先はバックエンドエンジニアに活躍してもらわないといけない領域がたくさんあります。
なお、アメリカのシリコンバレーのWeb開発の多くは、システムアーキテクチャは本国のアメリカ人が作ることがあっても、その先のエンジニアリングは、アジア圏を含めた海外の人間であることが多く、よりグローバルな作り方をしています。
本サイトも、モダン開発をしております。システムアーキテクチャは、編集長の配下であり、最近、日本の市民権を取得しましたが英語圏の外国人エンジニアが担当しております。
また、コロナの影響で、途中から、3名の外国人エンジニアが外国から開発に関わってもらい、11月には、日本からもう1名の編集長の配下の外国人エンジニアが参加しております。
そういった時代の流れを鑑みて、外国人エンジニアについて理解していただくために、別途、彼らへのインタビューの企画しておりますので、その時にさらに、本件については掘り下げていきたいと考えております。
モダン開発に必要なインフラ環境について
ここからは、少し難しくなってきますが、それでも3章と4章が理解できていれば、すんなりと理解できると思います。また、この章では、非エンジニアの方は、サーバの構成をなんとなく、理解できれば大丈夫です。
今までの図では、CMS管理画面から、閲覧者に情報が届くまでのフローを省いてきましたので、そちらからご紹介します。
ご覧になって、従来のCMSと、モダン開発のヘッドレスCMSでは、サーバ構成が違うのがなんとなく、ご理解いただけるのではないでしょうか。
本サイトのサーバ構成図は、別の記事にてご紹介させていただきますが、簡単に違いをお伝えすると、下記の通りです。
▼従来のCMS
LAMP環境が主流です。
今後は覚える必要がない時代になってきておりますが、L（Linux）＝OS、A（Apache）＝WEBサーバ、M（MySQL）＝DBサーバ、P（PHP or Perl）＝プログラミング言語で、構成された環境で、多くのWEBは未だにこの環境が多いはずで、編集長もこちらの時代の方が長いです。
日本でも2015年頃から、多くのWebべンダーも、AWSなどのクラウドベースにシフトしていきましたが、それでも、LAMP環境をクラウドにしているだけという印象が否めませんでした。
▼モダン開発でのヘッドレスCMS
本サイトもそうですが、モダン開発のヘッドレスCMSでは、JavaScriptを利用したAPIファーストで作成されております。また、Node.jsがインストールしてあり、静的サイトジェネレーターが自動で実行できるサーバレス環境が望ましいです。
それが簡単にできるのが、AWSやGCPなどのクラウドベースです。AWSではサーバレス環境として代表的なLambda（次の段落で説明します）があり、本サイトでも利用しています。
AWSのLambdaに対抗して、GCPもCloud Functionsがあります。AWSのシェアもサービス拡充も圧倒的ですが、編集長の個人的な意見では各Googleサービスとのデータ連携を考えると、GCPの方がマーケティングの観点でもAWSより良い点もあり、まだまだAWSの1択ではないため、頑張って欲しいです。
上記の通り、AWSなどのクラウド環境に変えないと、モダン開発は難しいです。しかし先日、ご要望はモダン開発のヘッドレスCMSにマッチしていましたが、クラウド外のLAMP環境でサーバ構築しているため、踏み切ることができないお客様がいらっしゃいました。
そのため、サーバ環境をご検討の際には、クラウド環境を選択肢に入れて、今後のシステム環境も視野に入れてからプロジェクトを進めることをお勧めします。
当社では、サーバ環境構築まで支援しております。
モダン開発のヘッドレスCMSである、本システムのサーバ概要図をダウンロードできるようにいたしました。
中間CV導線「モダン開発のヘッドレスCMSのサーバ構成図」は下記からダウンロードしていただき、ご確認ください。
サーバレス環境について
サーバレスとは何か、「サーバがないのに、Webが閲覧できるわけがない」と思われるでしょうが、その通りで、サーバはあります。
サーバレスとは、「一部のサーバが一時的に稼働していないのに、サービスが問題なく提供できているサーバ環境」です。これだけでは難しいですが、これもすごく簡単に理解できます。
サーバレス環境では、基本的には、サーバが分離されており、閲覧者とサイト運営者のサーバの行き来は、ネットワークから分離した一方通行です。
前の章にてLambdaというサーバレス環境をお伝えしましたが、モダン開発では、静的サイトジェネレーターというのがあります。こちらがLambdaサーバの役割です。
※CodeBuildなどのサーバの詳細構成の話は、別の記事のサーバ環境にて詳しくお伝え致します。
3章では、コックを必要としていないのが、ヘッドレスCMSだとお伝えしましたが、コンビニエンスストアのお弁当も、コックが現場にいないだけで、工場で大量に作って出荷しているからお弁当が売れるだけです。この例に当てはめると、Lambdaサーバの一部のマシンは、工場に当たります。
つまり、静的サイトジェネレーターがあることで、事前に静的ファイルが作れるため、従来のCMSのように、アクセスがあるたびに閲覧データを生成する必要がありません。そのため、コックが必要ないのです。
では、サーバレスを図で表します。
下記（図7）の隠れているサーバは、サイト運営者が作業していない時は、必要としないサーバです。
簡単にいうと、それがサーバレスと言われるゆえんです。隠れているサーバがいなくても、サイト閲覧者はサイトが見られて、サービスが止まらないわけです。
また、通常クラウドサーバでも、人を雇っていて、月給を支払うのと同じで、毎月固定の費用を請求されますが、LambdaサーバやCodeBuildなどは、実行した時だけしか請求されないため、本当の意味でのサーバレス（実行している以外、待機もしていなく存在もしないサーバ）です。またそのため、従来のCMSよりサーバ構成が複雑になっているにもかかわらず、費用がリーズナブルになります。
※本サイトは2020年10月にリリースしましたが、同月のAWS請求額は、Lambdaは0ドル、CodeBuildは1ドル未満です。実行している数がどれも少ない訳ではなく、開発環境と本番環境もこみでGitも連携しているため、ビルドもリリース作業のため数えきれないほどしております。
最後に、JAMstackについて
冒頭から「モダン開発のヘッドレスCMS」という、あいまいな伝え方でしたが、今回ご紹介した開発手法は「JAMstack」というものです。
JAMstackは、「JavaScript」「APIs」「Markup」の3つの技術を組み合わせた、WEBアーキテクチャです。APIなど省きましたが、大枠は、本記事に書かれている内容です。
ヘッドレスCMSでも、歴史があり、色々と試行錯誤を繰り返して、今回、ご紹介したJAMstackが生まれました。
単にSPA（シングル・ページ・アクション）で作るとSEO問題が発生しました。
そのためSSR（サーバ・サイド・レンダリング）で作り、SEO問題は解決できましたが、別サーバが必要になり複雑な構成になってしまいました。
それであれば、SSG（スタティック＝静的・サイト・ジェネレーター）で開発することが最適となり、インフラ構成も考えていき、今に至ります。
7章の図の赤枠に記載ある、静的サイトジェネレーターとありますが、それがそのままSSGのことを指しますので、SSGも簡単には、ご理解いただけたと思います。
なお、SSGとJAMstackの違いに関しては、JAMstackはサーバ構成やSSGが自動実行できる環境を含めたアーキテクチャです。JAMstackはSSGですが、SSGがJAMstackとは限りません。
JAMstack開発には、SSGを自動実行できるためのサーバ構成やCDNでの負荷分散を含めたインフラ環境の考えも根付いているため、それを忠実に本サイトでは実行しています。
サーバ構成も、もう少し触れたかったのですが、次回の記事にてご紹介します。
今回、全く触れませんでしたが、JAMstackを対象としたヘッドレスCMSは80製品ほどあります。
▼参考
https://jamstack.org/headless-cms/
本サイトでは、世界シェア率と拡張性を考えてStrapiというCMSを選定しました。
Strapi に選定した理由に関しては、ヘッドレスCMSの比較表も含めて、別記事にてご紹介させてください。
日本製のmicroCMSも別プロジェクトで利用しておりますが、日本語対応で導入のハードルが高くなく、要件によっては、とてもお薦めです。
横文字が多くて、非エンジニアの方は、理解が大変だったと思いますが、思ったより難しくなかったのではないでしょうか？
当社では、モダン開発である、JAMstackのヘッドレスCMSの制作・開発を推奨しております。
ぜひ、CMS環境でお悩みがあれば、ご相談ください。