OMS更改の開発期間は、保守サポート契約の満了、ハードウェアのリース満了、ベンダーのEOS/EOLといった動かせない期限から逆算して決まります。
実務期間を合算すると最低でも「半年弱」かかるため、期限の半年前から1年半前には始動させておくのが目安です。同じOMSを扱う関連記事のうち、モダナイゼーション記事は5つの技術的アプローチの使い分け（HOW）を、刷新記事は在庫連携ミス（二重販売・売り越し等）の経営インパクトと刷新の時期（WHY/WHEN）を扱います。
- 更改の期限と開発範囲の整理
- 要件定義・設計・開発・移行・テストの進め方
- 遅延要因と関係者間で確認する判断材料
▼全体ガイドの記事
・OMS更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
OMS更改の位置づけ（契約・ライフサイクル起点という論点）
同じOMSを扱う記事でも、技術手法に重きを置く記事、経営判断に重きを置く記事、契約やライフサイクルの期限に重きを置く本記事では、スケジュールに影響する要因が異なります。
発注する側は、開発期間やスケジュールを考える前に、本記事がどの論点を扱うのかを押さえておく必要があります。
モダナイゼーション記事・刷新記事との違い（外部期限を起点とする観点）
「OMSのモダナイゼーション」は、5つの技術的アプローチ（リホスト・リプラットフォーム・リファクタリング・リビルド・リプレース）をどう使い分けるかを扱う技術手法です。既存の注文データと在庫引当ロジックを新しい環境へどう移すかも、主な論点になります。エンジニアや情報システム部門に向けた技術の話です。
一方の「OMS刷新」は、老朽化したOMSを放置することの経営インパクトを数字で示す取り組みです。注文処理の遅れや、複数チャネル間の在庫連携ミス（二重販売・売り越し等）による機会損失などが、その例です。
経営層の稟議承認と、EC事業部門・カスタマーサポート・IT部門の合意形成をどう進めるかが論点で、経営層やプロジェクトマネージャーに向けた内発的な意思決定のプロセスです。同じ開発期間や納期を扱う場合でも、主眼を置く場所は異なります。
- モダナイゼーション記事：実装フェーズの工程別の期間配分が中心
- 刷新記事：経営判断と合意形成に要する期間が中心
- 本記事（更改）：動かせない期限から逆算して、いつまでに何を終えておくかという納期管理
これに対して更改は、プロジェクトを始める起点そのものが異なります。保守サポート契約の満了、オンプレミスサーバーのリース期限、ベンダーのEOS/EOLは、自社の判断とは関係なく外から決まる期限です。そこまでに「契約をそのまま更新するか、この機会に刷新するか」を判断せざるを得ない点が、更改の本質です。
「OMS開発」（新規導入）との共通点・相違点
「OMS開発」がゼロから構築する新規案件（グリーンフィールド）なのに対し、更改は、複数チャネルの受注を管理してきた稼働中のOMSを土台にする案件（ブラウンフィールド）です。この点は、モダナイゼーションや刷新とも共通します。ただし更改には、新規導入にもモダナイゼーション・刷新にもない固有の制約があり、それは「期限に交渉の余地がほとんどない」ことです。
経営判断による刷新であれば、社内の合意形成の状況次第で、着手を数ヶ月後ろにずらす選択肢も現実的にあります。一方で更改は、保守ベンダーが終了日を一方的に通知してくると、その日を過ぎた時点で受注処理の障害対応や問い合わせ対応を受けられなくなるおそれがあります。オンプレミスサーバーのリース契約であれば、満了後もそのまま使い続けることは契約上できず、返却か再リースかの判断を迫られます。
更改では、交渉の余地が乏しい外部期限を起点に計画を立てることが、開発期間と納期を考えるうえでの最大の前提です。
更改のトリガーとなる契約・ライフサイクルの期限
スケジュールを逆算する起点となる期限には、主に3つの種類があります。それぞれ通知の届き方や交渉の余地が異なるため、自社のOMSがどの期限に当たるかを正確に把握することが、更改の第一歩です。
保守サポート契約満了とハードウェアのリース満了
最も身近な期限は、OMSの保守サポート契約の満了です。オンプレミス型やパッケージ型のOMSでは、3年や5年単位で保守契約を結ぶのが一般的で、満了時に更新するかどうかの判断を求められます。
保守契約には、受注処理や在庫引当の不具合に対する障害対応や、ECモールの仕様変更・法改正（インボイス制度等）への追従が含まれることが多いです。そのため、契約が切れたまま運用を続けることは、注文受付業務の停止リスクを放置することと同じになります。
もう一つの期限は、オンプレミスサーバーのリース満了です。リース契約は、法定耐用年数や減価償却期間を踏まえて5年前後で組まれることが多く、満了時には返却・再リース、購入、クラウド型OMSへの移行のいずれかを判断することになります。保守とリースは別々の期日で満了することもあるため、片方だけを見ていると、もう一方の期限を見落とすおそれがあります。
ベンダーのEnd of Support/End of Life（EOS/EOL）
3つ目の期限は、OMSを構成するOS・データベース・ミドルウェア、あるいはパッケージ製品そのものの、End of Support（サポート終了）やEnd of Life（提供終了）です。ベンダーが製品戦略として一方的に定める期限で、保守契約やリースの満了時期とは関係なく訪れます。
EOS/EOLを迎えた製品は、セキュリティパッチの提供が止まり、脆弱性が見つかっても修正されないまま残ります。OMSは、ECモール・自社EC・実店舗POS・卸売取引先の受注データと在庫情報をまとめて扱うため、売上に直結する仕組みです。ここでセキュリティ上の事故が起きれば、注文データの改ざんや停止によって全チャネルの受注業務が止まり、経営リスクに直結します。
EOS/EOLを過ぎても稼働は続けられるケースが多いため、「まだ動いているから大丈夫」と先送りしがちです。しかし、その間は特別保守（延長サポート）に頼らざるを得ず、通常の保守費用より大幅に高い費用を払い続けやすく、保守・運用費用の面でも見過ごせません。EOS/EOLの日付は、多くの場合ベンダーが事前に告知しているため、更改の起点として最も早い段階から把握できます。
期限から逆算するスケジュール設計
更改のスケジュールは、要件定義から積み上げる通常のプロジェクトとは逆に、動かせない期限から各工程に必要な期間を差し引いていく「逆算方式」で組むのが基本です。
OMSは注文受付を一時も止められないため、逆算がずれると、そのまま受注機会の損失につながります。
逆算に必要な実務期間の内訳
動かせない期限から逆算するときは、4つの実務期間を積み上げる必要があります。1つ目は開発・テスト・データ移行で、販売チャネル数や在庫引当ロジックの複雑さに応じて、数ヶ月から1年以上と幅があります。既存の注文データと在庫引当ロジックを新システムにどこまで引き継ぐかによって、この期間は大きく変わります。
2つ目はベンダー選定・契約で、標準的なプロセスを踏むと約1.5〜2.5ヶ月かかります。3つ目はRFP（提案依頼書）の作成や社内稟議で、数週間から1ヶ月程度を見込む必要があります。4つ目は本番稼働直後の初期流動期間で、数週間から1ヶ月程度、特別な対応体制を敷いて臨む期間です。
これら4つを単純に合算すると、最低でも「半年弱」の実務期間が必要になります。OMSのように複数チャネルとの接続や既存注文データの移行が絡む場合は、この最低ラインにさらに余裕を持たせて見積もることが大切です。
プロジェクト始動のタイミング（半年前〜1年半前）
前述の実務期間の合計を踏まえると、システム停止や注文受付への悪影響を避けるには、少なくとも期限の半年前にはプロジェクトを始動しておく必要があります。
ただし、半年前は最短のラインです。社内稟議に時間がかかる企業や、販売チャネルが多く、既存の注文データ・在庫引当ロジックの移行対象が広範囲にわたる規模の大きいOMSでは、余裕を持って期限の1年〜1年半前から始めるほうが望ましいとされています。
EOS/EOLの通知を受けてから「まだ半年以上ある」と先送りを続けると、ベンダー選定の期間さえ確保できず、割高な特別保守を延長せざるを得なくなるか、十分な検証をしないまま移行を急ぐことになりかねません。そのため、通知を受けた時点で、社内の体制と大まかなスケジュールの仮組みに先に着手しておくことが、納期を守れるかどうかの最初の分岐点になります。
ベンダー選定・RFP作成に要する期間と移行方式
逆算スケジュールのなかでも見落とされやすいのが、ベンダー選定・RFP作成のプロセスと、移行方式が持つ期間の特性です。ここを軽く見ると、そのしわ寄せが実装フェーズに及び、結果として納期遅延につながります。
RFP作成からベンダー選定・契約までの標準プロセス
RFP（提案依頼書）の作成には、現行OMSの課題を洗い出すことと、更改後に求める要件の優先順位を付けることが必要です。そのため、数週間から1ヶ月程度の準備期間を見込んでおくことが大切です。RFPを複数のベンダーに提示してから契約に至るまでは、標準的に約1.5〜2.5ヶ月かかり、3つのステップに分かれます。
ステップ1は、技術適合の評価とRFI（情報提供依頼）の送付で、1〜2週間かけて候補ベンダーを数社に絞り込みます。ステップ2は、PoC等による実地検証で、3〜6週間かけて実際の精度や使い勝手を確かめます。ステップ3は、コンプライアンスと契約の精査で、1〜2週間かけてセキュリティ監査や契約条件の交渉を行います。
OMSの更改では、既存の基幹システム・WMS・決済システムとの連携仕様の確認も、この段階で行っておく必要があります。後工程での手戻りを防ぐため、RFPの段階で接続するチャネルと連携の要件を明記しておくことが望ましいです。
一括移行・段階移行それぞれの期間特性
OMSは日々の注文受付と直結するため、一括移行方式（ビッグバン移行）と段階移行方式（トリクルダウン移行）のどちらを選ぶかで、スケジュールの組み方が大きく変わります。一括移行方式は、現行システムから新システムへ一気に切り替える方式で、移行作業がシンプルな分、短期間かつ低コストで済むという利点があります。
ただし、移行中はシステムを完全に止める必要があるため、複数チャネルで注文受付を続けるOMSでは採用のハードルが高くなります。段階移行方式は、販売チャネル単位で、業務量が少なくリスクが低く、テストが完了したチャネルから順に接続する方式です。移行中も業務を続けられるため、事業への影響が小さく、トラブル時の影響範囲も局所化できます。
一方で、新旧システムを一定期間併用するため運用の手間が増え、移行完了までの総期間はビッグバン方式より長くなる傾向があります。期限までに全チャネルを切り替えるのか、主力チャネルを先に移して残りを並行運用するのか、この方針を早い段階で固めることが、逆算スケジュールの精度を左右します。
納期遅延を防ぐための実務ポイント
逆算スケジュールを組んだあとも、実際の進行では想定外のことが起きます。動かせない期限を守るうえで特に欠かせないのは、初期流動の管理と、注文データ移行・並行運用の2つです。
初期流動管理の期間設定と終了基準
本番稼働直後は、テスト環境で検知しきれなかった不具合や、現場担当者の操作の不慣れによる問い合わせが集中しやすい時期です。この期間に特別な対応体制を敷くことを初期流動管理と呼び、一般的には数週間から1ヶ月程度が目安とされています。
OMSの更改では、この期間に在庫引当の反映漏れや、ECモール・WMSとの連携エラーが見つかることが多いです。対応が長引くと、通常の保守フェーズへの移行が遅れ、結果としてプロジェクト全体の締めくくりも後ろにずれます。適切な期間はプロジェクトの規模やシステムの重要度で変わりますが、漫然と長く設定しすぎるのは避けるべきです。
そこで、「重大な障害の発生件数が週に一定件数以下になった時点で終了する」といった定量的な終了基準を、計画の段階で決めておくことが必要です。終了基準を先に決めておけば、初期流動期間がなし崩し的に延びるのを防ぎ、通常の保守・運用体制へ計画どおりに移れます。
注文データ移行・複数チャネル並行運用における遅延リスクへの備え
既存の注文データをどこまで新システムに移すかは、特に見積もりを誤りやすい設計です。過去の注文データをすべて移すと莫大な工数がかかるため、移さない理由を定めたうえで、未出荷（ステータスがオープン）の注文データだけを新システムに移すのが現実的です。出荷完了済み（クローズ）の過去データは、旧システムを参照専用で残すか、別のデータウェアハウスなどに保管します。
この方針を要件定義の早い段階で固めておかないと、移行対象が後工程で際限なく膨らみ、期限に対して致命的な遅れを生みます。また、複数チャネルを扱うOMSでは、新旧システムを並行稼働させて受注件数・出荷数量・請求金額を照合するパラレルランが必要になることが多く、その期間は最低でも2〜4週間程度を確保するのが目安です。
期限から後ろに工程を積み上げた結果、どうしても間に合わないと分かった場合は、早い段階でRFPを見直し、スコープを絞り込みます。たとえば、優先して接続するチャネルを選び直すといった判断が、納期そのものを守るための最終手段になります。
まとめ
OMS更改の開発期間は、保守契約の満了、リース満了、EOS/EOLといった動かせない期限から逆算して組みます。4つの実務期間を合算すると最低でも「半年弱」が必要で、そのうち開発・テスト・データ移行は数ヶ月から1年以上と幅があります。そのため、期限の半年前から1年半前にはプロジェクトを始動させるのが実務上の鉄則です。
EOS/EOLの通知は多くの場合事前に告知されるため、通知を受けた時点で、社内の体制と逆算スケジュールの仮組みに着手します。そのうえで、既存の注文データ移行や複数チャネルの並行運用に潜むリスクを早めに洗い出しておくことが、期限内に確実に更改するための鍵になります。
▼全体ガイドの記事
・OMS更改の完全ガイド
▼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を創業。