こんにちは。LIGでフロントエンドエンジニアをしているレンツと申します。
（「最近、ニックネームを持つ社員が少なくて浮いてきたかなあ」と思いながら日々働いております）。
エンジニアとして働きはじめて2年ほど経ちましたが、普段はWordPressを使用したサイト制作・または保守運用を行っています。そして、今回は「microCMS」というCMSを使用したサイトを制作したのですが、なにぶん初めての経験でよくわからないことがたくさんあったので、制作過程で感じたことをつらつらと綴りたいと思います。
目次
microCMSの良いところ
microCMSはAPIベースの日本製のヘッドレスCMSです
と紹介されているのをちらほら見ます。よくわかりませんが日本製のサービスということで何かと安心感がありますよね！
ここからはmicroCMSについて解説しつつ、メリットをいくつか紹介したいと思います。
ヘッドレスCMS
これが早速よくわからない概念で、最初は「ヘッドレスCMSってなんだ？」という感じでした。「ヘッドレスCMS」をとは、ユーザ側がアクセスするWebサイトのフロントエンド、つまり画面やUIと言った見た目の部分が用意されてないCMSのことです。実際にそういう裏側のソースファイルは基本的に存在していません。
現在もっとも使用されているCMSはWordPressだと思いますが、WordPressでは投稿者が記事を入稿する管理画面であるバックエンドと、コンテンツを閲覧するユーザのためのフロントエンドがセットになっています。つまり、WordPressはヘッドレスでないCMSということになります。
このことから、コンテンツをデータベースに登録して、登録したコンテンツを取得・管理する仕組みの部分「だけ」を持つCMSがヘッドレスCMSということになります。
ここでまた色々とわからないことが出てきます。
「コンテンツはどうやって取得するの？ そしてフロントエンドはどうしたらいいの？」
データはAPIで取得
ヘッドレスCMSにはコンテンツ配布のためのAPIが提供されていて、フロントエンド側でこれを取得する設計になっています。API取得用のキーなどを設定してあげれば、フロント側でコンテンツが取得できるというわけですね。
ちなみに、microCMSの管理画面はブラウザ上のUIになるのですが、ここで入力されたコンテンツはフロントエンド側でJSON形式で取得できます。むしろ、この特性がヘッドレスCMSをヘッドレスCMSとして成立させているとも言えるかもしれません。
さらに、microCMSはGraphQLに対応しており、データ取得時にクエリパラメータを指定することができるため、必要なデータだけ取得するといった絞り込みもできます。
※2023/3/15加筆：理解に誤りがあったので訂正いたします
microCMSはSDKが複数用意されており開発を支援してくれています。今回LIGではフロントエンド開発のフレームワークとしてGatsbyJSを使用したので、gatsby-source-microcmsというSDKを使用しました。これによりGraphQLを使用したデータの取得が可能となるということをお伝えさせていただきます。
microCMSの提供するSDKについてはこちらをご確認ください。
https://microcms.io/features/sdk
こういった開発者へのサポートの手厚さもツールの選定には一役買いますよね。
なお、本修正については記事を読んでくださったmicroCMS社の方がご指摘くださいました。ありがとうございました！
セキュアである
ここでもう一つの特徴であるSaaS型についても触れておきます。
microCMSはSaaS型のサービスなので、UIからサーバ、データベースまですべてがクラウド上にあらかじめ用意されており、ユーザはインターネット上だけで利用することができます。
ここで注意したいのは、このサーバはバックエンド用にだけ存在していて、フロントエンド用には自前でサーバを用意する必要があるということです。つまり、フロントエンドとバックエンドが完全に分離しているということなので、例えば一方が攻撃を受けたとしても他方に影響を与えることがないため、安全性が高い仕組みになっています。
ちなみに、データベースを管理しなくていいのも個人的に安心です。
フロントエンドの自由度
microCMSは別のサーバからJSON形式のデータのみを取得するため、WordPressのようにテンプレート構造に依存したフロントエンドの開発が必要ありません。つまり、取得したデータを好きな位置に表示するだけで、制約のない自由なデザインが可能になります。
さらに、この特性から「React」「Vue.js」「Angular」などのフレームワークやiOSやAndroidなどのモバイルのOSでアクセスすることも可能です。
ちなみにデータ取得APIは「microcms-js-sdk」というmicroCMS製のライブラリで提供されていて、これがjs製なのでフレームワークもjsベースのものが推奨されているようです。実際にLIGではReactベースの「Gatsby.js」で開発をしました。
SSGを使った高いパフォーマンス
「Gatsby.js」はSSG（静的サイトジェネレーター）と言われるツールで、APIで取得したデータが反映された静的なファイルを生成してくれます。
つまりフロントエンドのサーバにはhtmlやcss、jsなどの静的なサイト用のファイルだけ生成されて置いてあることになります。（実際はもっと色々あると思いますけど）！
そのため、リクエスト後にサーバ上でデータを取得したり計算したりする工程が不要で、リクエストがあればそのページのHTMLを返す処理のみが行われるため、高速というわけです。
microCMSの管理画面からコンテンツの更新があればhtmlがそれに合わせて更新されるというわけです。
サポートが手厚い
microCMSは新しいサービスのため、他のCMSに比べてWeb上に情報が少ない印象があります。
しかしながら、開発で困ったことがあればサイト上のチャットツールで質疑応答をしてくれます。割とニッチな質問にも真摯に応えてくれるのでありがたかった……
そして公式ドキュメントが日本語なので翻訳して理解する手間もありません！
パフォーマンスは抜群
microCMSで制作したサイトのLighthouseスコアを計測してみると、何もしなくてもほぼ満点だったりします。これはSSGの良さが存分に出た結果です。（HTML返すだけですからね）。
「サイト完成！」と喜んだあとにパフォーマンスの悪さを指摘されたときの絶望感を味わう必要がないのは素晴らしいことです！
開発体験が良いかも
microCMSではバックエンドの作業がないぶん、フロントエンドに集中して開発ができました。
とは言いつつ、バックエンド開発に当たる作業や、フロントエンドフレームワークの理解にもそれなりに苦労したので注意が必要ではあります。
microCMSの利用で注意すべきところ
microCMSの説明をしつつ良いところを挙げてみましたが、注意すべき点もいくつかあったので記載しておきます。
API設計が難しい
ここで言うAPIとは、microCMSからコンテンツを取得するためのAPIのことではなく、microCMSに登録するコンテンツを指します。
例えば「ブログ記事」というAPIを作って、その中に「記事」を登録します。さらに「ブログカテゴリ」というAPIを作って、その中に「何についてのブログか」といった「カテゴリ」を登録します。そして、これらのAPIを組み合わせて記事登録画面でカテゴリを選択するといったことが可能になります。
この設計がしっかりしていないとフロントエンドのプログラムが煩雑だったり無駄のある内容になってしまいます。
また、無料プランだとAPI数には制限があり大量に使用するにはコストがかかります。運用者のためにもミニマムで無駄のない設計が望まれます。
この設計については、お客様とディレクターがサイトで実装したいこととmicroCMSの管理画面を十分に理解しなければなりません。実際に「機能開発がどうにもできなくてAPIを追加・変更したい」ということが何回か発生してしまいました。（追加・変更というと大袈裟な内容でしたが）。
WordPressの管理画面はPHPが書けたり、適切なテーマを見つければ都合よく運用できますが、microCMSはAPIの作成とそれらの組み合わせが何より重要です。
エンジニアの学習コスト
WordPressであればテーマや情報が豊富なので、エンジニアがいなくてもサイト公開までできてしまいます。（実際にエンジニアが不要かというのは別問題として）。
これに対し、microCMSではフロントエンド開発が必須となるので、APIで取得したデータをどのフレームワークでサイトに落とし込むかかを判断し、そのフレームワークへの知識が必要となります。そのため、エンジニアでない方が気軽にmicroCMSを使用するのはちょっとハードルが高いと思います。
また、今回の開発においては高パフォーマンスな静的なファイルの配信を目指していたので、Gatsby.jsの習得と、フロントエンド用のサーバでGatsby.jsが動く環境にするための技術を要しました。（前者は最低限しか理解できていないし、後者は先輩に任せてしまっていますが）！
フロントエンドの自由度が高いぶん、実装したい内容によっては未知の技術が選定される可能性が十分あることは理解しておいたほうが良さそうです。
microCMSが向いている状況
これまで説明させていただいたとおり、microCMSは以下のような方に向いていると思います。
- セキュリティを重視したい（ヘッドレスのため）
- パフォーマンスを高めたい（静的なサイト配信ができるため）
- デザインに制限を設けたくない（依存するテンプレートがないため）
- 開発コストを抑えたい（バックエンドエンジニアが不要なため）
また、CMS化されていないサイトで部分的に導入するのもありかもしれません。たとえば「お知らせ」といった頻繁に変えたい文言はCMS化したほうが運用は楽です。
エンジニアではない運用者が都度ソースを書き換えている場合にも、導入を検討してみてもいいかも知れません。なぜなら、素人がコードをいじるのは大変危険で、面倒だからです。
大規模だったり複雑な作りで全体のCMS化が困難なサイトで機能を追加する際にも良さそうです。
最後に
microCMSのみならず、Gatsby.js、React、GraphQLなどの新しい開発経験を積めたことに感謝です！ 新しいことにはチャレンジしてみるもんだなあ、としみじみ思いました。
microCMSとGatsby.jsで開発したelnet様のサイト開発秘話もぜひ読んでみてくださいね！
microCMS✕期待を超える提案力で、使いやすさが劇的に向上！「ELNET」サイトリニューアル秘話
Yuka Inaba
それではまた今度。レンツでした。
