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

OMS改修とは、ECモール・自社EC・実店舗POS・卸売取引先といった複数の販売チャネルから発生する受注情報を一元管理してきたOMSを対象に、システム全体を作り替えるのではなく、特定チャネルの受注取込ロジック修正や特定帳票（出荷指示書・納品書等）の軽微なレイアウト変更といった、限られた範囲・限られた予算の中で行う部分的な修正を指します。ここで押さえておきたいのは、同じ「OMSを作り替える」というテーマでも、参照すべき記事によって前提がまったく異なるという点です。「OMSのモダナイゼーション」が5つの技術的アプローチ（HOW）を、「OMS刷新」が経営判断（WHY/WHEN）を、「OMS更改」が契約満了・EOS/EOLという外圧型トリガーを、「OMSのリニューアル」がUX/UI起点を、「OMSのリアーキテクチャ」がアーキテクチャ設計の技術深掘りを、「OMSリプレイス」が製品・ベンダーの乗り換え判断（ビルド・バイ）を、それぞれ主軸に据えているのに対し、本記事はそのいずれでもなく、「システム全体には手を付けず、特定チャネル・特定帳票だけを低予算・短納期で直す」という部分改修の切り口に軸足を置いて開発期間・スケジュール・納期を解説します。

本記事では、OMS改修の開発期間・スケジュール・納期について、他6波との位置づけの違いから、小規模改修（特定帳票の軽微なレイアウト変更等）と中規模改修（特定チャネルの受注取込ロジック修正等）の期間の違い、それぞれの工程別の期間配分、外部ECモールAPIへの依存が生む遅延リスクとバッファ設計、そして低予算・短納期のまま納期を守るための実務ポイントまでを体系的に解説します。全面刷新に踏み切る予算も時間もないが、目の前の受注業務の課題は早急に解消したいという情報システム部門・EC運営部門の方に向けて、現実的なスケジュール感を持ち帰っていただける内容です。

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

▼全体ガイドの記事
・OMS改修の完全ガイド

OMS改修とは何か（部分改修という選択肢の位置づけ）

OMS改修を検討する企業の多くは、OMS全体が老朽化しているわけではなく、「特定のECモールとの受注取込だけが古い連携方式のまま」「特定の帳票フォーマットだけが現場の運用実態に合っていない」といった、局所的な課題を抱えています。全面刷新やモダナイゼーションのように現状アセスメントから並行稼働までを含む数ヶ月〜数年規模のプロジェクトを組む余力がない事業者や、OMS本体には大きな不満がなく一部の連携機能・出力機能だけを直したい事業者にとって、部分改修は現実的かつ有効な選択肢です。建築の「改修（リノベーション）」が建物全体を解体せず一部の設備・間取りだけを直すのと同じように、OMSの改修も既存の骨格（受注受付〜在庫引当〜出荷指示という基本フロー）を維持したまま、対象範囲を絞り込むことが最大の特徴です。

モダナイゼーション・刷新・更改・リニューアル・リアーキテクチャ・リプレイスは、いずれもOMS全体（あるいは基幹となる受注ロジック全体）を対象にした作り替えであり、規模も期間も大きくなることが前提です。これに対しOMS改修は、対象範囲をあらかじめ「この受注取込ロジックだけ」「この帳票だけ」に絞り込むことで、開発期間・予算ともに他6波よりも一段小さいスケールに収めることを目指します。全面刷新に踏み切るほどの経営判断や稟議承認プロセスを経る必要がなく、部門内の決裁だけで着手できるケースも多いのが、開発期間の見積もり方が根本的に異なる理由です。

改修が「部分改修」の範囲に収まるかどうかを判断する最大の基準は、OMSの根幹である在庫引当ロジックや受注受付〜出荷指示という業務フロー全体に変更を加える必要があるかどうかです。既存の出荷指示画面に新しい帳票フォーマットを追加する、特定帳票の表示項目を差し替えるといった作業は、特定の出力機能のみの追加開発であり部分改修に収まります。一方、特定ECモールの受注取込ロジック修正であっても、既存のOMS本体やデータベースには一切手を加えず、外部モールとの間でデータ形式を変換する連携プログラムを外付けで追加開発するだけであれば部分改修に収まりますが、在庫引当ロジックそのものの変更やマスタデータ構造の根本変更を伴う場合は中規模改修へと発展してしまう点に注意が必要です。

開発期間の全体像（小規模改修と中規模改修の期間差）

OMS改修は、対象機能の規模によって開発期間が大きく異なります。要件定義や設計がシンプルでテスト工程も少ない小規模な改修と、外部ECモールとの通信・データ連携を伴うために要件定義や設計が複雑化する中規模な改修とで、期間感がおよそ倍以上変わってくるのが実務上の目安です。全面刷新のように現状アセスメントから並行稼働までを含む数ヶ月〜数年規模のスケジュールとは異なり、改修はこの2区分の中で完結する短期プロジェクトとして計画できる点が特徴です。

出荷指示書・納品書・ピッキングリストといった特定帳票のレイアウト変更や、既存画面への表示項目追加といった単機能の修正は、要件定義・設計がシンプルでテスト工程も少ないため、目安として1〜3ヶ月程度で完結します。既存の注文データをそのまま出力・フォーマット調整するだけであれば、在庫引当ロジックの根幹に手を加える必要がなく、影響範囲を特定の出力機能だけに限定できるため、短納期で対応可能です。ただし、帳票を出力するために受注データベースのテーブルへ新しい項目を大量に追加・変更しなければならない場合は、他の機能すべてに影響が及ぶため、この目安期間を超える可能性がある点は留意が必要です。

特定ECモールや新規卸売取引先の受注取込ロジック修正のように、外部システムとの通信やデータ連携を伴う改修は、要件定義や設計が複雑化し結合テストの工程も増えるため、目安として4〜8ヶ月程度を見込む必要があります。既存のOMS本体やデータベースに一切手を加えず、連携プログラム（グルーコードやAPI）のみを外付けで追加開発する形に留められれば、既存の在庫引当ロジックへの影響を最小限に抑えたまま対応できます。ただし、この連携追加によって在庫の引当タイミングが変わったり、保持すべきマスタデータ構造を根本から見直す必要が出てきたりする場合は、複数チャネルの業務見直しを伴う中規模改修の領域に踏み込むため、事前のスコープ確認が期間見積もりの精度を大きく左右します。

特定帳票改修のスケジュール（要件定義〜リリースの工程別期間配分）

特定帳票の改修は、OMS改修の中でも最も取り組みやすいテーマの一つです。対象範囲が明確で、影響範囲を特定の出力機能に絞り込みやすいため、工程ごとの期間配分もシンプルに組み立てられます。

帳票改修における要件定義では、現行帳票のどの項目を変更・追加するか、出力先（PDF・CSV・特定様式の紙帳票等）の仕様、既存の出荷業務フローとの整合性を確認します。この工程は通常1〜2週間程度で完了しますが、対象帳票がWMSや会計システムなど複数システムと連携している場合は、確認先が増えるため2〜3週間に伸びることもあります。設計では画面上の項目配置や出力ロジックを固める外部設計・内部設計を行い、こちらもおおむね1〜2週間程度で完了するのが一般的です。上流工程を丁寧に固めておくことで、後続の開発・テスト工程での手戻りを防ぐことができます。

設計書に基づく開発・実装は、単一帳票の改修であればおおむね2〜4週間で完了します。その後、単体テスト・結合テストで想定通りに帳票が出力されるかを確認し、既存の出荷業務への影響がないかを運用テストで検証する工程に1〜2週間程度を要します。最後の公開・リリースは、既存の受注処理ロジックへの影響が限定的であるため数日〜1週間程度で完了するのが一般的です。全体を通して見ると、要件定義から本番リリースまでを1〜3ヶ月で完結させられるのが、特定帳票改修という小規模改修ならではのスピード感です。

特定チャネル受注取込ロジック修正のスケジュール（外部依存が生む遅延リスク）

特定チャネルの受注取込ロジック修正は、OMS改修の中でも唯一「自社だけの都合ではコントロールできない」要素を含むテーマです。連携先のECモール・取引先の対応スピードや仕様次第で、当初の想定よりもスケジュールが延びるリスクを常に織り込んでおく必要があります。

ECモールのAPIや取引先とのEDIに接続する工程は、改修プロジェクトの中で最も遅延リスクが高い領域です。連携先モール側のAPI仕様変更、相手側テスト環境の不具合、問い合わせに対する返答待ち、APIのレート制限（アクセス回数制限）による不具合検証の遅れなど、自社（開発会社）だけではコントロールできない調整が多く発生するため、想像以上に時間がかかることがあります。実装フェーズでは外部API連携処理にさらに1〜2ヶ月程度の追加期間を要することもあるため、外部連携を含む改修では、外部との調整（テスト環境の準備等）を最優先で着手し、テスト期間に10〜20%程度のバッファを持たせたスケジュールを組むことが納期を守るための鍵となります。

OMSは在庫管理・出荷指示・請求など他業務と複雑に連動しているため、特定チャネルの受注取込ロジック修正という部分改修のつもりでも影響範囲が膨張しやすい性質があります。低予算・短納期で改修を終えるためには、既存のOMS本体やデータベースには一切手を加えず、外部とのデータ形式変換を担う連携プログラムのみを外付けで追加開発するという制約を設けることが重要です。「ついでに在庫引当ロジックも見直したい」「他のモールにも汎用的に使えるようにしたい」といった要望を同時に詰め込むと、一気にスケジュールが膨張するため、まずは特定の1チャネルとの必須連携に絞り込んでスモールスタートすることが、期間を4〜8ヶ月の目安に収める実務上のコツです。

納期を守るためのポイント（低予算・短納期を実現する進め方）

部分改修は全面刷新に比べて期間・予算とも小さいものの、だからこそ計画段階でのちょっとした甘さがスケジュール遅延に直結しやすいという側面があります。限られた期間の中で納期を守るためには、以下のポイントを押さえておく必要があります。

「どのチャネルのどの項目をどう連携するか」「どの項目を帳票に追加するか」といった要件が曖昧なまま開発に進むと、後工程で認識のズレが発覚したり、頻繁に仕様変更が発生したりして、大幅な手戻り（スケジュールの延長）を引き起こします。部分改修は工程全体が短いため、1回の手戻りが全体スケジュールに占める割合が全面刷新よりも大きくなりやすい点に注意が必要です。着手前に、対象範囲・対象外とする項目（Won’t）・完了の定義を1枚の合意文書にまとめておくことで、限られた期間の中でも手戻りのリスクを最小化できます。

開発途中での仕様に関する質問への回答や、提出された設計書などの確認・承認作業に日数を要すると、その分だけ開発作業全体がストップし、スケジュールが後ろ倒しになります。EC事業部門・カスタマーサポート・IT部門の間で連絡頻度が少ない、情報を共有する仕組みがないなどコミュニケーションが不足していると、仕様解釈のズレに気づけず、結果としてやり直しが発生して納期が遅延します。部分改修のような短期プロジェクトでは、週1回など高頻度の進捗確認の場を設け、確認事項への回答期限をあらかじめ2〜3営業日以内と決めておくことが、限られた期間の中で納期を守る実務上のコツです。

まとめ

本記事では、OMS改修の開発期間・スケジュール・納期について、全面刷新を前提とした他6波との位置づけの違いから、小規模改修（1〜3ヶ月）と中規模改修（4〜8ヶ月）の期間差、特定帳票改修・特定チャネル受注取込ロジック修正それぞれの工程別スケジュール、外部依存が生む遅延リスクとバッファ設計、そして納期を守るための実務ポイントまでを解説しました。改修はOMS全体を作り替えるのではなく、対象範囲を明確に絞り込むことで低予算・短納期を実現できる選択肢です。特に受注取込ロジック修正では外部モール都合による遅延リスクを見込んだバッファ設定が、帳票改修では要件の早期確定が、それぞれ納期を守る鍵になります。全面刷新に踏み切る前にまず部分改修で課題を解消したいという方は、小規模案件に強みを持つパートナーへ早めに相談することをお勧めします。

▼全体ガイドの記事
・OMS改修の完全ガイド

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