OMS更改の外注は、発注前に業務要件を整理し、RFPで委託先を選び、契約と役割分担を固めるという順に進めます。この順序で進めると、丸投げや追加コストを防げます。
発注準備から移行まで、段階ごとの判断を順に見ていきます。全体像は、次の記事にまとめています。
▼全体ガイドの記事
・OMS更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
OMS更改の外注前に整理する事項
自社の要件が固まらないままベンダーに相談すると、提案がかみ合わず、契約後に想定との差が生じます。OMSは受注、在庫引当、出荷、モール連携など複数の業務が関わるため、自社の運用をどこまで整理できたかが、RFPと見積もりの精度を左右します。さらに、発注前の整理を怠ると、そのしわ寄せは後工程のすべてに及びます。
必須要件と希望要件の切り分け
新OMSの機能は、必須要件（Must）と希望要件（Want）に分けておきます。機能をすべて必須にすると、そのぶん見積もりが膨らみます。
判断の基準は、事業の根幹に関わる機能かどうかと、汎用的な希望にとどまるかどうかです。そのうえで、標準機能と合うかも次のように確認します。
- 必須要件：受注処理性能や在庫一元管理など、競争力に直結する機能
- 希望要件：標準機能で対応できる帳票レイアウトなどの要望
- 運用で対応：使わない機能を決め、独自の例外処理を整理する
Fit to Standard（標準機能に業務を合わせる）の考え方に立つと、標準機能で足りるものは希望要件に回せます。必須と希望の切り分けが曖昧なままだと、後から追加開発が発生し、当初の予算を超えてしまいます。
独自処理のうち優良顧客向け値引きやセット商品の在庫分解は必須要件に当たります。一方で、帳票の見た目は希望要件に分類できます。また、文書化されていない例外まですべて載せると、改修費が膨らみ、将来の更新も難しくなります。
多販路オペレーションと例外処理の洗い出し
現場の例外処理がシステムに反映されないままだと、OMS更改後に在庫が合わなくなることがあります。そのため、発注前に販路別の例外を洗い出し、文書にまとめておきます。確認の対象には、次のような作業があります。
- 一部出荷：残りの注文をどのように管理するか
- 予約商品：モールごとに在庫を引き当てるタイミング
- 特注受注：電話やメールの注文をどこに記録するか
例外が重なると、実在しないのに引き当て可能な在庫、いわゆる「ゴースト在庫」が生まれます。その結果、売り越しや欠品につながります。そこで、現場のベテラン担当者に聞き取り、正規フローから外れる作業を確かめておきます。
例外を聞き漏らすと、稼働後の受注漏れや在庫差異につながります。さらに、集めた情報は、RFPの質を高めるだけでなく、受け入れテストのシナリオにも使えます。
OMS更改の発注先の種類と選び方
提供形態が違うと、初期費用、カスタマイズの自由度、運用後のコストも変わります。OMSは外部連携が多いため、見積もりの額だけでなく、連携実績と拡張性も比べておく必要があります。さらに、初期費用が安く見えた選択肢でも、中長期では割高になることがあります。
SaaS・パッケージ・スクラッチ・AI駆動開発の選択肢
方式ごとに費用や期間の特徴は異なるため、注文件数と必要な連携を踏まえて比べることになります。
- SaaS：初期費用を抑え、数ヶ月で稼働できる
- パッケージ：自社環境に構築し、一定のカスタマイズができる
- スクラッチ：自社業務に合わせられるが、期間と費用がかかりやすい
- AI駆動開発：工期とコストを従来比30〜70%圧縮できるケースがある
SaaSは主要なECモールやカートとの連携が標準で用意されています。一方で、注文件数に応じた従量課金には注意が必要です。とくに注文件数が多い事業者では、従量課金が中長期のコストに積み上がります。
パッケージは、年間保守費として初期構築費の15〜20%が固定的に発生します。また、パッケージを選ぶ際は、自社の販路を標準機能でどこまで扱えるかが判断の軸になります。
スクラッチは業務に100%合わせられますが、従来は開発に半年から1年以上かかり、費用も高くなりがちでした。これに対し、AI駆動開発なら、パッケージ並みの予算で自社業務に100%合うOMSを作る選択肢もあります。
季節変動が大きく、SaaSの従量課金が割高になりやすい事業者では、対応可能な開発手法も評価の対象に入れます。
EC・物流ノウハウと連携実績の見抜き方
提案書だけでは、EC運用や物流現場への理解度は判断しにくいものです。そのため、実績と運用体制を確かめておきます。
- 業務理解：在庫一元管理や売り越し防止を、こちらが聞く前に尋ねるか
- 導入実績：同業種・同規模のOMS更改を行ったか
- 連携実績：周辺システムや取引先との接続経験があるか
- 運用体制：モールAPIの仕様変更へ継続的に追従できるか
機能の説明にとどまらず、モール仕様の変更など現場の論点まで踏み込んで話せるかも、見ておきたいところです。
可能であれば、導入企業へのヒアリングや稼働画面のデモを依頼します。あわせて、WMS（倉庫管理）、ERP・会計、決済、EDIとのAPI・CSV連携も確認します。
発注先の比較基準を詳しく知りたい場合は、おすすめの開発会社をまとめた記事も参考になります。
RFP（提案依頼書）の書き方と丸投げの回避
RFP（提案依頼書）は、要件を伝え、各社から比較できる提案を得るための文書です。各社がばらばらの前提で見積もると、提案を横並びに比べられません。そこで、連携対象と在庫の扱いを具体的に示しておくと、各社の提案の前提がそろい、提案の精度が上がります。
丸投げを避けるRFPの構成
比較できる提案を得るには、RFPに要件だけでなく、背景や目標も盛り込みます。具体的には、次の観点で整理します。
- プロジェクト情報：背景、目的、想定スケジュールと予算レンジ
- 業務とシステム：現状（As-Is）のフローと構成、目指す姿（To-Be）
- 要件と評価：必須・希望要件、連携対象、評価基準
- 達成目標：在庫精度、処理自動化率、ピーク時の注文数
KPIは「在庫精度99.5%以上」「受注から出荷指示までの自動化率90%以上」のように数値で示します。さらに、ピーク時に1日2万件を処理する目標も書いておくと、性能要件の見積もりが正確になります。
「やってほしいこと」に加えて、その理由や背景も共有すると、ベンダーは代替案を出しやすくなります。評価基準を先に示しておくと、提案を見比べる際の判断がぶれず、社内での合意形成にも役立ちます。
RFPは、質問を受けて精度を高めていく前提で運用します。その質問からは、ベンダーがどの程度業務を理解しているかも見えてきます。
在庫同期方式と外部連携要件の伝え方
販路ごとの例外処理は、具体例を添えてRFPに記します。予約商品の引当時期も、その対象に含めます。たとえば、セット品のバラ返品では、月間件数と現状の処理方法まで書いておきます。
抽象的な要件だと、各社の解釈が分かれ、追加開発につながるおそれがあります。そのため、同期方式も具体的に書いておきます。
- 一方向同期：OMSからモールやカートに在庫を反映する
- 双方向同期：実店舗POSの販売をリアルタイムに取り込む
双方向同期では、複数チャネルの引当競合や更新の優先順位も設計する必要があります。方式によって、設計の難しさも費用も変わります。
WMS、ERP、決済、EDIとの連携では、APIかCSVか、データ項目と頻度まで明記しておきます。要件が具体的であれば、連携実績を契約前に確かめられ、稼働後のトラブルも減らせます。
契約・撤退で確認すべき条項
発注時には、契約内容と撤退（Exit）の条項を確認しておく必要があります。機能や費用だけで決めてしまうと、将来の更改でデータを引き上げられないことがあります。
OMSには取引履歴や顧客情報が蓄積されていきます。そのため、データの所有権を含め、撤退後の自由度を契約であらかじめ確保しておきます。
旧DBアクセス権とデータ引き上げ費用
旧システムのDBに自社が直接アクセスできない契約では、抽出のたびに旧ベンダーへの依頼が必要になります。1回あたり数十万円の費用が発生し、移行テストやリハーサルで繰り返すと百万円単位に膨らむこともあります。
新システムの契約では、撤退時に返してもらうデータの形式と範囲、費用の上限をあらかじめ決めておくと、依頼のたびに費用がかさむ事態を避けられます。返却の条件は、次の3点に分けて契約に書いておきます。
- 形式：CSVやデータベースダンプ
- 提供範囲：取引先・商品マスタ、受注・出荷記録、履歴
- 費用：データ返却にかかる対応費用の上限
受注データは件数が膨大なので、抽出ごとの費用がかさみやすい領域です。新しいベンダーとの契約でも、契約終了時の返却条件を確認しておきます。その条件を定めておくことが、長期的なベンダーロックインの回避につながります。
課金体系（固定か従量か）と解約・SLAの取り決め
課金体系は、事業の成長や繁忙期のコストを左右します。そこで、月間受注件数の平均と季節変動から、固定と従量のどちらが有利かを試算しておきます。
- 固定課金：基本料金を中心に費用が決まる
- 従量課金：受注件数に応じてトランザクション料金がかかる
セール期に注文が平常時の数倍になる事業者は、従量課金で想定外の請求が起きないかを確認しておきます。SaaSでは最低契約期間と中途解約の違約金を、パッケージやスクラッチでは保守更新と解約予告期間を押さえておきます。
SLA（サービス品質保証）には、復旧目標時間やサポート時間帯、問い合わせへの初動時間を盛り込みます。OMSの停止は受注と売上に直結するため、繁忙期を含めた対応体制も、発注前に合意しておきます。
費用の内訳や相場については、見積相場をまとめた記事も判断材料になります。
外注先と握るべき役割分担
任せる作業と自社が担う作業は、契約の段階で分けておきます。曖昧なままにしておくと、責任の押し付け合いが起き、計画が停滞します。そのため、担当と責任は作業分担表（RACIなど）に明文化し、取引先も含めて社内外の役割を一覧にします。
データ移行と「非移行」戦略の責任分界
OMS更改の失敗の約7割はデータに起因すると言われ、その大半は移行データの品質不良です。たとえば、マスタが基幹、会計、WMSに分散し、取引先名や商品名に表記揺れがあると、受注が結びつかず出荷が止まります。
ベンダーはデータを移行しても、データの中身を整える作業までは受け持たないことがあります。そこで、データ移行は工程ごとに責任を分けておきます。
- 自社主導：クレンジング基準の決定、名寄せ、表記統一
- ベンダー担当：移行ツールの開発、データ投入処理
何年分もの受注履歴を物理的に全件移すと、費用と工数が膨らみ、新システムの性能も低下します。そのため、過去データを参照用DBに残してAPIで参照する方法や、直近1年分だけを移行する方法があります。
また、直近12ヶ月に取引のないマスタや休止商品を移行しない基準も、自社で決めてベンダーに伝えておきます。
EDI切替・並行稼働とロールバック責任の明確化
取引先ごとに接続の切替時期がずれると、EDIでは注文の空白が生じます。旧システムへ発注が飛び、新システムで受注できない事態も起こりえます。そのため、次のような対応を計画に含めておきます。
- 取引先ごとの接続切替日程の自社主導での調整
- EDI非対応先に向けたFAX-OCRやLINE連携の用意
- 最低1〜3ヶ月の並行稼働と、実データでの月次締めの複数回検証
- 切り戻し条件と判断者の決定（API連携エラーで受注が3時間以上止まった場合など）
- 切り戻しに備えた、旧システム環境の一定期間の保管
並行稼働が1週間程度だと、月末締めなどを検証しきれず、本番後にバッチエラーが多発することがあります。なお、全体の進め方は、関連する解説記事も参照できます。
OMS更改の外注でよくある失敗と回避策
外注の失敗は、技術面より、発注側の準備不足や連絡設計の甘さから起きることがあります。典型的な失敗を把握しておき、準備と関係者の巻き込みによって回避します。
ベンダー丸投げと隠れコストの罠
ベンダーはOMSの専門家であっても、自社特有のオペレーションまでは知りません。そのため、要件整理をしないまま委託すると、例外処理が漏れ、在庫差異や受注の取りこぼしにつながります。そこで、自社業務を知る現場が要件整理とRFP作成に関わり、業務をベンダーに説明できる状態にしておきます。
見積もりでは、本体価格以外の複数年コストも確認しておきます。主な費用には、次のようなものがあります。
- 連携改修：モールや決済サービスの仕様変更への対応
- データ整理：ベンダーが担わないクレンジングの人件費
- 過剰な改修：現行業務に合わせるカスタマイズの初期費用
連携改修は年間で数十万円規模になることがあるため、TCO（総保有コスト）で総合的に判断します。
取引先・現場の巻き込み不足と切替タイミングの誤り
現場や取引先の準備不足と切替時期の誤りを防ぐには、次の対策を計画に含めておきます。
- 現場教育：受け入れテストからキーパーソンに参加してもらう
- 取引先周知：事前説明会やマニュアルを用意する
- 切替時期：受注量が落ち着く閑散期の選択
- 段階導入：最小要件で更改し、後から機能を追加する
教育が足りないと、Excel運用に戻ってしまい、データ入力が崩れて在庫精度が低下します。繁忙期は、二重入力と受注ピークが重なって現場の負荷が増します。
段階導入を前提にするなら、AI駆動開発で、パッケージ並みの予算で自社向けOMSを実現する選択肢もあります。ただし、どの方式を選ぶにせよ、自社の体力に合った切替計画は外注先と綿密にすり合わせておきます。
まとめ
OMS更改の外注は、要件を整理してRFPを作り、契約と役割分担を固め、よくある失敗を避けながら進めます。必須要件の切り分けや例外処理の洗い出しによって、発注先に伝える内容を具体化します。
同期方式と過去データの移行範囲を決めるほか、EDI切替と、定量的なロールバック基準も事前に定めておきます。選ぶ際は、本体価格に加えて、複数年のTCO、連携維持費、撤退時のデータ返却条件を踏まえます。さらに、移行しないデータや見送る機能を先に決めておき、最小要件から更改します。
▼全体ガイドの記事
・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を創業。