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