Drupal は「API 優先」であって「API のみ」ではない

「ヘッドレス CMS」として知られる「コンテンツ-as-a-Service」ソリューションを選択する開発者が増えている。それは最小限の編集インターフェイスを備えたコンテンツ置き場（リポジトリー）であり、増えていく一連のアプリケーションが使いこなすためのコンテンツ API が備わっている。ヘッドレス CMS には、いくつか共通した特徴がある。エンドユーザーにとってのフロントエンドがなく、表示およびレイアウトのための編集ツールがほとんど、または全くない。そのため、見せ方に関する事柄は、ほぼすべて、フロントエンド エンジニアに任せることになる。ヘッドレス CMS の人気が出たのは以下の理由による。

• フロントエンドとバックエンドそれぞれのチームが独立して作業できるよう、構造に関する事柄と提示（表示）に関する事柄を分けたいという願望があるため。
• コンテンツを数々のチャンネルに配信できるソリューションを編集者とマーケッターが求めているため。そのチャンネルには、Web サイト、バックエンド システム、シングルページ アプリケーション、ネイティブ アプリケーション、さらには、ウェアラブル機器、対話型インターフェイス、IoT デバイスといった、これから登場してくるデバイスまでもが含まれ、その数は増え続けている。

開発者の間では、こうしたトレンドがあるので、ヘッドレス CMS は従来型 CMS の市場に挑みかかっている（従来型にとって脅威である）のではないかと、もっともな問いを発する人が多い。僕自身は、ヘッドレス CMS というものが今日あるところに CMS 業界全般が向かっているという確信は持てていない。実際のところ、微妙な意味合いをもたせた見方が必要だと考えている。

このブログ記事では、登場してくるヘッドレスの競合たちを引き離す決定的な長所が Drupal にある理由を説明したいと思う。すなわち、Drupal は、自分のコンテンツの見せ方をコントロールする必要のある編集者にとって抜群の CMS であり得ること、そして、単一のパッケージに収まる大規模なコンテンツ エコシステムを増築していく開発者にとっては豪華なヘッドレス CMS になれることだ。

Drupal が長年、その本来の役目として Web サイトを動かし続けてきたなかで、コンテンツの出力先も増えてきた。他のバックエンド システム、シングルページ アプリケーション、ネイティブ アプリケーション、対話型インターフェイスさえもある。すべて同時に（並行して）増えたのだ。

ヘッドレス CMS は編集者が取り残される

コンテンツ編集者とマーケッターに限っていえば、Drupal や WordPress など従来型の CMS はヘッドレス CMS に入れ替わってしまうだろうという人もいる。僕はそうなるかどうかわからない。

ヘッドレス CMS が太刀打ちできないところは、インコンテクスト（in-context）管理、そしてコンテンツのインプレース（in-place）編集の分野だ。それとは対照的に、僕たちが「裏返し（outside-in）」と呼んでいる作業は、編集者がコンテンツとページ構造をライブプレビューのある１つのインターフェイス内で管理できるようになることを目指している。エンドユーザー体験とは全く別のインターフェイスではないのだ。このパラダイム（操作原理）の例としては、ブロックを直接、リージョンにドラッグする、メニュー項目の順序をドラッグで変える、そしてその変更がどちらも目の前ですぐに適用される、といったことが挙げられる。

ヘッドレス CMS には原理上、コンテンツの提供先であるフロントエンドに統合されたフル装備の編集体験（編集インターフェイス）がない。ひとつひとつのフロントエンドに結びつけたコンテンツ編集インターフェイスを開けておかないかぎり、インコンテクスト管理とインプレース編集は不可能だ。言い換えるなら、フロントエンドに編集体験を提供するには、そのフロントエンドには、そのコンテンツ編集インターフェイスがわかっていなくてはならない。よって、カップリングは必要だということになる。

表示とレイアウトの操作は、マーケッターが成功するかどうかを決めるカギとなる、もうひとつの領域だ。Drupal の主要な機能のひとつに、レイアウト構造のなかでコンテンツが表示される場所をコントロールできるということがある。ヘッドレス CMS には表示とレイアウト設定に関する独自の方針というものがない。しかし、インプレース編集とインコンテクスト管理と同様、それを実現する編集ツールを役立たせるには、エンド ユーザーが接するフロントエンドに統合する必要がある。

それに加えて、編集者とマーケッターには、コンテンツを公開したときの見え方がとりわけ気になる。特に、非公開コンテンツであってもエンド ツー エンドで容易なプレビュー システムにアクセスできる、ということが数多くの編集者のワークフローにとっては不可欠だ。開発者は、ヘッドレス CMS のパラダイムにおいてシームレスなプレビュー機能を実現するには、かなり奮闘しなくてはならない。すなわち、新しい API エンドポイントなりステージング環境なりを立てる、新しいパスに対するリクエストを出す別バージョンの自前アプリケーションを展開する、などといったことだ。そうしたことを鑑みて、開発者の手を煩わせなくても済むシームレスなプレビュー機能は、まだまだ必要だと僕は考えている。

インプレース編集、インコンテクスト管理、レイアウト操作、シームレスでありながらも信頼できるプレビューといった機能は、コンテンツ作者とマーケッターにとって最適な編集体験を構築する基本的な部品だ。これらの問題点は、特にアプリケーションが開発者側を対象にしていて編集用のインタラクションがほとんど不要な場合など、ユース ケースによっては全く問題なく対処できる。しかし、コンテンツ編集者にしてみれば、ヘッドレス CMS は期待してきたようなツールキットをそもそも提供してくれない。これが、ヘッドレス CMS は及ばず、Drupal が秀でたところだ。

Drupal は編集者とアプリケーション開発者の両方を支援する

こうしたことは全部、ヘッドレスが大事ではないと言っているわけではない。ヘッドレスは重要だ。しかし、ヘッドレスと従来型、両方のアプローチをサポートしているということが Drupal のいちばん大きな長所のひとつだということだ。結局のところ、コンテンツ マネージメント システムは、編集者を対象にした Web サイトを越えて、シングルページのアプリケーション、ネイティブ アプリケーション、さらには、ウェアラブル端末、対話型インターフェイス、IoT 機器など、これから現れてくるデバイスにさえもコンテンツを配信する必要があるのだから。

幸い、継続中の「API 優先」イニシアチブは、コンテンツ サービスとして Drupal を使うのがずっと容易に、かつ、開発者にとっていっそう最適化されたものになるよう、既存および新規の Web サービスに関する作業を進めるべく積極的に取り組んでいる。JSON API や GraphQL のようなすばらしい開発者体験（開発環境）を提供するなり、Waterwheel エコシステムのようにヘッドレス アプリケーション開発を加速させるようなツール群をそろえるなりして、これらのアプリケーションの開発者がより生産的になれるようにと、僕たちは努力している。

僕から見れば、この議論における主な収穫は「Drupal は編集者にとっても開発者にとってもすばらしい」ということだ。ただ、注意すべき点がある。編集者または（コンテンツの）構成編集者の体験（操作環境）を特に重要視する必要のある Web 体験には、一体型 Drupal のフロントエンドを使うべきだ。そうすれば、開発者を巻き込むことなしにフロントエンドの編集、操作ができる。（逆に）編集者を巻き込む必要がない Web 体験にも Drupal は理想的だ。API 優先のアプローチをとることで、Drupal は対応を明確にできない（Web ベースでない）他のデジタル体験にも備えている。これによって、どちらのオプションにも道が開かれているわけだ。

サイトには Drupal、アプリにはヘッドレス Drupal

今の時代、すべてのチャンネルが単独ソース（SSOT: Single Source of Truth）のコンテンツによって供給されるようにすることが重要だ。ただ、このアプローチにはどんなアーキテクチャーが最適なのか？これを読みながら、僕が去年、書いた「Drupal をどう分離すべきか」というブログ記事の「デジャヴ体験」を感じた読者もいることだろう。投稿して 1 年近くになるが、あの記事は今でも確かなアドバイスになる。

最終的に僕は、一体型でありながら分離型でもある Drupal アーキテクチャーを推奨する。要は、Drupal は編集者とアプリケーション開発者の両方に向けた位置づけにおいて秀でているということだ。どちらの役割にとってもすばらしいのだから。言い換えるなら、コンテンツのリポジトリーは（置き場所であるだけでなく）世間に向けた Web サイトでもあるべきだということになる。それは切れ目なくつながっていて、編集機能もフルに備えたサイトだ。同時に、そのサイトは一連のアプリケーションの中心であるべきだ。それらのアプリケーションは、編集ツールを必要としないが、開発者の求める開発体験を与えてくれるものだ。分離型アプリケーションを加えながらも Drupal を一体型に保つというのは「制限」ではない。「拡張」だ。

結論

今日の目標は Drupal を「API のみ」ではなく「API 優先」にすることだ。（だから）「API なし」の CMS のような一体型アプローチだけ、あるいは Contentful や他のヘッドレス CMS のような「API のみ」のアプローチだけに制限することはない。僕にとってはそれが、この議論から導かれるいちばん大事な結論だ。Drupal は可能性の領域全体をサポートする。だから、編集者・マーケッターのための最適化と、開発者のための最適化の間でうまく歩み寄ることができるし、ニーズが変わったら、その領域内のどこかに（妥協点を）移せばいい。

それは一体型とヘッドレス、双方のアプローチで生じる両極端の状況をすっぽりとカバーする領域だ。僕たちが何年もやってきたように、Drupal は単独の Web サイトを駆動するのに使える。同時に、従来型の Web サイトを越えて、多数のアプリケーションを動かすために Drupal を使うことも可能だ。こうして、Drupal は、開発者と編集者の要求に応じて、この領域のなかで（妥当なポイントを）上げたり下げたり調節することができる。

別の言い方をすれば、Drupal は API 優先であって API のみではない。だから、開発者のために編集者とマーケッターがほったらかしにされるようなことはない。誰が来ても、その人の求めるものを与えてくれる。そして、そのすべてが１つのパッケージに収められている、ということだ。

このブログ記事に貢献してくれたプレストン ソー（Preston So）、そして、この執筆中に意見を聞かせてくれたウィム リーアス（Wim Leers）、テッド ボウマン（Ted Bowman）、クリス ハンパー（Chris Hamper）、マット グリル（Matt Grill）に謝意を表したい。