在庫管理システムのRFP(提案依頼書)と要件定義書では、役割分担、連携条件、費用上限を明確にし、移行条件や現場での検証まで定めておくと、各社の提案を同じ条件で比べて選べます。
記事の後半では、責任分界と連携要件を取り上げたうえで、従量課金とSLA、データ移行・操作性の評価軸を見ていきます。全体像は在庫管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・在庫管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMS/OMS/WCS/WESの責任分界の要件

在庫・倉庫まわりのシステムは役割が異なるため、境界が曖昧だとトラブルにつながります。そこで、RFPの段階で関連システムの役割と責任分界を最初に整理します。
発注側は、WMS・OMS・WCS・WESのどこまでを在庫管理システムが担い、どこからを別のシステムに任せるかを決めておきます。この役割整理が、要件定義の出発点になります。
WMS(モノ)とOMS(注文)の役割の切り分け
WMS(倉庫管理システム)は、入荷・保管・ピッキング・出荷など倉庫内の「モノ」を管理します。一方、OMS(受注管理システム)は、販売チャネルの注文をまとめて管理し、在庫の引き当てと出荷指示を行います。
- 課題の領域:倉庫作業の効率化か、注文と在庫をまとめて扱うかを明記
- システム構成:一体型か、専用システム同士のAPI連携か
両者の違いを押さえずに一括で依頼すると、受注まわりの機能を期待していても、倉庫機能だけが提案される場合があります。
一体型は連携の手間が少ない一方で、各機能の専門性は専用システムに劣ることがあります。API連携なら最適な組み合わせを選べますが、タイムラグや責任分界の設計が欠かせません。また、RFPには構成方針と、連携時のデータ同期の頻度・タイミングを記載します。
WCS(制御)・WES(実行)との分界点の明記
自動倉庫やコンベア、AGVなどを使う倉庫では、WCS(倉庫制御システム)とWES(倉庫実行システム)も関わります。WCSは機器を直接制御し、WESはWMSとWCSの間に入って、作業全体を調整しながら実行します。
- 担当ベンダー:各層をどのベンダーが担うかを明記
- 障害時の窓口:層をまたぐ不具合の一次窓口を定める
- 既設機器:機種・メーカー・通信仕様を示し、接続実績の有無を提案で問う
三層の責任分界が不明確だと、機器のトラブル時に責任をめぐって揉め、復旧が遅れるおそれがあります。
古い自動倉庫との接続相性は、見積もり段階では見えにくいリスクです。要件として早めに確認しておくと、追加費用やトラブルの防止につながります。加えて、WMS・OMS・WCS・WESの役割と責任分界を文書にしておくと、複数ベンダーが関わるプロジェクトの安全策になります。
マテハン・外部システム連携の要件

在庫管理システムは、ERPやEC、配送会社、マテハン機器などと連携します。要件を具体化しておくと、見積もりの精度が上がり、導入後の手戻りも防げます。連携費用はシステム費用に大きく影響するため、要件の精度が総額を左右します。
連携先・方式・費用相場の整理
各社の提案を同じ前提で比べるには、連携先と方式の範囲を揃えておく必要があります。
- 連携先:ERP、ECモール、配送会社、取引先独自システムを列挙
- 連携方式:APIかCSVか、リアルタイムかバッチかを定める
方式が曖昧なままだと、各社の見積もりは前提がばらばらになり、金額の差が何によるのかを比べられません。
連携費用の一次データでは、基幹(会計・販売)は100〜500万円、ECモールは1モールあたり20〜100万円、配送会社は1社あたり30〜80万円です。取引先独自システムとの連携は50〜500万円以上とされています。これらを連携要件ごとに概算すると、提案の見積もりを判断できます。
発注側がRFPに連携先と方式を示し、費用内訳を求めると、連携が別料金となる想定外を防げます。
マテハン接続要件と既設機器の仕様提示
マテハン連携は、接続対象によって費用と難易度が大きく変わります。将来の拡張を見込む場合は、今すぐ導入する予定がなくても、RFPに拡張の余地を記しておきます。
マテハン連携の要件は、接続対象ごとに慎重に定める必要があります。
- バーコード・ハンディ:接続費用は50〜500万円です。
- 自動倉庫など:WCS制御は500〜1,000万円です。
- ロボット・AGV:接続費用は1,000〜3,000万円以上です。
既設機器がある場合は、メーカーと機種、通信プロトコル、導入年を提示し、ベンダーに接続実績と相性を確認してもらいます。
古い機器は接続情報が乏しく、メーカーのサポート終了で改修が難しいこともあります。そのため、責任分界とあわせて、早い段階で明文化しておく必要があります。
既設機器との相性やベンダー間の責任分界は、費用相場の表には現れにくい実務上の壁です。RFPで早期に明記すると、リスク回避につながります。さらに、要件を戦略的に定めておくと、将来の省人化投資の自由度を保てます。
従量課金のコスト上限とSLAの要件

クラウド型では、出荷件数やユーザー数に応じた従量課金が一般的です。そのため、発注側は繁忙期の費用増に備えて、RFPでコスト条件を定めておきます。サービスレベル(SLA)も、契約条件として明記しておきます。
出荷急増時のコスト上限条項
一次データでは、クラウド型在庫管理システムの月額料金は3〜30万円が相場です。月額は、基本料金に加えて、ユーザー1人あたりや出荷1,000件あたりの従量料金と、オプション料金で構成されます。
セールなどで出荷が数倍になると、従量部分によって月額費用が想定を超えることがあります。こうした出荷急増時のコスト増は、料金表だけでは見落としやすい点です。
- 利用シナリオ:通常期と繁忙期の出荷件数・ユーザー数を提示
- 料金条件:一定件数超過時の単価逓減と上限条項の有無
- プラン比較:固定料金と従量課金の損益分岐点
各シナリオの月額見積もりを出し、自社の出荷量にどちらのプランが有利かを判断します。また、5年TCOはクラウドで180〜1,800万円とされており、繁忙期を含めた試算が想定外の出費を防ぎます。
SLA・運用支援・物流効率化法対応
出荷を止められない業務基盤では、サービス品質保証であるSLAの比較が欠かせません。出荷ピーク時の停止は、その日の出荷全体を滞らせるおそれがあります。そのため、可用性の保証は事業の継続性に直結します。
- 稼働・復旧:稼働率の保証と障害時の復旧目標時間を明記
- サポート:対応時間帯と連絡手段を確認
- 導入後:定着までの支援と更新の範囲を問う
導入時の研修だけでなく、運用が軌道に乗るまで伴走してもらえるかを確かめます。改正物流効率化法に応じた更新が保守に含まれるかも、あわせて問います。
一次データでは、パッケージ・オンプレミスの保守は開発費の10%前後です。たとえば、倉庫管理SLIMSでは、オンプレミス保守が開発費の8%とされています。
SLA・運用支援・法対応をRFPに盛り込むと、導入後の安心とベンダーの信頼性を確認できます。
データ移行・現場操作性の評価軸
データ移行と現場操作性は、機能一覧には表れにくいものの、導入の成否を左右します。そのため、提案やデモで確認できるよう、評価軸を明文化しておきます。
商品マスタ・在庫データの移行要件
データ移行の工数は、量と品質によって変わり、導入時の隠れたコストになりがちです。そのため、移行対象と現状を整理し、見積もりの前提を揃えておきます。
- 移行対象:商品・得意先マスタ、ロケーション、現在庫
- 作業範囲:整備の担当、リハーサル、在庫差異の扱いを決める
Excelの在庫表には、表記ゆれや重複、欠損が多い場合があります。そのまま移すと、新しいシステムでもデータの精度は出ません。
RFPでは、データ種別・件数・フォーマットを示したうえで、移行範囲と費用、データクレンジング(整備)の支援の有無を各社に尋ねます。移行が導入支援に含まれるとは限らず、別途見積もりになることもあります。作業を明示的に切り出しておくと、リリース直後の混乱を防げます。
現場操作性をデモで検証する評価軸
在庫管理システムは現場の作業者が毎日使うため、発注側は操作性の評価軸をRFPに組み込んでおきます。画面が分かりにくく操作に時間がかかると、現場に定着しないことがあります。
- 評価方法:現場スタッフによる実機デモ
- 確認する作業:入荷・ピッキング・出荷を担当者に操作してもらう
- 観察点:画面遷移、エラー時の挙動、教育に要する時間
繁忙期に入る臨時スタッフがすぐ使えるかは、教育コストと出荷キャパシティに関わります。そこで、カタログの比較に加えて、実際の操作を確かめます。
書面で適合していても、導入後にベテランしか使えない事態が起こることがあります。そうなれば、導入への投資が無駄になるおそれがあります。
現場ヒアリングで業務の流れを洗い出し、システムとの適合をデモで検証します。この一手間が、現場に定着するシステムを選ぶ最大の決め手になります。
補助金活用と非機能要件を見据えた要件整理
要件定義では、機能要件に加えて、費用負担を抑える補助金活用も視野に入れると、予算の見通しを立てる助けになります。
導入には、IT導入補助金、ものづくり補助金、中小企業省力化投資補助金を利用できる場合があります。
- 対象制度:利用を検討する補助金と申請要件
- 費用・契約:対象経費の範囲と契約の扱い
- 申請支援:活用の可否とベンダーの支援の有無を尋ねる
制度ごとに申請要件と対象経費があり、選ぶ制度によってシステム形態や契約方法が変わることもあります。申請支援を提案の中で確認すると、初期投資の負担を実質的に抑えられる場合があります。
非機能要件には、性能・可用性・セキュリティがあります。たとえば、ピーク時の同時アクセスや出荷の継続、在庫データや取引先情報の保護について、発注側は必要な水準を定めます。
これらは要件から漏れやすく、運用が始まってから表面化すると、対処に大きな費用がかかります。そのため、機能だけでなく、運用で守る水準まで文書にしておきます。
機能・連携・費用・移行・操作性に、補助金と非機能要件も加えて整理すると、抜け漏れのないRFPになり、選定後の想定外を防げます。
まとめ
RFPでは、WMS・OMS・WCS・WESの役割と責任分界を明確にし、外部連携と従量課金の上限、SLAも定めます。移行範囲と操作性も、評価の対象にします。
連携費用は基幹が100〜500万円、マテハン接続は50万円から3,000万円以上と幅があります。そのため、要件の精度が見積もりの精度と総額に影響します。
曖昧なRFPでは、提案を横並びで比べられず、開発後の追加費用やトラブルを招きます。
要件定義では、機能を網羅するだけでなく、自社業務と責任分界を文書で固めます。
現場ヒアリングで業務の流れを洗い出し、連携・費用・移行・操作性を要件に書き起こしたうえで、デモで検証します。この順序で進めると、自社に合う提案を引き出し、納得して選定できます。
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を創業。
