EC刷新を発注する前にやるべき社内準備

EC刷新プロジェクトにおける最初の失敗は、発注前の社内準備不足から始まります。外部のベンダーに依頼する前に、まず自社のEC基盤の全体像を正確に把握することが不可欠です。現行システムで稼働している機能の一覧、商品マスタ・注文履歴・会員データの件数と品質、そして決済代行会社・物流WMS・在庫管理システムといった外部サービスとの連携状況を、部門横断で一元的に整理してください。

キングジムがEC基盤を刷新した際、最終的に選ばれたベンダーは最高額の見積もりを提示した会社でした。しかし選定理由は金額ではなく、提案の場でシステムキーパーソンが「旧システムの構成を全部洗い出します」と明言した一言でした。この姿勢が評価されたのは、発注側がそれだけ現行システムの複雑さを把握していたからこそです。逆に言えば、自社の棚卸しが曖昧なままベンダーへのヒアリングを始めても、適切な提案を引き出すことはできません。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・EC刷新の完全ガイド

特にデータの品質は、プロジェクト後半になって重大な問題として浮上するケースが多いです。ある中規模アパレルECの刷新では、注文履歴データの一部が旧システム固有のフォーマットで保存されており、移行作業の終盤になって互換性の問題が発覚しました。その結果、顧客からの問い合わせに対して「注文履歴が確認できない」という状況が発生し、カスタマーサービスに多大な負荷がかかりました。こうした事態を防ぐには、データのクレンジング作業を誰が担うのかを、RFP段階から明確に定義しておく必要があります。

EC刷新の発注先を探し始める前に、必ず社内で合意しておくべき最重要の意思決定が「SaaS型ECプラットフォームを利用するか、スクラッチ（または既存フレームワークでのカスタム）開発にするか」という選択です。この方針が固まっていないまま複数社にRFPを送ると、比較対象のそろわない提案書が集まり、評価そのものが困難になります。

Shopify PlusやBASE、ecforceといったSaaS型プラットフォームは、初期費用を抑えながら標準機能を素早く導入できる反面、独自の業務フローへの対応に限界があります。一方、スクラッチ開発は自由度が高いですが、初期開発コストが数千万円規模に上ることも珍しくなく、運用・保守のための社内体制も必要になります。年商10億円以下の中小ECであれば、まずShopify Plusのような実績あるSaaSを軸とした提案を複数社から取得し、カスタマイズ範囲を見極めるアプローチが合理的です。年商50億円超でかつ独自の商品管理フローや会員制度を持つ場合は、SaaS一択ではなくスクラッチ・セミオーダーも含めた比較検討が必要になります。

EC刷新の稟議書で承認を得るには、単に「システムが古い」という理由では不十分です。現状の課題を定量的に示した上で、刷新後の期待効果をROIとして提示する必要があります。具体的には、現行ECの表示速度の遅延による離脱率の上昇（GoogleのLighthouseスコアや直帰率の実績値を活用）、カートの離脱率の高さ、モバイル対応の遅れが売上に与えている機会損失額、そして刷新後に期待されるCVR改善幅と売上インパクトを試算して記載します。

また、刷新にかかる費用としては、初期開発費用だけでなく、並行稼働期間中の運用コスト（旧EC・新EC双方の保守費用）、データ移行・クレンジング費用、社内教育・運用体制構築費用、そしてトラブル時のバッファとして全体予算の15〜20%程度のリスク費用を明示することで、後から追加費用が発生した際の社内摩擦を最小化できます。

RFP（提案依頼書）の作り方

EC刷新のRFPは、単なる機能要件の羅列ではなく、プロジェクトの背景・目的・制約条件を体系的にまとめた文書です。ベンダーから精度の高い提案を引き出すためには、「何を作りたいか」だけでなく「なぜ今刷新が必要か」「どんな制約の中で進めるか」まで明示することが重要です。

RFPに記載すべき主要項目は以下の通りです。まず「プロジェクト概要」として、刷新の背景・目的・スコープを明示します。次に「現行システム情報」として、使用中のプラットフォーム、商品数・SKU数・月間注文件数・会員数といった規模感、連携している外部サービス（決済代行・物流WMS・MAツール等）の一覧を記載します。「機能要件」では、必須機能とオプション機能を分けて整理し、将来的な拡張予定がある機能はその旨を明記します。「非機能要件」には、ページ表示速度の目標値（Core Web VitalsのLCPが2.5秒以内など）、セキュリティ要件（PCI DSS準拠の有無）、可用性の目標（稼働率99.9%以上等）を盛り込みます。そして「プロジェクト条件」として、希望するリリース時期・予算の概算・選定スケジュールを明記します。

EC刷新を発注する際、デザインと開発を同一のベンダーに一括で依頼するケースが多いですが、それぞれ専門の会社に分けて発注する「分離発注」も有力な選択肢です。分離発注のメリットは、デザインの品質を独立して担保できる点と、ブランドのトンマナを守りながら開発コストの見直しが可能な点にあります。特に、ブランドイメージが差別化要因となるファッション・コスメ・ライフスタイル系のECでは、デザインにおける専門性の高さが直接的にCVRや顧客体験に影響するため、デザイン専門会社への依頼が有効です。

一方で分離発注には、デザインと開発の間の責任の所在が曖昧になるリスクがあります。例えば、デザインカンプ通りに開発が実装できない場合、「デザインが開発上の制約を無視している」「開発側の技術的な解釈が違う」という争いが発生しやすくなります。分離発注を選択する場合は、発注者側がデザインと開発の橋渡し役を担う体制を明確にし、両社間の仕様合意プロセスをプロジェクト管理計画の中に明示的に組み込む必要があります。

EC刷新のRFPには、一般的なシステム刷新では見落とされがちなEC特有の要件を明示的に記載することが重要です。その代表が「繁忙期を避けた移行タイムライン」「旧ECとの並行稼働期間」「SEO継続性の確保」の3点です。

繁忙期については、年末商戦（11月〜12月）・バレンタイン（1月〜2月）・母の日（4月〜5月）など、業種ごとのピークシーズンを明記し、その前後6週間はシステム切り替えを行わないことをRFPの前提条件として明記してください。切り替えに際してシステム障害が発生した場合、繁忙期であれば売上ダメージが何倍にも膨らむことをベンダーに共有することが、リリース計画の精度向上につながります。

SEO継続性については、「新ECへのURLリダイレクト設計（301リダイレクト）を誰が担当し、どの段階で完了させるか」をRFPに明記する必要があります。ある食品ECの刷新事例では、旧URLから新URLへの301リダイレクト設定が不完全だったために、Googleのインデックスが大幅に削減され、刷新後3ヶ月で自然検索経由の流入が約40%減少するという深刻な事態が起きました。検索エンジンの評価は一度失うと回復に数ヶ月を要するため、SEO継続性の責任範囲は契約書レベルで明確にしておくことが不可欠です。

ベンダー比較・選定プロセスの進め方

ベンダー選定においては、最低でも3社からの提案を取得することを強く推奨します。1〜2社では比較が成り立たず、価格の妥当性も判断できません。3社以上から提案を取得することで、見積もり額の相場感を把握しつつ、技術的なアプローチの違いや各社の強み・弱みを客観的に評価できるようになります。

評価基準はRFP送付時に明示することが理想的です。評価軸の例として、技術力・実績（30点）、提案の的確さ・課題理解度（25点）、プロジェクト管理能力（20点）、費用の妥当性（15点）、保守・運用体制（10点）といったウェイト設定が参考になります。評価基準を事前に公開することで、各ベンダーが優先すべきポイントを理解した上で提案を作成でき、発注側にとっても比較がしやすくなります。なお、評価は必ず複数の関係者（IT担当・業務担当・経営幹部）が採点し、平均値や合議で決定することで、特定個人の好みに左右されない選定プロセスを実現できます。

ベンダー選定において競合他社が見落としがちなのが「リファレンスチェック」、すなわちベンダーの過去クライアントへの直接確認です。ベンダーが提示する実績はすべて成功事例であるため、表向きの情報だけではプロジェクト遂行能力の本当の姿は見えません。リファレンスチェックを実施することで、「納品が6ヶ月遅延した」「仕様変更のたびに多額の追加費用が発生した」「担当者が途中で何度も交代した」といった重大な問題を事前に把握できます。

実際に筆者が関与した某アパレルECの刷新案件では、最終候補に残ったベンダーに対してリファレンスチェックを実施したところ、過去に類似規模のEC刷新で約8ヶ月の大幅遅延が発覚しました。ベンダーはその事実を提案書には一切記載しておらず、このリファレンスチェックがなければ選定されていた可能性が高い状況でした。リファレンス先の企業には「プロジェクトの進捗管理の精度」「追加費用の発生頻度と対応の透明性」「担当者の安定性」「本番移行後のサポート対応の速さ」という4つの観点で評価を求めるとよいでしょう。ベンダーに紹介を依頼する際は、「ベンダーが推薦する企業」ではなく「公開実績から発注側が連絡先を探す」という独自アプローチが、より客観的な情報収集につながります。

EC刷新のベンダー評価では、一般的なシステム開発と異なるEC特有の技術要件への対応能力を確認する必要があります。特に近年重要性が増しているのが、「Headless Commerce」への対応力と「Core Web Vitals」の改善実績です。

Headless Commerceとは、フロントエンド（表示層）とバックエンド（ commerce機能）を分離したアーキテクチャで、Next.jsやNuxt.jsといったフレームワークを使ったフロントエンド開発と、Shopify・Commercetoolsといったバックエンドを組み合わせる設計です。このアーキテクチャを採用することで、表示速度の大幅な向上とコンテンツ管理の柔軟性が高まりますが、実装の複雑度も上がります。ベンダーにHeadless Commerceの実績を確認する際は、具体的な構成（フロントエンドのフレームワーク・バックエンドのプラットフォーム・CDNの構成）と、実際の本番環境でのCore Web VitalsのLCPやINPスコアを提示してもらうことで、技術力を客観的に評価できます。なお、Googleが2024年以降Core Web Vitalsの指標として重視するINP（Interaction to Next Paint）の対応実績があるベンダーは、EC業界の最新動向に追随している証左といえます。

契約締結のチェックリスト

EC刷新の契約形態の選択は、プロジェクトの性格と発注者側のリスク許容度によって異なります。大きく分けると「請負契約」と「準委任契約」の2種類があります。請負契約は、成果物の完成をベンダーが責任を持って保証する契約形態で、仕様が明確に定まっているフェーズ（システム設計書や画面設計書をもとにした開発工程など）に適しています。発注者にとっては予算が固定される安心感がありますが、仕様変更が発生した場合に追加費用や工期延長の交渉が発生しやすいという特徴があります。

準委任契約は、ベンダーが善管注意義務をもって作業を遂行することを約束するもので、成果物の完成を保証するものではありません。要件定義や設計の初期フェーズ、あるいは継続的な保守・運用フェーズに適しています。実務上は、要件定義フェーズを準委任契約で進め、基本設計以降を請負契約に切り替えるという「フェーズ分割型契約」が、リスクと責任の観点から合理的です。ただし、スルガ銀行と日本IBMの法廷闘争に代表されるように、95億円規模の開発費用が白紙撤回になった事例では、業務要件に合わないパッケージ選定が原因でした。契約形態以前に、要件の合意プロセスを丁寧に踏むことが最大のリスクヘッジになります。

EC刷新の契約書で特に注意すべきなのが、旧ECと新ECの「並行稼働期間」の扱いです。新EC本番リリース後も、旧ECのサポートが一定期間必要なケースが多く、その期間中の費用負担と責任範囲を契約書に明記しておかないと、後のトラブルの原因になります。一般的には本番リリース後1〜3ヶ月を並行稼働期間とし、その間の旧EC保守費用をどちらが負担するか、障害対応の窓口をどこに設けるかを明確にします。

URLリダイレクトとデータ移行の責任分界点も、契約書に盛り込むべき重要事項です。特にURLリダイレクトについては、「誰が・いつまでに・どの範囲で・どのように確認するか」という4W1Hを契約書または別紙の仕様書に明記することが求められます。データ移行については、「移行対象のデータ範囲」「クレンジングの作業範囲と担当者」「移行後の検証方法と合格基準」「移行後に発覚したデータ不整合の対応費用の帰属」を明確に定義することで、移行後のトラブルに際した責任の所在を明確にできます。

契約交渉において、発注者側が特に注意すべき条項が瑕疵担保責任の範囲と期間、追加費用の発生条件、そして損害賠償の上限額です。標準的な瑕疵担保期間は納品後1年が多いですが、ECシステムの場合は繁忙期を経験した後に初めて発覚するバグや性能劣化が存在するため、最低1年・できれば2年の瑕疵担保期間を確保することが望ましいです。

追加費用については、「仕様変更の定義」と「追加費用が発生する条件のトリガー」を契約書に明記することが重要です。曖昧な仕様書をもとに開発を開始すると、ベンダーは「これは仕様変更」と主張し、発注者は「これは最初から合意した内容」と主張するという、典型的な追加費用トラブルに発展します。このリスクを低減するには、要件定義フェーズで作成する要件定義書を成果物として契約書に附属し、変更管理プロセス（変更管理委員会の設置・承認フローの明記）を契約書に盛り込むことが有効です。損害賠償の上限額については、ベンダー側の提示する上限（多くは請負金額の範囲内）に加え、EC売上停止による機会損失の一部を補償対象とする条項を交渉によって追加するケースもあります。

発注後のプロジェクト管理と移行当日の進め方

契約締結後のプロジェクト管理において、最初に確定させるべきはリリース日の選定です。EC刷新では、繁忙期を避けることが鉄則です。業種によって繁忙期は異なりますが、一般的なECにとって最大のリスクシーズンは11月〜12月（年末商戦・クリスマス・年賀状需要）です。この時期にシステム切り替えを実施して障害が発生した場合、売上損失が億単位に達するケースも想定されます。

理想的なリリースタイミングは、繁忙期終了後の2〜3月（閑散期）または5〜6月（梅雨前の中間期）です。リリース日を決めたら、そこから逆算して各フェーズの完了期限を設定します。リリース日の8週間前にはユーザー受入テスト（UAT）を開始し、4週間前には本番環境での最終検証、2週間前には移行リハーサルを実施するという「マイルストーン逆算設計」が、現場での混乱を防ぐ有効な手段です。また、各部署から「システムキーパーソン」を選出し、そのメンバーを定期的なプロジェクト会議に参加させることで、部門間の利害調整を円滑に進められます。この体制を早期に構築した案件では、現場の反発を最小化しながらスムーズな移行を実現した事例が複数報告されています。

移行当日の準備として絶対に欠かせないのが、「ロールバック計画」の策定です。ロールバックとは、新システムへの切り替え後に重大な障害が発生した場合に、旧システムへ戻す手順のことです。「新しいシステムに問題があれば旧に戻せばいい」という感覚でいる担当者は多いですが、実際にはロールバックの手順・タイムライン・判断基準・承認者を事前に定義していなければ、移行当日の混乱の中で素早く意思決定することは困難です。

ロールバック計画には、「どのエラーレートやエラー種別が発生した場合にロールバックを判断するか」という定量的な基準を設けることが重要です。例えば「注文確定エラーが5分間で10件を超えた場合」「決済処理のタイムアウトが連続して3件発生した場合」といった具体的なトリガーを事前合意しておくことで、移行当日に感情的な議論に陥ることなく、迅速かつ冷静な判断が可能になります。また、顧客告知については、移行作業中のメンテナンス告知に加え、新ECオープン時の「リニューアルのお知らせ」メール・SNS投稿の文案と送信タイミングを事前に準備しておくことで、移行当日の運用負荷を大幅に軽減できます。

EC刷新プロジェクトが炎上した場合、多くの発注担当者は「ここまで投資したのだから続けるべきだ」という「サンクコスト効果」に陥りがちです。しかし、回収不能な損失が拡大し続けているにもかかわらずプロジェクトを継続することは、経営上の合理的な判断とはいえません。重要なのは、「撤退の判断基準」と「撤退時の損害を最小化する方法」を事前に用意しておくことです。

プロジェクトからの撤退を検討すべきシグナルとしては、当初見積もりの150%以上の追加費用が発生している、品質基準を満たすためにリリース日が3回以上延期された、プロジェクトの中核を担う担当者（PMやテックリード）がベンダー側から交代した、といったケースが代表的です。撤退を決断した場合の契約上の手続きとしては、まず契約書の「中途解約条項」を確認し、既払い費用の返還や未払い費用の精算方法を弁護士を交えて協議します。部分的な成果物（設計書・データモデル・画面デザイン）の知的財産権の帰属を明確にし、次のベンダーへの引き継ぎが可能な形で資産を確保することが、撤退後の再起動コストを最小化するために不可欠です。スルガ銀行・日本IBM訴訟の教訓が示すように、法廷闘争は双方にとって長期間にわたるコストと労力を要します。撤退の判断は早ければ早いほど損失を限定できるため、プロジェクト炎上時こそ冷静かつ迅速な意思決定が求められます。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・EC刷新の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。