こんにちは、ウィルダー株式会社の松崎です。
高単価商材を扱うEC事業者A社様のECサイトを、ASP型カートからShopifyへ全面移行し、越境EC対応と真贋証明業務のオンライン化までを含めたリニューアルをご提案しました。
この事例は、「カートの仕様変更で作り直しが必要になった」「海外からのアクセスはあるのに受注につながらない」といった課題をお持ちの企業様の参考になります。
この記事では、課題・取り組み・成果の順にご紹介します。
| 匿名表記 | EC事業者A社様 |
|---|---|
| 業種 | 高単価商材のメーカー／小売（自社EC・実店舗の併用） |
| 地域 | 東京都 |
| 規模感 | 少人数で運営。サイト更新は実質ご担当者お一人 |
| ご支援内容 | ECサイトリニューアルの要件整理・デザイン提案・開発計画の立案 |
こんな課題をお持ちの方におすすめです
- 使っているカートシステムの仕様変更で、サイトの作り直しが避けられなくなった
- 海外からのアクセスはあるのに、言語の壁で受注につながっていない
- 更新のたびに制作会社へ依頼が必要で、施策のスピードが上がらない
導入前の課題｜作り直しが避けられない状況と、積み上がった運用の負担
導入前の最大の課題は、カートシステム側の仕様変更により、サイトの作り直しが避けられない状況になっていたことです。開設から10年以上が経過し、商品ページは約2,000点まで積み上がっていました。
課題1：スマートフォンでの閲覧体験が崩れていた
最も影響が大きかったのが、レスポンシブ対応ができていなかったことです。
PCでは問題なく見えていても、スマートフォンでは文字が小さく、画像も重い状態でした。高単価の商材は購入前にじっくり読み込まれるため、その読み込みが快適にできない状態は機会損失に直結していました。
課題2：海外からの流入はあるのに、受注がほぼゼロだった
海外からのアクセスや問い合わせはあるものの、ECからの受注はほとんどない状態でした。
それでも、サイトが日本語のみで「読めない」ため、購入まで到達できていませんでした。
課題3：力を入れた特集ページが、分散して重くなっていた
A社様では、商品の背景を語る特集ページを個別のHTMLで制作されていました。
内容の質は高いものの、1本ずつ手作業で作られているため制作にも改修にも工数がかかり、画像も最適化されていないため表示速度の負荷になっていました。
課題4：更新がご担当者お一人に依存していた
サイトの更新は、実質的にご担当者お一人で担われていました。
「月額の保守費用はなるべく抑えたい。自分たちで管理できる仕組みにしたい」というご意向も、当初からいただいていました。
ウィルダーに依頼した理由
ご相談のきっかけは、複数社を比較検討されるなかで、デザインと開発を一社で完結できる体制を評価いただいた点にあります。
A社様が選定で重視されていたのは、次の2点でした。
- 世界観を表現できるデザイン力があること
- 海外から閲覧したときに、きちんと読める状態になること
私たちはデザインから実装、データ移行までを分けずに担当します。デザイン会社と開発会社を分けると、「デザインは良いが、そのとおりに再現されない」という事故が起きやすくなるためです。
取り組み内容
取り組みの中心は、作り直しの機会を使って「公開後に自社で運用できる状態」まで設計することでした。
プロジェクトの概要を以下の表にまとめます。
| 項目 | 内容 |
|---|---|
| 期間 | 要件定義から公開まで約4〜5か月（＋予備期間1〜2か月） |
| 体制 | プロジェクトマネージャー／アートディレクター／デザイナー／フロントエンドエンジニア／移行・QA担当 |
| 担当範囲 | 要件定義・情報設計／UI/UXデザイン／構築・実装／データ移行／多言語対応／SEO移行／公開後の初期サポート |
| 使用技術 | Shopify（ハイエンドテーマのカスタマイズ）、多言語・翻訳アプリ、CRM連携ツール |
| 費用感 | スコープにより変動 |
STEP1：現状の棚卸しと、ご要望の裏側を読む
最初に行ったのは、いただいた提案依頼書と打ち合わせの内容を突き合わせる作業です。
今回も、依頼書に記載されていた項目が打ち合わせの途中で口頭により修正される場面がありました。書面と口頭が食い違うのは実務では珍しくありません。
こうした箇所は、どちらの条件を採用したのかを理由とあわせて提案書に明記しています。
STEP2：デザインの方向性を、動くモックで示す
デザインは静止画の案ではなく、ブラウザで実際に動くモックを作成してご提示しました。
トップページ、商品詳細ページ、特集ページの3画面です。選定理由の第一にデザインを挙げられていたため、その場で操作しながら確認いただける状態を用意しました。
画面の大半を余白が占める構成とし、商品画像を主役に据えています。
ファーストビューは、縦位置の素材が混在していたため、横位置の動画・縦位置の動画・静止画のいずれも同じ枠で扱える設計にしました。
商品詳細ページでは、管理・物流用の項目とお客様に見せる項目を分離しました。
特集ページは、長文を前提に本文の幅を制限し、行間を広めに取った組版としました。
STEP3：特集ページを「自社で量産できる部品」に組み替える
既存の特集ページは、よく使う見せ方を部品化し、セクションの組み合わせで再現できる構造に置き換えました。
公開後は、コードを書かずに同等品質のページを追加できます。「作って終わり」にせず、運用が回るところまでを納品範囲と考えています。
STEP4：越境EC対応は、運用負荷を上げない方式を選ぶ
多言語対応では、言語ごとにサイトを複製する方式を採用しませんでした。
この方式では更新のたびに全言語ぶんの作業が発生し、少人数で運営されているA社様の体制では破綻する可能性が高いためです。
代わりに、日本語をマスターとした1サイト＋言語切り替えの構成をご提案しました。更新は日本語だけ、表示は多言語という形です。
STEP5：お客様の「理想」を、そのまま実装しない判断をする
このプロジェクトで最も時間をかけた判断が、真贋証明の仕組みの設計です。
A社様では、取り扱う商品を一点ずつ撮影し、固有のコードを付けて社内のデータベースで管理されています。
購入者から「これは本物か」と照会があれば、お手元の商品と証明書の画像を送ってもらい、登録内容と一致した場合にのみ記録を開示する運用です。現在はすべてメールでの手作業のため、「オンラインで自己完結できる仕組みにしたい」というご要望をいただきました。
一方で、A社様は同時に懸念も共有されていました。
コードを入力すれば誰でも照会できる方式にすると、番号を順番に試されて記録画像を大量に取得され、模造品の製作に使われてしまう、という危険性です。
さらに、後から拝見した社内資料には、「蓄積したデータベースはオフラインで厳重に管理することが最も安全である」という会社としての立場が明記されていました。
つまり、「オンラインで参照できるデータベースを作る」という提案は、ご要望に応えているようで、ブランドの根幹にある判断を否定することになります。
そこで、提案を組み替えました。
オンライン化するのは「データベース」ではなく「申請と回答の体験」だけ、という切り分けです。
- 守るもの：記録画像のデータベース本体。外部から検索・閲覧できる状態には一切しない
- 変えるもの：申請の受け口。画像添付に対応した専用フォームをサイト内に設置する
- 効率化するもの：社内の照合作業。申請を一覧で管理し、定型返信を数クリックで送れる画面を用意する
回答は従来どおり、担当者が確認して数営業日以内に返す形を維持します。
人手は残りますが、外部から記録を引き出す経路がそもそも存在しないため、懸念されていた総当たりは構造的に成立しません。
そのうえで、将来セルフ照会へ進む場合の安全設計を、第2フェーズとして別に提示しました。
公開用の照会コードを連番と切り離して新規発行すること、2要素での照合を必須にすること、画像を有効期限付きのURLで配信することなどを含みます。
STEP6：スコープの増加を、数字ごと共有する
提案期限の直前に、サイトマップの草案とカテゴリーごとの原稿一式が届きました。
読み込んで数えたところ、サイトの構造は3階層で、カテゴリーページだけで150ページ近くあることが分かりました。
テンプレート自体は共通化できますが、1ページずつタイトル・説明文・本文・バナーを設定する作業が150回分発生します。
ここが当初の見積から抜けていました。
対応として、ご予算内に収める「推奨プラン」と、ご要望をすべて満たす「フルスコープ」の2案を並べてご提示しました。
超過額を隠さずに記載したうえで、「まず推奨プランで予算内に着地させることを第一に考えている。超過分は、今すぐ必要か公開後でよいかを判断いただくための材料である」という趣旨を添えています。
導入後の成果
本提案は実装前の段階のため、現時点の数値は提案時の目標値です。
以下の表に、導入前の状態と目標をまとめます。
| 項目 | 導入前 | 導入後の目標 |
|---|---|---|
| スマートフォン対応 | 未対応。表示が崩れる | 全端末で世界観が崩れない表示 |
| 海外からのEC受注 | ほぼゼロ | 多言語化により購入まで到達できる状態 |
| 特集ページの制作 | 1本ずつ個別HTMLで制作 | 管理画面のセクション組み合わせで自社制作が可能 |
| 真贋証明の受付 | すべてメールでの手作業 | フォーム受付と社内照合画面により往復の手間を削減 |
| メール配信の管理 | 配信先を手作業で登録 | 購入・登録と同時に自動でリスト化 |
| 月額の保守費用 | ― | 自社更新を前提に最小構成 |
担当者コメント
今回のプロジェクトで最も気を配ったのは、ご要望の裏側にある「なぜそう言っているのか」を読みにいくことでした。
真贋証明については、ご要望どおりオンライン照会システムを提案するほうが、提案書としては書きやすく、技術力のアピールにもなります。
けれど、それを実装すればA社様が20年近くかけて守ってきた資産を、こちら側から危険にさらすことになります。
「できません」ではなく「御社の方針を守ったまま、いま効く部分だけ先に取る」という順序の話として整理できたことで、提案の軸が一本通りました。
見積についても同様で、150ページ分の作業を見なかったことにして受注すれば、後から追加費用の話になって必ず揉めます。
そのときに失うのは、金額よりも信頼のほうだと考えています。
今後は、公開後に運用が回り、数字が改善していくところまでご一緒できればと思っています。
同じような課題をお持ちの方へ
同じような課題をお持ちの場合、まずは現状のサイト規模とご予算を把握することから始めるのが近道です。
今回の事例を自社に当てはめる際の目安を整理します。
- 期間の目安：本格的なリニューアルで4〜6か月程度。商品点数やページ数が多い場合はさらに見込む
- 規模の目安：商品数が1,000点を超える、またはカテゴリーが3階層になる場合は、ページ数の総量を先に数える
- 費用の目安：スコープによって大きく変わるため、まずはご相談ください
カテゴリー構造が深いサイトでは想定よりページ数が膨らみます。サイトマップができた段階で総ページ数を数え、「誰がその投入作業をするのか」を決めておくと、後から見積が動くことを防げます。
よくある質問
Q. 開発期間はどれくらいかかりますか？
A. 本格的なECサイトリニューアルの場合、要件定義から公開まで4〜6か月程度が目安です。今回の事例では、年内公開を目標に設定し、そのうえで予備期間を1〜2か月確保する計画としました。商品点数が多い場合や独自機能が必要な場合は、さらに期間を見込んでおくと安全です。
Q. 費用の目安はどれくらいですか？
A. サイトの規模と機能要件によって大きく変わるため、一律の金額はお伝えしづらいのが実情です。今回の事例では、ご予算内に収める推奨プランと、ご要望をすべて満たすフルスコープの2案をご提示しました。まずは現状のサイトと実現したいことをお聞かせいただければ、概算の幅をご提示できます。
Q. 商品データは全部移行したほうがよいですか？
A. 必ずしも全件移行する必要はありません。検索からの流入がある商品や、販売終了後も閲覧されている商品は残す価値があります。アクセス解析で流入のあるページを確認し、残す基準を決めてから移行点数を決めることで、工数と効果のバランスを取れます。
Q. 公開後の更新は自社でできますか？
A. 設計次第で可能です。今回の事例でも、公開後にご担当者だけで特集ページを追加できる状態を納品範囲に含めています。商品登録や新着情報の更新は自社で行い、大きな機能追加だけご依頼いただく、という分担がよく取られます。
Q. 越境EC対応では何を準備すればよいですか？
A. まず決めるべきは、対応言語と配送・決済の条件です。言語については、サイトを複製する方式か、1サイトで切り替える方式かによって運用負荷が大きく変わります。少人数で運営されている場合は、更新を1言語に集約できる後者をおすすめしています。
Q. 地方の企業でも依頼できますか？
A. はい、オンラインでの打ち合わせを中心に進めるため、地域を問わずご対応しています。要件定義やデザインの確認もオンラインで完結できる体制を取っています。
さいごに
今回のECサイトリニューアル事例の要点を、3点にまとめます。
- お客様が「理想」として挙げた機能を、そのまま実装しない判断をした。ご要望の裏側にある会社としての方針を優先し、オンライン化する範囲を切り分けた
- 途中で判明したスコープの増加を隠さず、予算内プランと予算超過プランの2案を数字ごとご提示した
- デザインは静止画ではなくブラウザで動くモックで提示し、公開後に自社で運用できる状態までを設計範囲に含めた
ECサイトのリニューアルは、公開して終わりではありません。公開後に運用が回り、数字が改善して初めて成功と言えます。
「カートの仕様変更で作り直しが必要になった」「海外に向けて売れる状態にしたい」「更新を自社で回せるようにしたい」。
こうした課題をお持ちの方は、お気軽にご相談ください。現状のサイトを拝見したうえで、課題の整理からご一緒します。
