- 記事管理の仕組みが複数のシステムに分散しており、管理が複雑化していた
- WordPress構成による独自カスタマイズの蓄積で、SEO担当者が気軽に更新できない状態だった
- 記事更新のたびにエンジニアの対応が必要で、施策のPDCAサイクルを回せなかった
- 記事更新にかかるエンジニア工数がほぼゼロになり、マーケティング部門主導で運用が完結できるようになった
- マーケティング担当者だけでSEOのメタ情報変更や記事の軽微な修正が実施可能になり、施策のPDCAサイクルが大幅に加速した
- 記事更新のリードタイムが7日から1日以下に短縮された
導入の背景:複雑化した記事管理体制を刷新し、コンテンツに注力できる環境を整備したい
microCMSを導入した背景をお聞かせください。
-堀川さん
「引越し侍」は約20年の歴史をもつサービスということもあり、長期にわたって記事管理をしています。記事管理システムが時代ごとに作られており、データは複数のシステムに分散していました。
また、運用していたWordPressには独自のカスタマイズが積み重なっていて、気軽に記事を更新できる状態ではなかったんです。記事を新規作成するときだけでなく、軽微な修正をしたいときでもエンジニアがHTMLを直接触ることで対応しており、CMSとしての強みを活かせていない状況でした。
こうした課題を解消し、コンテンツ運用そのものに注力できる体制を整えるために、CMSの移管プロジェクトが始まりました。
ヘッドレスCMSを選んだ理由はなんだったのでしょうか?
-堀川さん
エンジニアチームにNext.jsの知見があったので、モダンなフロントエンド技術を活かしたいと思い、ヘッドレスCMSをバックエンドに利用することを考えました。

microCMSを選んだ決め手はなんでしたか?
-堀川さん
SaaSで提供されていて、自分たちでCMS自体を管理しなくて済むことが最大の理由です。
OSSのヘッドレスCMSをセルフホストすることも検討しましたが、対応バージョンが古く、ビルドやデプロイの環境構築がなかなか大変だとわかりました。自社グループ内で開発している独自CMSも候補だったのですが、こちらについても運用のためのメンテナンスコストはどうしてもかかってしまうのがネックだったんです。
microCMSを試してみたところ感触がよかったので、他のヘッドレスCMSと比較検討する前に採用を決めました。日本語のUIで操作できることやサポートを利用しやすい点はマーケティング部門にとって便利ですし、エンジニアの目線ではスキーマの自由度の高さが決め手になりました。
導入までのプロセス:他社事例を参考に、メンテナンスコストをなるべく低くする形でmicroCMSを組み込み
開発にあたって、工夫した点や参考にした事例はありましたか?
-堀川さん
当初はリッチエディタを使って独自記法でコンポーネントを埋め込む方式で開発していました。しかし、「引越し侍」の記事はデザインの要件が細かいため、変換処理を自分たちで実装しなければならない箇所が増えてしまいます。メンテナンスコストを下げるという当初の目的から乖離してしまったので、途中からZOZOさんの記事を参考にして、繰り返しフィールドを用いた構造化データへと設計変更しました。構造化することでコンポーネントと記事のスキーマを合わせやすくなり、エンジニアが扱いやすい形でコンテンツを受け取れるようになりました。

導入時の体制と進め方を教えてください。
-堀川さん
エンジニア2名とデザイナー1名のチームに、記事を制作するマーケティング部門のメンバーが加わる形で進行しました。移管プロジェクトの開始時にはステークホルダーとなる部署の方を集めて方針を共有し、週次でミーティングをしながらマーケティング担当者が実現したいことやほしい機能をすり合わせていきました。
最初の記事を公開したのは、microCMSの検討を始めてから3〜4か月後です。途中でリッチエディタ方式からの設計変更も行ったため、最終的なWordPressからの移管完了までには14か月ほど掛かっています。SEOなどへの影響を見極めながらテストを繰り返していったためです。
活用の状況:SEO記事の管理をmicroCMSに移管
どのようにmicroCMSを活用していますか?
-堀川さん
おもにSEO記事の管理・配信に利用しています。具体的には、引越しに関するハウツー記事や引越し費用についての記事、インタビュー記事などのSEO記事です。
技術構成について教えてください。
-宮﨑さん
フロントエンドにはAstroを利用し、CSSにはTailwind CSSを採用しています。インフラはAWS App Runnerで、CDNはFastlyです。
開発当初からしばらくの間はNext.jsを利用していましたが、SEO対策の一環としてAstroに切り替えました。もともとNext.jsで開発する際にコンポーネントをフレームワークから切り離して設計していたため、Next.jsからAstroへの変更作業は2か月ほどで完了しています。ヘッドレスCMSによってフロントエンドとコンテンツ管理が分離されていたので、スムーズに進めることができました。

コンテンツの運用フローを教えてください。
-宮﨑さん
マーケティング部門の担当者がGoogle ドキュメントなどで下書きをつくり、microCMSに入稿しています。入稿作業が完了したあとはマーケティング部門内でレビューを行い、記事公開ステータスに進みます。URLルーティングの本番反映など一部の作業はエンジニアが対応していますが、多くの記事はマーケティング部門だけで公開まで完了します。
導入の効果:非エンジニアのみで記事制作や更新を完結。SEO対策のPDCAも高速に
microCMSを導入して、どのような効果がありましたか?
-宮﨑さん
一番の効果は、記事更新にかかるエンジニアの工数がほぼゼロになったことです。以前はエンジニアがHTMLを書いて記事を制作していたため、場合によっては1本の記事を制作するためにエンジニアが1か月以上も関わることもありました。microCMSの導入後は、これまでと変わらない品質の記事をマーケティング部門だけで運用できています。
移行前の運用では、タイトルやディスクリプションなどのメタ情報を変えたいときにもエンジニアが作業する必要がありました。リードタイムも7日間ほど発生してしまうため、SEOの効果検証がなかなかできませんでした。また、記事内のコンテンツの順序を入れ替えるような作業も、当時のカスタマイズしたWordPressでは気軽には行うことができず、その都度エンジニアがコーディングをして、表示の崩れがないかどうか確認してからリリースしていました。microCMSに移行してからは、こうした更新作業をマーケティング部門だけで実施できるようになり、検証が進めやすくなっています。

CMS移管によるSEOなどへの影響はありましたか?
-宮﨑さん
既存の記事をすこしずつ移していく形で進めていたため、PVや検索順位に大きな変動はありませんでした。リスクを抑えながら安全に切り替えを完了できたと思います。サイトの更新性が上がったことで、新しい記事をスピーディーに公開できるなどのPDCAサイクルの高速化という効果も出ています。
microCMSの使い勝手についてはいかがでしょうか。
-堀川さん
それまでのCMSが複雑すぎたということもありますが、マーケティング部門のメンバーからもmicroCMSは好評です。詳しいレクチャーをすることも特になく、簡単に運用を始めることができました。制作段階からマーケティング部門の意見を丁寧に聞いていったので、リリース時にトラブルになることもありませんでした。
-宮﨑さん
何度かmicroCMSのサポートに問い合わせをしていますが、すぐに日本語で返事がくるのはやはり嬉しいですね。開発や運用の途中でなにか不安なことが起きても、すぐに解消できています。

今後の展望:引越し事業で管理しているすべてのサイトでのmicroCMS導入を目指す
今後はmicroCMSをどのように活用していきたいですか。
-宮﨑さん
引越し事業では複数のSEOサイトを管理していますが、現時点ではまだ1サイトへの導入にとどまっています。今後は他のサイトへもmicroCMSを導入していく方針です。
また「引越し侍」へのmicroCMS導入はSEO記事を中心とした一部のページのみとなっているため、サイト全体・すべての記事ページをmicroCMS管理できるよう拡大していこうと考えています。
microCMSに期待することはありますか。
-宮﨑さん
構造化したJSON形式で記事を登録しているため、記事の全文検索で引っかからないケースがあります。検索の精度がさらに強化されるとありがたいです。
-堀川さん
記事公開前のレビューがmicroCMSの標準機能としてワークフローに組み込まれている点は、とても使いやすく感じています。レビューや承認の機能がさらに充実していくと、もっと便利に使えそうだと思います。
取材協力:エディット合同会社(ライター:藤井亮一 撮影:八木智三)
