Headless CMS というトレンドに Drupal は適応している!?

Drupal is API-first, not API-only

開発者の多くが、Headless CMS（ヘッドレスCMS）として知られるcontent-as-a-serviceソリューションを選ぶようになってきています。Headless CMSは、余計なものを省いた編集用インターフェースと、あらゆるアプリケーションが利用するためのコンテンツAPIを提供するストレージとなります。

Headless CMSはいくつかの共通する特徴があります。エンドユーザー側のフロントエンドがないこと、表示したりレイアウトするための編集画面がほとんどない、もしくは全くないため、フロントエンド開発者にとっては、どうやってデザインするか、というプレゼンテーション上の懸念が常に残っています。以下の理由により、Headless CMSは有名になりました。

情報の構造化とプレゼンテーションの懸念を切り分けたいという希望。そうすることによりフロントエンドチームとバックエンドチームはそれぞれ独立して働くことができるコンテンツ編集者とマーケティング担当者は、日々増えるマーケティングチャネル（ウェブサイト、バックエンドシステム、シングルページアプリ、ネイティブアプリ、ウェアラブルデバイス、音声アシスタント端末、IoTなどの新興デバイス）にコンテンツを提供できるソリューションを探しています。

開発者の中で話題になっているこういったトレンドにより、Headless CMSは旧来型のCMS市場に挑んでいるのかどうか、といったことが当然のように議論されています。私は、今日あるようなHeadless CMSのあり方が、今後CMSが向かう方向かどうかはまだ確信を得ていません。実際に、微妙な見方が求められていると考えています。

この投稿では、なぜDrupalにはヘッドレスの競合プロダクトを超えた利点があるのか、ということを説明したいと思います。Drupalは、コンテンツの出方を制御する必要があるコンテンツ編集者にとっては例外的なCMSであり、大規模なコンテンツエコシステムを単一のパッケージに構築する開発者にとってはHeadless CMSである、という点です。

Drupalが長い間簡単なウェブサイトに力を与え続けていると、他のバックエンドシステム、シングルページアプリ、ネイティブアプリ、さらには会話型インタフェースにもコンテンツを提供するために使われるようになってきました。しかも同時にです。

（関連記事：「詳細解説：Drupalサイトを静的HTML（Static HTML)に変換する方法」）

Headless CMSはコンテンツ編集者を置き去りにする

 

この図は、従来のDrupal Webサイトと、コンテンツを受け取るさまざまなフロントエンドを持つHeadless CMSの違いを示しています

中には、コンテンツ編集者やマーケティング担当者の観点で言うと、Headless CMSはDrupalやWprdpressといった従来型のCMSを置き換える存在になると言う人もいますが、個人的にはどうなるかわかりません。

Headless CMSがうまくいかない時は、コンテンツの即時編集と、設定画面へ直感的にアクセスさせたい時です。これとは対照的に、私たちの外部を取り込む取り組み（Drupalコミュニティ以外から良いものを取り入れる取り組み）は、エンドユーザーエクスペリエンスとはまったく別のインターフェイスではなく、ライブプレビューと並行してインターフェイスでコンテンツおよびページ構造を管理することをエディターに許可することを目指しています。このパラダイムのいくつかの例には、ブロックを直接リージョンにドラッグすることやメニュー項目を並べ替えることなどがあります。

そもそもHeadless CMSは、コンテンツを提供するフロントエンドに統合された本格的な編集体験が不足しています。各フロントエンドに関連付けられたコンテンツ編集インターフェイスが公開されていない限り、設定画面への直感的なアクセスや、コンテンツの即時編集は不可能です。

言い換えれば、フロントエンドで編集体験を提供するためには、そのフロントエンドはコンテンツ編集インターフェイスのことを知っておかなければならないと言うことです。つまり、カップリングの必要性がある、ということです。

表示とレイアウトの操作は、マーケティング担当者を成功に導く鍵となるもう一つの領域です。Drupalの主な機能の1つは、コンテンツがレイアウト構造内に表示される場所を制御する機能です。Headless CMSは、表示やレイアウト設定について何もできません。しかし、設定画面への直感的なアクセスや、コンテンツの即時編集のケースと同じように、これを可能にする編集ツールは、エンドユーザーにつながるフロントエンドに連携している必要があります。

加えて、編集者とマーケティング担当者は、一度コンテンツが投稿されるとそれがどのように見えるのか、ということについて特に気にしています。簡単な閲覧ユーザーと同じテーマを使ったプレビューシステム、特に投稿されていないのコンテンツへのアクセスは、多くのエディタのワークフローにとって不可欠です。

Headless CMSのパラダイムでは、開発者はシームレスプレビューを実現するために、新しいAPIエンドポイントやステージング環境を設定したり、新しいパスに対してリクエストを発行する別バージョンのアプリをデプロイすることを含む、かなり重要なフープを飛び越えなければなりません。結果的に、シームレスプレビューは（開発者の肩をたたくことなく）まだ必要だと思っています。

設定画面への直感的なアクセスや、コンテンツの即時編集、レイアウト操作のような機能、そしてシームレスだが正確なプレビューは、コンテンツ制作者やマーケティング担当者にとって最適な編集体験を得るための不可欠な要素です。

いくつかのユースケースでは、これらの欠点はアプリケーションが編集上のやり取りをほとんど必要とせず、開発者重視の場合完全に管理することができます。しかしコンテンツ編集者にとってHeadless CMSは単純に彼らが期待するような機能を提供することができません。Drupalが評価される時に他のヘッドレスシステムは評価されないでしょう。

（関連記事：「CMS機能比較 DrupalかWordPressか？- 最適なWebプラットフォームを選択する方法」）

Drupalはコンテンツ編集者のことも、アプリ開発者のこともサポートします

 

この図は、結合されているがヘッドレス対応のDrupal Webサイトと、様々なフロントエンドでコンテンツを受け取るHeadless CMSの違いを示しています

ヘッドレスが重要ではない、ということを言いたいわけではありません。ヘッドレスは重要です。しかしヘッドレスな部分と従来型のアプローチを両方サポートしている、という部分がDrupalの最も大きな利点の一つになります。結局のところ、コンテンツ管理システムは編集者の要望に寄ったウェブサイトだけでなく、シングルページアプリ、ネイティブアプリ、ウェアラブルデバイス、音声アシスタント端末、IoTなどの新興デバイスにもコンテンツを提供していくことが必要になります。

幸運にも、進行中のAPI-firstイニシアチブは、開発者にとってより簡単で最適なコンテンツサービスとして利用する既存のWebサービスや新しいウェブサービスの努力をさらに発展させるために機能しています。私たちは、JSON APIやGraphQLのような優れた開発者体験を提供するWebサービスやWaterwheelエコシステムのようなヘッドレスアプリケーション開発を加速するツールを使って、これらのアプリケーションの開発者をより生産的にすることに取り組んでいます。

私にとってこの議論のポイントは、Drupalは開発者にとってもコンテンツ編集者にとっても良いということです。しかしいくつか注意点があります。エディタやサイトビルディングに重点を置く必要のあるWeb体験のために、開発者を関与させることなくフロントエンドを編集し操作する能力を備えた、結合されたDrupalフロントエンドを使用する必要があります。

逆に編集者を必要としないWeb体験にもDrupalは理想的なソリューションです。APIファーストのアプローチでは、Drupalは明示的にサポートできない他のデジタルエクスペリエンス（ウェブベースではないもの）を提供します。どちらのオプションもオープンです。
 

自分のサイトのためにはDrupalを、アプリにはヘッドレスDrupalを

 

この図は、Drupalの理想的なアーキテクチャを示しています。フロントエンドとして、そして他のフロントエンドのためのコンテンツサービスとして活用されるべきアーキテクチャです。

今のこの時代、一つのソースから全てのチャネルにコンテンツが提供されるということは重要なことです。しかし、このアプローチのためにはどんなアーキテクチャが最善なのでしょうか？この記事を読んでいる間に、私が昨年投稿した記事「どうやってDrupalをdecoupleにすべきか」を読んだことがあるかもしれない、とデジャブに陥ったかもしれないですね。あの記事は、投稿から1年たった今も適切なアドバイスだと思います。

最終的に、Drupalがcoupledにもなりdecoupledにもなるアーキテクチャをお勧めしました。簡単にいうと、Drupalはコンテンツ編集者とアプリ開発者の両方のために役立ちたい時に力を発揮します。なぜならDrupalは両方のパートが得意だからです。言い換えると、あなたのコンテンツストレージは公に情報を発信しているウェブサイト（編集機能が完全に揃った切れ目のないサイト）であるべきです。

そしてそのサイトは、数あるアプリケーションの中心であるべきです。編集機能は必要としませんが、開発者が求めている体験を提供できるものであるべきです。統合ウェブサイトとしてのDrupalを維持すると同時に、Decoupleアプリケーションを追加することは制限ではなく、機能強化です。
 

結論

今日のお話のゴールは、DrupalをAPIだけに対応したプラットフォームにするということではなく、APIファーストにするということです。これは、APIなしのCMSのような結合されたアプローチに制限するものではなくContentfulやその他のHeadless CMSのようなAPIのみのアプローチに限定されません。

私にとっては、これが最も重要な結論です：Drupalはあらゆる可能性をサポートしています。このことにより、コンテンツ編集者とマーケティング担当者のために最適化をすることと、開発者のために最適化をすることの間で適切なトレードオフを可能にします。またニーズの変化によって方向性をシフトすることも可能にします。これは、結合アプローチとヘッドレスアプローチが表すシナリオの両極端を包括するスペクトルです。長年やってきたように、Drupalを使って一つのウェブサイトで力を発揮させることができます。

同時に、従来のウェブサイトを超越した領域で、たくさんのアプリで力を発揮することも可能です。そうすることで、Drupalは開発者や編集者の要求に応じてこのスペクトルに沿って仕組みを調整できます。言い換えれば、DrupalはAPI-onlyではなく、API-firstであり、編集者やマーケティング担当者を開発者に任せておくのではなく、必要なものを1つのパッケージで提供します。

Preston Soにこのブログ投稿に貢献してくれたこと、Wim Leers、Ted Bowman、Chris Hamper、Matt Grillに書くにあたりフィードバックしてくれたことに感謝します。
 

終わりに - Headless CMSというトレンド

非常に示唆に富んだ記事です。2016年初頭のDrupal 8が発進した当初からHeadless Drupalについての議論が熱く交わされてきました。曰く、「Node.jsでDrupalを作り変えるべきではないか？」「Drupal標準のJS Frameworkを決定して早急にコアに取り込むべきではないか？」などなど。

その頃の喧騒から一年経ってANNAIではDrupalの魅力を再発見しています。実際Driesが話しているとおり、サーバーサイドを別システムで構築しフロントをDrupalで担当する機会が以前より増えています。Headlessの逆パターンによるDecoupledです。

名前はまだないのですが「API Storage Drupal」「Bodyless Drupal」とでも呼ぶべきアーキテクチャですが、このDrupalを使ったUI開発の可能性に驚いています。今後、世界に先駆けた先進事例をご紹介できると思います。ぜひ楽しみにしておいてください。

(Photo by Milada Vigerova on Unsplash)