アプリエンジニアにこそHeadless CMSが必要だと思う話

こんにちは、松田です。

Headless CMSとは

みなさまHeadless CMSをご存知でしょうか？
CMSはContents Management Systemのことです。有名どころだとWordPressやMovable Typeがありますね。
このCMSの頭にHeadlessという文言が付いています。

ウェブの世界でHeadlessというと主にGUI(View)がないことを指します。
CMS - GUI = Headless CMSですね。

より具体的に説明していきましょう。
まずは図です。左側が古典的なCMS、右側がHeadless CMSです。

Kontent.aiより図をお借りしました

まずは左側。いわゆる普通のCMSの場合、まずはインフラ（サーバマシン）のうえにDBとCMSの2つのプロセスを動作させます。CMSには管理画面が付いているのでそこからコンテンツを入力し、その内容をHTMLやCSSなどを使ってクライアントに表示します。

では右側のヘッドレスCMSはどうでしょうか？
図の通りの説明をするとインフラはクラウド上に構築されているため導入側にとってはインフラを気にする必要はありません ¹ 。
次にコンテンツの入力ですが、ここは普通のCMSと同じく管理画面から入力していきます。
最後に表示部分です。ここがもっとも違います。

**Headless CMSの出力はAPIなのです。**HTML/CSSなどの色付け係の仕事をHeadless CMSは一切行いません。
そのため取得した値の表示先はどこでもよくウェブ・アプリ・VR・デジタルサイネージなどどんなところにでも自由に表示できます。

Headless CMSはどんな時に使えるの？

実際にありそうなケースを一つ考えてみましょう。
まずはHeadless CMSがない場合です。

---

あなたはすごくクールなコミュニケーションアプリを作っています。

ある日、マーケ担当者から依頼がありました。
「来月からキャンペーンを始めようと思うんだけど、アプリの目立つ部分にその内容を表示してくれませんか？」

「なるほど。」あなたは詳細な内容をマーケに聞きながら急いでヘッダや詳細画面に実装して、ストアに申請を出します。

申請が通った翌日、またマーケ担当者が近づいてきました
「すいません、あのキャンペーンなんですけど予算の都合で一部内容が変わっちゃいまして...」

さあ、再度似たような作業を始めましょう。消えゆく工数と気力と共に...。

---

アプリに直接実装してしまっているような極端な例を出してしまいましたが、

• JSONファイルなどをどこかのサーバに置く
• DBにキャンペーン情報を用意

などの方法で動的にデータを差し込む場合でも、キャンペーン内容の修正や誤字脱字の修正ですらエンジニアが手を動かさなければいけません。
こういった作業は徐々に作業時間とモチベーションを蝕んでいきますね...。

ではキャンペーンの運用のため入稿ツールでも作りましょうか？
...おそらくやめた方が良いです。
まず、入稿ツールを作るのはそんなに簡単なことではありません。入力の例外処理やファイル(ストレージ)の取り扱いなど意外と複雑なためかなりの時間がかかってしまうでしょう。
また、キャンペーンを続ける期間が不明、入稿ツールのインフラはどこ？、入稿ツールに障害が起きたらどう対応する？など不明点やリスクが盛りだくさんです。

Headless CMSのある世界

Headless CMSがあるとどうなるでしょうか？
もう一度考えてみます。

---

あなたはすごくクールなコミュニケーションアプリを作っています。

ある日、マーケ担当者から依頼がありました。
「来月からキャンペーンを始めようと思うんだけど、アプリの目立つ部分にその内容を表示してくれませんか？」

「なるほど。」あなたはHeadless CMSの管理画面を開いて"キャンペーン"というAPIを作成します。
「キャンペーンの内容はここに入力しておいてください」と伝えマーケに入力用のURLを教えます。
その後、APIを使ってヘッダや詳細画面にキャンペーン紹介を実装し、申請します。

申請が通った翌日、またマーケ担当者が近づいてきました
「すいません、あのキャンペーンなんですけど予算の都合で内容が変わっちゃいまして...」

「あ、そうですか。管理画面で内容を修正しておいてください。」

さあ、キャンペーンのことはマーケにまかせ元気に次の施策に取りかかりましょう！

---

これがHeadless CMSのある世界です。

アプリはAPIの内容を読み取って表示しているだけなので内容そのものの変更には全く動じません。
また、キャンペーンに一番詳しいマーケ担当者が自分で表示するコンテンツも管理するため余計なコミュニケーションコストも発生しません。
これは素晴らしい！

Headless CMSを使うとかなり柔軟にAPIと管理画面を用意できます。
今回の例はキャンペーンでしたが、例えばニュースやアプリの更新内容(をアプリ内で表示)、ブログ記事紹介などはよくあるケースでしょう。
また、そのアプリ独自のデータを管理しておくこともすごく簡単です。

なんでアプリに必要だと思ったのか

実はこのHeadless CMS、ここ数年Webフロントエンド界隈ではかなり話題になっています。
しかし元々アプリエンジニアである自分はこう思いました。

「ウェブはいつでもデプロイできるから方法は色々ありそう。アプリの方が開発と配布のサイクルが長くなっちゃうからこの辺の課題あるよね。」

と。

ウェブ側は賢くCI/CDをやれば一切デプロイのことは気にしなくて良くなるはずです。
例えばAmazonはかなり前から1時間に1000回もデプロイしてるようですし！（めちゃくちゃすごい事例ですが）

一方でアプリはまだまだそんな風なリリースはできませんよね。
なのでできるだけ外部から動的に変更できる部分を増やしておきたいところです。

それに対して例えばFirebaseのRemote ConfigやA/B Testingのようなサービスもありますが、これは対象者がエンジニア寄りです。
先ほどの例のような他職種の方との連携が取りづらいという点が気になります。

一方でHeadless CMSならすごくうまくいくだろうと思いました。
動的に変更できる部分を増やしエンジニア工数を節約しつつ他業種とも連携を取りつつ、それぞれの仕事のパフォーマンスを最大化する。
これができるのはすごく良いですね！

この辺の思いを言語化しておこうと思ったのがこの記事を書くきっかけです。
この記事を読んでくれたアプリエンジニアのみなさん、ぜひHeadless CMSを試してみてください。
きっとビジネスサイドの人とももっと仲良くなれます笑

以上です。
長々とありがとうございました。

Headless CMSを作ったよ！

最後に宣伝。
この記事で少しでもHeadless CMSが気になったアプリエンジニアのみなさん、ぜひ弊社のHeadless CMSを試してみてね！

microCMS
https://microcms.io/blog/
無料で使えます👍

ちょっと前にoimo23さんも記事を書いてくださってました！ありがとうございます！！
https://qiita.com/oimo23/items/fc2b36b5bf543b0f23cc

1. サーバインストール型のHeadless CMSもあるため必ずしもHeadless CMSだからと言ってクラウド構成な訳ではありません。個人的にはクラウド型を使ってこそ価値が出ると思うのでそういったプロダクトがオススメですが！ ↩