繁忙期の直前に基幹を入れ替えた｜スペインDisfrazzesのEC移行

自社の都合に合わせて作ったシステムが、ある時期から足を引っ張り始めることがあります。スペイン・アリカンテ県イビの仮装用品店Disfrazzesは、自分たちで作り込んだECの土台を捨て、1年の売上を決める繁忙期が始まる2026年9月にShopifyへ移りました。Shopifyの公式導入事例には、移行後30日間の転換率が前年同期より60%伸びたこと、30,000点を超える商品を移したこと、6か国のストアを1つのストアから運用していること、最も忙しい日には最大5,000件を出荷していることが数字として載っています。

この記事では、公表されている範囲だけで3点を整理します。順番として何をしたのか。公表された結果はどこまで言える数字なのか。そして、日本の実務者が自分の事業にどう読み替えられるのか。確認日は2026年11月6日です。数値はいずれもShopifyの導入事例に掲載されたもので、第三者が検証した値ではありません。

先に結論を書きます。この事例の読みどころは、転換率が伸びた割合ではありません。自社開発をやめる判断の理由が「機能が足りない」ではなく「反映までに人の時間がかかる」だった点と、その入れ替えを繁忙期の直前にやった点です。

何をしたか：自社ビルドをやめ、9月に土台を入れ替えた

導入事例によると、Disfrazzesは2007年にJuanvi García Belda氏とEncarni氏が創業した、仮装用品とパーティー用の装飾を売る会社です。拠点はアリカンテ県のイビにあります。公式サイトは「Desde 2007」と掲げ、ドイツ・スペイン・フランス・イタリア・ポルトガル・イギリスの6か国に向けて売っていることと、仮装用品が30,000点を超えることを示しています。導入事例の側には、6か国のストアを1つのShopifyストアから運用し、出荷先は15か国より多いと書かれています。

それまでの売り場は、自社で作り込んだ独自のプラットフォームでした。移行したのは2026年9月で、地元のWebエンジニアリング会社Nitsnetsと組んでいます。導入事例は、この案件に必要だったものをこう説明しています。独自に作られたものすべてを理解でき、サイトが社内の基幹システム（ERP）とどうつながっているかまで分かる上級の技術者が必要で、それをより固い標準的な環境へ移す作業だった、という記述です。表の画面を作り替えるだけの話ではなかったことになります。

移したのは点数だけではありません。導入事例には「Each of the 30,000 products carries tags for theme, celebration, age, colour, and even how scary it is」とあります。テーマ、行事、年齢、色、そしてどれくらい怖いかまでタグを持っていて、さらに商品同士がひも付けられている、という説明です。この対応付けが済んだので、行事やテーマごとにカタログを季節に合わせて組み替えられるようになった、と書かれています。移行で失われやすいのは、点数ではなくこうした関係のほうです。サイトを作り替えるときの段取りはホームページリニューアルの進め方に整理しています。

1年を決める時期の直前に入れ替えている

この事例でいちばん目を引くのは、入れ替えた時期です。導入事例は繁忙期をこう書いています。「From Halloween to Carnival, through Christmas and Three Kings’ Day, is the stretch that decides the company’s year」。ハロウィンからカーニバルまで、クリスマスと公現祭（三賢者の日）をはさむこの期間が、会社の1年を決める、という一文です。移行は2026年9月ですから、その助走の位置にあたります。

季節性の強い事業では、繁忙期の前に基幹を触らないのが普通の判断です。売れる時期に止まれば、その年の取り返しがつきません。なぜこの時期を選んだのかは、導入事例に書かれていません。書かれていない理由を埋めるのではなく、ここでは「繁忙期の直前という時期に実行し、その直後の30日間の数字を公表している」という事実だけを押さえます。繁忙期と閑散期の差をどう扱うかという論点では、売上の振り分けを先に決めた冬に閉めるか開けるか。米アイス店Piper’sが数字で決めた季節対策も参考になります。

ボトルネックは機能ではなく「反映までの時間」

自社開発をやめた理由として導入事例が挙げているのは、機能の不足ではありません。Chief Digital Officerのカルロス・ムニョス氏の発言が引かれています。「Right now, with our own in-house build, I think what we have structurally in technology is more of a handicap than a help, mostly because we’re totally dependent on the internal team」。いま自社ビルドで持っている技術の構造は、助けより足かせになっている、理由はほとんど社内チームに完全に依存しているからだ、という内容です。

もう1つの発言が、その依存の正体を言い当てています。「Until now, the more we grew, the more human time it took to keep the store evolving」。これまでは、成長するほど、売り場を進化させ続けるために人の時間がかかった、という一文です。売上が増えるほど運用が重くなる構造だったことになります。

導入事例には、具体的な作業の例も載っています。仮装用品で2点で1点ぶんの価格になる施策を出すとき、チームは依頼を送り、バナーが差し替えられるのを待ち、さらにキャッシュが更新されるのを待つ必要があった。そしてその施策は翌日まで公開されなかった、という記述です。

日本の中小企業でも同じ形は起きます。制作会社や社内の1人の担当者に依頼を出し、反映は翌営業日。価格やキャンペーンの判断そのものは5分で終わるのに、出すまでに1日かかる状態です。この遅れは、機能一覧を比べても見えません。見えるのは、施策を思いついてから公開するまでに何人を経由するかを数えたときです。

公表されている結果は4つ

導入事例が数字として出しているのは4つです。1つめは転換率で、「Grew its conversion rate by 60% over the past 30 days, compared with last year」。直近30日間の転換率が前年と比べて60%伸びた、という記載です。2つめは移した商品の点数で、30,000点を超えます。3つめは運用の範囲で、6か国のオンラインストアを1つのShopifyストアから動かしています。4つめは出荷で、最も忙しい日には最大5,000件が倉庫から出ていきます。

売上高、従業員数、移行にかけた期間と費用は、いずれも書かれていません。導入事例は会社の規模を数字で示していないため、この事例から「どれくらいの規模なら真似できるか」を読み取ることはできません。商品の点数と出荷の件数から分かるのは、1人で回す規模ではないという程度です。

「転換率が60%伸びた」は何と何を比べた数字か

60%という伸びは、そのまま持ち帰りたくなる数字です。ただし、何を数えた率が、どの期間と比べて伸びたのかを押さえておかないと、自社の数字と並べる意味がありません。

まず分母です。Shopifyのヘルプセンターは、オンラインストアのコンバージョン率を「購入に至ったセッションの割合」と定義しています。人数ではなく訪問（セッション）を数える方式です。同じヘルプは途中の段も定義しています。カートに商品が入った訪問の数、決済画面で入力や操作があった訪問の数、購入が完了した訪問の数で、各段の率はその段の訪問数を訪問の総数で割って出します。

次に比較の相手です。公表されているのは直近30日間と前年の同じ時期の比較です。ここで注意が要ります。この会社の売上は行事に集まるため、前年同期との比較には、移行以外の変化もまとめて入ります。カタログを行事やテーマで組み替えたこと、取り扱う商品の構成、広告や価格の施策、前年のその時期に何が起きていたか。導入事例は、60%の伸びを移行の効果だけを切り出した値として示していません。どの段の率が動いたのかも書かれていません。

さらに、率そのものの値が公表されていません。伸びた割合だけが分かっても、元が何%だったかが分からないため、自社の転換率と高低を比べることはできません。相対の変化と絶対値を混ぜないでください。自社で率を追うときの手順はWebサイトのCVRを改善する方法にまとめています。

この事例から持ち帰れるのは、60%という目標値ではありません。繁忙期の入り口で、段ごとの数字を見られる状態に移っていたという事実です。どの段で人が減っているか分からないままでは、何を直すかも決められません。

「Sidekickがやってくれる」をどこまで当てにできるか

導入事例には、運用の属人性についての発言もあります。「If someone on the team wants to do something and doesn’t remember or doesn’t know how… Sidekick does it for them」。やりたいことがあるのに手順を覚えていない、あるいは知らないとき、Sidekickが代わりにやってくれる、という内容です。社内の誰かに依頼を出す工程が減る、という話として読めます。

ここは発言だけで受け取らず、公式ヘルプの記載も合わせて見ておきます。Shopifyのヘルプセンターは、Sidekickを管理画面の中で日常の言葉を使って案内を受けたり作業を済ませたりできるAIの商取引アシスタントだと説明しています。繰り返しの作業をワークフローとして組むこと、コードを書いて実行して店舗のデータを集計したり比較したりすること、教えた指示を覚えて従うことが挙げられています。

同時に、ヘルプには条件も書かれています。ストアによってはコードを実行できず、スキルを選ぶかショートカットを入れたときだけそのスキルを使うという記載です。そして変更は適用する前に確認のために提示される、とも書かれています。つまり、人が見て通す工程は残ります。依頼先が社内の開発者からアシスタントへ移っても、最後に判断するのは担当者です。自動で全部終わる道具として期待すると、確認の工程を誰も持っていない運用になります。

日本の実務者が参考にできる点

公表されている範囲から、そのまま置き換えられる判断を取り出すと3つになります。

Disfrazzesがしたこと	日本の実務での置き換え	先に確かめること
機能ではなく「反映までの人の時間」で乗り換えを判断した	施策を思いついてから公開されるまでに何人を経由するかを数える	1回の更新で、依頼・作業・確認の待ちが何回あるか
タグと商品同士のひも付けを維持したまま移した	移行の対象を点数ではなく「分類と関係」で棚卸しする	季節や用途で組み替えるための分類が、いまのデータにあるか
繁忙期の入り口で、段ごとの数字が見える土台に移った	率の前に、訪問・カート・決済画面・購入の各段の件数を取れる状態にする	どの段の数字が、いま自社で取れていないか

重要なのは順番です。土台を替えること自体ではなく、替えたあとに何を見るかを決めてあるかが先にあります。段ごとの件数が取れていなければ、転換率が動いた理由を後から説明できません。実店舗とネットショップの顧客情報を1つにつないだ小規模店の判断は実店舗とECの顧客を1つに｜NY最古の菓子店Economy Candyの選択で扱いました。

もう1つ、移行の体制について書かれていることがあります。ムニョス氏は組んだ会社について「They delivered on deadlines, on deliverables, on efficiency, on everything」と述べ、決済については「Shopify’s pitch about its checkout seems to hold true」と言っています。後者は「宣伝文句は本当のようだ」という言い方で、数値の裏付けとしては提示されていません。評価の言葉と測った数字は分けて読んでください。

公表されていないこと

推測で埋めないために、導入事例と公式サイト、公式ヘルプを読んでも分からなかった項目を残します。

確認したかった項目	記載	どうするか
売上高と従業員数	記載がありません	事業規模を推定しない
移行にかけた期間と費用	記載がありません	自社の見積りの根拠に使わない
転換率そのものの値	記載がありません	自社の率と高低を比べない
どの段の率が動いたか	記載がありません	原因を決めつけない
移行後に施策を出すまでの時間	記載がありません	「即日で出せる」と書き換えない
繁忙期の直前を選んだ理由	記載がありません	推奨される時期として読まない
移行前の自社サイトの指標	記載がありません	前後比較として扱わない

書かれていない項目が多いのは、導入事例という形式では普通のことです。問題になるのは、書かれていない部分を自社の企画書で埋めてしまうときです。社内で共有するときは、公表値と自分たちの仮定を分けて書いてください。

まとめ

Disfrazzesは2007年創業、スペイン・アリカンテ県イビの仮装用品とパーティー装飾の会社です。自社で作り込んだプラットフォームから2026年9月にShopifyへ移り、地元のNitsnetsと組んで、ERPとの接続を含む独自の作りを標準的な環境へ移しました。タグと商品同士のひも付けを保ったまま、30,000点を超える商品を移しています。

公表されているのは4つの数字です。直近30日間の転換率が前年同期より60%伸びたこと、移した商品が30,000点超であること、6か国のストアを1つのストアから運用していること、最繁忙日の出荷が最大5,000件であることです。いずれも絶対値・期間・内訳のどれかが欠けており、転換率の伸びは移行の効果だけを切り出した値として示されていません。

乗り換えの理由として挙げられていたのは、機能の不足ではなく人の時間でした。施策を1つ出すために依頼とキャッシュの更新を待ち、公開は翌日。成長するほど運用に人の時間がかかる構造です。60%を目標値として持ち帰らないでください。持ち帰れるのは、反映までの工程を数えることと、段ごとの数字が取れる状態を繁忙期の前に作っておくことです。確認日は2026年11月6日です。