WMSのRFPや要件定義書は、WMSと上流・下流のシステムとの責任分界を決めることから組み立てます。
連携の境界を要件として正しく決められるかで、現場に使われるWMSになるか、使われず放置されるかが分かれます。全体像をまだつかめていない方は、まずWMSの完全ガイドを読むことをおすすめします。
▼全体ガイドの記事
・WMSの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMS/OMS/WCS/WESの責任分界の要件化
WMSの要件定義でまず行うのは、隣接するシステムとの役割分担を明確にすることです。倉庫まわりには、WMS（倉庫管理）、OMS（受注管理）、WCS（倉庫制御）、WES（倉庫実行）といった似た略語が並びますが、それぞれが担う範囲は異なります。
役割を整理しないまま開発に進むと、機能の重複や抜け漏れが生じ、責任の押し付け合いにもなります。
WMSとOMSの役割分担の明確化
WMSは「倉庫の中のモノ」を管理し、OMSは「注文（受注）」を管理します。受注の取り込み、在庫の引き当て、出荷指示の発番までをOMSが担い、倉庫内の入出庫・ピッキング・検品をWMSが担うのが、一般的な分担です。
ただし、どこまでをOMSが、どこからをWMSが担うかは、製品やプロジェクトによって異なります。だからこそ、要件定義で「在庫の引き当てはどちらが持つのか」「出荷指示の単位はどちらが決めるのか」を明文化しておく必要があります。
多くの競合解説は、この役割分担の説明が不足しています。実務でもっとも危険なのは、OMSとWMSの連携にタイムラグがあり、在庫情報が一致しないことです。
たとえば、OMSが「在庫あり」と判断して受注を取ったのに、WMS側ではすでに引き当て済みで欠品していた、といった事態が起きます。こうしたずれを防ぐには、OMSとWMSの在庫をどう揃えるかを要件定義の段階で先に決めておく必要があります。
- 在庫の同期方式：リアルタイムかバッチかの別、同期の頻度、不一致時の優先ルール
- システム構成：一体型（WMS+OMS統合）にするか、API連携にするかの選定基準
この役割分担を文書化するときは、データの流れを図にして、「在庫の真実（マスタ）」をどのシステムが持つのかを一つに決めることが肝心です。在庫マスタが2か所に分散すると、どちらが正しいか分からなくなり、不整合の温床になるからです。
OMSが受注を取り、WMSが実在庫を持つ形で、両者をどう同期させるかを要件定義書に明記しておけば、ベンダーは迷わず実装でき、後の「言った・言わない」の紛争も防げます。
役割分担の明文化は地味ですが、連携トラブルを根本から減らす最重要の作業です。
WCS・WESとの境界と責任分界点
自動倉庫やコンベア、ソーターといったマテハン機器を使う倉庫では、WCS（倉庫制御システム）とWES（倉庫実行システム）が関わってきます。WCSは個々の機器を制御し、WESはWMSとWCSの中間で作業全体を最適に実行する役割を担います。
具体的には、WMSが出した出荷指示を、WESがどの機器でどう実行するかに翻訳し、WCSが機器を動かす、という階層になります。この三層の境界を要件で定義しておかないと、機器が思った通りに動かないとき、原因の切り分けができません。
WMS/WCS/WESの役割の違いを体系的に解説した記事は少なく、ここは要件定義で見落とされがちな領域です。とくに古い自動倉庫が既設の場合、その制御システムとの接続相性や、ベンダー間の責任分界点が問題になります。そのため、WMSの指示範囲と、その先を担うシステム・ベンダーの境目を、要件定義の段階で書き残しておく必要があります。
- 担当範囲の整理：WMSの指示範囲と、その先の制御を担うシステム・ベンダーを図で示すこと
- 障害時の一次切り分け：誰が行うかまで取り決める（責任の押し付け合いを防ぐ唯一の方法）
マテハン連携・外部連携の要件化
責任分界を整理したら、次は具体的な連携要件を定義します。WMSは、上流の基幹・OMS・ECや、下流のマテハン機器・配送会社と数多く連携するため、この定義が欠かせません。
連携の範囲と方式が要件で明確でないと、ベンダーは正確な見積りを出せません。その結果、後から「その連携は別費用」というトラブルになります。
既設マテハン機器との接続相性の要件化
自動倉庫・コンベア・オートピッカー・AGV（無人搬送車）といったマテハン機器との連携は、WMS要件定義の難所です。
とくに既設の古い機器がある場合は、その制御システムが提供する連携インターフェースを事前に調べ、新WMSと接続できるかを確認する必要があります。接続相性を確認しないまま要件を固めると、リリース直前に「この自動倉庫とは繋がらない」という致命的な問題が見つかります。
マテハン連携の費用は、規模によって変わります。バーコード・ハンディ接続は50〜500万円、自動倉庫・コンベア・オートピッカー（WCS制御）は500〜1,000万円です。また、ピッキングロボット・AGVでは、1,000〜3,000万円以上が目安です（出典：ripla）。
費用相場だけを示す競合記事が多いなか、接続相性とベンダー間責任の事前確認まで要件化することが、差別化になります。連携の範囲をどこまで見込むかは、この段階で固めておく必要があります。
- 連携の対象：どの機器を、どのフェーズで連携させるか
- 拡張への備え：将来のマテハン拡張を見据えた連携設計（後の大規模な作り直しを避けるため）
ERP・EC・配送会社連携の要件化
上流・周辺システムとの連携要件も、詳細に定義します。基幹システム（会計・販売）との連携では、受注・在庫・出荷・請求のどのデータを、どの方向に、どのタイミングで連携するかを定めます。
ECモールや自社ECとの連携では、注文データの取り込みと、在庫の引き当て・反映の方式を決めます。配送会社との連携では、送り状発行や追跡番号の連携方式を整理します。
連携費用は接続先ごとに異なり、基幹システムで100〜500万円、ECモール1モールで20〜100万円、配送会社1社で30〜80万円です。また、取引先独自システムでは50〜500万円以上が目安です（出典：ripla）。
連携先が多いほど費用とリスクは積み上がるため、要件定義で連携範囲を絞り込むことが、コスト管理の生命線になります。既存システムの連携インターフェース（API・CSV・ファイル連携）を事前に把握しておかないと、ベンダーは見積りを出せません。連携要件の精度によって、見積りの妥当性を判断できるかどうかが決まります。
すべてを一度に連携しようとせず、効果の大きい連携から着実に繋ぐのが現実的です。段階的に広げていけば、予算超過を避けながら拡張できます。連携の順番と接続方式は、次のとおり決めます。
- 連携の優先順位：初期リリースで必須の連携と、後から追加してよい連携の切り分け
- 接続方式：接続先ごとの連携方式の確定
従量課金のコスト上限条項の要件化
クラウド型WMSの多くは、出荷件数やユーザー数に応じた従量課金を採用しています。月額の安さに惹かれて契約すると、繁忙期に出荷が急増した途端に料金が跳ね上がる、というコストの落とし穴にはまります。
要件定義とRFPの段階で従量課金のコスト構造を明確にし、上限条項を取り決めておくことが、予算超過を防ぐ重要な防衛策です。
繁忙期の出荷急増を見込んだ料金要件
クラウド型WMSの料金は、基本料3〜10万円に加え、ユーザー1人あたり0.5〜3万円、出荷1,000件あたり1〜5万円、オプション1〜5万円などの従量部分で構成されるのが一般的です（出典：ripla）。
問題になるのは、セールや歳暮シーズンに出荷件数が数倍に跳ねる業態です。通常月の出荷件数で月額を試算していると、繁忙期に出荷課金が膨らみ、年間コストが想定を超えてしまいます。
これを防ぐには、要件定義の段階で、自社の年間の出荷件数の変動（最繁忙月と通常月の差）を把握し、ピーク時の料金を試算しておくことです。
月額の安さだけで選ぶと、繁忙期のコスト爆発を招きかねません。多くの解説は、この点の注意喚起が不足していますが、ここを要件に組み込むことが堅実な選定につながります。
- 見積りの範囲：繁忙期も含めた年間総額
- ピーク時の料金条項：出荷件数が一定を超えた場合の料金上限と、段階的な単価逓減の条項
5年TCOによる料金妥当性の判断
料金の妥当性は、月額単体ではなく5年TCO（総保有コスト）で判断します。クラウド型WMSの5年TCOは180〜1,800万円、パッケージ/オンプレ型は800〜6,000万円です。
また、フルスクラッチは5,000万〜1億3,000万円以上が目安です（出典：ripla）。形態によって総額の幅が大きいため、同じ条件で比べることが大切です。要件定義で従量課金とTCOの構造を明確にすることは、長期的な投資判断を支えます。
とくに注意したいのは、データ移行費・ハンディ端末費・保守費といった隠れコストです。月額だけが安く見えても、これらを加えると総額が逆転することがあります。
RFPでは、隠れコストを含む費用の示し方を、ベンダーと先に取り決めておきます。
- 5年分の総額：初期費用から教育費まで含めて提示
- 隠れコストの内訳：カスタマイズ単価（軽微10〜50万、中程度50〜200万、大規模500〜1,000万以上が目安）の事前合意
データ移行と現場操作性の評価軸
機能、連携、料金の要件が固まったら、見落とされがちな2つの要件を詰めます。その2つとは、既存データの移行と、現場の操作性です。どちらも要件定義書で軽視されやすいものの、リリース後の定着を左右します。
商品マスタ・在庫データの移行要件
WMS導入時には、既存の商品マスタ・取引先マスタ・在庫データを新システムへ移行する必要があります。Excelや旧システムで管理してきたデータは、表記ゆれや重複、不整合を抱えていることが多いため、そのまま移行すると新WMSでもエラーの原因になります。
データ移行は隠れコストになりやすいので、要件定義の段階で移行の中身を具体的に決めておく必要があります。ロケーション情報やバーコードの採番ルールは、移行にあわせて整備する好機です。旧来の曖昧なロケーション管理を、この機会に体系的なルールへ刷新すれば、新WMSの効果を最大化できます。
データ移行は、マスタを整える機会として要件に組み込みます。その設計が、導入後の在庫精度を左右します。
移行データの量と品質によっては、クレンジングに想定以上の工数がかかることもあります。そのため、RFPには次の内容を盛り込みます。
- 移行データの範囲：どのデータを、どのフォーマットで、どこまでクレンジング（整備）して移行するか
- 移行の検証：移行範囲と費用の明示、本番移行前のリハーサル（問題の洗い出し）
現場操作性をデモで評価する要件
WMSは、現場の作業者が毎日使うシステムです。どれだけ高機能でも、ハンディや作業画面が使いにくければ現場は定着しません。そこで要件定義の段階から、現場操作性を評価する仕組みをRFPに盛り込みます。
繁忙期には臨時スタッフが大量に入るため、教育コストの低さは大きな評価軸になります。デモで操作性を確認せずに機能リストだけで選ぶと、リリース後に「現場が使いこなせない」という事態に陥ります。
riplaはフルスクラッチ受託と国内開発の立場から、現場の作業フローをヒアリングし、操作性まで含めた要件整理と、見積り内訳を明示する進め方を重視しています。
データ移行と現場操作性という地味な要件こそ、WMS定着の成否を分ける最後の決め手です。
仕様書では機能一覧が目立ちますが、ここを丁寧に要件化できているかで、稼働後に現場が本当に使うシステムになるかが静かに決まります。具体的には、次のとおり評価します。
- ハンディの試用：操作デモをベンダーに求め、現場メンバーが実際に試すこと
- 習熟にかかる時間：新人や臨時スタッフが、何分で使えるようになるかの検証
保守・SLA・開発体制の要求
機能・連携・料金・データ移行の要件が固まったら、RFPで見落とされがちな保守・SLA・開発体制の要件を盛り込みます。
WMSは導入して終わりではなく、稼働後も止めずに運用し続ける必要があります。そのため、これらの要件がベンダー選定の最終的な決め手になります。
SLAと障害時の復旧体制の要件化
倉庫の出荷は、システムが止まると即座に物流全体が停止します。だからこそ、RFPではSLA（サービス品質保証）を明確に求めます。
クラウド型なら、提供事業者のSLAを確認し、自社の業務に耐える水準かどうかを判断します。
保守費用も要件で明確にします。オンプレ型では年300万円＋開発費の10%、あるいは開発費の8〜10%が年間保守費の目安です（出典：ripla）。
SLAと保守を曖昧にしたまま契約すると、稼働後の障害対応が後手に回り、出荷が止まるリスクを抱え込みます。改正物流効率化法への対応など、法令の変化に追従する保守があるかどうかも、あわせて確かめておく必要があります。こうした点は、SLAの中身と保守の範囲を数値と条件で書き残しておくことが欠かせません。
- 稼働と復旧の目標：稼働率の目標（たとえば99.9%）、障害時の受付時間、復旧までの目標時間、計画停止の事前通知
- 保守の範囲：障害対応のみか、軽微な改修も含むか、問い合わせ窓口の対応時間、繁忙期の優先サポート
開発体制と実装担当者のRFPでの確認
RFPで見落とされがちなのが、開発体制の要求です。「コンペにエース級の担当者が出てきたが、実際の開発は技術力の低い下請けが行い、リリース後に障害が多発した」という失敗は、WMS開発でも起こり得ます。
これを避けるには、RFPで体制図の提出を求めることが有効です。WMSは、倉庫の物流ノウハウとシステム技術の両方の理解が求められます。
人月単価は、年収600〜1,000万円クラスのエンジニアで人月100万円が一つの目安とされています。中規模WMS（20機能×各2人月）なら、開発費だけで4,000万円に上ります。
また、総額は5,000〜6,000万円が一般的です（出典：ripla）。RFPでは、プレゼンの上手さより、実開発体制と物流への理解度を確かめられる項目を盛り込むことが、ベンダー選定の最後の防衛策になります。
riplaはフルスクラッチ受託と国内開発の立場から、実装体制を透明にし、物流業務に即した開発を重視しています。RFPの段階で、実際に開発を担う人と体制を確かめておく必要があります。
- 体制図：提出と、開発担当者・PM（プロジェクトマネージャー）・再委託の有無の明記
- 体制の専門性：物流業務に精通した体制かどうかの確認
まとめ
WMSの要件定義・RFP・提案依頼書は、機能を並べる前に、WMS/OMS/WCS/WESの責任分界を整理することから始めるのが鉄則です。
そのうえで、マテハン連携の接続相性とベンダー間の責任、ERP・EC・配送会社連携の範囲を要件に落とします。さらに、従量課金のコスト上限条項と、データ移行・現場操作性の評価軸も押さえます。
連携費用（基幹100〜500万、配送1社30〜80万）や、5年TCO（クラウド型180〜1,800万、オンプレ型800〜6,000万）といった相場（出典：ripla）に照らせば、見積りの妥当性も判断できます。
WMSの要件定義は、自社の倉庫だけでなく上流・下流のシステムとの境界をどう引くかが本質です。
責任分界とコスト上限を曖昧にしたまま進めると、リリース後に在庫のズレと費用の膨張という二重のトラブルに直面します。
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を創業。