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

通販サイト／システム更改とは、自社が長年運用してきた通販システムについて、保守サポート契約の満了時期、サーバーやネットワーク機器のハードウェアリース期限、あるいはECパッケージ（EC-CUBEベースの独自カスタマイズ環境など）やOS・ミドルウェアのEnd of Support／End of Life（EOS／EOL）という「外部から強制される期限」をきっかけに、そのまま契約を更新して使い続けるか、システムを刷新するかを判断・実行するプロジェクトを指します。同じプロジェクト内で先に解説した「通販サイト／システムのモダナイゼーション」は、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチをどう使い分けるかという、IT部門・エンジニア視点の技術手法（HOW）に重心を置く記事です。また「通販サイト／システム刷新」は、会員基盤・受注実績という自社固有の資産価値を根拠に、経営層への説明から稟議承認までを進める、内発的な経営判断（WHY／WHEN）に重心を置く記事でした。

これに対して本記事が扱う通販サイト／システム更改は、決済代行会社の旧APIの提供終了、Windows Serverなど基盤OSのサポート終了、サーバーのメーカー保守切れといった「自社が主体的に選んだわけではないタイミングで判断を迫られる」という前提が最大の違いです。刷新のように「いつ着手するか」を自社のペースで決められるわけではなく、期限までに「そのまま契約更新して延命するか、この機会に刷新するか」を判断し、判断した以上は期限内に実行を完了させなければなりません。本記事では、この外圧型トリガー特有の開発期間・スケジュール・納期の考え方を解説します。

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

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

通販サイト／システム更改とは何か（契約・ライフサイクル起点という前提）

開発期間を正しく見積もる前に、本記事が扱う論点がモダナイゼーション記事群・刷新記事群とどう違うのかを明確にしておく必要があります。トリガーの性質が異なれば、スケジュールに影響する要因もまったく異なるためです。

「通販サイト／システムのモダナイゼーション」は、自社が保有する具体的な通販システムを対象にしつつ、5つの技術的アプローチをどう使い分けるかという実装フェーズの工程別期間配分に重心を置きます。「通販サイト／システム刷新」は、会員データ・受注実績という資産価値をどう経営層に説明し、稟議承認・三者合意形成にどれだけの期間を要するかという、実装に着手する前の意思決定プロセスに重心を置きます。両者に共通するのは、いずれも「いつ着手するか」を自社の意思とペースで決められるという前提です。これに対し本記事が扱う通販サイト／システム更改は、保守サポート契約の満了日、ハードウェアリースの契約満了日、パッケージやミドルウェアのEOS／EOL告知日という、あらかじめ決まった外部の期限が先に存在し、その期限から逆算してスケジュールを組まざるを得ないという点で、両記事とはまったく異なる制約条件の中で開発期間を考える必要があります。

本記事が想定する外圧トリガーには、大きく4つのパターンがあります。第一に、EC-CUBEベースの独自カスタマイズ環境など、利用しているECパッケージそのもののサポート終了です。第二に、通販システムが稼働するサーバーのOSやミドルウェア（Windows Serverなど）のEnd of Supportです。第三に、クレジットカード決済代行会社が旧APIの提供を終了し、3Dセキュア2.0対応など新しい仕様への切替を求められるケースです。第四に、オンプレミス環境でサーバーを運用している場合のハードウェアリース契約の満了、あるいはメーカー保守切れです。いずれも、自社の都合とは無関係に期限が決まっており、その期限までに「そのまま契約更新して延命するか、この機会に刷新するか」を判断しなければならないという共通点があります。

更新か更改かを判断する意思決定プロセスと期間

契約更新の通知が届いた時点から、まず着手すべきは「そのまま契約を更新するか、この機会に刷新するか」の判断です。この判断そのものに要する期間を見誤ると、判断が長引いた分だけ実際の開発・移行に充てられる時間が圧縮されてしまいます。

更改の意思決定は、初期費用の安さだけで判断すると危険です。既存システムを延命した場合にかかる割高な延長保守費用と、刷新した場合の初期費用に新たな月額費用・運用保守費を加えた金額を、3〜5年間のTCO（総所有コスト）で比較して評価することが基本になります。あわせて、自社のEC業務プロセスを既存のSaaS型カートシステムやECパッケージの標準機能にどこまで合わせられるか（Fit to Standard）を評価し、これが可能であればカスタマイズ費用を抑えて短期間での更改が見込めます。ECサイトは顧客の個人情報や決済情報を直接扱うため、EOS／EOLを迎えた古いシステムを使い続けるセキュリティリスク・ブランドリスクも、この判断に織り込む必要があります。

更改を選択した場合、自社の要望を正確に伝え、複数のベンダーを比較選定するための期間として、現状分析とRFP（提案依頼書）の作成に数週間〜1ヶ月、候補企業を絞り込む技術適合評価・RFI送付に1〜2週間、自社データを用いた実地検証としてのPoCに3〜6週間、セキュリティ監査や契約交渉を含むコンプライアンス・契約精査に1〜2週間を見込みます。合計するとベンダー選定から契約締結までに約2.5〜3.5ヶ月を要するのが一般的です。契約満了やEOS／EOLの期限が迫っている場合、この選定期間をどれだけ前倒しで開始できるかが、実際の開発・移行に充てられる期間を左右する最初の分岐点になります。

開発期間・データ移行の目安（半年〜1年半）

ベンダーが決まった後の実際の開発・移行期間は、システムの規模や複雑さによって大きく異なります。ここでは通販サイト・EC通販システムに特有の論点を含めて解説します。

小規模な更改であれば数ヶ月で完了するケースもありますが、対象範囲が広く連携先の多い大規模で複雑な通販システムでは、1年以上かかることも珍しくありません。とくにSaaS型カートシステムやECパッケージへのリプレースでFit to Standardが徹底できれば開発期間は圧縮できますが、独自の受注・在庫引当ロジックを多く抱えるシステムほど、標準機能とのギャップを埋めるための追加開発が積み上がり、期間が伸びる傾向にあります。契約満了やEOS／EOLという動かせない期限がある以上、まず対象範囲の見立てを早期に固め、規模に応じた現実的な期間感を関係者と共有しておくことが欠かせません。

通販サイト・EC通販システムの更改では、商品マスタだけでなく、過去の受注履歴（トランザクションデータ）や顧客データの移行が必ず発生します。すべてを移行しようとすると工数が跳ね上がるため、業務部門と連携し「過去何年分の注文履歴を移行するか」を早い段階で定義しておく必要があります。あわせて、決済代行会社や倉庫管理システム（WMS）とのAPI連携の切り替え・接続テストは相手都合に左右されやすく、数週間〜1ヶ月以上を要することがあるため、スケジュールに組み込んでおきます。移行ミスは会員のログイン不能や注文履歴の消失といった深刻なクレームに直結するため、本番と同じ条件での複数回のリハーサル（テスト移行）を必ず実施します。

契約満了・EOS／EOLから逆算したスケジュール設計

更改プロジェクトの最大の特徴は、稼働目標日が自社の裁量ではなく、契約満了日やEOS／EOLの告知日によって先に決まっている点です。この動かせないデッドラインから逆算してスケジュールを組み立てる考え方を解説します。

これまでの意思決定・ベンダー選定・開発・データ移行に要する期間を合算すると、通販サイト・EC通販システムを安全に切り替えるには、最低でも半年〜9ヶ月程度、大規模な移行やフルスクラッチ開発を伴う場合は1年〜1年半程度の期間が必要になります。契約満了やEOS／EOLの期限をそのまま稼働目標日に設定するのではなく、稼働後のトラブルに備えた初期流動期間（数週間〜1ヶ月程度）もあらかじめスケジュールに含めて逆算することが欠かせません。判断が遅れるほどこの初期流動期間から削られていくため、契約更新通知を受け取った時点で速やかに検討を開始することが、期限に追われた無理な短納期化を避ける唯一の方法です。

期限ギリギリにすべてを一斉に切り替える一括移行（ビッグバン方式）は、スケジュールそのものは短期間で組めますが、システム停止による販売機会の損失やトラブル発生時の影響範囲が甚大になるリスクを抱えます。一方、特定のチャネルやブランドから順次移行する段階移行や、限定した対象で先行稼働させるパイロット移行は、リスクを抑えられる反面、全体のスケジュールにはより多くの余裕を持たせる必要があります。契約満了やEOS／EOLという明確な期限がある更改プロジェクトでは、期限直前に無理な一括移行へ追い込まれることのないよう、判断のタイミングでどちらの移行方式を取るかをあらかじめ検討し、必要な期間をベンダーと早期にすり合わせておくことが重要です。

納期遅延を防ぐための実務ポイント

動かせない期限を抱える更改プロジェクトだからこそ、遅延要因を事前に把握し、発注前の段階で対策を講じておくことが極めて重要です。最後に、実務上のポイントを2つ解説します。

通販サイト・EC通販システムは、決済代行会社、倉庫管理システム（WMS）、基幹システムといった多数の外部インターフェースと連携しており、これらの切替・接続テストの日程は自社の都合だけで動かせません。とくに決済代行会社側のAPI仕様変更に伴う切替では、審査やテストに数週間〜1ヶ月以上を要することがあり、着手が遅れるほど契約満了日やEOS／EOL期限との間隔が狭まっていきます。外部連携先の担当窓口とスケジュールを早期に確定させ、自社側の要件定義と並行して連携先の対応可否を確認しておくことが、期限内に間に合わせるための鍵になります。

見積もりの精度を高めるには、発注時点で現行の保守契約・リース契約の満了日、対象パッケージやミドルウェアのEOS／EOLの正確な告知日、そして連携が必要な外部システムの一覧をまとめた棚卸し資料を用意しておくことが欠かせません。あわせて、会員データ・商品マスタ・注文履歴のデータ量と現状の品質、現行システムの仕様書がどこまで実態と一致しているかも、可能な範囲で洗い出しておきましょう。これらの情報があれば、開発会社は期限内に対応可能かどうかを現実的に見積もることができ、期限に間に合わない前提でのやみくもな短納期発注を避けられます。

まとめ

本記事では、通販サイト／システム更改における開発期間・スケジュール・納期について解説しました。技術手法に重心を置く「通販サイト／システムのモダナイゼーション」、内発的な経営判断に重心を置く「通販サイト／システム刷新」とは異なり、本記事が扱う更改は、保守サポート契約の満了、ハードウェアリース期限、ECパッケージやOS・ミドルウェアのEOS／EOLという外部から強制される期限が起点になります。そのまま契約更新するか刷新するかの判断には3〜5年のTCO比較が基本となり、ベンダー選定・RFP作成に約2.5〜3.5ヶ月、開発・データ移行には半年〜1年半という期間を見込む必要があります。動かせないデッドラインから逆算したスケジュール設計と、決済代行・WMS等の外部連携先都合の把握、そして発注前の現行契約・資産の棚卸しが、期限内に無理なく更改を完了させるための鍵となります。

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

株式会社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を創業。