OMS開発の開発期間・スケジュール・納期について

OMS開発の期間は、対象チャネル数、在庫引当ロジックの複雑さ、既存システムとの連携範囲で決まり、1〜2か月から6か月〜1年以上まで幅があります。

OMSは受注受付・在庫引当・出荷指示に特化した専用システムです。EDI(電子データ交換)は、企業間で受発注データをやり取りする通信規格・連携の仕組みです。BtoBシステムは、見積・与信管理・取引先ポータルを含む業務基盤全体を指します。OMSは、これらとは観点が異なります。

ECモールへの出店や、実店舗と通販を横断するオムニチャネル戦略を取る企業が増えています。複数チャネルの在庫と受注をまとめたいと考える企業も多くなっています。複数チャネルの受注一元管理を検討する方や、社内で日程を策定する方にとって、現実的な計画を立てる判断軸になる内容です。

▼全体ガイドの記事
・OMS開発の完全ガイド

OMS開発の開発期間の全体像

汎用機能だけを使うクラウド型・ASPなら、小規模版は約1〜2か月が目安です。一方で、追加カスタマイズを行う中規模版は3〜6か月、基幹システムやWMSとの統合、またはフルスクラッチを伴う大規模版は6か月〜1年以上が目安です。

期間を左右する主因は、画面数よりも接続チャネル数と在庫引当設計の難易度です。既存システムとの連携度合いも期間に影響します。さらに、ECモール、自社EC、実店舗POS、卸売取引先のうち、どのチャネルをどの同期方式でつなぐかによって、同じ中規模導入でも期間は変わります。

費用相場も規模によって異なります。クラウド型の小規模版は、初期費用0〜10万円、月額費用1〜5万円が目安です。中規模版は初期費用10〜50万円、月額費用5〜15万円で、大規模版は初期費用50〜200万円、月額費用15〜30万円以上です。

オンプレミス型やフルスクラッチ開発は、初期費用300万〜1,000万円以上、年間保守費用50万〜200万円が目安です。さらに、追加カスタマイズ費用も100万円から発生します。

小規模導入でも旧システムとの並行運用期間が必要になるため、実務では合計3〜6か月を見込んでおくのが現実的です。

規模別の開発期間と費用の目安

規模ごとの標準的な工程配分は、導入方式によって変わります。

  • 小規模:要件定義・選定に2週間、契約・初期設定に1週間、移行・テストに2週間、研修・周知に2週間。
  • 中規模:要件定義・選定に1か月、契約・要件確定に1か月、開発・初期設定に2〜3か月。
  • 大規模:要件定義・選定に2〜3か月、契約・仕様設計に2〜3か月、開発に3〜6か月。

小規模版はクラウド型で汎用機能だけを使い、研修を終えるとすぐに本稼働へ移るのが標準的です。

中規模版はパッケージをベースに、追加カスタマイズを加える形です。また、データ移行と結合テストに2週間、社内研修と周知に1か月をかけます。並行運用から本稼働開始までは、さらに1〜3か月を確保します。

大規模版は、基幹・WMS統合またはフルスクラッチで、高度な分配ロジックや複数システムの統合連携を含みます。そのため、移行・結合テストと研修・周知には、それぞれ1〜2か月かかると考えておきます。段階的な並行稼働から本稼働開始までは、3か月以上が必要です。

開発期間を左右するOMS特有の要因

期間を延ばしやすい要因は、同期方式、商品マスタの統合、例外業務の組み込みです。なかでも、在庫引当と同期ロジックの設計は、開発期間を最も左右します。

  • 一方向同期:基幹システムを正として、各チャネルへ在庫を配信する方式。
  • 双方向同期:各チャネルの在庫変動を全体へ反映し、競合の解決が必要な方式。
  • 商品マスタ統合:チャネルごとに異なる商品コードやバリエーションをそろえること。

双方向同期では、複数チャネルで同時に売れた場合の競合(コンフリクト)について、解決ルールの設計とテストが必要です。そのため、一方向同期と比べて開発コストと期間が大きく増えます。

商品マスタ(SKU)の統合では、同じ商品でも商品コードやバリエーションの登録ルールが異なると、在庫を正しく合算・引当できません。品目点数が多い場合は、商品マスタのクレンジングに2〜3か月程度を確保しておきます。

標準業務は「受注受付→在庫引当→出荷指示」の流れです。ただし、分割出荷(スプリット)、セット商品の在庫分解、同梱処理をどこまで扱うかで、WMSへの出荷指示連携を含むテスト工数が変わります。

ポイント

期間と費用は、導入方式と連携範囲で大きく変わります。判断の目安は、汎用機能だけで足りるか、追加開発や基幹・WMSとの統合が必要かです。

要件定義から本稼働までの工程別スケジュール

中規模OMS導入の要件定義、開発・接続、結合テストから本稼働までの工程と期間を示す図。
後半のテストと並行運用にも、まとまった期間を見込む構成です。

期間を見積もるには、工程ごとに必要な時間を把握しておく必要があります。たとえば、総期間約5〜6か月の中規模導入では、作業を次の3つの段階に分け、順に進めます。

  • 要件定義・在庫引当設計:後工程に影響する設計を確定させる段階。
  • 開発・チャネル接続:在庫引当エンジンを作り、各システムと接続する段階。
  • 結合テスト・並行運用・本稼働:複数チャネルの接続テストから本稼働まで。

OMSでは、要件定義の段階で在庫引当方式を決め、後半の複数チャネル接続テストに十分な時間を配分する必要があります。特に、上流の仕様確定を急ぐと、終盤にチャネルごとの食い違いが見つかり、大きな手戻りにつながります。

要件定義・在庫引当ロジック設計フェーズ(1〜1.5ヶ月)

このフェーズには、プロジェクト全体のうち1〜1.5か月程度を充てます。後工程への影響が大きい設計項目は、この段階で確定させます。

  • チャネル:対象とする販売先と、その優先順位。
  • 同期方式:在庫を一方向と双方向のどちらで同期するか。
  • 引当順位:先入れ先出しにするか、特定チャネルを優先するか。
  • 在庫の扱い:複数倉庫の引当ロジックと、予約在庫をどう持つか。

基幹・WMSとの連携範囲や、商品・取引先マスタの統合ルールも洗い出しておきます。後から一方向同期を双方向同期へ変えると、設計と開発をやり直すことになり、全体の日程に響きます。

要件定義書と在庫引当ロジック設計書を文書にしておくと、後続フェーズでの手戻りを防げます。

開発・複数チャネル接続フェーズ(2〜3ヶ月)

この工程は全体の中でも比重が大きく、中規模案件では2〜3か月が目安です。次に、設計が終わったら在庫引当エンジンを作り、各システムとの接続や例外処理を実装していきます。

  • 在庫引当:決めた同期方式に基づいて動くエンジン。
  • チャネル接続:ECモール、自社EC、実店舗POS、卸売取引先の各API。
  • 出荷・例外処理:WMS連携、分割出荷、セット商品の在庫分解。

期間を縮めるには、各モールのAPI仕様変更の頻度や、実店舗POSがオフラインになったときの挙動を早い段階で確かめておくことが有効です。そのうえで、仕様を共通化できる部分と個別対応が必要な部分を分けます。社内テストでは、まず基幹システムやWMSとの連携を確認し、不具合を解消してから複数チャネルの接続テストへ進みます。

結合テスト・並行運用・本稼働フェーズ(1.5〜4ヶ月)

このフェーズは1.5〜4か月が目安で、テスト、並行運用、本稼働の順に進みます。

  1. 結合テスト:期間は2週間〜1か月。
  2. 並行運用:中規模は1〜3か月、大規模は3か月以上を確保します。新旧システムの受注件数と出荷数量を毎日照合し、データの不整合を解消します。
  3. 本稼働:業務量が少なく、リスクの低いチャネルから順に切り替えます。

結合テストでは、受注受付から出荷指示までの基本フローを確認したうえで、例外的な処理も検証します。たとえば、一部キャンセル、セット商品の在庫分解、複数倉庫への分割出荷が挙げられます。業務シナリオのテスト完了率は100%を目指します。

全チャネルを一斉に移行することは避けます。システムの完成日と、複数チャネルの受注が実運用で正しく回り始める日は別々です。そのため、並行運用を日程に含めることが、納期を守る鍵になります。

ポイント

工程の期間は、要件定義で在庫引当方式を決められるか、後半の接続テストと並行運用に時間を残せるかで決まります。上流の仕様を急いで決めると、終盤の手戻りが大きくなります。

複数チャネル統合が納期に与える影響

一方向同期の設計・テストの簡便さと、双方向同期の複雑さを並べて示す図。
同期範囲を広げるほど、競合への対応も設計に含まれます。

EDIでは、取引先ごとの通信手順にどう対応するかが期間を左右します。一方、OMSのECモール、自社EC、実店舗POSは標準APIが多く、個別の調整費用は通常かかりません。

納期のリスクは、チャネルの接続・移行順と在庫同期方式の選び方にあります。ここで判断を誤ると、開発が終わったあとも本稼働までに想定以上の時間がかかります。

段階的カットオーバー(フェーズドカットオーバー)による接続順序設計

複数チャネルを一度に新システムへつなぐ一斉移行は、不具合が起きたときのリスクが高まるため避けます。そこで、「業務量が少ない」「リスクが低い」「テストが完了している」の3条件を満たすチャネルから、段階的に接続します。

  1. 取扱品目カテゴリが限られる小規模モールから連携を始めます。
  2. 運用の負荷とエラー率の見極め。
  3. 業務量が最も多い主力モールや実店舗POSは、最後の段階で統合します。

主力チャネルから着手すると、不具合が起きたときに影響範囲が広がり、全体の納期に響きます。

在庫同期方式(一方向/双方向)の選択が開発期間に与える影響

同期方式によって開発期間が変わるため、業務要件と負担を踏まえて選ぶ必要があります。

  • 一方向同期:基幹システムの在庫を正とし、各チャネルへ配信する形。
  • 双方向同期:店舗や各ECの在庫変動を、リアルタイムに全体へ反映する形。

一方向同期は設計やテストが比較的簡単で、不具合のリスクも低く、導入しやすい方式です。一方、双方向同期は同時販売時の競合解決やデッドロック対策が必要で、処理が複雑になります。

多店舗展開や実店舗との在庫共有を重視する企業ほど、双方向同期を選びたくなる場面があります。ただし、開発期間とコストを押し上げるため、どこまで双方向にするかを見極めることが、現実的な納期につながります。

ポイント

接続は一斉移行を避け、影響の小さいチャネルから段階的に進めます。在庫同期は一方向と双方向のどちらを選ぶかで開発期間が大きく変わるため、必要な範囲に絞って選ぶのが現実的です。

納期を短縮する具体的な方法

マスタデータの前倒し整理、実データによる先行検証、小規模チャネルからの開始を示すチェックリスト図。
データ整備と対象範囲の絞り込みが、開発後の手戻りを抑えます。

開発チームを増員しても、OMSの納期が縮むとは限りません。むしろ、導入完了までの期間を左右するのは、マスタデータの整備状況と検証範囲の絞り込みです。品質と現場への適合を保ったまま導入期間を縮めるには、準備の前倒しと小さな開始が効果的です。

マスタデータクレンジングの前倒し着手

商品マスタ・取引先マスタのクレンジングは、要件定義の前に社内で進めておきます。整理せずに開発を始めると、テスト時に紐付けエラーが多発し、納期遅延の原因になります。

  • 表記揺れ:「株式会社」と「(株)」などの違い。
  • 重複登録:同じ商品が二重に登録されている状態。
  • コード不一致:チャネルごとに異なる商品コード体系。

品目点数が多い場合は、クレンジングだけで2〜3か月かかることもあります。そのため、開発会社へ発注する前、または要件定義と並行して始めると、開発以降の日程を圧縮できます。

クラウド型OMSの無料トライアル活用によるスモールスタート

クラウド型OMSの無料トライアルを起点に、実データを投入して先行検証する進め方があります。

  1. 2週間〜1か月程度の無料トライアル期間を、検証の場として活用。
  2. 立ち上げ対象は、受注件数が少ない小規模チャネル。
  3. 運用が定着してから、他チャネルや独自の在庫引当ロジックへ段階的に広げます。

全チャネル・全機能をいきなりフルスクラッチで作ると、要件が膨らみ、意思決定にも時間がかかります。一方で、小さく始めれば、コア機能を数週間〜1か月程度で立ち上げられ、投資対効果を早い段階で確かめられます。

ポイント

納期を縮めるには、マスタデータの整理を前倒しし、無料トライアルで小さく検証するのが効果的です。人員を増やすよりも、データの整備状況と検証範囲の絞り込みを優先して判断します。

納期遅延の典型要因と対策

綿密に計画を立てても、OMS開発の納期遅延リスクをゼロにはできません。だからこそ、典型的な要因を把握し、対策を契約や進捗管理の仕組みに組み込んでおきます。また、OMS特有の要因は、例外的な受注業務の洗い出し不足と、切り戻し基準が決まっていないことです。

イレギュラー受注業務の洗い出し不足

最も多い遅延要因は、現場に根付いた例外的な受注業務を洗い出せていないことです。これを怠ると、結合テストの終盤になって要件が表面化します。

  • 分割出荷:予約商品と通常商品を同時購入した場合。
  • セット商品:構成品ごとに在庫を分解する場合。
  • 注文処理:同梱、一部キャンセル、割引クーポンの端数処理。

後から要件を加えると、当初の範囲を超える追加開発になり、納期を圧迫します(スコープクリープ)。そこで、要件定義の時点で現場担当者に十分ヒアリングします。さらに、例外業務シナリオのテスト完了率100%を、受入テストの必須の判定基準にします。

ロールバック基準未定義によるトラブル長期化

カットオーバー直後に致命的なエラーが起きたときに備え、どの状態で旧システムへ切り戻すかを、定量的な撤退ラインとして事前に決めておきます。基準が曖昧なまま本稼働すると、トラブルが起きたときの判断が遅れ、業務停止が長引きます。

開発会社と事前に合意し、ロールバックを発動する基準を文書にしておきます。基準の例を挙げると、次のようになります。

  • API連携:本稼働から72時間以内に、3時間以上、全チャネルの受注データの自動取り込みが停止する場合。
  • 出荷指示:WMSへのデータが文字化けし、倉庫の出荷ラインが完全停止。
  • 在庫同期:競合により複数チャネルで売り越し(二重販売)が多発。

想定外の事態に備えて、全体工数の10〜20%程度をバッファとして確保しておきます。

ポイント

納期遅延を防げるかは、例外的な受注業務を要件定義で洗い出せているかと、切り戻しの基準を事前に決めてあるかで分かれます。どちらも開発が始まってからでは決めにくいため、契約前に開発会社と合意しておくのが現実的です。

まとめ

ここまで、OMS開発の期間、工程配分、複数チャネル統合の影響、納期短縮策、遅延要因と対策を見てきました。

期間の目安は、小規模なクラウド型で1〜2か月、中規模のパッケージとカスタマイズで3〜6か月、大規模な基幹統合やフルスクラッチで6か月〜1年以上です。

費用は、クラウド型が初期0〜200万円、月額1〜30万円以上が目安です。オンプレミス・フルスクラッチは、初期300万〜1,000万円以上、年間保守50万〜200万円が目安です。

納期を左右するのは、取引先ごとの通信手順の調整より、在庫同期方式とチャネル統合の順序です。開発が終わったあとも本稼働までに時間がかかることがあるため、並行運用も含めて現実的な日程を組みます。

遅延の典型要因は、例外業務の洗い出し不足と切り戻し基準の未定義です。対策の柱は、要件定義を徹底することと、全体工数の10〜20%を確保することです。

まずは販売チャネル数と在庫引当の要件を整理し、OMS構築の実績がある複数の開発会社に見積もりを依頼しましょう。

▼全体ガイドの記事
・OMS開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。