OMS（Order Management System／注文管理システム）の開発を発注するとき、プロジェクトの成否をもっとも左右するのが要件定義とRFP（提案依頼書）です。OMSは、複数チャネルの受注を一元化し、在庫を引き当て、倉庫側のWMS（倉庫管理システム）へ出荷指示を渡す「受注の司令塔」であり、ECモール・ERP・決済・WMSといった多くのシステムと連携します。だからこそ、自社の受注フローと各システムの責任分界を曖昧にしたままベンダーへ丸投げすると、在庫の不整合や出荷遅延を抱えた使えないシステムが出来上がってしまいます。要件定義とRFPの精度こそが、OMS導入の品質と費用を決めるのです。
本記事は、OMSの要件定義書とRFP（提案依頼書）を、現場ヒアリングからの進め方・OMSとWMSの責任分界の要件化・機能/非機能要件の整理・RFPに盛り込むべき項目という観点で体系的に解説する「要件定義特化」の記事です。受注フローの可視化、在庫マスタの責任分界、従量課金のコスト上限条項、データ移行と現場操作性の評価軸まで、具体的に整理します。要件定義の前提となるOMSの全体像をまだ把握していない方は、まずOMSの完全ガイドから読むことをおすすめします。読み終えるころには、自社のRFPに直結する「要件チェックリスト」が描けるはずです。
▼全体ガイドの記事
・OMSの完全ガイド
現場ヒアリングと受注フロー可視化から始める
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上は在庫ありなのに倉庫に実物がない、という出荷不能の注文が発生します。同期のタイミングが日次バッチかリアルタイムかも、売り越しリスクに直結するため要件で固めます。
あわせて、OMSとWMSを一体型にするかAPI連携型にするかも、要件定義で判断します。一体型は在庫データが一つで情物一致を保ちやすい反面、自社の倉庫運用に合わせたカスタマイズがしにくい場合があります。API連携型は柔軟性が高い一方、同期エラーやタイムラグへの対処を丁寧に設計する必要があります。どちらを選ぶにせよ、連携時のエラー処理、リトライ、データ不整合時のリカバリー手順まで要件化しておくことが、運用後のトラブルを防ぎます。在庫の整合性は、OMS要件の生命線です。
自動倉庫やマテハン機器を使う現場では、WMSの下にWCS（倉庫制御システム）やWES（倉庫実行システム）が入るため、責任分界はさらに多層になります。OMSはこれらの最上流で受注の指令を出す位置づけになり、出荷指示がWMSからWCS/WESを経て現場機器へ届くまでの流れを要件で整理する必要があります。各層がどこまでの情報を持ち、どこで在庫や進捗を更新するかを定義しておかないと、層の境目で情報が抜け落ちます。OMSの要件定義は、受注の入り口だけでなく、出荷の現場までのシステム階層全体を見渡して責任分界を定めることが求められます。
モール・ERP・決済との連携要件と分界点
OMSは多くの外部システムと連携するため、それぞれの連携要件と責任分界を要件定義で具体化します。対応すべきECモールの一覧と各モールの連携方式、ERPへ流すデータの種類（受注・売上・請求）と頻度、決済サービスとの与信・入金消込の連携などを、漏れなく定義します。連携費用はモール1つあたり20〜100万円、基幹システム連携で100〜500万円が相場であり、連携範囲が広いほど費用が膨らむため、必須の連携と将来追加の連携を要件段階で切り分けることが予算管理の要点です。
連携で見落としがちなのが、複数ベンダーが関わる場合の責任分界点です。OMSのベンダー、WMSのベンダー、3PL、モール側のそれぞれが、どこまでのデータ連携に責任を持つかを明確にしておかないと、不具合が起きたときに「どちらの問題か」で揉めて復旧が遅れます。連携仕様書を共通言語として整備し、データの受け渡し点ごとに責任の所在を定めることが、マルチベンダー構成でのOMS導入を成功させる鍵です。この点はRFPにも明記し、提案を求める段階から責任分界を意識させることが有効です。
機能要件と非機能要件の整理
受注フローと責任分界が固まったら、それを機能要件と非機能要件に落とし込みます。機能要件は「何ができるか」、非機能要件は「どれだけの性能・品質で動くか」を定めるもので、OMSでは特に非機能要件が見落とされがちです。繁忙期のピーク負荷に耐える性能や、在庫同期のリアルタイム性といった非機能要件こそ、OMSの実用性を左右するため、機能要件と同等の重みで定義する必要があります。
機能要件を必須・優先・将来で分類する
機能要件は、すべてを同列に並べるのではなく、必須・優先・将来追加の三段階で分類します。複数チャネルの受注一元化、在庫引当、出荷指示、WMS連携といった「これがないと受注が回らない」機能は必須。レポート機能や需要予測、顧客分析などは優先または将来追加に回せます。OMSは機能を盛り込むほど費用が膨らむため、この優先順位付けが予算内で最大の効果を出す鍵になります。カスタマイズが全体の70%を超えるようなら、パッケージではなくスクラッチ開発を検討する判断材料にもなります。
分類の際は、各機能が「どの業務課題を解決するか」を明記しておくと、ベンダーとの認識合わせがスムーズになります。たとえば「在庫の一括引当機能」は「複数チャネルの売り越し防止」のため、という目的を添えれば、ベンダーは代替案も提案しやすくなります。機能要件を目的とセットで整理することが、要件定義書の質を高めます。優先順位の付いた機能要件は、後述するRFPでの提案依頼の中核資料となり、見積りの妥当性を判断する基準にもなります。
非機能要件（ピーク性能・在庫同期・可用性）
OMSの非機能要件で最重要なのが、繁忙期のピーク性能です。セールやテレビ放映で受注が平常時の何倍にも跳ね上がっても、注文取込・在庫引当・出荷指示が遅延なく処理できる性能を、具体的な数値（同時注文数、処理件数/秒など）で要件化します。ここを曖昧にすると、肝心の繁忙期にシステムが詰まって出荷遅延を起こします。あわせて、在庫同期のリアルタイム性（許容するタイムラグの上限）も、売り越しを防ぐ非機能要件として明記します。
さらに、可用性（システムが止まらない度合い）、セキュリティ（顧客情報・決済情報の保護）、現場操作性（臨時スタッフでもすぐ使えるUI）も非機能要件に含めます。受注が止まれば売上が止まるため、OMSは高い可用性が求められます。また顧客の個人情報や注文履歴を扱うため、セキュリティ要件は法令対応も含めて慎重に定義します。これらの非機能要件は、機能要件のように目に見えないため見落とされがちですが、OMSが現場で実用に耐えるかどうかを左右する決定的な要素です。要件定義の段階で数値目標まで落とし込むことが重要です。
拡張性も、OMSの非機能要件として軽視できません。事業が成長すれば、販売チャネルの追加、取扱SKU数の増加、出荷拠点の拡大、将来的なマテハン連携といった拡張が必要になります。導入時点の要件だけを満たすシステムを作ると、数年後に再構築を迫られ、二重投資になりかねません。チャネルや拠点を後から追加できる設計か、API連携の口が用意されているかを、将来の事業計画に照らして要件化しておくことが、長く使えるOMSの条件です。非機能要件は、いまの業務ではなく数年後の事業規模を想定して定義する視点が欠かせません。
RFPに盛り込む項目と見積り妥当性の判断
整理した要件は、RFP（提案依頼書）としてベンダーへ提示します。RFPは、各ベンダーから同じ土俵で提案と見積りを引き出すための共通仕様書です。RFPの質が低いと、ベンダーごとに前提がバラバラの見積りが集まり、比較できなくなります。OMS特有の連携要件や責任分界、ピーク性能までを盛り込んだRFPを作ることが、適正なベンダー選定と妥当な見積り取得の前提になります。
RFPに必ず盛り込むべき項目と従量課金の上限条項
OMSの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作成と見積り検証までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。