OMS改修の発注/外注/依頼/委託方法について

OMS（受注管理システム）の改修を検討する段階になると、多くの企業がまず突き当たるのが「自社だけで進めるのは無理がある。どこに、どうやって発注すればよいのか」という壁です。OMSはECモールや自社カート、実店舗POSからの注文を集約し、在庫の引き当てから出荷指示、決済・基幹システムへの連携までを担う、通販・物流オペレーションの心臓部にあたります。ここを改修するということは、売上に直結する受注の流れに手を入れるということであり、発注・外注のやり方そのものがプロジェクトの成否を大きく左右します。

この記事では、OMS改修を外注・委託する際に押さえるべき実務を、発注前の準備からRFP（提案依頼書）の書き方、契約・撤退条項の確認、外注先との役割分担、そしてよくある失敗の回避策まで体系的に解説します。特に「過去データをあえて全部移行しない判断」「在庫の一方向同期と双方向同期の選び方」「取引先を巻き込むEDI切替の空白リスク」といった、製品比較の記事ではあまり語られない泥臭い論点を、具体的な数字とともに掘り下げます。これから発注先を選ぶEC運営の責任者や情シス担当の方が、丸投げによる失敗を避け、適切なパートナーへ過不足なく委託できる状態を目指せる内容です。

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

OMS改修を外注する前に整理すべきこと

発注で失敗する企業の多くは、自社の要件が固まらないまま「とりあえず話を聞かせてほしい」とベンダーに声をかけてしまいます。OMSは受注・在庫・出荷・決済という現場オペレーションと密接に結びついているため、自社の業務を言語化しないまま外注すると、提案がかみ合わず、契約後に「思っていたものと違う」という事態を招きます。発注の前段階でどこまで整理できているかが、その後のRFPの精度と見積もりの妥当性を決めます。改修は新規導入と違い「どこまで直し、どこは残すのか」というスコープの線引きが特に重要になります。

外注前にまず行うべきは、自社が新しいOMSに求める機能を「必須要件（Must）」と「希望要件（Want）」に明確に切り分ける作業です。すべての要望を必須として伝えると、ベンダーは安全をみてカスタマイズ費用を積み上げ、見積もりが膨らみます。逆に切り分けが曖昧だと、後から「これも必要だった」と追加開発が発生し、当初予算を大きく超過します。改修の場合は、既存システムのどの部分を活かし、どこをモダナイズするのかというスコープ自体を、この段階で決めておく必要があります。

実務では、Fit to Standard（標準機能に業務を合わせる）の発想で、SaaSやパッケージの標準機能でカバーできるものは希望要件に寄せ、自社の競争力に直結する独自オペレーションだけを必須要件として残すのが定石です。たとえば多販路展開なら在庫の一元管理とモール連携、定期通販ならサブスク課金や同梱ロジックといった事業特有の要件は必須に置き、画面の細かな見た目の好みは希望に分類します。この線引きができていると、ベンダー比較の際に「どこまで標準でカバーできるか」という同じ土俵で各社を公平に評価できます。OMS改修では、ここで欲張りすぎないことが、結果的に費用対効果の高い改修につながります。

OMS改修で在庫が合わなくなる最大の原因は、現場が「良かれと思って」行っている例外処理がシステムに反映されないことです。特定の優良顧客にだけ適用する個別値引き、在庫が揃わない場合の一部出荷（分割出荷）、複数商品をまとめたセット商品の在庫分解といった処理は、担当者の頭の中だけにある「職人芸」になっていることが少なくありません。こうした暗黙のルールが言語化されないまま改修に入ると、要件定義で漏れ、稼働後に受注が正しく紐づかず出荷が止まります。

発注前に、現場でどのような例外処理が日常的に発生しているかを棚卸しし、ドキュメント化しておくことが重要です。ここで合わせて検討したいのが「機能を見送る勇気」です。文書化されていない例外ルールをすべてシステムに載せようとすると、カスタマイズ費が膨張し、将来のアップデートも困難になります。今回はあえて捨てる機能を決め、運用フローでカバーするという線引きを発注側が主体的に行うことで、改修費を現実的な水準に抑えられます。ベテラン担当者にヒアリングして「正規フローから外れる作業」を洗い出しておくことが、後述するRFPの質を決定的に高める準備になります。

OMS改修の発注先の種類と選び方

OMSの外注先には、提供形態によって大きく異なるタイプがあります。どの形態を選ぶかで、初期費用・カスタマイズの自由度・運用後のコスト構造がまったく変わるため、自社の要件と照らし合わせて選定する必要があります。発注先のタイプを理解しないまま見積もりだけを比較すると、安く見えた選択肢が中長期で割高になるといった判断ミスを招きます。

クラウド型（SaaS）は初期費用を抑えて数ヶ月で稼働でき、標準機能で運用したい企業に向きます。一方で注文件数に応じた従量課金が積み上がるため、受注件数が多い大規模事業者では中長期のコストに注意が必要です。パッケージ型は自社環境に合わせてある程度のカスタマイズが可能ですが、年間保守費として初期構築費の15〜20%が固定的に発生します。改修の場合、既存パッケージのバージョンアップで対応できるのか、別製品への載せ替えが必要なのかを見極めることが、費用を大きく左右します。

フルスクラッチ型は自社の業務に100%フィットさせられる反面、従来は開発期間が半年から1年以上、費用も高額になりやすいのが難点でした。ここで近年注目されているのがAI駆動開発です。AIを活用した開発手法により、工期とコストを従来比で30〜70%圧縮できるケースが出てきており、「パッケージ並みの予算で自社に100%フィットしたシステムを作る」という新しい選択肢が現実的になっています。OMSのように事業ごとの差が大きいシステムでは、こうした開発手法に対応できる発注先かどうかも評価軸に加えると、選択の幅が広がります。

提案書はどの会社のものも一見すると良く見えます。重要なのは、その会社がEC・物流現場のリアルを理解しているかと、技術的な開発力を本当に持っているかを見抜くことです。EC・物流ノウハウの有無は、在庫の同時更新コンフリクトやモール仕様変更への追従、繁忙期の処理負荷といった現場特有の論点について、こちらが聞く前に踏み込んだ質問をしてくるかどうかで判断できます。表面的な機能説明に終始するベンダーは、稼働後の運用で苦労する可能性が高いと言えます。

開発力については、同業種・同規模のOMS改修実績を具体的に確認し、可能であれば導入企業へのヒアリングや稼働中の画面デモを依頼します。特にECモールや自社カート、WMS、ERP・会計、決済サービスとのAPI・CSV・EDI連携の実績は重要な判断材料です。連携先が仕様変更するたびに自社側でも継続的な調整が発生するため、こうした追従を保守の中でどこまで担ってくれるかも確認しておきます。各社の比較や選定基準をより詳しく知りたい場合は、おすすめの開発会社をまとめた記事もあわせて参考にしてください。

RFP（提案依頼書）の書き方と丸投げの回避

RFP（提案依頼書）は、自社の要件をベンダーに伝え、各社から比較可能な提案を引き出すための文書です。RFPの質が低いと、各社が異なる前提で見積もりを出すため横並び比較ができず、結果として「ベンダー丸投げ」の状態に陥ります。逆に、RFPで要件と評価軸を明確に示せば、提案の質と見積もりの精度が格段に上がります。OMS改修では、現状の連携構成と例外処理をどこまで正確に書けるかが、提案の精度を決める分かれ目になります。

RFPには最低限、プロジェクトの背景と目的、現状（As-Is）の業務フローとシステム構成、目指す姿（To-Be）と達成したいKPI、必須要件と希望要件、連携対象システム、想定スケジュールと予算レンジ、評価基準を盛り込みます。特にKPIは「受注処理の自動化率80%以上」「在庫差異率0.5%未満」「受注から出荷指示までのリードタイムを半減」のように定量化しておくと、ベンダーが目標達成の手段を具体的に提案しやすくなります。改修であれば「現状この処理に1日あたり3人時かかっているのをゼロにしたい」といった現状値とのセットで示すと、効果が伝わりやすくなります。

丸投げを避ける鍵は、「やってほしいこと」だけでなく「なぜそれが必要か」という背景を伝えることです。背景を共有することで、ベンダーは自社の意図をくみ取り、より良い代替案を提示できるようになります。また、評価基準を事前に明示しておくことで、提案を受ける側も判断がぶれず、社内の合意形成もスムーズになります。RFPは一度作って終わりではなく、ベンダーからの質問を通じて精度を高めていく前提で運用するとよいでしょう。

OMS改修のRFPで特に重要なのが、在庫同期の方式と外部連携の要件です。複数のECモールや自社カート、実店舗POSの在庫をどう同期するかには、基幹側を正とする一方向同期と、各販路の更新を相互に反映する双方向同期があります。双方向同期は柔軟ですが、同時に複数の販路で在庫が動いたときの更新コンフリクトが起きやすく、どちらの数値を優先するかという優先ルールの設計が欠かせません。実店舗POSを持つかどうかなど、自社の運用体制に応じてどの方式が適切かをRFPで示し、ベンダーの見解を求めることが、稼働後の売り越しや欠品を防ぎます。

連携要件も具体的に書きます。ERPや会計、WMSとの在庫・出荷データのやり取りをリアルタイムAPIで行うのか、CSVのバッチ連携で許容できるのかによって、開発工数も障害時のリスクも大きく変わります。取引先とのEDI連携がある場合は、対象となる取引先の数と接続方式、切替の段取りまで含めて記述しておくことが重要です。「在庫管理を正確にしたい」とだけ抽象的に書くと各社の解釈がばらつくため、連携対象・方式・データ項目・頻度をRFPで明示し、契約前に各社の連携実績を確証しておくことが、後の追加開発を防ぐ近道になります。

契約・撤退で確認すべき条項

発注時に見落とされがちなのが、契約内容と「撤退（Exit）」に関する条項です。多くの企業は新システムの機能や費用には注目しますが、いざ次の改修やベンダー変更が必要になったときに、データを引き上げられず高額な費用を請求されるケースが後を絶ちません。発注の段階で撤退戦略まで見据えて契約条件を確認しておくことが、将来の自由度を守ります。OMSは受注・売上データという事業の生命線を扱うため、データの所在と権利関係は特に慎重に確認すべき論点です。

OMS改修で意外な落とし穴になるのが、旧システムからのデータ抽出です。旧システムのデータベースへの直接アクセス権が自社にない契約だと、移行のためにデータを抽出するたびに旧ベンダーへ依頼することになり、1回あたり数十万円のスポット費用が発生します。受注履歴や顧客マスタは件数が膨大なため、移行テストやリハーサルで繰り返し抽出すると、この費用だけで百万円単位に膨らむこともあります。

こうした事態を避けるには、新システムを発注する段階で、将来の撤退時にデータをどのような形式で、どの程度の費用で引き上げられるかを契約に明記してもらうことが重要です。具体的には、データのエクスポート形式（CSVやデータベースダンプ）、提供範囲（顧客・商品マスタ、受注・出荷トランザクション、履歴）、対応費用の上限を確認します。今まさに発注しようとしている新ベンダーに対しても、同じ視点で「契約終了時のデータ返却条件」を確認しておくと、次の改修で同じ苦労を繰り返さずに済みます。

契約では、解約に関する条件も事前に確認します。SaaSの場合は最低契約期間や中途解約時の違約金、パッケージやスクラッチの場合は保守契約の更新条件と解約予告期間を押さえておきます。特にOMSの料金は基本料金に加え、ユーザー数課金か注文件数によるトランザクション（従量）課金が乗る形が多いため、受注件数の平均と季節波動から固定型と従量型のどちらが得かをシミュレーションし、5年・7年といった長期で見たときの総額（TCO）を試算しておくことが、見かけの安さに惑わされないコツです。

あわせて、SLA（サービス品質保証）の取り決めも欠かせません。障害発生時の復旧目標時間、サポートの対応時間帯、問い合わせへの初動応答時間などを契約に盛り込みます。OMSが止まると受注の取り込みや出荷指示が止まり、売上機会の損失に直結するため、繁忙期やセール時を含めた対応体制をどう確保するかは発注前に必ず握っておくべき論点です。費用の内訳や相場感をより詳しく確認したい場合は、見積相場をまとめた記事もあわせて確認すると判断材料が増えます。

外注先と握るべき役割分担

OMS改修は、外注先に任せきりにできる作業と、自社が主体的に担うべき作業が混在します。役割分担を曖昧にしたまま進めると、「ベンダーがやってくれると思っていた」「それは御社の作業範囲です」といった押し付け合いが発生し、プロジェクトが停滞します。契約段階で作業分担表（RACIなど）を作り、誰が何に責任を持つかを明文化しておくことが、トラブルの予防につながります。

OMS改修の失敗原因の約7割は、移行データの品質不良に起因すると言われます。顧客・商品マスタが基幹や会計、WMSに分散し、取引先名や商品名の表記揺れが放置されたまま移行されると、受注が正しく紐づかず出荷が止まります。データ移行では、旧システムからの抽出、クレンジング（名寄せ・表記統一）、新システムへの投入という工程があり、それぞれの責任を外注先と明確に分ける必要があります。ベンダーは「移行」はしても「整理」はしないことが多いため、クレンジングは自社の業務知識が不可欠な作業として自社主導で担う前提に立っておくと、想定外の工数増を防げます。

ここで検討したいのが「過去データをあえて全部移行しない」という逆転の発想です。受注履歴を全件物理移行すると、コストと工数がかさむだけでなく、新システムのパフォーマンス低下も招きます。過去データは専用DBに残してAPIで参照できるようにする、あるいは直近1年分だけを移行するといった割り切りが、費用対効果を大きく改善します。UAT（ユーザー受け入れテスト）のシナリオ作成も自社が主体的に担うべき領域で、前段で棚卸しした個別値引きや分割出荷、セット商品の在庫分解といった例外処理を、そのままテストシナリオに落とし込み、自社の目で検証することが、稼働後の受注トラブルを防ぎます。

新旧システムを同時に動かす並行稼働（パラレルラン）は、二重入力で現場の工数が1.5〜2倍に膨らみます。OMSで起きやすい事故は、新旧両方から出荷指示が出てしまう「指示系統の二重化」で、これが誤出荷や二重出荷を連発させます。出荷指示は新システムのみから出すという一本化ルールを、外注先と現場の双方で徹底することが鉄則です。並行稼働の期間は最低でも1〜3ヶ月確保し、月末締めなど特定サイクルのバッチ処理を実データで複数回検証してから本番に移ることが、稼働後のバッチエラーを防ぎます。

本番稼働後に問題が起きた際のロールバック（切り戻し）については、判断基準を感覚に頼らず定量化しておくことが重要です。たとえば「API連携エラーで受注取り込みが3時間以上停止したら、無条件で旧システムへ戻す」といった撤退ラインを、発注の段階でベンダーと事前合意し、明文化しておきます。基準を決めずに走り出すと、いざトラブルが起きたときに対応が後手に回り、受注停止が長期化します。誰の判断で、どの状態になったら切り戻すのかという権限と発動条件を契約段階で握っておくことが、業務停止のリスクを最小化します。プロジェクト全体の進め方を体系的に把握したい場合は、進め方をまとめた記事もあわせて参照してください。

OMS改修の外注でよくある失敗と回避策

OMSの外注では、過去のプロジェクトで繰り返されてきた典型的な失敗パターンがあります。これらを事前に知っておくことで、同じ轍を踏まずに済みます。失敗の多くは技術的な問題ではなく、発注側の準備不足やコミュニケーション設計の甘さ、そして社外を巻き込む段取りの不備に起因しているのが特徴です。

最も多い失敗が、要件整理をせずにベンダーへ丸投げするパターンです。自社の業務を理解しているのは現場であり、ベンダーはシステムの専門家であってもその企業特有のオペレーションまでは知りません。丸投げすると、要件定義で例外処理が漏れ、稼働後に受注の紐づけミスやオペレーション混乱が噴出します。前段で述べた要件整理とRFP作成を丁寧に行うことが、最大の回避策です。

隠れコストの罠も見逃せません。「初期費用無料」をうたうSaaSでも、注文件数に応じた従量課金が積み上がると中長期で割高になることがあります。たとえば初期0円＋月20万円なら5年で1,200万円、初期100万円＋月10万円なら5年で700万円と、TCOで見ると逆転します。このほか、モールや決済サービスが仕様変更するたびに発生する連携改修費、データクレンジングの人的コスト、現状業務に無理に合わせる過剰カスタマイズ費は、見積書の表面には出てこない代表的な隠れコストです。見積もりを比較する際は、本体価格だけでなくこうした周辺費用と5年TCOで総合的に判断することが欠かせません。

OMS改修ならではの失敗が、取引先を巻き込むEDI切替の段取り不足です。取引先ごとにEDI接続の切替タイミングがずれると、「旧システムへ発注データが飛んでいるのに新システムでは受注できない」という空白が生まれ、受注の取りこぼしにつながります。さらに、すべての取引先がEDIに対応しているとは限らず、FAXや電話で発注してくるアナログな取引先も残ります。こうした相手にはFAX-OCRやLINE連携といったインターフェースを別途用意し、取引先ごとに切替スケジュールを泥臭く調整しておくことが、空白リスクの回避につながります。

現場教育の不足も稼働後の混乱を招きます。システムが優れていても、それを使う現場の教育が不足していると、二重入力や操作ミスが増え、結局は旧来のExcel運用に逆戻りしてしまいます。新システムの操作研修を稼働直前に駆け足で行うのではなく、UATの段階から現場のキーパーソンを巻き込み、操作に慣れてもらうことが定着の近道です。取引先向けの説明会やマニュアル整備も含め、社内外の関係者が新しい受注フローに納得して移行できる状態を作ることが、改修を成功させる最後の鍵となります。

まとめ

OMS改修を外注・委託する際は、発注前の要件整理から始まり、RFPによる丸投げの回避、契約・撤退条項の確認、外注先との役割分担、失敗パターンの理解という一連の流れを丁寧に踏むことが成功の条件です。特に、必須要件と希望要件の切り分けと「機能を見送る勇気」、現場の例外処理の棚卸し、在庫の一方向・双方向同期の方式選定、過去データをあえて全部移行しない判断、定量的なロールバック基準の明文化は、製品比較だけでは見えてこない実務上の急所です。

OMSは受注と在庫という事業の根幹を支えるため、発注の巧拙がそのまま現場の混乱や追加コストとして跳ね返ります。本体価格の安さだけでなく、5年TCOや連携改修・クレンジングといった隠れコスト、取引先を巻き込むEDI切替の段取り、撤退時の自由度まで含めて発注先を見極め、自社が主体的に関与すべき領域はしっかりと握ったうえで、信頼できるパートナーへ委託することをおすすめします。AI駆動開発のように、自社に100%フィットしたシステムをパッケージ並みの予算で実現する新しい選択肢も視野に入れながら、自社にとって最適な発注のかたちを検討してください。

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