本記事の対象読者と前提
本記事は、企業サイト、オウンドメディア、技術ブログなどのコンテンツ配信基盤を検討している方を対象としている。
ただし、本記事は microCMS の利用方法を解説するものではない。
また、WordPressや他のCMSと優劣を比較する記事でもない。
本記事の目的は、DataLiner がコンテンツ管理基盤に何を求め、
その結果としてなぜ microCMS を採用したのかを整理することである。
重要なのは microCMS そのものではない。
DataLiner がどのような判断基準で CMS を選定したのかである。
本記事で参照する主な情報
WordPress
参照内容
- CMSとしての基本思想
- プラグインによる拡張性
- 世界的な普及状況
WordPress Security
https://wordpress.org/about/security/
参照内容
- WordPressのセキュリティ方針
- 継続的なアップデート
- セキュリティメンテナンス
Newt サービス終了告知
https://www.newt.so/notice/newt-close
参照内容
- サービス終了に関する公式発表
- サービス終了時期
- 移行方針
microCMS
参照内容
- Headless CMSとしての機能
- APIベースのコンテンツ配信
- 国産サービスとしての特徴
microCMS セキュリティ
https://microcms.io/features/security/
参照内容
- microCMSのセキュリティ方針
- データ管理
- 提供体制
microCMS 会社概要
https://microcms.co.jp/company
参照内容
- 事業主体
- 国内事業者であること
- サービス提供体制
Astro
参照内容
- Static Site Generation
- Content Collections
- Headless CMS連携
- APIベースのコンテンツ取得
1. DataLinerがCMSに求めたもの
1.1 CMSに求めた役割
表玄関および語り部の座を構築するにあたり、DataLinerではCMSが担う役割を明確に定義した。
CMSの役割は、
コンテンツを管理すること
である。
一方、
ページを表示すること
はフロントエンドの役割である。
この責務は分離したかった。
DataLinerでは、表示基盤として Astro + React を採用している。
そのため、CMSには表示機能よりも、
- コンテンツ管理
- APIによるデータ提供
- 長期運用性
を求めた。
1.2 Headless CMSを前提にした理由
DataLinerでは、CMSと表示基盤を疎結合にしたいと考えていた。
コンテンツ管理はCMS。
表示はAstro。
この責務分離を実現しやすいのが Headless CMS である。
Headless CMSであれば、
フロントエンド技術を自由に選択できる。
将来的に表示基盤を変更したとしても、コンテンツ資産は維持できる。
また、コンテンツ管理とフロントエンド開発を独立して進めることもできる。
この考え方は、DataLinerのアーキテクチャ方針と一致していた。
[推奨 Callout]
DataLinerでは、CMSを「Webサイトを表示する仕組み」ではなく、「コンテンツを管理する仕組み」として捉えている。
2. なぜWordPressを採用しなかったのか
2.1 WordPressは優れたCMSである
まず明確にしておきたい。
WordPressは優れたCMSである。
世界中で利用されており、実績も豊富である。
プラグインも充実している。
テーマも豊富である。
企業サイトから個人ブログまで幅広く利用されている。
その意味で、WordPressは非常に有力な選択肢だった。
2.2 DataLinerとの相性
しかし、DataLinerが求めていたものとは少し異なっていた。
DataLinerでは、
- CMS
- フロントエンド
を明確に分離したかった。
一方、WordPressは、
コンテンツ管理
表示
を一体として扱うことを得意としている。
もちろんHeadless WordPressという選択肢も存在する。
しかし、それであれば最初からHeadless CMSを採用する方が自然だと考えた。
2.3 管理対象を増やしたくなかった
WordPressでは、
- WordPress本体
- プラグイン
- テーマ
- サーバー環境
などを継続的に管理する必要がある。
もちろん、これはWordPress固有の問題ではない。
自らCMS実行環境を保有する場合には一般的に発生する運用である。
DataLinerでは、
開発・運用を少人数で継続することを前提としていたため、
コンテンツ管理以外の運用負荷をできるだけ減らしたかった。
その結果として、
WordPressを採用しなかった。
3. 当初はNewtを採用予定だった
3.1 Newtを選んだ理由
実は、DataLinerは当初から microCMS を選んでいたわけではない。
当初は Newt を採用する予定だった。
Newtは国産のHeadless CMSであり、
- API中心の設計
- Astroとの親和性
- シンプルな構成
に魅力を感じていた。
DataLinerの構想との相性も良かった。
そのため、CMS選定はほぼ完了したと考えていた。
3.2 サービス終了
しかし、その後 Newt のサービス終了が発表された。
技術的な問題が発生したわけではない。
サービスそのものが終了することになったのである。
当然ながら、継続利用は困難になった。
その結果、DataLinerではCMS選定をやり直すことになった。
なお、本判断の根拠となったサービス終了については、
Newt運営元による公式アナウンスを参照している。
詳細については、本記事末尾の参考情報を参照いただきたい。
DataLinerでは、
サービス終了そのものを問題視したのではない。
むしろ、
SaaSは将来的に終了する可能性がある
という事実を改めて認識する機会となった。
3.3 SaaS選定で学んだこと
この経験から学んだことがある。
それは、
技術的に優れていること
と
長期運用できること
は別であるということだ。
SaaSを選定する場合、
機能だけを見れば良いわけではない。
事業継続性
サポート体制
利用実績
なども重要になる。
今回の経験は、そのことを改めて認識する機会になった。
4. なぜ microCMS を採用したのか
4.1 国産Headless CMSとしての実績
再選定の結果、DataLinerでは microCMS を採用した。
最大の理由は、
国産Headless CMSとしての実績
である。
利用実績も豊富であり、
サービス継続性についても一定の安心感があった。
また、Headless CMSとして必要な機能も十分に備えていた。
4.2 データロケーションを重視した
DataLinerでは、データがどこに保存されるのかを重要な判断基準としている。
これは単なる技術的な興味ではない。
- 事業継続性
- 法規制
- セキュリティ
- 将来的な運用リスク
を考慮した結果である。
そのためCMS選定においても、
データ保管場所やサービス提供主体について確認を行った。
microCMSは日本企業によって提供されているHeadless CMSであり、
DataLinerが重視する判断基準との整合性が高かった。
なお、データ保管場所やサービス提供体制については、
microCMS公式サイトおよび公式ドキュメントを参照している。
4.3 海外製Headless CMSを採用しなかった理由
海外製のHeadless CMSには優れた製品が数多く存在する。
例えば、
- Contentful
- Sanity
- Hygraph
などは有力な選択肢である。
しかしDataLinerでは、
海外製だから不採用
ではなく、
国内データロケーションを優先した結果として採用しなかった。
つまり、
機能比較で負けたのではない。
判断基準が異なっていたのである。
4.4 Astroとの相性
microCMSはAPIベースでコンテンツを提供する。
この仕組みは Astro と相性が良い。
ビルド時にコンテンツを取得し、
静的HTMLとして生成できる。
その結果、
表示速度
SEO
保守性
を両立しやすい。
これはDataLinerが目指していたサイト構成とも一致していた。
5. 技術選定から学んだこと
5.1 CMS選定は機能比較ではない
CMS選定というと、
機能比較になりがちである。
しかしDataLinerでは、
何を実現したいのか
どのような制約があるのか
どのリスクを受容するのか
を先に考えた。
その結果として、
WordPress
↓
Newt
↓
microCMS
という意思決定に至った。
5.2 技術選定は将来の変更を前提にする
今回の経験で改めて認識したことがある。
それは、
技術選定は永久ではない
ということである。
Newtは魅力的な製品だった。
しかしサービス終了によって再選定が必要になった。
だからこそ、
将来の変更可能性を残す設計
が重要になる。
DataLinerがHeadless CMSを採用した理由の一つも、まさにそこにある。
おわりに
本記事では、DataLinerがなぜ microCMS を採用したのかを整理した。
重要なのは、
microCMSが優れているかどうかではない。
WordPressが劣っているかどうかでもない。
DataLinerが何を実現したかったのか。
どのような制約があったのか。
どのようなリスクを避けたかったのか。
その結果として、
WordPressではなくHeadless CMSを選び、
NewtからmicroCMSへ移行したのである。
技術選定とは、技術の勝敗を決めることではない。
判断基準を定め、その基準に照らして選ぶことである。
DataLinerにおけるmicroCMS採用は、その一つの記録である。
参考情報
WordPress
WordPress Security
https://wordpress.org/about/security/
Astro Documentation
microCMS
microCMS Security
microCMS Company
Newt サービス終了告知