先にアプリを作ってしまった小売企業があとからCMS連携するまでの「現実的なリカバリ手順」

「店舗アプリはもうあります。
　でも運用してみたら、“Webと連動できないと困る”ことにようやく気付きました。」

こうしたご相談をいただくことが、実務では少なくありません。

• 先にアプリを公開して、会員証・クーポン配信をスタートした
• しばらく運用する中で、「Webサイトの情報とアプリの情報を揃えたい」というニーズが高まった
• 気付いた頃には、Webとアプリでの二重登録や、更新漏れが大きな負担になっていた

本記事では、すでにアプリが存在する前提で、「今からCMS連携をしていく」ための現実的なステップを、
ある小売企業（以下「小売店A社」）の事例をベースにご紹介します。

小売店A社は、全国に店舗を持つチェーン企業です。
数年前に「店舗アプリ」をリリースし、

• デジタル会員証
• 来店ポイント
• アプリ限定クーポン

などを中心に、来店促進の施策を進めていました。
一方で、Webサイト側ではすでに、

• CMSによるお知らせ更新
• キャンペーン情報やチラシの掲載
• ブランドコンテンツやコラム記事

といった運用が走っていました。

当初は、
「アプリはアプリで、Webとは別物として運用すればよい」
と考えていたため、

• Webサイト：CMSでお知らせ・キャンペーンを更新
• アプリ：アプリ用の管理画面で、同じ内容を再入力

という二重登録の運用を続けていました。
しかし2〜3年運用するうちに、

• 更新の手間が単純に二倍かかる
• Webだけ更新してアプリを忘れる、あるいはその逆が起きる
• 「アプリとWebで内容が違う」とお客様から指摘される

といった問題が顕在化してきたのです。

そこでA社は、アプリ改修・CMS連携を検討する前に、
現状の運用をすべて棚卸しすることから始めました。

特に洗い出したのは、次のようなポイントです。

• どの情報を、どこで更新しているか
  • Webサイトのお知らせ／キャンペーン → CMS
  • アプリのお知らせ／クーポン情報 → アプリ用管理画面
  • 一部の固定文言 → アプリのコードに直接埋め込まれている
• Webとアプリの両方で、同じ内容を登録している箇所はどこか
• 更新頻度が高いのはどの情報か
  • 週替わりのキャンペーン
  • セール・フェア情報
  • 店舗限定企画のお知らせ
• 誰が更新作業をしているか
  • Web担当チーム
  • アプリ担当チーム
  • 店舗販促担当からの依頼を受ける本部スタッフ

ここでわかったのは、
「頻繁に更新されるコンテンツほど、Webとアプリの二重登録になっている」
という状況でした。

棚卸しの結果をもとに、A社はすべてのコンテンツを次の2つに分類しました。

1. 今すぐCMSに寄せられそうなもの
   • すでにWebサイトのCMSで管理している
   • アプリ側にも「ほぼ同じ内容」を登録している
   • データ構造もシンプルなニュース・キャンペーン系
2. 時間をかけて移行するもの
   • アプリ専用の画面設計と強く結びついているもの
   • 会員情報やポイント残高など、既存の基幹システムと深く連動しているもの
   • 画面ごと見直しが必要なもの

その結果、①に分類されたのは主に次のような情報でした。

• お知らせ・ニュース（新サービス、営業時間変更、システムメンテナンスなど）
• キャンペーン・フェア情報
• アプリのトップ画面に載せているバナー・告知枠

ここでA社は、「すべてを一気に統合する」のではなく、

まずは①の“コンテンツ寄り”の情報だけでも、
CMSをマスタにしてアプリにも配信する

という方針に切り替えました。

方針が決まったところで、A社が実際に行ったステップは次の通りです。

ステップ1：CMS側に「アプリ向けの出力口」を作る

• 既存のCMS上で管理している
  • お知らせ
  • キャンペーン
  • バナー情報
  に対して、「アプリにも出す」ためのフラグやカテゴリを追加しました。
• 併せて、アプリから取得しやすい形で
  • JSON API
  • もしくはアプリ向けの専用フィード
  を用意しました。

これにより、 「同じコンテンツをWeb・アプリ両方に出したい場合、CMSの“アプリ表示”にチェックを入れればよい」
という状態を作りました。

ステップ2：アプリ側で“裏側のデータソース”だけ切り替える

次に、アプリ側の改修です。

• これまで、アプリの管理画面やアプリ内の固定データから取得していた
  • ニュース一覧
  • トップバナー
  などを、
  • CMSのAPIを叩いて取得する
  ように裏側の仕組みを切り替えました。

ステップ3：古い更新ルートを閉じるルールを徹底した

最後に、運用ルールと社内の動きも見直しました。

• アプリ専用管理画面で行っていたニュース・キャンペーン更新機能を段階的に停止
• 運用マニュアルを更新し、
  • 「ニュース・キャンペーン・バナーの更新はCMSからのみ」
  • 「アプリ側での直接更新は禁止」
  というルールを明文化
• 店舗向けの連絡でも、
  • 「告知を出したいときは、Webサイトのお知らせ依頼フローに乗せる」
    
  という一本化を行いました。

こうして、「同じ内容をWebとアプリで二度入力する」状況を、現場レベルから減らしていきました。

この取り組みの結果、A社では次のような変化がありました。

• Web・アプリのコンテンツ更新にかかる時間が、体感で3〜4割ほど削減された
• 「Webとアプリで内容が違う」というお客様からの指摘がほとんどなくなった
• 本部側の担当者が、
  • 「まずCMSに正しい情報がある状態を作る」
    ことを意識するようになり、コンテンツの品質も安定
• アプリの改修は、
  • 新機能追加
  • クーポン施策の強化
  など「アプリならではの部分」に集中できるようになった

特に、「更新作業の窓口が一本化された」ことにより、
「どこを直せばいいのか分からない」というストレスが減った
という現場の声があったのが印象的でした。

A社のプロジェクトで特徴的だったのは、
「理想の姿」すべてを、一度に実現しようとしなかった
ことです。

• 会員情報やポイントの仕組みは、基幹システムとの関係が複雑である
• ログインやIDまわりは、影響範囲が大きい

といった理由から、これらは第二フェーズ以降の検討テーマと割り切りました。

その代わりに、

• 更新頻度が高く
• Webとアプリの両方に掲載したいコンテンツで
• データ構造が比較的シンプルなもの

に絞って「CMSマスタ化」を先行させたことで、

• プロジェクトが現実的な規模に収まった
• 早い段階で目に見える効果（工数削減・ミス減少）が得られた

というメリットがありました。

小売店A社の事例のように、

• すでにアプリを持っていて
• CMSもある程度導入済みで
• でも両者がうまく連動していない

という状況は、少なくありません。
その際に大切なのは、

• すべてを作り直そうとするのではなく
• 現状の運用を棚卸しし
• 「今すぐCMSに寄せられるコンテンツ」から順に移行していく

という段階的なリカバリの発想です。

「うちも、まさにA社と似た状況かもしれない」
「どこから手を付ければよいか一緒に整理してほしい」

という場合は、
まずは「どのコンテンツをどこで更新しているか」を簡単な表にしていただくだけでも十分です。
そこから、A社のように少しずつ「CMSマスタ＋アプリはクライアント」という形に近づけていく道筋をご提案できます。