こんにちは。SBT の富田です。
前回のブログでは、Headless CMS が注目される理由や、メリット・デメリットなどを紹介いたしました。
まだ読まれていない方は是非チェックしてみてください。
【第1回】Headless CMSとは？今求められるその理由
さて、第2回である今回は、Sitecore における Headless CMS（本ブログでは Sitecore Headless CMS と表記します）について紹介いたします。
前回の最後で「Sitecore の Headless CMS では、デメリットを克服している！！」と強力な一言を放って終わっておりますので、この伏線回収を行いつつ、Sitecore Headless CMS における活用シーンについても紹介していこうと思いますので、是非最後まで読んでいただければと思います。
なお、今回で Headless CMS に関するブログは最終回となります。
第1回では、Sitecore Headless CMS では以下のデメリットを克服していると紹介いたしました。（再掲）
これらはどういったことなのかを説明させていただく前に、Sitecore における Headless CMS の仕組みをご紹介いたします。
おさらいですが、従来型の CMS と Headless CMS の仕組みの違いは以下でした。
そして、Sitecore Headless CMS では以下のようになります。
※一部語弊があるかもしれませんが、分かりやすくお伝えするために簡略化して図解いたします。
お気付きでしょうか。
そう、Sitecore Headless CMS には、フロントエンド（Head）も API も存在するのです。
この状態を、ハイブリッド CMS と呼びます。
Sitecore Headless CMS は、ハイブリット CMS なのです。
フロントエンドエンジニアが Sitecore にフロントエンドプログラム（HTML/CSS/JavaScript など）と定義データ（後述します）をデプロイすると、Sitecore 管理画面上で”公開される見た目そのまま”にページを編集するための必要な情報が自動生成されます。
これにより、サイト管理者はテキストや画像の編集、ページ要素（コンポーネントと呼びます）の配置変更、別のコンポーネントの配置などが直感的に操作できるようになるのです！
言い換えると、従来の動的 CMS としての Sitecore（以後 Sitecore Headless CMS と区別して「従来型 Sitecore」と記載します）でサーバーサイドプログラムとして埋め込んでいた HTML/CSS/JavaScript といったフロントエンドプログラムを、サーバーサイドエンジニアだけでなくフロントエンドエンジニアが開発できるようになる選択肢が増えた、とも言えます。
ライセンスがあれば、AB テストやパーソナライズ（エンドユーザーのアクセス履歴に応じてコンポーネントを出し分ける機能）といった Sitecore のマーケティング機能も従来通り使用することができます。
鬼（Headless CMS のデメリット）に金棒とはこのためにある言葉ですね。（うまいっ、座布団100枚！）
一般的な Headless CMS のデメリットが克服されたことで、Sitecore Headless CMS の活用シーンも第1回ブログで紹介したものと変わってきます。
一般的な Headless CMS の活用シーンである
に加え、以下が加わります。
従来型 Sitecore では、例えば「全く新しいコンポーネントを新規で追加したい」となった場合は大まかに以下の2パターンの方法を取ります。
1.は他社に依頼することとなるので、リードタイムが発生するなどスピードに欠ける可能性がありますし、2.はスキルセットとして敷居が高い場合があります。
そのような状況において、WEB サイト運用業務を中心としている企業は、サーバーサイド開発はできなくてもフロントエンド開発はできるよ！という企業も存在すると思います。
そういった企業はもちろんのこと、サーバーサイド/フロントエンドの両方共開発できるがフロントエンド開発の方が得意である、という企業は、選択肢として Sitecore Headless CMS を採用するメリットがあります。
「都合のいいことばかり言っちゃって。騙されないぞ！」と思われる方もいらっしゃるかと思います。
はい、うまい話には裏があるので、その裏を包み隠さずお話しします。（騙すつもりはないのです。）
一般的な Headless CMS のデメリットである「フロントエンドエンジニアも API の知識が必要」というのは、Sitecore Headless CMS でも同じです。
これに加えて、フロントエンドエンジニアの方は以下3つを押さえておく必要があります。
1.の「定義ファイル」について、Sitecore に HTML などをアップすると、Sitecore 上に必要な情報が自動生成される、とご紹介しました。
この必要な情報を自動生成するために、コンポーネント等に関する定義データ（コンポーネント名や配置場所などを定義した yml ファイル）を作成してデプロイする必要があります。
仕組みを理解すれば難しいものではなく手間ではないのですが、フロントエンドスキルとは別モノなので挙げさせていただきました。
2.について、1.とも関連するのですが、フロントエンドプログラムを Sitecore へデプロイした後は、サイト管理者が Sitecore 管理画面でページ作成などの運用をすることとなります。
デプロイ時に自動生成される「必要な情報」がどのような形で Sitecore で管理されることとなるのかの理解は、運用しやすいコンポーネント設計に繋がってきます。
Sitecore の仕組みを理解することで、よりサイト管理者が使いやすいサイトを作ることができるため、フロントエンドエンジニアにも Sitecore の仕組みを理解していただくことを推奨します。
3. で GraphQL というワードが出てきました。
GraphQL は、従来の API リクエストで返却される JSON データが予め決められたフォーマットに沿った情報を返すのに対して、GraphQL では欲しい情報だけ返してもらうことができるため、通信データを軽量化することができ、表示速度の改善につながります。
Sitecore Headless CMS では、API リクエスト時に GraphQL という技術を使用するため、GraphQL についての知識も必要です。
以上が Sitecore Headless CMS の注意点です。 いずれも「スキル習得」といった大げさなものではなく、お作法を学べば十分使えるものだと考えております。 これらのお作法を学ぶことで、Sitecore 運用性の向上、データ通信の軽量化が見込めるため、十分取り組む価値のあるものではないでしょうか。
導入からデジタルマーケティングのコンサルティングまでご支援 - Sitecore on Cloud 詳細はこちら全 2回に渡って Headless CMS について紹介いたしました。 Headless CMS の何が嬉しいのか、どんなシーンで活用できるのか、デメリットを克服する「ハイブリッド CMS」などなど、イメージは湧きましたでしょうか？ 疑念が晴れて、これで夜も眠れるようになりましたね！（恩着せがましい） 少しでも Headless CMS の理解に役立ち、WEB サイト運用やマーケティング活動でお悩みの方の参考となったのであればこれ以上嬉しいことはありません。
今や様々なデバイスがネットワークに繋がるようになり、さらにこの流れが加速していくことに疑いの余地はないと思います。 WEB に限らず、様々なデバイスや場所で有益な情報を常に届けることでエンドユーザーが喜んでくれたのなら、幸せなことこの上ないですよね。 その1つの選択肢として、Headless CMS の導入も検討に入れてみてはいかがでしょうか。
今回は技術的な話は抜きに、Headless CMS の理解を目的にブログを執筆いたしました。 「逆に抽象的すぎてよく分からん！」であったり、「Sitecore Headless CMS について技術的な部分が知りたい」などご意見がある場合は、以下リンクよりお気軽にお問い合わせできますので是非ご活用ください！
以上、Headless CMS についてでした。
おしまい。
関連ブログ記事 |
関連ページ導入からデジタルマーケティングのコンサルティングまでご支援 - Sitecore on Cloud |
