倉庫管理システムの要件定義は、責任分界、連携と例外処理、移行と現場評価を固めてRFPにまとめるのが基本の流れです。この順で進めれば、導入後の欠品や形骸化を防ぎやすくなります。
個々の項目の位置づけは、倉庫管理システムの完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・倉庫管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMS/OMS/WCS/WESの責任分界の要件
要件定義は、システム間の責任分界を固めるところから始めます。役割が曖昧なままだと、機能に空白や重複が生まれ、リリース後に欠品や責任の押し付け合いが起きます。
倉庫管理では、業務ごとにシステムの役割を割り当てます。WMSは倉庫のモノの管理、OMSは受注、つまり注文の管理を担い、WCSはマテハン機器の制御を受け持ちます。WESは両者をつなぎ、実行を最適化する層です。
WMSとOMSの在庫連携の要件
在庫連携では、在庫の正をどのシステムが持つか、どのタイミングで同期するかを先に決めておく必要があります。
- 在庫の正：在庫数を管理するシステムの指定
- 同期タイミング：リアルタイムか、何分間隔のバッチか
- 引き当て：注文に対して在庫をどこから割り当てるか
- システム構成：一体型（WMS+OMS）か、別々に選んだうえでAPI連携するか
参照在庫と現物在庫の間にタイムラグがあると、欠品や過剰受注が起こります。ECで在庫ありと表示されたまま実際は欠品している、という売り越しが構造的に生じることもあります。
在庫連携は技術的に難しく、後から直すと影響範囲が広がります。だからこそ、要件段階で時間をかけて詰めることが、欠品や過剰受注の予防につながります。
要件定義書では、入荷・出荷・引き当て・取消の各イベントごとに、双方の在庫がどう変わるかを図で示しておきます。
自社EC・複数モール・店舗など、複数のチャネルで同じ在庫を売る場合は、チャネルごとの在庫配分も決めておきます。全在庫をすべてのチャネルに見せると、ある一つのチャネルの急な売れ行きが、他チャネルの売り越しを招きます。
在庫の扱い方には、チャネルごとに在庫枠を割り当てる方法と、共有在庫としてリアルタイムに同期する方法があります。自社の販売戦略に合わせ、配分と同期の両方を要件として書き出します。
WCS/WESとの分界と例外処理の要件
自動倉庫やコンベアを使う場合は、WMSとWCS/WESの境界を先に決めておきます。製品によって機能の境界が異なるため、必要な機能がどの層に属するかを整理します。
- WMS：在庫と作業の管理
- WCS：マテハン機器の制御
- WES：両者をつなぐ実行の最適化
- 責任分界点：複数ベンダーの担当範囲の明文化
担当範囲が不明確なままだと、トラブルが起きたときにベンダー同士で責任を押し付け合うおそれがあります。そのため、どこまでが各ベンダーの責務かの線引きを要件書に書いておきます。
例外処理には、欠品時のバックオーダー（入荷待ちでの後日出荷）と分納（複数回に分けた出荷）があります。ほかに、誤受注の取り消しや返品の再入庫もあります。
正常系だけを要件にすると、例外が起きるたびに現場が手作業で対応することになります。そこで、AsIs（現状業務）の聞き取りで例外を洗い出し、ToBe（あるべき姿）の流れで各システムの処理を決めます。
マテハン連携と外部システム連携の要件
WMSは、ERPやEC、配送会社などの外部システムや、自動倉庫・ハンディなどの機器とつながって効果を発揮します。なかでも、連携範囲は見積りの精度を左右します。
連携の範囲が曖昧なままだと、ベンダーは正確に見積もれず、稼働後に追加費用が発生します。連携要件は、要件定義のなかでも丁寧に詰めておきたい部分です。
連携範囲・方式・データ項目の定義
外部連携では、接続先・データ・連携方向・タイミングの4点を定義します。具体的には、ERPとは在庫・入荷・出荷実績を、ECやモールとは受注と在庫数を、配送会社とは送り状データを連携します。
- 基幹システム：会計・販売との連携は100〜500万円
- ECモール：1モールあたり20〜100万円
- 配送会社：1社あたり30〜80万円
- 取引先独自システム：50〜500万円以上
連携方式は、API・CSV・ファイル連携から選び、データ項目と合わせて明記します。連携先が増えるほど費用は積み上がるため、初期に必要なものと将来でよいものを分けて考えます。
マテハン連携では、接続する機器を具体的に特定します。機器の種類ごとに、連携費用の目安も異なります。
- バーコード・ハンディ接続：50〜500万円
- 自動倉庫・コンベア・オートピッカー：WCS制御で500〜1,000万円
- ピッキングロボット・AGV：1,000〜3,000万円以上
既設の古い自動倉庫では、接続の相性やインターフェースの有無を事前に確かめておきます。確認が不十分なまま進むと、想定より費用が膨らみます。
複数のベンダーが関わる場合は、責任分界点を要件書に明記しておきます。そうしておくと、後から責任の所在を確かめやすくなります。
従量課金のコスト上限条項
クラウド型WMSでは、従量課金の条件を要件と契約の段階で確かめておきます。ある料金例では、基本料金が月3〜10万円で、ユーザー1人あたり0.5〜3万円が加算されます。
別の料金例では、出荷1,000件あたり1〜5万円が加算されます。平常時は安くても、繁忙期に出荷件数が数倍になると月額が急増し、いわゆる「コスト爆発」が起こり得ます。
- ピーク時の試算：繁忙期の出荷件数を前提にした年間費用
- 超過時の単価：一定件数を超えた場合の料金
- 年間上限：課金に歯止め（キャップ）があるか
出荷件数が大きく変動する事業では、従量課金より固定料金や定額プランが有利になる損益分岐点があります。その分岐点の条件を、ベンダーに確認しておきます。
クラウド型の5年TCOは180〜1,800万円です。この開きの多くは従量部分から生じるため、上限条項は想定外の高額請求を防ぐ助けになります。
データ移行と現場操作性の評価軸
機能要件や連携要件が固まっても、データ移行と現場操作性は見落とされやすい項目です。両方を要件と評価軸に入れておけば、導入後のギャップを防げます。
倉庫管理システムは、作業者が毎日使う道具です。高機能であっても操作性が悪ければ、現場では使われなくなります。
既存のExcelや旧システムからのデータ移行では、隠れたコストと工数が発生しやすいものです。そのため、要件として取り上げ、見積もっておきます。
データ移行の範囲と隠れコストの要件
データ移行では、移行の対象と履歴の範囲、移行元データの品質を決めておきます。移行対象には、商品マスタや取引先マスタのほか、ロケーション、在庫数、過去履歴があります。
Excelで管理してきた倉庫では、表記ゆれや重複、欠損が多く、そのまま移行できないケースがほとんどです。そのため、データクレンジング（整理・名寄せ）の工数も見込んでおきます。
- 移行対象：データの種類と件数、引き継ぐ履歴
- 移行元の品質：現状のデータに、どの程度の手直しが要るか
- 移行方式：手作業の再入力か、変換ツールによる一括取り込みか
- 移行後の検証：データの正しさを確かめる方法
稼働直前にデータが入らない事態や、誤ったマスタによる在庫差異・誤出荷を避けるには、移行と検証の工数を計画に含めておくことが欠かせません。
RFPには、移行の内容とスケジュールを書いておきます。そのうえで、ベンダーに作業工数と費用を示してもらえば、見積りの漏れを防げます。また、データ移行・ハンディ・保守費は、WMSの隠れコストとして要件段階から織り込む項目です。
現場操作性をデモで評価する基準
現場操作性は、カタログのスペックでは見極めにくいものです。そこで、要件定義の段階で、実機デモを作業者に試してもらう評価方法を決めておきます。
- 画面と指示：ハンディ画面の見やすさ、ピッキング指示の分かりやすさ
- 誤読への対応：読み取りを誤ったときの警告の有無
- 習得しやすさ：繁忙期の臨時スタッフが短時間で操作を覚えられるか
操作性が良ければ、教育コストが下がり、人を増やした分だけ処理量も伸ばせます。一方で、操作性が悪いと、現場は旧来の方法に戻り、システムが形骸化するおそれがあります。
複数の製品を公平に比べるには、評価軸を具体的な項目に分けておく必要があります。たとえば、1注文あたりのピッキング操作回数、新人が一定の精度に達するまでの時間、例外時の手順の分かりやすさを評価表に載せます。
デモでは、評価表に沿って各製品を採点します。現場の納得感は導入後の定着率に直結するため、操作性も要件に含めておきます。
非機能要件（性能・可用性）の数値定義
性能と可用性も、現場操作性と合わせて要件化します。大量のSKUを抱える倉庫では、在庫照会の速さや、繁忙期に多くの作業者が同時に使うときの応答が重要になります。
- 処理規模：想定する商品数と1日の入出荷件数
- 同時利用：ピーク時の同時接続数
- 稼働と復旧：稼働率の目標、障害時の復旧時間（RTO）
- バックアップ：頻度とデータの保持期間
数値があれば、ベンダーは適切なインフラ構成を見積もれます。性能の条件が曖昧なままだと、繁忙期に画面が重くなり、作業が止まるおそれがあります。
受発注や出荷が止まると取引に影響するため、可用性の条件も定めておきます。クラウド型では、SLA（サービス品質保証）の範囲を確かめ、要件と突き合わせます。
非機能要件も機能要件と同じ程度に詰めておけば、稼働後の「遅い」「止まる」といった問題を防げます。現場の信頼を保つうえでも、この詰めは欠かせません。
RFPに盛り込む項目と体制要求
要件定義書をもとにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質は、提案や見積りの質を左右します。
RFPが曖昧だと、ベンダーの提案を横並びで比べられません。構築形態によって費用の幅が大きいWMSでは、RFPで提案の前提を揃えておくことが、見積りを判断するうえで欠かせません。
RFPに必ず盛り込む項目
RFPには、プロジェクトの目的と、業務の現状・目標を書いて共有します。あわせて、KGI（誤出荷率の削減、棚卸し時間の短縮、出荷能力の向上など）も示します。
- 業務・機能：AsIsとToBeの業務フロー、基幹・先端機能を必須・優先・将来で分類した機能要件
- システム・データ：責任分界、外部・マテハン連携の範囲と方式、移行対象
- 費用・計画：従量課金の上限、予算、スケジュールの目安
- 倉庫固有の条件：ロット・賞味期限・複数荷主・繁忙期の物量変動
非機能要件には、性能・可用性・セキュリティを含めます。性能は、商品数（SKU数）や1日の入出荷件数、ピーク時の同時アクセス数を数値で示し、稼働率の目標もあわせて書きます。
受発注への影響を踏まえて、障害時の復旧時間やバックアップ体制も定めておきます。条件を明記すれば、ベンダーはインフラ構成と運用体制を見積もれます。
曖昧な要件は曖昧な見積りを生むため、RFP全体で要件の具体性を保ちます。
体制要求と見積り内訳の確認
RFPで見落とされがちなのが、体制要求です。体制図の提出を求め、実際に開発を担当する人やPM、保守担当者が誰かを確かめます。
コンペでエース級の人材が提案しても、実際の開発は別の下請けが担うことがあります。体制を確かめないままだと、リリース後に障害が多発するおそれがあります。
運用支援やSLA（サービス品質保証）も見ておく必要があります。保守体制と問い合わせ対応の範囲を確かめ、改正物流効率化法などの制度の動きに追随できるかも見極めます。
見積りの妥当性は、まず相場観で判断します。方式によって初期費用と5年TCOの幅が大きく違うため、方式ごとの目安を並べておきます。
- クラウド型：初期0〜100万円、5年TCO 180〜1,800万円
- パッケージ／オンプレ：初期500〜3,000万円、5年TCO 800〜6,000万円
- フルスクラッチ：初期3,000万〜1億円以上、5年TCO 5,000万〜1億3,000万円以上
相場から外れる場合は、その理由を確かめます。見積りの内訳で「テスト・デバッグ費」や「ディレクション費」が一式にまとめられているなら、詳細の開示を求めます。また、カスタマイズが全体の70%を超える場合は、スクラッチ開発も検討します。
riplaは、フルスクラッチ受託と国内開発の立場から、要件の透明な整理と見積り内訳の明示を重視しています。
RFP段階での補助金の活用可否
WMSの投資額を抑える手段として、RFP段階で補助金を活用できるかを確認しておきます。候補には、IT導入補助金、ものづくり補助金、中小企業省力化投資補助金などがあります。
- 対象可否：検討中のWMSが対象になるか
- 申請支援：ベンダーによる申請支援の可否
- 計画への反映：申請・採択・交付までの期間を織り込んだ見通し
制度によっては、対象ITツールの事前登録や、申請書類・スケジュールの要件が定められている場合があります。さらに、公募要件や採択条件、日程は年度ごとに変わります。
導入の時期に合わせて制度を確かめ、補助金を当てにして身の丈に合わない構築形態を選ぶことは避けます。
まず適切な要件と形態を固め、そのうえで補助金は負担を軽くする手段として扱います。要件定義の精度が高いほど、申請に必要な事業計画も書きやすくなります。
まとめ
倉庫管理システムの要件定義は、WMS/OMS/WCS/WESの責任分界を固め、在庫連携と例外処理を明確にすることから始まります。
連携費用の目安は、基幹システムが100〜500万円、ECモールが1モールあたり20〜100万円です。自動倉庫は500〜1,000万円、AGVは1,000〜3,000万円以上です。
要件には、従量課金の上限、データ移行の隠れコスト、現場操作性の評価軸も含めます。RFPには、目的、非機能要件、体制要求も書き込みます。
具体的な要件を揃えておけば、ベンダーの提案を横並びで比べられます。見積りは相場と照らし合わせて、妥当かどうかを判断します。
5年TCOの目安は、クラウド型180〜1,800万円、パッケージ／オンプレ800〜6,000万円、スクラッチ5,000万〜1億3,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を創業。