楽天市場からShopifyへのEC基盤再設計プロジェクトを開始しました
記事
コラム
このたび、楽天市場で長年展開されてきた商品群を、
Shopify上で再設計するプロジェクトを開始しました。
今回のテーマは「商品移行」ではありません。
目指しているのは、
外部モール依存から、自社で育てられるEC基盤への転換。
そして、
“社内で増やせる構造”の構築です。
■ ご相談の本質
今回のご相談は、単なる「データ移行」ではありませんでした。
・楽天市場で販売している商品を自社ECへ展開したい
・既存のブランドイメージは維持したい
・今後は社内で商品追加できるようにしたい
・コストは抑えつつも、将来を見据えた設計にしたい
・最初から全商品を一括で外注するのは難しい
つまり、
今すぐの構築と、将来の内製化を両立させたい
という、非常に現実的かつ健全なご相談でした。
ここを無視して「全数一括移行」を提案することもできます。
しかしそれでは、
運用負担は残り、依存構造は変わりません。
本案件では、そこを根本から整理しました。
■ 採用した進め方：段階設計モデル
今回採用したのは、
代表商品で構造を確定し、全体に展開する設計モデルです。
第一段階（基盤構築）
・各シリーズから代表商品を選定（計15商品）
名札
クリスタル
名入れタンブラー
・商品構造の再整理
・オプションルール設計
・Shopify上でのバリエーション設計
・商品登録テンプレート化
まずはここで“型”をつくります。
第二段階（再現可能状態の構築）
・社内追加用テンプレート整備
・商品追加手順の明文化
・オプション追加手順の整理
・構造ルールの文章化
・実運用を想定したマニュアル作成
ここまで整えて初めて、
「自走可能」な状態になります。
第三段階（段階拡張）
・残り商品はテンプレートに沿って追加可能
・社内でも対応可能
・必要に応じて外部サポートも可能
いきなり全数ではなく、
構造確定 → テンプレート化 → 拡張
この順番を取ることで、
・コストを抑え
・設計のブレを防ぎ
・将来の修正コストを下げます。
■ なぜCSV一括移行を採用しなかったのか
今回、あえてCSV主体の一括流し込みは採用していません。
理由は明確です。
CSV移行は“移せる”だけで、
・社内で再現しにくい
・構造理解が進まない
・担当者変更時に崩れる
という課題が残ることが多いためです。
本案件では、
✔ Shopify管理画面で再現可能
✔ 社内担当者が理解できる
✔ ルールが明文化されている
という状態を優先しました。
ゴールは「移すこと」ではなく、
運用できること。
■ オプション設計の考え方
名入れやカスタム要素を含む商品群では、
・入力項目
・選択項目
・価格加算ルール
・バリエーション制御
これらを整理しないまま構築すると、
後から必ず破綻します。
今回は
Infinite Options を活用し、
・柔軟なカスタム入力
・バリエーションの整理
・拡張前提の設計
を実装しています。
アプリを入れることが目的ではなく、
構造を崩さず拡張できることが目的です。
■ テーマ・初期設定・決済まで含めた整理
構造設計は商品だけでは終わりません。
・推奨テーマの方向性整理
・必要アプリ一覧の明確化
・初期設定チェックリスト作成
・クレジット決済導入手順の整理
販売開始までの動線を整理し、
「作ったけど公開できない」状態を防ぎます。
■ 今回のプロジェクトの本質
これは商品登録業務ではありません。
・商品構造の再設計
・オプション設計の標準化
・内製化前提のテンプレート構築
・再現可能な運用フロー整備
ECの“裏側”を整えるプロジェクトです。
楽天市場という完成されたモールから、
自社ECへ移行するということは、
単なるプラットフォーム変更ではなく、
設計思想の切り替えでもあります。
モール依存から、自社基盤へ。
外注依存から、内製化へ。
登録作業から、構造設計へ。
■ 現在の進行状況
・商品構造整理
・オプション設計
・テンプレート化
・マニュアル整備
・初期設定整理
を進行中です。
販売開始に向け、段階的に整備を進めています。
■ 最後に
ECは「つくる」ことよりも、
“回せる”ことの方が難しい。
構造が整えば、追加は容易になります。
構造が曖昧なまま増やせば、必ず崩れます。
今回のプロジェクトは、
増やせるECをつくるための基盤再設計。
その第一歩です。
.png)
