非エンジニアと進めた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をなくしたいと思っていたので、クローズできそうでうれしいです。ただテスト時の実装をそのまま残してしまい、リファクタリングを後のタスクとして残してしまったのは後悔していますが、リファクタリングもロードマップに乗せて今後改善できる見通しがついたので、そこはよかったと感じています。あとこれまで関わりがなかった社員にヒアリングして開発を進めることができたのは貴重な経験でした」と話す。
