動画やラジオも！ リッチなWebコンテンツを支えるシステム
クラシコムでは「北欧、暮らしの道具店」というメディアECサイトを運営している。北欧を中心とした生活雑貨やオリジナル商品を販売する「ECサイト」と、その世界観をつくる記事や動画など幅広いコンテンツを配信する「パブリッシャー」としての側面を持つ。
北欧、暮らしの道具店の開発・運用は同エンジニアリングチームが実施している。外部の会社との協力も積極的に行っており、スマートフォンアプリや受発注システムは別会社と共同開発している。
今回のテーマはコンテンツ管理システムの移行。経緯について、同システムプラットフォーム部 テクノロジーグループ 矢田和沙氏が解説する。なお同氏はヤフー（現LINEヤフー）を経て、2020年7月からクラシコムに中途入社して6年目。現在は主に同社のフロントエンド・バックエンド・インフラと、「北欧、暮らしの道具店」のサービス周辺の開発を担当している。
まず「北欧、暮らしの道具店」は、おおまかに商品ページ、読みもの（テキスト）、ビデオ（動画）、ラジオ（音声）といったコンテンツとトップページからなり、読みものには、コラム、ブランドノート（他社企業製品の紹介記事）、お知らせ、着用レビューなど幅広い種類がある。読みものは基本的に平日の朝9時半に数本が公開される。ほとんどが新規記事の予約公開だが、たまに過去記事の修正や再掲載もある。
今回CMSをWordPressからStoryblokに移行した。移行前は読みもの、ビデオ、ラジオのコンテンツが自社でホスティングしているWordPressを使用していた。なお商品ページとトップページは内製したシステムで管理していた。
記事更新時には、WordPressをヘッドレスCMSとして利用し、Laravelで動いているシステムやアプリケーションからAPIを経由してバッチで内容を取得し、Amazon OpenSearch Serviceへデータ保存するという流れで処理していた。このアーキテクチャだと、読みものの更新時に最大10分程度のラグが生じていた。
移行後はWordPressで稼働していた読みもの、ビデオ、ラジオに加えて、トップページをStoryblokへと移行した。Storyblokでは更新したタイミングでWebhookを叩くことができるため、Laravelのアプリケーションでエンドポイントを作成して更新通知して、データの反映を行う。
現在はWordPressのデータもStoryblokのデータも（読者が閲覧する）OpenSearchに格納しているので、新旧のCMSを併用している状態だ。今後CMSはStoryblokに一本化する予定なのでWordPressのデータ移行を終えたら、WordPressは廃止する。
安くて使い慣れたWordPressからの移行先、選定のポイントは？
そもそも移行に至る背景として、WordPressではバージョンアップが必要となりメンテナンスコストがかかること、プラグインのなかにはサポートが廃止されて使えなくなることが挙げられる。またHTMLを直接変更できるため柔軟性が高いと言えるが、スクリプトを自由に入れられるためHTML構造が壊れてしまうことも問題視されていた。他にもスマートフォンアプリ向けに読みものコンテンツのデータを構造化したい、写真にメタデータとして商品情報を紐付けたいなどの要望もあった。
とはいえ、WordPressはサーバー代以外はコストがかからない、柔軟性が高いといったメリットもある。慣れ親しんだ編集スタッフや社外パートナーも多くいて継続を望む声もあったが、最終的にはシステム管理上の観点から移行が決まった。
移行先CMSへの要件は各チームからいろいろ寄せられた。運営・管理側としては、WordPressと内製システムで管理していたコンテンツを一本化したいという要望があった。また読者や顧客が閲覧・検索しやすいことも重要だ。エンジニアチームにはメンテナンスコストを減らし、より機能開発に注力したいという要望があり、編集チームには入稿しやすさ、並べ替えやすさなど利便性や、データの再利用性への期待があった。
移行先CMS選定では、日本語がうまく使えること、予約投稿ができること、データのインポート・エクスポート、並べ替えのしやすさを重視。続いて権限管理やスタイル周辺の機能もあることが望ましい。
こうした要件や希望があるなかで、移行先の候補として挙がったのがSaaS、WordPressホスティング、OSS、外注などだ。最終的にはStoryblokというヘッドレスCMSのSaaSを選択することにした。
Storyblokはビジュアルエディターを備えており、フォーム（編集画面）で変更内容を保存すると、リアルタイムでプレビューができる。また各言語に対応したSDKがあり、コンテンツのバージョニングも可能であることなどがメリットとなる。
ここまでがチームにおけるCMS選定や技術検証となるが、後にCTOとロードマップなどの相談（隔週）、同時並行に関連する部署に要望をヒアリング（都度）を繰り返した。問題なさそうだと見えてきたら、社長にコスト面・工数とメリット・デメリットを提示して導入の許可を得た。そこから本格的に実導入に向けた実装を開始し、導入時には関連部署への説明やサポートなども行った。
非エンジニアと進めたCMS移行、実運用で見えた課題とは
クラシコムではコンテンツごとに担当部署が割り当てられている。読みものはメディア編集グループがメインで担当しているため、まずは同グループにWordPressの利用実態や課題をヒアリングした（矢田氏のチームはWordPressを管理しているだけで、利用することはないため）。
ヒアリングした内容をもとにWordPressと同様の機能をStoryblokでざっくりと作成し、テスト環境で同グループのスタッフに使ってもらい、使用感を評価してもらった。例えば、社外ライターからの原稿を代理入稿するケースなら「スタイルはうまく作成できないが、Storyblokでの作成は簡単だった」と特に問題はない様子。
一方、着用レビューのような記事だと画像を大量に挿入し、何度も差し替えるため、Storyblokになると現状より手間がかかるという苦情もあった。こうしたケースにおける運用フローを検討し、場合によってはプラグインを使うなどして、課題を丁寧に解消していった。
問題が解消できると、各部署への説明会を実施した。各部署に1時間程度で6回ほどのオンライン会議の形態をとった。社外ライターには担当部署を通じてレクチャーしてもらったり、説明会録画を共有したり、Google Docsで作成したマニュアルを共有したりして周知を進めた。
ユーザーアカウントは説明会の前に発行しておいて、アカウントや多要素認証の設定は各自にしてもらった。ここはつまづくメンバーが多く、多くがSlackのチャットで解決したが、難しいケースだとオンラインミーティングでサポートすることもあった。
説明会後には評価メンバーだけではなく全てのCMS利用ユーザーがStoryblokを使用するようになり、質問や機能要望などが多く寄せられた。あまりに多かったのでフィードバックをスプレッドシートに集約し、チーム内で課題のトリアージを行い、優先順位が高いものから対応した。
Storyblokの利用開始は4月1日からとして、それ以降に公開する新しい記事はStoryblokで制作してもらうことにした。なかにはすでにWordPressで作成していた記事もあったが、併用できるのでそのままWordPressで続けてよいとした。
3月31日にStoryblokの機能をリリースして、緊張しながら4月1日を迎えることになった。4月1日公開予定の記事がうまく公開されなかったらWordPressを使う、逆にWordPressで不具合が出たらStoryblokで記事を作り直す……と想定シナリオごとに準備して待機した。
4月1日にはWordPressで作成された記事、Storyblokで作成された記事、両方の新規公開があった。矢田氏は「いくつか問題があり、朝から結構バタバタしましたが、エンジニア全体で作業分担することで1日でエラーを収束させることができました」とほっとした様子で話す。その後も初めてStoryblokを使い始めるユーザーもいて、サポートしたり、機能漏れ、要望も散発的に出ては都度対処していった。
リリース1カ月後に利用者にアンケートしたところ、約半数が「使いやすくなった」と高評価だった。矢田氏が力をいれたサポートにも労いの言葉が寄せられた。
リリースから3カ月ほどが過ぎ、サポートの量は減ってきた。現状ではWordPress廃止に向けてデータ移行を進めている。現時点でStoryblokを使っていない大きなコンテンツは商品ページのみとなった。ここはチームでデータ構造を見直しており、移行に向けて進んでいる。
チームでは移行の振り返りをKPT（Keep、Problem、Try）で実施した。矢田氏は「個人としては、入社時からWordPressをなくしたいと思っていたので、クローズできそうでうれしいです。ただテスト時の実装をそのまま残してしまい、リファクタリングを後のタスクとして残してしまったのは後悔していますが、リファクタリングもロードマップに乗せて今後改善できる見通しがついたので、そこはよかったと感じています。あとこれまで関わりがなかった社員にヒアリングして開発を進めることができたのは貴重な経験でした」と話す。
