はじめに
動機
現在、フロントエンドエンジニアとしてとあるオウンドメディアの保守・エンハンスを担当しています。そのサービスでは日本製ヘッドレス CMS である microCMS でコンテンツを入稿・管理しており、管理画面上の入力項目の追加・削除・変更などの対応も請け負っています。
microCMS を含め、一般的に CMS は管理画面で入力項目の設定や変更が可能であり、非開発者であっても簡単に操作が可能です。
しかし、プロダクトとして提供されているサービスで利用している microCMS の設定変更を実際に対応していく中で、気をつけなければならないポイントが多くあることに気づきました。本記事ではそれらのポイントをご紹介します。
また、本記事では microCMS に絞った内容となっていますが、抑えるべきポイントとしては他の CMS にも共通する部分も多々あるのではと思っています。
想定読者
- microCMS（もしくは他の CMS）でコンテンツ管理しているサービスの保守・エンハンスを担当しているフロントエンドエンジニアの方
いきなり結論: microCMS は DB と思って操作せよ
microCMSでコンテンツを管理しているということは、そのサービスにとって microCMS は DB の役割を担っていると言えます。一般的に DB はサーバーサイドエンジニアが管理し、スキーマ変更やデータの移行などは慎重に、しっかり計画立てて行われるものです。
microCMS では管理画面上で簡単に操作が可能であり、フロントエンドエンジニアに限らず非開発者でも気軽に操作することが可能です。しかし、DB の役割を担っている以上、microCMS の管理画面で行う変更操作も DB と同じくらい慎重に、そしてその重みを理解して行うべきです。
microCMS の変更操作のうち、特に気をつけるべき点を2つ以下にご紹介します。
1. API スキーマの変更は DB スキーマ変更と思え
microCMS の API スキーマを変更する、つまり入力項目の設定を変えるということは、microCMS で管理するデータの設定を変えるということです。これを DB に置き換えると、DB 内のデータ構造（スキーマ）を変更するということになります。その変更によって既存データに影響がないか、ある場合はどんな影響があるかを必ず事前に考える必要があります。特に以下のような変更に注意しましょう。
既存データを破壊する変更
フィールドの削除
既存のフィールドを削除した場合は、過去にそのフィールドで入力したデータは全て消えてしまいます。本当に消えても問題ないデータなのかを確認した上で削除する必要があります。
フィールドの種類の変更
microCMS におけるフィールドの種類の変更とは、各フィールドにおけるデータ入力形式の変更のことを指します。例えばテキスト形式のフィールドをリッチエディタ形式に変更したい、というような要望が該当します。
microCMS では、既存フィールドの種類の変更はできません。変更したい場合は、新しいフィールドを作成し、既存のフィールドから移行する、というステップを踏む必要があります。
移行完了後は元のフィールドを削除することになるので、元のフィールドに入力されていたデータは全て消えることになります。移行の際には元のフィールドから新しいフィールドへデータの移し漏れがないように行う必要があります。
データ破壊は起こらないが注意が必要な変更
任意のフィールドを必須に変更（または必須項目を追加）
任意入力だったフィールドを必須にした場合、microCMS の仕様としては再編集しない限り過去に入稿したコンテンツにおいては必須に変更したフィールドが未入力のままでもエラーにはなりません。
しかし、そもそものデータのあり方として正しくない状態を許容することになるので、必須に変更する時点で過去の全てのコンテンツの該当フィールドに対して何らかのデータを入れるべきです。また、必須であるはずのデータが空で返ってくる可能性があることをフロントエンド側の実装で考慮しなければならなくなり、そのような状況はいつか事故を生む可能性があります。
まとめ1: 既存データへの影響を考慮しよう
APIスキーマを変更する際は、入稿済みの既存データにどう影響するか？を常に意識することが重要です。また、そもそもの話ではありますが、フィールド変更がなるべく発生しないよう最初の API 設計も慎重に行うことが大切です。
2. データ移行は DB のデータマイグレーションと思え
APIスキーマの変更によって、データ移行が必要になるケースがあります。例えば先に例として挙げたフィールドの種類の変更については、元のフィールドから新しいフィールドへデータを移行する、という作業が必ず発生します。microCMS ではコンテンツ API を利用してデータの登録・削除もできるので、移行スクリプトさえ作ってしまえば移行作業自体は比較的簡単に実施することが可能です。
しかし、このような microCMS におけるデータ移行は、DB におけるデータマイグレーションと同等と捉えるべきです。DB のデータマイグレーションは通常、ユーザーによるアクセスや更新などを一時的に受け付けないようにして、マイグレーション作業とは関係ない DB 操作が発生しない状態で行います。同様に、microCMS についても移行中は別の作業者によって更新がかけられないように、そしてユーザーから閲覧されないようにするための措置の検討が必要となります。
移行中更新しないようにする
データ移行の最中は、データ不整合を防ぐために別の作業者によって同じデータに対して変更が加えられないようにする必要があります。業務の中で管理画面を操作する人が複数いる場合は、関係者全員にデータ移行のための操作禁止期間を周知することが重要です。特に、フロントエンド実装チームとコンテンツ入稿・管理チームが別の場合は周知漏れがないようにしましょう。
移行中閲覧されないようにする
データ移行の手順によっては、データ移行の過程でこちらが公開したくない状態の画面を閲覧ユーザーに届けてしまう可能性があります。一番確実なのはメンテナンスモードにすることですが、難しい場合は影響が少ない時間帯での実施や、データ移行が完了するまではフロントエンド側からは新しいフィールドデータ > 元のフィールドデータの順で参照し、移行が完了したら新データのみ参照する、というように、フロントエンド側を二段階でリリースする等の対応を検討する必要があります。
その他にも気をつけることはたくさんある
上記以外にも、本番環境でデータ移行を行うまでに確認・検討すべきことがたくさんあります。
例えば、いざデータ移行をしてみたら移行対象データが多すぎて完了までに何時間もかかってしまう、という可能性も0ではありません。あらかじめ本番同等の環境及びデータで移行にかかる時間も見立てておかないと、操作禁止期間やメンテナンスモードにしておく期間の見立ても立てられません。
また、移行時のログは記録として残すべきですし、万が一移行に失敗した場合の対応についてもあらかじめ検討し、サービス側の責任者との間で取り決めておく必要があります。リリース手順の考慮漏れを防ぐためにリリースリハーサルを行うことも重要です。
まとめ2: リリース計画を作成し、リリースリハーサルをしっかり実施しよう
データ移行という1つの作業に対して、事前に考慮・検討しなければならないことがたくさんあるということがお分かりいただけたでしょうか。
これらを全て漏れなく実施するためには、詳細なリリース計画の作成とリリースリハーサルの実施が重要です。
リリース計画では、microCMS 管理画面側及びフロントエンド側それぞれのリリース手順について、フロントエンド側（ユーザーに届く画面）への影響を考慮しながら考える必要があります。また、管理画面操作期間の告知・リハーサル用のダミーデータ作成・データ移行時間の計測など、リリース前の開発・準備フェーズのタスクも全て洗い出して計画に落とし込み、必要な前準備が漏れないようにすることが重要です。そして、リリース計画はフロントエンド実装者以外の関係者も巻き込んで作成し、作成後は関係者全員が把握している状況にすることも忘れずに。
リリース計画の作成が完了したら、その計画に従ってリリースリハーサルを実施し、考慮漏れや改善点があればリリース計画に反映した上でリリースを迎えるようにしましょう。
おわりに
microCMS は全ての設定変更が管理画面上で行えるため、非開発者でも簡単に操作することができます。ただし、操作が簡単だからといって気軽に扱っていいものでは決してありません。
また、microCMS における API スキーマの変更は一見簡単な作業に見えがちですが、想定以上に要検討事項や必要な作業が多く、難易度も高いです。例えばデータ移行が伴う変更の場合は、管理画面側・フロントエンド側の修正以外にもデータ移行スクリプトの作成や要検討事項の洗い出し、リリース計画の作成を行う必要があります。リリース計画についてはフロントエンド以外のメンバーやサービス側の責任者を巻き込んで作成・すり合わせを行う必要があり、全て円滑に行うためには実装スキル以外にもさまざまな能力が求められます。
操作自体が簡単だからといって甘く見ず、上記を踏まえて余裕を持ったスケジュールで丁寧に計画〜リリース作業まで対応できるように心がけましょう。