単なるメモ。

Decoupled CMSの世界ではそれぞれ別々に道具を選べる

Jekyllの外の世界からdataを作る準備 - あーありがち(2018-12-09) で書いたような仕組みさえできてしまえば、逆にユーザー向けの HTML の生成が Jekyll でなければならないということもなく、バックエンドの CMS もユーザー向けの HTML を生成するジェネレータも要件に合わせて選択し直せばよい。もはや我々は

• CMS 上での作業者の作業しやすさ
• コンテンツを提供する仕組み
• コンテンツを通じたユーザー、ビジネスへの価値提供
• ユーザーの体験からどんなデータを得たいか（ビジネス価値など）

などを独立して考えることができる。

「○○だからこれができません」も「○○でないと作業担当が困ります」もない世界へ。上に挙げた要件がそれぞれ明確であれば CMS が一体ですべてを担う必要はない。これぞ Decoupled CMS のメリット。

それぞれの道具がマッチするかどうかをどう判断するのか

これらの要件を明らかにするためには一体のアリモノ（Coupled CMS）でまず始めてみて、ここがこうなっていた方がよい、いやこのままでよいといった学習が大事なんだけど、ここの線引きができるかどうかが実際にはかなり難しいと思う。

技術的には Decoupled CMS はそこまで難しい話ではない。しかし「『目先の道具が使いにくい』という視点から離れられるかどうか」は難しい問題だ。それぞれの価値を定義し、それを共有できて始めて分離後の姿を考える話に進むことができる。¹

例えば Prismic.io は "Headless API CMS for both developers and marketers" と謳っている。

Headless API CMS for both developers and marketers - Prismic

マーケターにとって大事なのは細かいデザインの調整ではなく、商品価値が潜在ユーザーに伝わり、それが顧客へコンバージョンされることであり、そのために役に立たないことが CMS で実現されていても別に嬉しくもなんともない。逆にいろんな SNS と手軽に連携するための何かは即時機能追加されてほしいところだろう。

これは「マーケター」という言葉があるから考えやすくなっているのであって、恐らく同様の定義が個々の Decoupled CMS 案件であるべきなのだろう。

• コンテンツを publish する主体者は誰なのか？
• その目的はなんなのか？
• 提供する価値は何か？
• 何が成果なのか？

という話があって初めてそれぞれの道具が果たすべき役割を明確にできる。何のことはない普通の開発の話っちゃ話なんだろうけど、CMS とコンテンツということになると、その目的はそんなにきれいに整理されていないことが多そうだ。

例えば publish する主体が仮に「ライター」と定義されてしまった場合はどうだろう？ 途端に要件がボヤけてしまったはずだ。では「SEOライター」ではどうだろうか？ こうなると例えば検索エンジンのアドバイス（人気の検索ワードとか）にしたがってコンテンツをリアルタイムに採点するような仕組みがあると作業が早くなるはずだ。²

もちろんエンジニアが試してみるだけなら面白ければおっけー

いろいろ書いたけど、エンジニア一人がエンジニア一人のために分離するのはそんなに難しい話はないので、なんでもやってみるのがよさそう！（時間があれば）