通販サイト刷新の発注は、目的とKPIを社内で固め、要件をMustとWantに分けてから、RFPと稟議、発注後の管理へと進めるのが基本の流れです。この順で進めると見積もりの精度が高まり、プロジェクトの進行も安定します。
▼全体ガイドの記事
・通販サイト/システム刷新の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
発注前の目的・KPI・要件の整理
社内の合意が不十分なまま見積もりを取ると、刷新が失敗に終わることがあります。そのため、ベンダーに渡す前に、刷新の理由と改善したい数字、必須の要件を社内で固めておく必要があります。
刷新の目的とKPIの数値定義
「システムが古い」という理由だけで発注すると、提案の前提がベンダーごとに異なり、見積もりを比較できません。そこで、刷新の目的を売上やコストといった経営指標に結び付けます。
数値目標の例としては、スマートフォン経由のコンバージョン率を1.2%から2.0%に上げることや、カート落ち率を15%改善することが挙げられます。受注処理の人件費を月40時間減らすことも、目標になります。
KPIを定めておけば、提案が目標の達成につながるかを評価でき、公開後の効果も検証できます。
- 売上の改善：コンバージョン率とカート落ち率の数値目標
- 業務コストの削減：受注処理にかかる人件費などの削減目標
- 優先順位：複数の目的に付けた序列と、要件の取捨選択の基準
一方、KPIが曖昧なままだと、デザインの好みや機能の多さといった本質的でない基準で発注先を選んでしまい、投資対効果を後から説明できなくなります。
Must/Wantによる要件の仕分けと肥大化の防止
要件が膨らむと、見積もりが当初想定の1.5倍から2倍になることもあります。このため、部門から出た要望を、Must（必須）とWant（あれば望ましい）に分けておきます。
- Must：事業運営に不可欠な機能、またはKPI達成に直結する機能
- Want：初期リリースから外し、公開後の追加を検討する機能
分類を社内で済ませてから見積もりを取ると、必要最小限の構成同士を比べられ、フェーズ分割も交渉しやすくなります。また、Wantに分けた理由は、目的とKPIに照らせば各部門に説明できます。
RFPの作成と経営層への稟議
要件が固まったら、ベンダーに伝えるRFP（提案依頼書）を作成します。RFPの出来によって、提案内容と見積もり精度が左右されます。
数千万円から数億円規模の投資になる場合は、社内の承認を得るための稟議資料も必要です。RFPと稟議は、どちらも要件・予算・リスク・効果の情報を整理する点でつながっています。
提案を比べやすくするRFPの構成要素
RFPには、ベンダーが同じ前提で提案できるよう、必要な情報をまとめます。特に連携仕様と見積もり内訳を具体的に書いておくと、追加費用や比較の漏れを見つけられます。
- プロジェクト情報：背景と目的、KPI、現行システムの構成と課題を示す
- 要件と計画：Must/Want、想定スケジュール、概算予算のレンジ
- 連携要件：基幹システム、WMS（倉庫管理システム）、CRM、会計システムとのデータと頻度
- 見積もり内訳：要件定義、設計・開発、データ移行、テスト、公開前後の保守を分けた形
連携の具体像がないまま「連携可能」と回答されても、開発時に仕様を詰める過程で追加費用が出ることがあります。そこで、内訳にデータ移行費や連携開発費が計上されているかも確認します。
ROI・リスク対策・比較表による稟議承認
稟議では、投資の回収見込みとリスク対策を示す必要があります。ROIを試算する際は、初期費用と3〜5年分の運用費を合わせたTCO（総保有コスト）を分母に置き、売上増加やコスト削減を分子にして回収年数を求めます。
TCOには、決済手数料や従量課金、アプリの追加費も含めます。これらの隠れコストを織り込むことで、稟議後の想定外費用を避けやすくなります。
- 移行リスク：売上や顧客を失わないためのデータ移行計画
- 障害対応：公開時の切り戻し手順を明記する
- 社内体制：ベンダー任せを防ぐための担当体制
- ベンダー比較：価格と実績、連携対応力、公開後の支援を比較表にまとめる
比較表には、KPI達成への貢献度も含めます。選定理由を一枚にまとめて示せば、経営層は判断の根拠を一目で確認できます。
ベンダー丸投げを防ぐ発注側マネジメント
丸投げにすると、現場に合わないシステムになるおそれがあります。自社の業務を最も理解している発注側こそ、プロジェクトに主体的に関わる必要があります。
責任分界点の合意とFit to Standard
外部連携では、責任範囲が曖昧だとトラブルの原因になります。API仕様やCSV連携の単位ごとに、ベンダーと発注側、別ベンダーの担当範囲を文書にして合意しておきます。
口頭で「連携できます」とだけ合意していると、開発後半になって対応範囲の認識違いが判明し、追加費用や遅延につながることがあります。
Fit to Standardは、標準機能に業務を合わせて、過剰なカスタマイズを避ける考え方です。独自業務の追加開発は開発費や保守費を増やし、さらに将来のバージョンアップも難しくします。
- 責任分界点：仕様単位で決めた連携の開発担当
- 標準機能の活用：カスタマイズが必要な業務の見極め
- 社内調整：標準機能で代替できる業務の見直しと、経営層の後ろ盾
業務の変更には現場の抵抗も伴うため、発注側が調整を主導します。
週次定例・課題管理表・成果物承認の運営
発注側がプロジェクトの進行を支えるには、日々の運営を回すことが欠かせません。各運営で担当者と期限を明確にしておくと、判断待ちや論点の放置を防げます。
- 週次定例：進捗と未決事項の確認、決定者と期限の設定
- 課題管理表：担当者、期限、ステータスをひとつの表で追う
- 成果物承認：要件定義書、基本設計書、テスト計画書の中身を見て承認する
成果物を承認しないまま次の工程に進むと、認識違いが後の工程で手戻りを生みます。発注側が関わり続けることで、現場に合うシステムの定着を目指せます。
契約・支払い条件と移行リスクへの備え
発注の前に、契約と支払い条件を確認しておきます。条件が曖昧なままだと、追加費用やトラブル時の責任を巡る問題が起きます。
データ移行とカットオーバーのリスクも、契約に織り込む必要があります。そのためには、費用の範囲と障害時の対応を発注前に決めておくことが欠かせません。
契約形態と支払い条件で確認すべき費目
要件定義は準委任契約、設計・開発は請負契約とする分割契約が一般的です。要件が確定しにくい段階と、固まったあとの工程を分けることで、双方のリスクを抑えます。
- 見積もり費目：要件定義費、構築中の保守費、公開前のテスト費の有無
- 検収と支払い：着手金、中間金、検収後の支払い条件
- 運用保守：月額費用の範囲と、範囲外作業の単価
- 責任期間：瑕疵担保責任または契約不適合責任の期間
見積もりから費目が漏れていると、後から追加請求の根拠になることがあります。また、検収完了の条件と受け入れテストの基準・期間を契約書に記し、検収前に支払いが済んでしまう構造を避けます。
切り戻し基準と段階移行によるリスク抑制
公開直後に重大な障害が起きると、販売機会と顧客の信頼を損ないかねません。そこで、カットオーバーの前に、旧システムへ戻す切り戻し（フォールバック）の基準を文書で合意しておきます。
- 決済処理のエラー率が一定値を超えた場合は、切り戻しを行う。
- 指定時刻までに正常稼働を確認できない場合は、旧システムへ戻す。
- 切り戻しを判断する担当者を、基準とあわせて決めておく。
全面切り替えを避けて段階移行にすると、影響を限定しながら検証できます。BtoB ECでは、主要顧客の一部から始める方法や、商品カテゴリごとに移す方法があります。
URLを変更する場合は、301リダイレクトでSEO評価を引き継ぎます。一方で、パスワードは暗号化方式の違いから移行できないことが多く、顧客への再設定案内が必要になります。
再設定案内をポイント付与キャンペーンと組み合わせ、再設定を促す方法もあります。こうした業務面のフォローも、発注時の移行計画に含めておきます。
まとめ
通販サイト刷新の発注は、ベンダーに渡す前の社内準備が要です。目的とKPIを定め、Must/Wantで要件を分けておくと、見積もり精度と進行の安定につながります。
RFPでは連携要件と見積もり内訳を示し、稟議ではTCOによるROIの試算、リスク対策、比較表を用意します。そのうえで、選定理由をKPI達成への貢献度からも説明できるようにします。
発注後は、責任分界点とFit to Standardを合意したうえで、定例や課題管理、成果物承認を通じて発注側が主導します。あわせて、契約条件と検収基準を確認し、移行時の切り戻しや段階移行も計画しておきます。
発注は、外注の手続きであると同時に、自社が関わり続けるプロジェクト管理です。主体的に関わることが、投資を成果につなげる第一歩になります。
▼全体ガイドの記事
・通販サイト/システム刷新の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。