大規模ECサイト構築/選定のすべて｜費用や手順・成功ポイント

ライセンス費用は利用するパッケージにより大きく異なります。
たとえば、EC-CUBEのように無料のものもあれば、数千万円規模の商用ライセンスが必要なものもあります。

支払い形態にも違いがあり、初期に買い切るパターンもあれば、年商に応じたレベニューシェア型（売上連動課金）も存在します。

ライセンス費用の傾向

• 国内パッケージ：買い切りが多く、数百万円〜1,000万円程度が目安。
• 海外パッケージ：レベニューシェア型が主流で、年間売上の1〜2%が相場。

導入時に必要となる初期構築費用は、以下のような項目に分かれます。
下記の金額は、カスタマイズが比較的少ないケースの目安ですが、構成比の参考としてご覧ください。

• 環境構築・設定費用：100万円～
  • サーバー設定やパッケージ設定などの費用。
• 要件定義費用：200万円～
  • デザインや機能要件など検討/確認する費用。
• デザイン/UI設計費用：100万円～
  • オリジナルのデザインを製作する費用。
• カスタマイズ開発費用：500万円～
  • システムの設計や開発に関わる費用。
• テスト費用：100万円～
  • システムの動作確認に関わる費用。
• データ移行費用：100万円～
  • 旧サイトから新サイトへデータを移行する費用。

サイト公開後も、継続して発生する費用があります。主に以下のような項目です。

• サーバー費用：数千円～/月
  • システムを稼働するサーバー費用です。ライセンス料がレベニュー形式のパッケージの場合には、ライセンス費用に含まれる場合もあります。
• 保守費用：10万円～/月
  • セキュリティ対応やシステムの監視、新たな改修の相談などに要する費用です。ライセンス料がレベニュー形式のパッケージの場合には、ライセンス費用に含まれる場合もあります。
• その他外部ツール利用料
  • 外部のMAツールやCRMツール、BIツールなどを利用する場合、そうした外部ツールの利用料がかかります。

構築時に見落とされがちなのが、この運用フェーズの費用です。
初期構築は同じだけど、ランニングコストの差で、中長期には何倍にもなるケースもあるため、トータルコストを把握することも重要です。

構築やリニューアルの背景には、様々な目的があるはずです。

• 新規構築の場合：
  • 「新たな収益チャネルを確立したい」「営業をデジタル化して効率化したい」など
• リニューアルの場合：
  • 「現行システムの使い勝手が悪い」「拡張性や管理機能に限界がある」など

これらの目的が曖昧なまま進めると、途中で現場から多くの要望が噴出し、目的がぼやけてコストが膨らむ原因となります。

特にリニューアルの場合は、各部署からヒアリングを行い、

• 現在の課題
• 今後の理想像

を一旦テーブルに上げ、「やるべきこと」と「やらないこと」を明確に定義しておきましょう。

目的が明確になったら、次に行うのは「機能面」と「非機能面」での要件整理です。
機能的な要件は「問い合わせ業務をシステム内部で行えるようにする」「会員ランクに合わせた施策を行えるようにする」「基幹システムとデータ連携する」といった機能的な内容になり、非機能的な要件は「こういうデザインが良い」「大量アクセス時もシステムが遅くならないようにする」「セキュリティを強化する」といったデザイン面や性能、環境的な内容となります。

特にリニューアルでは、現行システムの仕様を前提に要件を考えがちですが、システム会社は現在のシステムを知らないこともあり、また既存の仕様のままでは改善にならない場合もあるため、現状のシステムの機能も含めて要望を取りまとめることが重要です。

リニューアルの場合、関係者にヒヤリングすると、現在のシステムからの改善に関する要望が多く挙がるかと思いますが、ベンダーが現システムのすべてを把握している訳ではないため、現在のシステムで利用している機能も含めてリストアップするのが重要です。

要件分類の一例（ECサイト向け）

• ユーザー機能
  • 商品閲覧／検索、購入、レビュー、マイページ機能 など
• 管理機能
  • 商品・在庫管理、顧客情報管理、受注・出荷管理、返品対応、販促、売上分析、外部システム連携 など
• 非機能要件
  • 表示速度、セキュリティ強度、アクセシビリティ、管理画面の操作性 など

プロジェクトが大きくなるほど、関係者やステークホルダーも増えていきます。
「誰が、どの領域を担うのか」を整理することで、スムーズな進行が可能になります。

社内の主な役割分担例

• プロジェクトオーナー
  • スケジュールやコストなどの重要事項の承認を行う最終意思決定者。
• プロジェクトリーダー
  • システム会社や各関係部署のとりまとめや調整を行う調整役。プロジェクト中はほぼすべての会議に参加するため、一番負荷の高いロールになります。
• マーケティング責任者
  • 売上施策やプロモーションの検討を担う。
• UI責任者
  • デザインなど、UIの検討を担う。
• 業務責任者
  • 商品登録、受注処理など、業務要件の検討を担う。
• 経理責任者
  • 請求・会計まわりの要件検討を担う。プロジェクトオーナー

また、複数のベンダーやコンサル会社が関わる場合は、役割とスコープだけではなく、より具体的に各社の成果物が、後続の工程で利用できる形態になっているかまで確認することも重要です。

体制イメージ

社内の要件がまとまったら、次にRFP（Request for Proposal：提案依頼書）を作成し、ベンダーに提案を依頼します。

RFPに盛り込む内容の一例

• プロジェクトの背景と目的
• 機能要件・非機能要件の一覧
• スケジュール感
• 法令対応（特商法、インボイス制度など）
• 提案時の要件（金額、契約期間、支払いなど）
• 提出期限・評価基準

RFPも初めて作成する場合には、どのようにまとめたらよいか迷うこともあるかと思いますが、そうした場合にはシステム会社に相談してみる手もあります。提案力のあるシステム会社であれば、ヒアリングベースでこうした情報を収集し、良い提案をしてくれます。

RFPを作成したら、各ベンダーに配布し、提案の提出を依頼します。
提出の締切は通常、配布から2～4週間前後が目安。その後、提案内容の説明を受ける打ち合わせを1週間以内に設定します。

評価時に重要なのは「評価基準の明確化」です。提案書は100ページ近くに及ぶこともあり、ベンダーごとに強みや方針も異なります。
評価軸が不明瞭だと、「営業の印象が良かった」「一番安いから」という曖昧な理由で進んでしまい、後から後悔することも。

以下のような定量的な比較ポイントをあらかじめ社内で設定しておきましょう。

選定が完了したら、次は契約フェーズに入ります。
ECシステムに関わる契約は、主に以下の3種類に分かれます。

また、業務委託契約の形式としては、次のいずれか（または併用）になるのが一般的です。

請負契約（成果物保証型）

• 要件に基づき見積を提示し、決められた金額で成果物を納品する形式。
• 不具合対応も契約不履行として無償で対応される。
• 要件追加時には再見積が必要になる。

準委任契約（時間課金型）

• 時間単価ベースで費用を請求。プロジェクトの実作業時間に応じた支払い。
• 要件変更やアジャイル開発との相性が良く、要件の変更にも柔軟に対応可能。
• 不具合修正も作業時間に応じた課金が発生することがある。

初期構築は費用が大きくなるため予算が確定する「請負契約」が好まれ、リリース後の保守や継続改修は柔軟に作業が可能になる「準委任契約」が選ばれる傾向があります。

最初に行うのが「要件定義」です。
パッケージ型の構築では、システム仕様に精通しているベンダーと、要求を持つ事業者で、MTG形式で要件をすり合わせていく進め方が一般的です。

要件定義は、デザインや機能を決めると思われがちですが、サービス内容や事業内容を整理することも重要です。 サービス内容や事業内容が事前に整理できないと、前提となる認識に相違が生じ、大きな要件漏れにつながります。

要件定義では以下のような観点をドキュメントとして明文化します。

定義項目	内容	ドキュメント形式
サービス概要	商品の販売方法、販売施策、送料や決済、税や割引の端数処理ルールなど、お客様から見えるサービス内容をまとめます。	文章形式 （箇条書き）
業務フロー	商品登録、受注、返品など、システムで対応しうる業務のフローを、業務を担うロールを意識して定義します。 自動が主導かを明確にする！ 業務フローにおいては、自動的に処理されるものなのか、画面の操作などの手動対応が必要なのかを確認すると、効率的な業務の設計につながります。	フローチャート
機能要件	実現すべき機能要件（以下例）を定義します。 商品機能 会員機能 受注機能 販促・SEO・分析機能 連携機能 定時処理機能 メールなど	文章形式・ 表形式
非機能要件	実現すべき非機能要件（以下例）を定義します。 データの移行 性能・スケーラビリティ 法令事項 セキュリティ事項 インシデントの対応フローなど	文章形式・ 表形式
画面仕様（ワイヤー）	管理画面やユーザー画面の画面イメージと合わせて仕様を定義します。 デザインではなく仕様にフォーカスする 画面仕様はサイトの見た目をイメージできるため、どうしてもデザインに目が行きがちになりますが、どのような操作感を実現したいか、条件や押下によって、どのように要素が変わるかなど、機能項目にフォーカスすると、スムーズかつ漏れのない定義が可能です。	図形式

要件が固まったら、次はUIデザインとシステム構築フェーズに入ります。

• デザイン工程では、ワイヤーをベースに具体的なビジュアルへと落とし込んでいきます。ここではユーザー目線で確認しやすく、フィードバックもしやすい段階です。
• システム構築工程では、詳細設計〜開発が進行します。ただし設計書の確認は専門知識を要するため、基本的にはベンダーに進行を委ねる形が一般的です。

開発が完了したら、次はテストフェーズです。

• ベンダーによる内部テスト（単体・結合）
• 事業者側による受け入れテスト（UAT）

それぞれで要件通りに動作するか確認します。

特に受け入れテストでは、単なる機能の動作確認にとどまらず、実際の業務運用に支障がないかどうかまで含めてチェックすることが大切です。

不具合が見つかった場合は修正対応が行われますが、要件漏れによる追加実装は別途費用や工期が発生する可能性があるため、早期の洗い出しが重要です。

新規構築の場合には、登録が必要なデータは商品のデータに限られる場合もありますが、既存サイトからリニューアルする場合には顧客データや受注データなどを移行する作業が生じます。

特に大規模サイトではデータ量も多く、データ変換・整備・検証に多くの工数がかかります。
本番リリースのスケジュールに影響することがあるため、早めの着手・スケジュール化が必須です。

リニューアルを伴う場合、事前の告知はとても重要です。
多くの企業では、2週間前／1週間前／前日など、段階的に案内メールを送るのが一般的です。

告知内容の例

• リニューアル日時
• メンテナンス期間（サービス停止時間）
• 利用者に必要な作業（例：パスワード再設定）
• 変更点（廃止機能・新機能など）
• リニューアルキャンペーン情報
• よくある質問（FAQ）や問い合わせ窓口

いよいよ本番公開です。
一般的には夜間や早朝にメンテナンス時間を設けて移行作業を実施します。
また、リリース日程は「トラブル発生時に対応しやすい」「関係者が稼働している」という理由から、週の前半（月曜〜水曜）を選ぶことが多いです。
なお、一度リリースすると、本番環境にデータが追加され始めるため、簡単には元に戻せません。
公開直前には、本番環境でログインや決済の最終確認を必ず行いましょう。

当社は、REGOLITH ECというAI搭載の独自パッケージをベースに、貴社の事業・商材・運用体制に最適化されたECシステムを構築いたします。
これからECサイトの構築やリニューアルをご検討中の方は、ぜひお気軽にご相談ください。
現状整理からご一緒に対応いたします。