OMS（OrderManagementSystem／注文管理システム）の開発を発注するとき、プロジェクトの成否と費用をもっとも左右するのは、要件定義とRFP（提案依頼書）の精度です。自社の受注フローと責任分界を曖昧にしたままベンダーへ丸投げすると、在庫の不整合や出荷遅延を抱えたシステムができてしまいます。
まずOMSの完全ガイドで全体像をつかむと、自社のRFPに直結する「要件チェックリスト」が描けます。
▼全体ガイドの記事
・OMSの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングと受注フローの可視化
OMSの要件定義は、現場が「いま実際にどう受注を処理しているか」を可視化するところから始めます。機能の一覧は、その後に作るものです。
複数モールの注文確認、在庫の手引き当て、出荷指示、例外注文の判断といった一連の作業を、誰が・いつ・どんな順序で行っているかを丁寧に洗い出します。この現状（AsIs）の受注フローを飛ばして理想論で要件を作ると、現場の実態と噛み合わないシステムになり、結局は手作業に戻ってしまいます。
AsIsの受注フローと例外パターンの洗い出し
受注フローの可視化で特に重要なのは、正常系だけでなく例外パターンを徹底して洗い出すことです。例外フローは、要件定義の段階で網羅的に拾うべき対象です。
OMSの要件定義で抜け落ちやすいのは、バックオーダー（取り寄せ）、分納、キャンセル・返品・交換といった例外です。件数が少なくても、設計が漏れると現場が手作業で対応することになり、自動化の効果が削がれます。
洗い出しは、受注担当・出荷担当・カスタマーサポート・経理といった関係者へのヒアリングで行います。各担当が「どんなときに手が止まるか」「どんな判断を毎回しているか」を聞き取ると、自動化すべき定型処理と、人が判断すべき例外が見えてきます。
- 受注の例外：ギフト・のし対応、住所不備、決済保留
- 名寄せ：複数モールにまたがる同一顧客の注文
この一次情報は、OMSの自動判定ルールやステータス設計の土台になります。現場の言葉でフローを記述し、関係者全員が同じ理解に立つことが、後の手戻りを防ぐもっとも効く予防策です。
ヒアリングで意識したいのは、無駄や手戻りを削ぎ落としてから要件にすることです。現場には、長年の慣習で続いているだけの非効率な手順が紛れていることがあります。
そうした手順をそのまま自動化すると、無駄を高速化するだけの投資になります。AsIsの可視化は、現状を記録するためではなく、改善点を見つけるために行います。各工程で「なぜこの手順なのか」を問い直し、本当に必要な処理だけをToBeへ引き継ぐことで、要件定義の価値が高まります。
ToBeモデルによる自動化と人手の境界の設計
現状を可視化したら、次は「あるべき受注業務の姿（ToBeモデル）」を描きます。ここで決めるべきもっとも重要なことは、自動化と人の判断の境界線、つまりどこまでを自動化し、どこから人が判断するかです。
LOGILESSがRPA活用で全注文の約90%を自動出荷している事例が示すように、定型注文の大半は自動化でき、残りの例外に人を集中させるのが現実的な姿です。自社の注文のうち、例外がどれくらいの比率を占めるかを見積もり、自動化率の目標と例外処理の体制を要件として定義します。
ToBeモデルでは、受注から出荷・請求までの流れを、ステータスごとに描きます。この設計があるからこそ、ベンダーは「どこまで作り込むべきか」を正確に見積もれます。
逆にToBeが曖昧なまま開発に進むと、自動化の範囲が現場の期待とずれ、リリース後に「思ったより手作業が残った」という不満が噴出します。ToBeモデルを描くことが、OMSの投資対効果を設計段階で固める近道です。
- ステータス遷移：受注から出荷・請求までの、理想的な状態の変わり方
- 処理の担い手：各ステータスを自動と手動のどちらが処理するか
OMS・WMS・ERPの責任分界の要件化
OMSの要件定義でもっとも差がつくのは、OMS・WMS・ERPという複数システムの責任分界を明確に定めることです。
OMSは「注文＝情報」を、WMSは「倉庫のモノ＝物理」を、ERPは「会計・販売の基幹」を管理します。ただし在庫データや出荷情報は、これらの間を行き来します。
誰がどのデータのマスタを持ち、どの方向に同期するかを要件で固めなければ、在庫が二重管理になって不整合を生みます。この責任分界の要件化こそ、OMS導入の失敗を防ぐもっとも効く予防策です。
在庫マスタの所在と同期方向の定義
責任分界の中心は、在庫データのマスタをどこに置くかです。OMSが管理するのは「販売可能な引当在庫」、WMSが管理するのは「倉庫の物理在庫」です。
入荷・出荷・棚卸のたびにWMSの実在庫をOMSへ反映し、情物一致（情報上の在庫と物理在庫の一致）を保つルールを定めておく必要があります。OMS上は在庫があるのに倉庫に実物がない、という出荷不能の注文も起きます。同期のタイミングが日次バッチかリアルタイムかは、売り越しリスクに直結するため、要件で固めます。
- マスタの置き場：引当在庫と物理在庫、どちらを正とするか
- 同期の方向とタイミング：WMSの実在庫をOMSへ、どの時点で反映するか
あわせて、OMSとWMSを一体型にするかAPI連携型にするかも、要件定義で判断します。一体型は在庫データが一つで情物一致を保ちやすい反面、自社の倉庫運用に合わせたカスタマイズがしにくい場合があります。API連携型は柔軟性が高い一方、同期エラーやタイムラグへの対処を丁寧に設計する必要があります。
どちらを選ぶにせよ、連携時のエラー処理、リトライ、データ不整合時のリカバリー手順まで要件化しておくことが、運用後のトラブルを防ぎます。在庫の整合性は、OMS要件でもっとも外せない点です。
自動倉庫やマテハン機器を使う現場では、WMSの下にWCS（倉庫制御システム）やWES（倉庫実行システム）が入るため、責任分界はさらに多層になります。OMSはこれらの最上流で受注の指令を出す位置づけです。
そのため、出荷指示がWMSからWCS/WESを経て現場機器へ届くまでの流れを要件で整理し、各層がどこまでの情報を持ち、どこで在庫や進捗を更新するかを定めておく必要があります。定めておかないと、層の境目で情報が抜け落ちます。OMSの要件定義は、受注の入り口だけでなく、出荷の現場までのシステム階層全体を見渡して責任分界を定めることが求められます。
モール・ERP・決済との連携要件と分界点
OMSは多くの外部システムと連携するため、それぞれの連携要件と責任分界を要件定義で具体化します。
決済サービスとの与信・入金消込の連携なども、漏れなく定義します。連携費用は、モール1つあたり20〜100万円、基幹システム連携で100〜500万円が相場です。連携範囲が広いほど費用が膨らむため、範囲は要件の段階で決めておくことが大切です。
必須の連携と将来追加の連携を要件の段階で分けておくことが、予算管理の要点です。
- 連携先の一覧：ECモールごとの連携方式と、ERPへ流すデータの種類や頻度
- 責任の所在：OMS、WMS、3PL、モールのどこまでを誰が持つか
ERPへ流すデータの種類には、受注・売上・請求があります。
連携で見落としがちなのは、複数ベンダーが関わる場合の責任分界点です。OMSのベンダー、WMSのベンダー、3PL、モール側のそれぞれが、どこまでのデータ連携に責任を持つかを明確にしておかないと、不具合が起きたときに「どちらの問題か」で揉めて復旧が遅れます。
連携仕様書を共通言語として整備し、データの受け渡し点ごとに責任の所在を定めておけば、マルチベンダー構成でもOMS導入を前に進められます。この点はRFPにも明記し、提案を求める段階から責任分界を意識させることが有効です。
機能要件と非機能要件の整理
受注フローと責任分界が固まったら、それを機能要件と非機能要件に落とし込みます。
機能要件は「何ができるか」、非機能要件は「どれだけの性能・品質で動くか」を定めるものです。OMSでは特に非機能要件が見落とされがちです。
繁忙期のピーク負荷に耐える性能や在庫同期のリアルタイム性は、OMSの実用性を左右します。そのため、機能要件と同じだけの重みで定義する必要があります。
機能要件の必須・優先・将来による分類
機能要件は、すべてを同列に並べず、必須・優先・将来追加の三段階で分類します。複数チャネルの受注一元化や在庫引当など、「これがないと受注が回らない」機能は必須です。
レポート機能や需要予測、顧客分析などは、優先または将来追加に回せます。OMSは機能を盛り込むほど費用が膨らむため、この優先順位付けが、予算の中で効果を出すための要になります。カスタマイズが全体の70%を超えるようなら、パッケージではなくスクラッチ開発を検討する判断材料にもなります。
分類の際は、各機能が「どの業務課題を解決するか」を明記しておくと、ベンダーとの認識合わせがスムーズになります。たとえば「在庫の一括引当機能」は、「複数チャネルの売り越し防止」のためという目的を添えれば、ベンダーは代替案も提案しやすくなります。機能要件を目的とセットで整理することが、要件定義書の質を高めます。
優先順位を付けた機能要件は、後述するRFPの提案依頼の中心になり、見積りの妥当性を判断する基準にもなります。
- 必須：これがないと受注が回らない機能
- 優先・将来追加：必須を入れた後に、順番を決めて入れる機能
非機能要件（ピーク性能・在庫同期・可用性）
OMSの非機能要件で最重要なのは、繁忙期のピーク性能です。セールやテレビ放映で受注が平常時の何倍にも跳ね上がっても、注文取込・在庫引当・出荷指示が遅延なく処理できる性能を、具体的な数値で要件化します。
ここを曖昧にすると、肝心の繁忙期にシステムが詰まって出荷遅延を起こします。あわせて、在庫同期のリアルタイム性（許容するタイムラグの上限）も、売り越しを防ぐ非機能要件として明記します。
- ピーク性能：同時注文数や処理件数/秒を、繁忙期の受注量から決める
- 在庫同期の遅れ：許容するタイムラグの上限
可用性（システムが止まらない度合い）、セキュリティ（顧客情報・決済情報の保護）、現場操作性（臨時スタッフでもすぐ使えるUI）も非機能要件に含めます。
受注が止まれば売上が止まるため、OMSには高い可用性が求められます。また、顧客の個人情報や注文履歴を扱うため、セキュリティ要件は法令対応も含めて慎重に定義します。
これらの非機能要件は、機能要件のように目に見えないため見落とされがちです。しかし、OMSが現場で実用に耐えるかどうかを左右する決定的な要素です。要件定義の段階で数値目標まで落とし込むことが重要です。
拡張性も、OMSの非機能要件として軽視できません。事業が成長すれば、販売チャネルや取扱SKU数、出荷拠点が増え、将来的にはマテハン連携も必要になります。導入時点の要件だけを満たすシステムを作ると、数年後に再構築を迫られ、二重投資になりかねません。
そのため、チャネルや拠点を後から追加できる設計か、API連携の口が用意されているかを、将来の事業計画に照らして要件化しておくことが、長く使えるOMSの条件です。非機能要件は、いまの業務ではなく数年後の事業規模を想定して定義する視点が欠かせません。
RFPに盛り込む項目と見積り妥当性の判断
整理した要件は、RFP（提案依頼書）としてベンダーへ提示します。RFPは、各ベンダーから同じ条件で提案と見積りを引き出すための共通仕様書です。RFPの質が低いと、ベンダーごとに前提がバラバラの見積りが集まり、比較できなくなります。
OMS特有の連携要件や責任分界、ピーク性能までを盛り込んだRFPを作ることが、適正なベンダー選定と妥当な見積り取得の前提になります。
RFPに必ず盛り込むべき項目と従量課金の上限条項
RFPには、目的や対象業務範囲、機能・非機能要件、連携と責任分界を書き込みます。OMS特有の重要項目として、クラウド型の従量課金の上限条項を必ず明記すべきです。
クラウドOMSは出荷件数に応じた従量課金が中心で、繁忙期に受注が急増するとコストが想定外に膨らむ「コストトラップ」があります。受注量が増えた場合の料金体系を提案段階で開示させ、上限や段階料金を確認することが、長期コストの予測精度を高めます。
データ移行も、RFPで軽視できない項目です。既存システムやExcelで管理してきたデータを新OMSへ正確に移すには、相応の工数がかかります。
データ移行や並行稼働の隠れ費用は、プロジェクト全体の20〜50%に達することもあります。そのため、移行対象データの範囲・件数・クレンジングの要否をRFPで明示し、移行費を見積りに含めさせます。
これを曖昧にすると、リリース直前に移行費が膨らんで予算が破綻します。RFPで、こうした見えにくいコストを事前に洗い出すことが大切です。
- スケジュールと予算感：プロジェクトの期間と、想定する予算の幅
- 運用保守の条件：導入後の運用と保守を、ベンダーにどこまで任せるか
見積りの妥当性を見る観点
集まった見積りの妥当性は、相場観と内訳の透明性で判断します。OMSの構築形態別の相場は、クラウド型が初期0〜100万円・月額3〜30万円（5年TCO 180〜1,800万円）です。
また、パッケージ/オンプレは初期500〜3,000万円、フルスクラッチは初期3,000万円〜です。人月単価は、エンジニアで100万円程度が一つの目安です。たとえば20機能規模を各2人月で開発すれば、開発費だけで4,000万円前後になる計算です。
この相場と照らして、極端に安い見積りは要件の取りこぼし、極端に高い見積りは過剰スペックを疑います。
見積りで特に注視したいのは、内訳が機能や連携ごとに分かれているかです。一式いくらの丸めた見積りは、後から「それは含まれていない」という追加費用を招きます。
- 内訳の粒度：機能、連携、データ移行、テスト、運用保守ごとに費用が分かれているか
- 相場とのずれ：極端に安ければ要件の取りこぼし、高ければ過剰スペックを疑う
連携費用（モール20〜100万円、基幹100〜500万円）や移行費（全体の20〜50%）が明記されているか、保守費が初年度開発費の10%程度に収まっているかを確認します。riplaはフルスクラッチ受託と国内開発の立場から、OMSとWMSの責任分界を踏まえた要件定義とRFP作成、見積りの妥当性検証までを一貫して支援しています。
要件定義への投資が、その後の開発費と運用費を左右することを覚えておいてください。
まとめ
OMSの要件定義とRFPは、現場の受注フローと例外パターンの可視化から始まります。そのうえで、ToBeモデルで自動化と人手の境界を定め、OMS・WMS・ERPの責任分界（とりわけ在庫マスタの所在と同期方向）を要件化します。
機能要件は必須・優先・将来で分類し、ピーク性能や在庫同期のリアルタイム性といった非機能要件まで定めることが核心です。
RFPには、連携要件と責任分界、従量課金の上限条項、データ移行を盛り込みます。そして、クラウド型の5年TCO（180〜1,800万円）やフルスクラッチの初期3,000万円〜といった相場と、内訳の透明性で見積りの妥当性を判断します。
要件定義は、機能の一覧を作る作業にとどまらず、自社の受注業務とシステム間の責任分界を言葉にする作業です。ここを丁寧に詰めるほど、開発の手戻りと運用後のトラブルが減り、結果として総コストが下がります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、受注フローから逆算した要件整理と責任分界の設計を行い、RFP作成と見積り検証まで支援します。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。