なぜHeadless CMSをこのサイトに採用しなかったのか

要するにめんどくさくなったからです。

経緯

もともと、このサイトはHugo + Netlifyという構成で、Markdownで記事を書くタイプのブログでした。ただ、それだと更新がめんどくさいかなあと思って、ファイルベースのHeadless CMSであるForestly.ioを使用していた時期もありましたが、意外とエディタとしての使い勝手がよくなく、またログインに手間もかかるので、劇的に更新しやすくなるといった効果はありませんでした。そこで、もっと良いものはないかと、他のHeadless CMSを検討していました。

何を考えたのか

CMSを使えば、確かにドラッグアンドドロップで画像を配置するなど、WYSWIGで編集できます。しかし、文章を主体とするならば、Markdownでの機能で十分といえますし、事前に画像を配置するディレクトリをきっちり決めておけば、それほど悩まずに画像を挿入できると今更ながら気づきました。画像のファイル名をカメラなどからそのまま持ってくるとフォルダの中で見分けがつかないのであらかじめリネームする必要がありますが、それもよく考えればCMSを使うか否かとは無関係に必要な作業です。

また、モバイル端末から更新できるようにすれば、記事を書くための心理的ハードルが下がって更新頻度を上げることができるかも？という淡い期待もありました。 しかし、実際Forestlyの編集画面をスマートフォンで開いてみると、レスポンシブ対応はしているので一応使えるが、快適とは言い難いものだった。モバイル環境で書き上げるというよりかは、下書きツールとしての使用を想定していたが、今のところ書き貯めた下書きは全然書き上げられていません。むしろ、下書き状態で放置せずにさっさと公開してしまった方が自分には合っているような気がします。

それでも、ForestlyやNetlify CMS以外で、より優れた編集機能を持つHeadless CMSは無いのかと探してみました。しかし大抵のHeadless CMSはAPIベースで、これには(自分にとって)最大の弱点が存在します。それはバックアップや他のサービスへの移行が難しいという問題です。現在Headless CMSはサービスが乱立しており、正直言ってどれも未来永劫安泰とは言えないと思っていますが、エクスポートされる形式がjsonなどそのままでは扱いにくかったり、そもそもエクスポート機能が有料だったりすることが分かりました。これではいざという時の避難に手こずることが想像できます。このリスクを背負ってまで、自分一人のためだけに豪華な編集画面を用意する必要はあるのか、段々疑問に感じてきました。

結論

散々悩んだあげく、一つの結論に達します。「要は我慢すればいい」

MarkdownベースのSSG(静的サイトジェネレータ)でサイト/ブログを更新していくのは、CMSを使うのに比べて少し手間がかかるのは事実でしょうが、そもそも記事を書くというのはそれ自体が大変なことであり、ツールの差は些細な問題であると、なぜか僕はそのことに長年気付いていなかった、もしくは気付かないフリをしていたのです。やり方は既に知っているのだから、あとは中身を書くしかないし、中身に関わらない学習/管理コストはなるべく下げるべき、という当たり前のことに、ようやく気付けました。

結局のところ、このサイトはMarkdownで更新する方法を維持することにしました。SSGをHugoからNext.jsへ、ホスティングをNetlifyからVercelへ変更しましたが、これはまた別の理由があるので(やる気があれば)別の記事で書きます。