OMS改修とは？｜考え方/特徴/仕組み/目的を解説

ECモールや自社ECサイト、卸売取引先からの受注を長年同じOMSで処理してきた企業ほど、「新しく取引を始めたモールの仕様に合わせて受注取込だけ直したい」「出荷指示書のレイアウトを少し変えたい」といった小さな要望を、全面刷新するほどの予算も時間もかけずに解決したい場面に直面します。OMS改修とは、既存のOMSを土台として残したまま、特定チャネルの受注取込ロジックや特定帳票のレイアウトなど範囲を絞った修正を、低予算・短納期で行う取り組みを指します。

本記事では、OMS改修の基本的な考え方と特徴、改修が必要になるサインと規模の見極め方、改修の進め方とスケジュール設計、費用と保守契約の考え方、モックアップ・プロトタイプ・PoCの使い分け、フルスクラッチ・オーダーメイド開発という選択肢を順に解説します。全面刷新はまだ検討段階にないものの、特定の業務だけを直したいと考えている担当者の方が、自社の要望がどの規模の対応に当てはまるかを判断できるよう、実務の流れに沿って整理します。

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

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

OMS改修とは何か？低予算・短納期で行う部分修正という考え方

OMS改修とは何を指すのか、他の対応と何が違うのかを最初に明確にしておくことが、検討をスムーズに進める出発点になります。

OMS(Order Management System)に関わる取り組みには、モダナイゼーション、刷新、更改、リニューアル、リアーキテクチャ、リプレイスなど複数の呼び方があります。モダナイゼーションはクラウド化やAPI化といった技術手法そのものに焦点を当て、刷新は事業上のなぜ・いつという経営判断を起点にし、更改は保守契約の満了やハードウェアのEOS/EOLという外部から強制される期限を起点にします。リニューアルはUI/UXの見直しから、リアーキテクチャはシステムのアーキテクチャそのものの技術的な組み替えから、リプレイスは製品やベンダーの乗り換えから、それぞれ議論が始まります。

これらがいずれもシステム全体、あるいは大きな範囲の作り替えを前提にしているのに対し、OMS改修は既存のOMSをそのまま使い続けることを前提に、特定の箇所だけを直す取り組みです。予算や期間の規模がひとまわり小さく、経営会議で大きな投資判断を仰ぐ前に、現場の担当者が主導して着手できる点も特徴です。

改修が扱う代表的な対象は、特定チャネルの受注取込ロジックの修正と、特定帳票の軽微なレイアウト変更の2つに大きく分かれます。前者は、新しく取引を始めたECモールや卸売取引先からの注文データを、既存のOMSへ正しく取り込めるようにする作業で、外部システムとの通信を伴います。後者は、出荷指示書や納品書といった帳票の項目配置やフォーマットを、現場の運用に合わせて調整する作業で、外部連携を伴わないことがほとんどです。

この2つは見た目こそ似た「改修」という言葉でくくられますが、必要な技術検証の深さも、費用や期間の目安も大きく異なります。自社が直面している課題がどちらに近いかを最初に見極めることが、以降の検討をスムーズに進める鍵になります。

改修が必要になるサインと規模の見極め方

OMS改修を検討し始める際は、まず自社が直面している修正が小規模か中規模かを見極め、対象範囲を具体的な言葉で言い切れる状態にしておくことが重要です。

小規模改修の典型は、特定帳票の軽微なレイアウト変更のように、外部システムとの通信を伴わない修正です。目安となる期間は1〜3ヶ月程度で、現場の担当者が要望を出してから比較的短期間で反映できます。一方、中規模改修は、特定のECモールの受注取込ロジックを修正するなど、外部連携を伴う修正を指し、目安となる期間は4〜8ヶ月程度に伸びます。外部システムとやり取りする分だけ、要件の確認や技術検証に時間がかかるためです。

自社の依頼内容がどちらに近いかを、着手前に社内で共有しておくと、依頼先や検証の深さについての認識違いを防げます。

改修の検討で陥りやすい失敗の一つが、要望を集めているうちに対象範囲がなし崩し的に広がり、気づけば全面刷新に近い規模の作業になっているという状態です。低予算・短納期で進めるためには、対象を「特定チャネルの受注取込ロジックのみ」「特定帳票のレイアウトのみ」のように、最初から言葉で絞り込んでおくことが欠かせません。

現場から寄せられる要望をすべて一度に反映しようとせず、業務への影響が大きい箇所から優先順位をつけ、必須の修正と、次回以降に回してよい修正を分けておくと、見積りや検証の対象がぶれにくくなります。

改修の進め方とスケジュール設計

中規模改修になると外部連携の検証が加わるため、工程ごとの目安を把握したうえで、遅延を防ぐ実務を組み込んでおくことが重要になります。

外部連携を伴う中規模改修では、要件定義・設計に全体の20〜30%程度、開発・実装に40〜50%程度、テスト・修正に20〜30%程度、公開・リリースに残りの一部を充てる進め方が一般的です。要件定義と設計にはそれぞれおおよそ2ヶ月程度、開発・実装には2〜3ヶ月程度、テスト・修正には1〜1.5ヶ月程度、公開・リリースには0.5ヶ月程度を見込んでおくと、全体で4〜8ヶ月という目安に収まりやすくなります。

改修の遅延要因として特に注意すべきなのが、自社だけではコントロールできない外部要因です。連携先のECモールが予告なく仕様を変更する、外部企業側のテスト環境に不具合が生じて回答待ちの時間が発生する、APIのレート制限によって不具合の検証そのものが遅れるといった事態は、日程に一定の余裕を見込んでいても起こり得ます。

納期を守るための実務としては、外部連携に関わるタスクを最優先で着手し、全体スケジュールに10〜20%程度のバッファを確保しておくこと、確認や承認の工程をガントチャート上に明示しておくこと、連携先とのやり取りに迅速に対応できる体制を整えておくこと、そして遅延が発生した場合のリカバリー策(対象機能を絞り込んで先行リリースするなど)をあらかじめ関係者間で合意しておくことが挙げられます。

改修にかかる費用と保守契約の考え方

改修費用は規模によって大きく変わるため、相場観を持ったうえで、保守契約の枠内で対応できる範囲かどうかを見極めることが欠かせません。

改修費用の基本的な考え方は、関わるエンジニアの人数×稼働月数×人月単価です。人月単価の目安はプログラマーで月40万〜100万円程度、システムエンジニアで月80万〜160万円程度とされています。これをもとにすると、小規模改修は数十万〜300万円程度(相場としては30万〜160万円程度、小規模なスクラッチ開発を伴う場合は100万〜300万円程度)、中規模改修は300万〜800万円程度(周辺システムとの連携やデータ移行を伴う場合は500万〜2,000万円程度)が目安になります。改修後にかかる保守費用は、初期の開発費用の15〜20%程度(年額)が一つの目安で、中規模の基幹・業務システムであれば年間300万〜800万円程度(月額25万〜60万円程度)、小規模な社内ツールであれば月額数万〜10万円程度(年額50万〜150万円程度)というレンジで考えられます。

保守契約には、無償で対応してもらえる範囲と、別途見積りが必要になる範囲の境界があります。目安としては、1〜2時間程度で完了する軽微な修正は保守契約の無償枠内で対応されることが多く、数日から1週間程度を要する改修は枠外の追加案件として扱われる傾向があります。この境界を事前に確認しておかないと、想定していなかった追加費用が発生してから気づくことになりかねません。

全面刷新と比較すると、費用と期間の差は明確です。全面刷新は中規模で2,000万〜8,000万円程度、大規模になると8,000万円〜数億円程度かかり、期間も半年から数年単位に及びます。これに対して部分改修は数十万〜数百万円程度、数週間から数ヶ月程度でスモールスタートできる点が、改修という選択肢の実務上の利点です。

コストを管理する実務としては、まず見積りが「一式」とまとめられていないかを確認し、要件定義10〜15%程度、設計20〜25%程度、実装30〜40%程度、テスト20〜30%程度、プロジェクト管理10〜15%程度という工程別の比率に照らして内訳が妥当かを点検します。テストに割かれる比率が10%以下しかない見積りは、検証不足のリスクを抱えている可能性があるため注意が必要です。あわせて、対象範囲を「特定チャネルの受注取込ロジックのみ」のように極小化し、必須の要件と対応できれば良い要件を切り分けること、テストパターンの作成など自社で巻き取れる工数を切り出して外注費を抑えること、SLAを明記したうえで2〜3社から相見積りを取ることも、費用を適正に保つうえで有効です。

なお、こうした改修を場当たり的に繰り返していくと、設計書とソースコードの内容が乖離し、当時の担当者が退職して経緯が分からなくなるといったブラックボックス化が進みます。年間の保守費用が初期の開発費用の20%を大幅に超えてきた場合は、パッチ改修による延命がそろそろ限界に近づいているサインとして受け止め、フルスクラッチでの再構築も選択肢に含めて検討する必要があります。

モックアップ・プロトタイプ・PoCの使い分け

改修の内容によって、事前に行うべき検証の深さは大きく異なります。全面刷新と同じ感覚で検証を設計すると、かえって時間とコストをかけすぎることになります。

全面刷新のPoCが、システム全体や業務プロセス全体を対象に、広い範囲かつ長い期間をかけて実現可能性を検証するのに対し、部分改修における検証は、対象となる1つの機能に範囲を絞り込み、「既存の機能にデグレード(悪化)が生じないか」「現場の使い勝手が悪化しないか」を局所的に確認することが目的になります。検証の設計段階で、この目的の違いを意識しておくことが重要です。

検証の手法は、目的に応じて使い分けます。モックアップは画面のレイアウトを静的に確認する手法、プロトタイプは実際に操作できる試作品で使い勝手を確認する手法、PoCは外部連携など技術的な実現可能性を確認する手法です。特定帳票の軽微な変更であれば、デザインツールで作成したモックアップを現場の担当者に見てもらい、項目やレイアウトを視覚的に確認してもらうだけで十分なことがほとんどです。一方、特定チャネルの受注取込ロジックの修正は外部システムとの通信を伴うため、技術的な検証が必要になります。本番のデータベースを直接使わず、テスト用のダミーデータと、本物の代わりとなる疑似的な代役コンポーネント(モック)を用意し、受注データの送受信を疑似的に行うことで、既存機能への影響を遮断した安全な環境でPoCを実施できます。

期間の目安は2〜8週間程度で、これより長引くと検証にコストをかけすぎる「PoC貧乏」の状態になりやすくなります。モックアップ単体の確認であれば数日から1週間程度で完了します。費用の目安は本開発費用の10〜20%程度、特定機能に絞った検証であれば50万〜300万円程度です。

検証を省略してよいのは、帳票フォーマットの変更や、既存データベース内の単純な計算ロジックの修正など、技術的な不確実性がほとんどない改修です。こうしたケースでは、モックアップやプロトタイプによる現場確認だけで着手して問題ありません。反対に省略してはいけないのは、新しく追加する特定チャネル(外部APIやEDIなど)との連携仕様が複雑で、通信が問題なく行えるという確証がない場合です。ここでの検証を省略して本番実装へ進んでしまうと、重大なデータ不整合や連携エラーといったデグレードを招くリスクが高まります。

フルスクラッチ・オーダーメイド開発という選択肢

改修の対象を切り分けていく過程で、既存のOMSにパッチを当て続けるべきか、対象機能をフルスクラッチで作り直すべきかという判断が必要になる場面があります。

この判断には主に3つの視点があります。1つ目は、対象箇所のブラックボックス度と現行の品質です。安定して稼働している部分はそのまま活かし、スパゲッティ化が進み触ると悪影響が出やすい機能は切り出してフルスクラッチで再構築する対象にします。2つ目は、全モジュールの棚卸しです。既存のまま残せるもの、パッチ改修で済むもの、フルスクラッチで置き換えるべきものの3つに分類し、対象範囲を具体化します。3つ目は、その機能が競争力の源泉かどうかです。自社独自の複雑な受注計算ロジックのように競争優位に直結する部分はオーダーメイドで作り込み、どの企業でも共通する標準的な業務は、既存の仕組みの流用やSaaS・ローコードツールの併用を検討します。

改修の実務でよく採られるのが、既存のOMS本体には手を加えず、外付けの連携プログラムとしてオーダーメイド開発を行う方法です。単一チャネルとのシンプルな受注データ連携を追加する程度の小規模なものであれば、費用の目安は約100万〜300万円、期間は1〜3ヶ月程度です。データ変換ロジックが複雑になったり、複数チャネルを統合したりする中規模な連携・ミニリビルドになると、費用の目安は約300万〜800万円(場合によって〜2,000万円程度)、期間は4〜8ヶ月程度に伸びます。外部連携である以上、相手先の仕様変更やテスト環境の都合によって遅延しやすいため、ここでもバッファの確保が欠かせません。

低予算・短納期を実現するには、対象範囲を絞り込む姿勢が重要です。最も業務負荷が高い1つのチャネルの受注取込だけに絞って開発・リリースし、そこから段階的に対象を広げていくMVP(実用最小限の製品)的な考え方や、必須の要件と対応できればよい要件を切り分けるMust/Wantの整理、そして着手前に現状の業務フローを見える化しておくことが、範囲の膨張を防ぐうえで役立ちます。フルスクラッチを選ぶべきなのは、既存ロジックのブラックボックス化が深刻でパッチ当てがかえって危険な場合や、自社特有の複雑な受注処理・例外ルールが競争優位の源泉になっている場合です。逆に、既存のSaaSやパッケージの標準機能で代替できる場合や、現行仕様がまったく解明されていない状態での見切り発車は避けるべきケースとして扱います。委託先を比較する際の評価軸は、OMS改修の選定ポイント・選び方・種類で整理しています。

OMS改修に着手する前に確認しておきたいポイント

改修の対象範囲や依頼先がおおよそ固まった段階でも、着手前に確認しておくと後戻りを防げる論点がいくつかあります。

見積書が「一式」とだけ記載され、工程ごとの内訳が示されていない場合は、要件定義、設計、実装、テスト、プロジェクト管理といった項目に分解してもらうよう依頼します。とくにテストに割かれる比率が極端に低い見積りは、検証不足のまま進んでしまうリスクがあるため、内訳を確認したうえで判断することが大切です。

現在契約している保守ベンダーに、今回の改修が無償の保守枠内で対応できるのか、それとも別途の見積りが必要な追加案件になるのかを、着手前に確認します。1〜2時間程度で終わる軽微な修正か、数日から1週間程度かかる改修かという時間の目安を一つの判断材料にすると、認識のすり合わせがしやすくなります。

今回の改修が、これまでのパッチ改修の延長線上にあるものなのか、あらためて現行のブラックボックス度を確認しておきます。年間の保守費用が初期開発費用の20%を大幅に超えている、あるいは設計書と実際のソースコードの内容が食い違っているといった兆候がある場合は、今回の改修と合わせて、将来的なフルスクラッチでの再構築も視野に入れておくと、次に同じ課題に直面したときの選択肢が広がります。

今回の改修が、技術的な不確実性がほとんどない軽微な変更なのか、外部連携の仕様が複雑で通信の確証がない変更なのかを、あらためて切り分けます。後者に該当する場合は、モックアップの確認だけで済ませず、テスト用のダミーデータとモックを使ったPoCを実施し、既存機能へのデグレードがないことを確認してから本番実装に進むようにします。

まとめ

OMS改修は、既存のOMSを活かしながら、限られた範囲を低予算・短納期で直していく現実的な選択肢です。

OMS改修は、モダナイゼーションや刷新、更改、リニューアル、リアーキテクチャ、リプレイスといった全面的な取り組みとは異なり、特定チャネルの受注取込ロジックや特定帳票のレイアウトなど、範囲を絞った修正を指します。小規模なら1〜3ヶ月・数十万〜300万円程度、中規模でも4〜8ヶ月・300万〜800万円程度が目安になり、全面刷新に比べて着手のハードルが低い点が特徴です。

まず自社の要望が小規模改修と中規模改修のどちらに近いかを見極め、対象範囲を具体的な言葉で絞り込んだうえで、保守契約の枠内で対応できるのか、外部への追加発注が必要なのかを確認することから始めてください。既存のOMSに大きな手を入れず、外付けの連携プログラムとして低予算で改修したい場合や、パッチ改修の繰り返しでブラックボックス化が進み、対象箇所をフルスクラッチで作り直したい場合、riplaはフルスクラッチ開発の立場から、既存システムを活かした部分改修と、独自要件に応じた個別開発の両面から支援しています。

▼全体ガイドの記事
・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を創業。