編集者向け管理画面の開発やメンテナンスに別れを告げよう

2020/02/18

松田承一

今までのCMSでやりづらかったこと

業種を問わず、サービスを提供するうえでお客様とのコミュニケーションは欠かせません。
コーポレートページや採用情報、自社メディアや更新情報（お知らせ）など、お客様に伝えるべき情報はたくさんあります。

これに対してWordPressなど古典的なCMSで対応できれば良いのですが、こういったCMSでは柔軟性に欠ける場面もかなり多くあります。
例えば自社サービスを独自実装をしている中にお知らせを差し込みたい場合や、スマホアプリやサイネージなどマルチデバイス対応が必要な場合です。

エンジニア工数の使い方は正しいですか？

こうなるとエンジニアの出番です。
非エンジニアの方が入稿・編集できるような管理画面のUIの開発し、サーバやDBといったバックエンドを構築・運用することで解決を図ります。
普段は編集者が管理画面を操作してスムーズにお客様に情報発信をしつつ、UI修正やインフラのトラブルは都度エンジニアが対応するような形です。

さあ、これでみんなハッピー。本当にそうでしょうか？

編集者視点ではこれで問題はないでしょう。自分が普段の業務で使える画面ができているのですから。

問題はエンジニアのリソースです。
エンジニアリソースは人手不足が深刻化する日本では特に貴重です。
こういった貴重なリソースを社内用の管理画面のためだけに使うのはあまり良い兆候ではないでしょう。
ビジネスはお客様のためのものです。通常、社内向けの開発対応はお客様からは遠すぎます。
また、あるいはそもそも工数が取れず、管理画面に代わる代替案としてエンジニアがコンテンツ公開の度に手を動かす方法を取らざるを得ないこともあるでしょう。

ヘッドレスCMSの登場

こういった場面によく適しているのはmicroCMSのようなヘッドレスCMSです。
ヘッドレスCMS自体の説明は下記URLをご参照ください。
https://microcms.io/blog/what-is-headlesscms/

ヘッドレスCMSの利点としてマルチデバイス対応や既存サイトへの差し込みが挙げられていますが、ここでは別の視点で捉えてみましょう。
ヘッドレスCMSの利点は「管理画面にまつわるUI実装やインフラの管理を一切しなくてよくなる」ことです。

事例紹介

あるお客様企業の事例を紹介します。
彼らは新たなメディアサイトを作るにあたりPHPフレームワークを使った独自実装を行おうとしていました。
サイトで提供するコンテンツはメディア記事、口コミ、他社紹介などコンテンツが多岐に渡り、一つ一つのコンテンツの入稿項目が多いことや各コンテンツ間の関連関係も複雑で、古典的なCMSでは対応しきれないことは明らかでした。

開発にあたって管理画面の実装についての課題が上がりました。
新たに開発するメディアの要件を満たし、編集者だけで入稿ができるような管理画面を開発するのに6ヶ月ほどとかなり長い期間がかかることが明らかになったのです。
更に、問題はそれだけでは終わりません。
新たに作るサービスなのでリリース後の実際の閲覧データや関係会社からの要望に応じてコンテンツやその項目の変更が頻繁に必要になることも予測できました。

リリース予定日も非常に近く、苦渋の選択を迫られた彼らの対応策は以下のようなものでした。

入稿者にステージング環境のDB自体にデータ追加してもらいつつ、OKなら本番DBにエンジニアがそのデータを移行して公開
管理画面は新たにエンジニアを一人雇用して対応

しかしこの方法では編集者はとても難しいDBマネジメントシステムの画面を触らなければならず、コンテンツ公開の度にエンジニアが手を動かす必要があります。
新しいエンジニアによる一ヶ月あたり数十万円以上の人件費の増加も予算への打撃が大きいでしょう。

ここで登場するのがmicroCMSです。
microCMSであれば編集者にとって使いやすい管理画面が用意されています。
あらゆるスキーマのコンテンツを定義でき、コンテンツ間の関連を表現するのも容易です。
また、エンジニアにとってもmicroCMSの提供するREST APIを用いてサービス構築をすることはとても自然なものでしたし、全てクラウドで動いているSaaS型のサービスのためサーバやDBの管理コストも一切必要ありませんでした。

先ほどの企業は開発中のタイミングでmicroCMSの導入に踏み切り、当初6ヶ月と見込んでいた作業をまるごと削減できたのです。
またmicroCMSはスキーマの変更も自由にできるため、さまざまな更新に非常に素早く対応できるようになりました。