通販サイト/システム刷新の開発期間・スケジュール・納期について

通販サイト／システム刷新の開発期間・スケジュール・納期を検討する際、まず押さえておきたいのが、同じ「通販サイト・通販システム」というテーマを扱いながらも、本記事が焦点を当てる論点は「通販サイト／システムのモダナイゼーション」「EC刷新」とはまったく異なるという点です。「通販サイト／システムのモダナイゼーション」は、EC-CUBEベースの独自カスタマイズや独自スクラッチ構築のOMSなど、自社が保有する具体的な通販システムを対象に、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチをどう使い分けるかという「どう技術的に刷新するか（HOW）」に重心を置く記事です。「EC刷新」は、プラットフォームやビジネスモデルを問わない一般総論として、なぜ・いつ刷新に踏み切るべきかという経営判断（WHY/WHEN）を扱いますが、対象システムの主語は抽象的な「ECサイト」にとどまります。

これに対し本記事が扱う通販サイト／システム刷新は、この2記事の交差点に位置づけられます。すなわち、電話・FAX・Web・実店舗という複数チャネルの受注を統合し、コールセンターや基幹システム（ERP）・倉庫管理システム（WMS）と連携しながら事業を支えてきた自社所有の具体的な通販システムを対象にしつつ、技術手法の詳細ではなく、会員データ・受注実績という自社固有の資産価値を踏まえた投資判断、そしてEC事業責任者が社内をどう巻き込み合意形成しながらプロジェクトを推進していくかという経営判断・意思決定プロセスに焦点を当てます。技術的な刷新手法そのものの詳細は通販サイト／システムのモダナイゼーションの記事に譲り、本記事では「いつまでに、誰を巻き込み、どう合意形成しながら進めるか」という事業推進の実務に重心を置いて解説します。

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

▼全体ガイドの記事
・通販サイト／システム刷新の完全ガイド

通販サイト／システム刷新とは何か（自社所有システムの経営判断という論点）

開発期間を正しく見積もる前に、本記事が扱う論点の位置づけを明確にしておく必要があります。同じ「通販サイト・通販システムの刷新」というテーマでも、技術手法に重心を置く記事群、プラットフォーム非依存の経営論に重心を置く記事群、そして本記事が扱う「自社所有システムを主語にした経営判断」とでは、スケジュールに影響する要因がまったく異なるためです。

「通販サイト／システムのモダナイゼーション」は、EC-CUBEベースの独自カスタマイズや独自スクラッチ構築のOMSなど、貴社がすでに保有している具体的な通販システムを主語にしつつ、5つの技術的アプローチをどう使い分けるかという、IT部門・エンジニア視点の技術手法論です。「EC刷新」は、EC事業責任者・経営層がなぜ今このタイミングで刷新に投資すべきかを判断する経営判断プロセスに重心を置きますが、対象を特定のシステム構成に絞り込まない一般総論です。本記事が扱う通販サイト／システム刷新は、この2つの軸を掛け合わせ、自社が実際に運用している具体的な通販システムを主語にしながら、その刷新に「いつ・なぜ・どれだけの予算で」踏み切るべきかという経営判断・意思決定プロセスに焦点を当てます。同じ「開発期間・スケジュール・納期」というテーマを扱っていても、モダナイゼーション記事群が「実装フェーズの工程別期間配分」を主眼とするのに対し、本記事は「自社が保有する会員基盤・受注実績という資産をどう評価し、実装に着手する前の意思決定にどれだけの期間を要するか」を主眼とする点が最大の違いです。

自社所有の通販システムを刷新するかどうかの意思決定は、抽象的な「ECサイトの老朽化」という一般論ではなく、長年蓄積してきた会員データ（会員数・購買履歴・保有ポイント）と受注実績（年間受注件数・売上規模・チャネル別構成比）という具体的な資産をどう評価するかから始まります。ゼロから中〜大規模の通販システム基盤を新規に立ち上げる「通販サイト／システム開発」とは異なり、本記事が扱うのは、複数チャネル（電話・FAX・Web・実店舗）の受注を長年支えてきた既存基盤を、業務を止めずに刷新するプロジェクトです。この資産価値を経営層に正しく伝えられるかどうかが、開発期間の見積もり以前の、そもそも刷新に着手するかどうかという意思決定のスピードを大きく左右します。

経営層への説明〜稟議承認までの意思決定スケジュール

通販サイト／システム刷新のプロジェクト全体スケジュールを左右する最初の関門が、経営層の稟議承認です。この段階でどれだけ時間を要するかは、企業ごとの意思決定文化と、EC事業責任者がどこまで自社固有の資産を根拠にした説得材料を準備できているかによって大きく異なります。

経営層は、通販システム刷新への投資を「システムを新しくするコスト」ではなく「保有する会員基盤・受注実績という資産を守り、成長させるための再投資」として捉えられるかどうかで、稟議の通りやすさが大きく変わります。EC事業責任者が用意すべきは、「現行システムを使い続けた場合に想定される会員離脱・受注機会損失」と「刷新した場合に見込める会員基盤の維持・受注効率の向上」を対比させた資料です。ここで重要なのは、一般的な業界平均値を持ち出すのではなく、自社の会員データ・受注実績・チャネル別構成比を根拠に、自社固有の課題として語ることです。あわせて、システム刷新一般で投資回収期間の目安として語られる1.5〜4年というスパンを引き合いに、初期フェーズでは一定のコスト増を許容しつつ、稼働後の会員維持率向上・保守コスト削減によって投資を回収する計画を提示することが、稟議を通すうえでの説得力を高めます。

経営層と現場の認識の乖離を埋めるためには、綿密なコスト・効果シミュレーションを関係者間で共有する必要があります。このシミュレーション作業だけで、実務上は1〜2ヶ月程度を要するケースが多く見られます。具体的には、刷新した場合としなかった場合の3〜5年スパンでのコスト比較、会員データ・商品マスタ・注文履歴という既存資産の棚卸し結果を踏まえた移行難易度の試算、そして基幹（ERP）・WMS・EDIといった外部連携先の仕様調査を、EC事業責任者と情報システム部門が共同で準備することになります。稟議のスケジュールを短縮するためには、経営会議の開催サイクルを逆算し、いつまでにどの資料を揃えるべきかをマイルストーンとして設定し、財務部門やコールセンター運営部門を早い段階から巻き込んでおくことが有効です。中規模の通販システム刷新であれば意思決定〜稟議承認までに3〜6ヶ月、全社的な投資判断が絡む大規模案件では半年〜1年を見込んでおくのが現実的です。

繁忙期を避けたリニューアル時期の意思決定

通販サイト／システム刷新の開発期間・スケジュールを決めるうえで、EC刷新と共通する固有の意思決定ポイントが、年間の売上を大きく左右する繁忙期との兼ね合いです。加えて、自社所有の通販システムならではの論点として、コールセンター運営部門を巻き込んだ判断が必要になります。

年末商戦や大型セールに加え、カタログ通販・テレビ通販特有のカタログ配布直後や放送直後の受注集中期に新システムの公開やデータ移行が重なると、トラブル対応と通常業務の繁忙が同時に襲いかかり、致命的な機会損失に直結します。刷新・データ移行の直後は、どれだけ入念にテストをしても「データ差異」や「連携エラー」が発覚し、確認作業に追われることが少なくないため、年間を通じて最もアクセス・受注量が落ち着く閑散期にカットオーバーのタイミングを設定し、そこから逆算して意思決定・要件定義・開発・テストの各工程のスケジュールを引くのが鉄則です。この逆算スケジュールは技術的な都合ではなく経営判断そのものであり、EC事業責任者が年間の販促カレンダーとカタログ・放送スケジュールを最も正確に把握している立場として、プロジェクトの起点となる稼働目標日を主体的に提示する必要があります。

閑散期にカットオーバーを合わせるという意思決定は、単に「稼働開始日を後ろにずらす」だけでは済みません。意思決定のタイミングによっては、次の閑散期まで半年以上待たなければならないケースもあり、この待機期間をどう扱うかもプロジェクト推進上の重要な論点です。稟議承認が繁忙期直前にずれ込んでしまった場合、無理に間に合わせようと全チャネル一斉の切り替えを急ぐのではなく、次の閑散期を新たな目標に据え、その間に会員データ・商品マスタ・注文履歴という既存資産の棚卸しや、コールセンター運営部門との要件すり合わせを丁寧に進めるという判断が結果的に事業リスクを抑えます。EC事業責任者としては、稟議のタイミングと年間販促カレンダーの両方を俯瞰し、「今期の閑散期に間に合わせるべきか、次期に照準を合わせるべきか」を早期に判断し、開発ベンダーとも稼働目標日を早い段階で共有しておくことが、実務上の手戻りを防ぐポイントになります。

EC事業責任者とIT部門・コールセンター運営部門の合意形成に要する期間

稟議承認が得られた後も、通販サイト／システム刷新は事業側（売上・マーケティング）、IT部門（システム・保守）、そして自社所有の通販システムならではのステークホルダーであるコールセンター運営部門という、3者の合意形成というもう一つの大きな関門を越える必要があります。

事業側・IT部門・コールセンター運営部門の認識のズレは、通販サイト／システム刷新のスケジュール遅延を招く最大の要因のひとつです。EC事業責任者は「一刻も早く新しいデザイン・機能を公開して売上を伸ばしたい」というスピード志向、IT部門は「既存の基幹システム・WMSとの連携を壊さず安全に移行したい」という安全確実志向、そしてコールセンター運営部門は「オペレーターが日々使う受注代理入力画面の操作性を落としたくない」という現場志向で動くため、三者の温度差から要件のすり合わせが難航しがちです。この認識ギャップを放置したまま開発をスタートさせると、実装フェーズに入ってから「事業側が想定していた機能がIT部門の計画に入っていなかった」「コールセンターの現場運用に合わない画面ができあがった」という手戻りが発生し、結果的にプロジェクト全体の納期を圧迫します。合意形成のスケジュールを短縮するには、プロジェクトのごく初期段階で、事業側・IT部門・コールセンター運営部門の三者が参加するキックオフを設け、「なぜ・いつまでに・何のために刷新するのか」という目的を数値目標とともに共有し、三者の温度差を早い段階で埋めておくことが不可欠です。

合意形成を円滑に進めるためには、会員データ・商品マスタ・注文履歴という自社固有の資産の現状を、三者共通の事実として棚卸ししておく必要があります。会員数・保有ポイント残高・年間受注件数・チャネル別売上構成比といった定量情報に加え、現行システムの仕様書がどこまで実態と一致しているか、設計書のない機能や退職済みの担当者しか把握していない仕様がどれだけ残っているかも、可能な範囲で洗い出しておきましょう。この棚卸し作業には、規模にもよりますが1〜2ヶ月程度を要するのが一般的です。これらの情報があれば、事業側・IT部門・コールセンター運営部門の三者が同じ事実に基づいて議論でき、「言った・言わない」による手戻りを防げます。逆に、この棚卸しを省略して合意形成に進んでしまうと、要件定義フェーズに入ってから資産の実態が判明し、スケジュール全体が後ろ倒しになるリスクが高まります。

リニューアル予算の確保とプロジェクト全体スケジュール

意思決定・合意形成という上流プロセスを経た後は、確保した予算のもとで実際にプロジェクトを推進していくフェーズに入ります。ここでも経営判断・プロジェクト推進の視点で押さえるべきポイントがあります。

リニューアル予算は、新規構築費用に加えて、会員データ・商品マスタ・注文履歴の移行費、EDI連携先ごとの切替対応費、コールセンターの受注代理入力画面の再構築費が上乗せされるため、一般的に新規構築よりも20〜50%程度の追加費用が発生します。この上乗せ分を織り込まずに予算申請してしまうと、プロジェクト途中で追加の稟議が必要になり、スケジュール全体が停滞する原因になります。予算規模の目安としては、年商1億円未満であれば低価格帯の刷新に留め集客・広告への投資を優先すべき局面が多く、年商1億円〜5億円であればブランド独自のUI刷新やCRM連携に、年商5億円〜50億円であれば基幹連携の刷新とデータ活用の自動化に、年商50億円以上であれば独自の物流オペレーションとコールセンター統合に対応した大規模な刷新に、それぞれ投資対効果の重心が移っていきます。EC事業責任者は自社の売上規模と保有資産の規模に見合った投資水準を経営層に提示し、過大投資・過小投資のいずれにも陥らないよう説明することが求められます。

予算が確保された後の実行フェーズでも、全チャネル・全商品・全取引先を一斉に切り替える「ビッグバン方式」は、テスト規模が膨大化してエラーの特定が事実上不可能になり、稼働直後に受注・出荷が止まる致命的な障害を引き起こすリスクが高いため、経営判断としても避けるべき選択肢です。業務量が少なくリスクが低いチャネルや特定の商品カテゴリーに絞って新システムを稼働させ、運用負荷やエラー発生率を確認しながら対象を広げていくスモールスタートと、旧システムと新システムを一定期間並行稼働させて両者の出力が一致するかを確認する進め方が有効です。プロジェクト推進の実務としては、経営層を含むステアリングコミッティを設置し、週次・月次の定例会議で進捗と課題を可視化することが基本です。仕様変更の申し出があった場合は口頭で済ませず変更要求として起票し、影響範囲の調査・工数見積もり・承認というプロセスを経てから実施するルールを徹底することで、事業側からの要望が際限なく積み上がってスケジュールが破綻する事態を防げます。全体工程には10〜20%程度のリスクバッファを組み込み、閑散期のカットオーバー目標日から逆算したスケジュールに対して常に余裕を持たせておくことが、通販サイト／システム刷新における納期管理の要諦です。

まとめ

本記事では、通販サイト／システム刷新における開発期間・スケジュール・納期について、自社が保有する具体的な通販システムを対象にした経営判断という観点から、経営層への説明〜稟議承認までの意思決定スケジュール、繁忙期を避けたリニューアル時期の意思決定、EC事業責任者とIT部門・コールセンター運営部門の合意形成に要する期間、そしてリニューアル予算の確保からプロジェクト全体の進め方までを体系的に解説しました。技術的な刷新手法の詳細は通販サイト／システムのモダナイゼーションの記事に譲るとして、本記事で強調したいのは、通販サイト／システム刷新における最大の変動要因は実装作業そのものよりも、会員基盤・受注実績という自社固有の資産価値の可視化に基づく稟議承認・三者の合意形成・繁忙期を踏まえたスケジュール設計という上流の意思決定プロセスに潜んでいるという点です。EC事業責任者が主体となって年間販促カレンダーから逆算したスケジュールを提示し、経営層・IT部門・コールセンター運営部門の三者を巻き込みながら段階的に進めていくことが、通販サイト／システム刷新を成功に導く鍵となります。

▼全体ガイドの記事
・通販サイト／システム刷新の完全ガイド

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

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

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