WMSリプレイスの発注は、発注前の業務整理、RFP（提案依頼書）での要件提示、契約と役割分担の確認の順に進めます。業務を整理してから要件を示すと、見積もりを比べやすくなり、稼働後の混乱も防げます。
各段階で何を決め、誰が何を担うかを、順に説明します。
▼全体ガイドの記事
・WMSリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMSリプレイスを外注・委託する前の整理事項
発注前に業務を棚卸しして優先順位を決めておくと、見積もりの精度が上がります。現場の運用と密接に結びつくWMSでは、この準備がトラブルの予防にもつながります。
自社で担う範囲と外注する範囲の切り分け
発注前に決めておきたいのは、自社と外注先のどちらが何を担うかです。工程ごとに担当を分けておくと、丸投げによる抜け漏れを防げます。
- 自社が担う業務：現場業務の棚卸しと、例外処理の洗い出し
- ベンダーに委ねる業務：システムの設計・開発・連携実装
丸投げにすると、現場特有の例外処理が漏れ、稼働後に在庫差異として表面化します。
進め方は、現状業務分析（As-Is）で今の業務を把握し、要件定義（To-Be）で目指す業務を定めるところから始まります。その後、設計・開発、データ移行、テスト、並行稼働を経て本番稼働に進みます。データ移行の主担当やUAT（受け入れテスト）のシナリオ作成者も、発注前にたたき台を用意しておきます。
必須要件（Must）と希望要件（Want）の仕分け
現行機能をそのまま再現しようとすると要件が膨らみ、見積もりが想定の二倍、三倍に跳ね上がるケースも珍しくありません。そこで、機能要件をMustとWantに仕分けて、要件の膨張を防ぎます。
- Must：ないと業務が止まる必須要件
- Want：あれば便利な希望要件
過度なカスタマイズが属人化やブラックボックス化を招いている場合は、Fit to Standard（標準機能に業務を寄せる考え方）への転換が有効です。そのためには、現行のカスタマイズを一つずつ洗い出し、必要な理由を業務の目的から問い直します。
たとえば入出荷の実績を見ると、月に数件しか使われない例外機能のために、高額な追加開発を抱えている例も少なくありません。
Mustに絞った要件リストを固めておけば、各社の見積もりを同じ条件で比べられます。さらに、過剰なカスタマイズの提案にも冷静に対応できます。
WMSリプレイスの発注先の種類と選び方
発注先は、SaaSベンダー、パッケージベンダー、スクラッチ開発会社の三つに大別できます。近年は、AI駆動開発を取り入れた開発会社も新たな選択肢として台頭しています。得意領域やコスト構造、リスクはそれぞれ異なるため、自社の業種特性と要件に照らして候補を見極めます。
SaaS・パッケージ・スクラッチの違いと向き不向き
提供形態の違いは、初期費用と継続費用、業務への適合度に表れます。比べる際は、自社の出荷や拠点の見通しと合わせて検討します。
- SaaS：初期費用を抑えやすく、数ヶ月で導入できます
- パッケージ：業種特化型なら標準機能で業務に合わせやすい形態です
- スクラッチ：自社業務に合わせられますが、期間と費用がかかります
SaaSの月額従量課金は、5年や7年といった中長期で割高に転じることがあります。たとえば、初期0円・月20万円のSaaSは5年で1,200万円に達します。一方、初期100万円・月10万円のパッケージは5年で700万円に収まるため、費用の関係が逆転します。
業種特化型のパッケージなら、アパレルの色・サイズや食品の賞味期限・温度帯を標準機能で管理でき、業務への適合度を高められます。これに対し、スクラッチは開発に半年から1年以上かかり、高額になりがちです。
出荷件数の増減見込み、拠点数、マテハン連携も、選定時に確認しておきたい条件です。形態ごとの費用は、見積相場の記事であわせて確認できます。
AI駆動開発という新しい選択肢と見抜き方
従来は「パッケージで妥協するか、スクラッチで高額を払うか」という二択が常識でした。
一方で、AI駆動開発により、工期とコストを30〜70%圧縮してスクラッチ開発を行える道も開けています。提案書の見栄えからは発注先の実力を測りにくいため、確認する観点を決めておきます。
- 開発の適合性：パッケージ並みの予算で、自社に100%フィットするWMSを構築できるか
- 実績と連携：WMS導入の実績件数、ERPやOMSとのAPI連携の経験
- 物流業務への理解：在庫の時点整合性や例外処理への向き合い方
- 移行経験：過去のデータ移行の失敗と対処を語れる会社は、信頼に値します
会社選びの観点は、おすすめ開発会社の記事でも確認できます。
丸投げを避けるRFP（提案依頼書）の書き方
RFP（提案依頼書）は、複数のベンダーを同じ条件で比べ、丸投げを防ぐための文書です。情報が不足すると提案の前提がばらつき、見積もりを比べられなくなります。完璧な仕様書である必要はなく、判断に必要な情報を過不足なく伝えることが大切です。
RFPに必ず盛り込むべき項目
RFPには、提案と見積もりの前提になる情報を記載します。あわせて、物流業務の理解度や移行・稼働後の体制も比較できるようにします。
- プロジェクト情報：目的、背景、現状業務、対象範囲
- 要件と計画：Must・Want、想定スケジュール、予算感
- 評価基準：業務理解、移行支援、稼働後サポートも含める
刷新の背景は、老朽化やサポート終了（EOSL）、EC化による出荷増、属人化の限界などを具体的に書きます。そうすると、ベンダーは本質的な提案をしやすくなります。
あわせて、1日あたりの出荷件数、在庫アイテム数（SKU）、拠点数を示します。ピッキング方式や現在使用しているハンディ端末の台数も示すと、見積もりの精度が上がります。
安さだけで選んで後悔しないよう、価格以外の観点も評価基準に加えます。
自社特有の例外処理・連携要件の伝え方
在庫が合わなくなる原因の多くは、現場の「良かれと思った」例外処理にあります。これらをRFPに明記しないと、ベンダーは標準フローしか想定しないため、稼働後に在庫差異が表面化します。標準フローから外れた例外は、返品の数え方、破損品の在庫の扱い、記録のない持ち出しの三つに表れやすいものです。
- 返品単位：2個1セットの商品が1個だけ返品されるケース
- 破損品：物理隔離後に論理ステータスを変え忘れるケース
- 持ち出し：記録を残さずサンプルを持ち出す行為
連携先は、ERP、OMS、TMSのほか、自動倉庫やAGV・AMRなどのマテハン機器です。そのうえで、リアルタイムAPIか日次CSVか、接続の要否も明記します。
ERPとのCSV手動取り込みで二重入力や転記ミスが常態化している場合は、その解消を要件として書き込みます。例外処理と連携要件の書き方が、丸投げになるか、適切な発注になるかを分けます。
契約・撤退時に確認すべき条項
新ベンダーとの契約条項だけでなく、旧システムからの撤退条件も確認しておきます。隠れコストの多くは撤退時に発生するため、出口戦略（Exit戦略）を発注前から織り込んでおくことが、総コストを抑えるうえで欠かせません。
旧DBアクセス権とデータ引き上げ費用
旧DBに自社で直接アクセスできず、旧ベンダーに依存する契約は要注意です。移行テストやリハーサルのたびにCSV抽出を依頼すると、1回あたり数十万円のスポット費用を請求されることがあります。抽出はテストとリハーサルで何度も繰り返されるため、費用が累積していきます。
契約では、次の項目を確認し、可能な範囲で交渉します。
- 旧契約：解約条件、データ引き上げ条項、DBアクセス権の所在
- 移行期間：データ抽出を定額か無償にできるか（可能であれば交渉）
- 新契約：将来、自社でデータを自由に取り出せる権利の明記
解約条件と倉庫移転を伴う場合の注意点
解約時にどのような費用が発生するかは、契約前に確かめておきます。なかでも、早期解約違約金があるか、ある場合は金額がいくらかを必ず確認します。倉庫移転も同時に進める場合は、旧倉庫の撤退費用も大きくなります。
- 発生しうる費用：出庫作業費、早期解約違約金、割増保管料、棚卸費
倉庫を移す場合は、一覧の費用のほかに移動手数料が発生し、その額が月額保管料の3〜6ヶ月分に相当する場合があります。倉庫移転とシステム刷新を同時に行うと、業務停止と移行のリスクが重なり、現場負荷が高まります。そのため、段階的な移転を計画し、出荷停止期間が生じる場合はバックオーダー（未出荷の受注残）の処理を決めておきます。
契約と撤退の条件は、システム費用だけでは見えない総所有コストの要素です。発注判断の前に、必ず洗い出します。
外注先と握るべき役割分担と責任範囲
役割や責任が曖昧なままだと、発注後のトラブルにつながります。複数のベンダーが関わる場合も、障害時の担当が決まらない事態を避けるため、責任分界点を文書にして合意しておきます。
データ移行とUATシナリオの責任分担
失敗の7割はデータに起因するといわれます。そのため、マスタのクレンジングや名寄せ、在庫残高の時点整合性を誰が担うかを、事前に明確にします。
- 対象データ：過去12ヶ月入出荷実績のないマスタや休止ロケーションを捨てる「12ヶ月ルール」
- 移行方式：抽出から投入までの時間差の吸収方法と、差分移行か週末停止後の一括切替かを決める
判断基準の設定者と、データ精査の担当者も合意します。在庫の時点整合性は、移行方式と切り離さずに考えます。
UAT（ユーザー受け入れテスト）の標準業務フローは、ベンダーが用意できます。一方、自社特有の例外は、業務を知る自社が主体となってシナリオを作ります。セット品のバラ返品、不良品のステータス変更、繁忙期の大量出荷などもテストに含めます。例外を網羅しないと、本番で初めて分かる不具合を抱えることがあります。テストデータの準備、テストの実施、合否判定の役割も、発注時に決めておきます。
並行稼働・ロールバックの責任とExit Criteria
並行稼働（パラレルラン）は、新旧システムを一定期間動かし、新システムの正しさを検証する工程です。役割分担が結果を左右します。
- 指示系統：物理作業指示書は新システムだけから出し、統制担当を置く
- 終了条件：出荷エラー率0.5%未満、API連携の4週間連続安定稼働などを基準にする
- 切り戻し：重大障害時の判断基準と権限、旧環境の保持期間の取り決め
新旧両方からピッキングリストや送り状を出すと、指示が二重化し、重複ピッキングや誤出荷につながります。
基準を満たしたら、本番を新システム一本にする段階へ移ります。その際は、棚卸差異率やエラー率の水準と、旧システムへ戻す判断者を決めておきます。
旧システムと旧ハンディ端末は、稼働後も最低3ヶ月保持しておくと、切り戻せない事態を防ぎやすくなります。
WMSリプレイス外注でよくある失敗と回避策
WMSリプレイスの外注では、過去の事例から繰り返し起きる失敗パターンがあります。事前に知っておけば、発注設計の段階で対策を織り込めます。代表的な失敗は二つあります。
ベンダー丸投げによる例外処理漏れ
最も多い失敗は、要件定義を丸投げした結果、現場の例外処理が抜け落ちることです。ベテランが無意識に行う細かな運用は、表面的なヒアリングでは見えにくいものです。対策としては、現場の例外を洗い出し、RFPと要件定義に反映します。
- 稼働後のリスク：在庫差異や特定出荷のエラーが起き、追加開発で予算が膨らむ
- 業務レビュー：現場担当者と複数回確認し、過去の在庫差異の原因を共有する
- 発注先の選定：選定段階から、物流ノウハウのある会社と一緒に例外処理を掘り起こす
繁忙期切替と現場教育不足
切替時期と教育内容をあらかじめ決めておくと、繁忙期の混乱や操作習熟の遅れを抑えられます。
- 切替時期：二重入力で工数が1.5〜2倍になる並行稼働は閑散期に行う
- 日程計画：年末商戦やセールなどの繁忙カレンダーを共有して逆算する
- 現場教育：操作研修、マニュアル作成、稼働直後の現地支援を役割に含める
現場の人が操作を身につけてはじめて、システムの力が在庫精度に表れます。
現場の実情を踏まえる点では、フリーロケーションの設計でも、フォークリフトの旋回半径や重量物の配置、作業者の熟練度を考慮に入れます。理論上の最適化を進めても、実際のピッキング速度が落ちることがあります。
まとめ
発注や外注、委託を成功させるには、自社が主導して準備することが欠かせません。まず自社と外注先の役割を分け、MustとWantを仕分けます。
RFPでは、例外処理や連携要件を示します。発注先は提供形態ごとの特性を踏まえ、価格だけでなく物流ノウハウと開発力を見て選びます。
旧DB権限、データ抽出費用、倉庫移転の手数料を把握し、撤退コストを契約に織り込みます。データ移行とUATの役割、並行稼働の指示系統、Exit Criteriaと切り戻しの責任は、文書に残しておきます。
これらを発注設計に反映し、自社に合ったパートナーとWMSリプレイスを進めてください。
▼全体ガイドの記事
・WMSリプレイスの完全ガイド
▼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を創業。