WMS移行の発注は、発注先の種類を把握し、社内の要件を整理し、RFP（提案依頼書）で候補を同じ条件で比べ、契約と役割分担を決める順に進めます。この流れを守ると、トラブルを未然に防げます。
▼全体ガイドの記事
・WMS移行の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMS移行の発注・外注先の選択肢
委託先は、SaaS、パッケージ、SIer、スクラッチ開発企業の4タイプに分かれます。得意分野と費用の構造が異なるため、業務の特性と予算に合わせて選ぶことになります。
同じ製品を使う場合でも、物流ノウハウやデータ移行支援の中身によって、稼働後の在庫精度や誤出荷率は変わります。特に、倉庫を止めずに在庫データを移す場面では、ベンダーへの丸投げが現場崩壊につながりやすいです。
4つの発注先タイプと向き不向き
各タイプの提供形態と強みを比べると、自社に合う発注先を絞り込めます。
- SaaS：月額課金で短期間に導入でき、業務を標準機能に合わせることが前提です。
- パッケージ：アパレルの色・サイズ管理や、食品の賞味期限・温度帯管理に強みがあります。
- SIer：複数システムや自動倉庫・AGVとの大規模な連携を得意とします。
- スクラッチ開発：自社業務に100%フィットできる一方、費用と期間がかさむ傾向にあります。
AI駆動開発では、工期とコストを従来比で30〜70%圧縮できるケースもあります。さらに、パッケージ並みの予算で自社業務に100%フィットする選択肢も現れています。
相見積もりでは、比べる条件をそろえ、SaaSかスクラッチかの二択にせず、AI駆動開発も比較対象に含めます。タイプを理解しないまま相見積もりを取ると、条件がそろわず、業務に合わない提案を選ぶおそれがあります。
自社の状況別に見る発注先の選び方
発注先は、出荷件数や連携要件、例外処理の量を見て絞り込みます。
- 少量出荷・標準業務：初期費用を抑えやすいSaaSが候補です。
- 連携必須・例外が多い：連携実績の豊富なSIerやスクラッチ開発が候補です。
- 発注前の確認：例外処理の量を洗い出し、発注先を選ぶ判断軸にします。
ERPやOMS（受注管理システム）とのリアルタイム連携が欠かせず、独自の例外処理も多い場合は、連携実績が豊富なSIerやスクラッチ開発を選ぶと総コストを抑えられることがあります。
WMS移行を外注する前の社内整理
社内の要件整理が足りないまま相談すると、ベンダー任せになりやすくなります。自社の業務を最もよく知る現場の情報を渡せなければ、提案の精度は上がりません。
外注の品質は発注側の準備の質に左右されるため、現状業務と要件を整理してから相談します。
現状業務（As-Is）の可視化と課題の言語化
現状業務を見える化し、課題を数値で表すと、外注先が解くべき問題が明確になります。
- 業務フロー：入荷から棚卸までの業務の流れを一覧にします。
- 例外処理と課題：現行の運用を洗い出し、それぞれの課題を数字で表します。
例として、2個1セットの商品を1個だけ返品する処理があります。また、破損品を物理的に隔離しても、システムの状態は変えない運用も例外に当たります。
こうした例外を見落とすと、要件定義で聞き漏れが起きます。そのため、稼働後にゴースト在庫（実在しないのに引当される在庫）が発生し、欠品クレームにつながるおそれがあります。
課題は「月次棚卸差異率が2%、誤出荷率が0.3%発生」のように数値で示します。この数値は、稼働後の効果検証（ROI測定）の基準になり、経営層への説明にも使えます。
要件のMust/Want切り分けとFit to Standardの線引き
要件をMustとWantに分けておくと、必要なカスタマイズを見極められます。
- Must（必須）：稼働に欠かせない要件だけを入れる区分です。
- Want（希望）：標準機能に寄せられる業務は、Fit to Standardで判断します。
すべてを必須にすると、過度なカスタマイズで費用が膨らみます。さらに、将来の更新を妨げる属人化やブラックボックス化を招きます。一方で、標準機能に合わせれば、初期費用と保守負担を抑えられます。
現場から「今までのやり方を変えたくない」という声が出た場合は、発注側が、その例外処理は売上や顧客満足に直結するのかを検証します。そのうえで、惰性で続いている運用は標準機能に合わせます。
発注側がMust要件だけを外注先に明確に伝えると、見積もりのばらつきが小さくなり、複数社を公平に比べられます。
丸投げを防ぐRFP（提案依頼書）の書き方
RFP（提案依頼書）は、複数のベンダーから同じ前提で提案を受けるための設計図です。精度が低いと見積もりを比べられず、提案書の見栄えで選んでしまう失敗につながります。
丸投げを防ぐには、自社特有の要件と制約を発注側が具体的に書き出して伝えます。
RFPに必ず盛り込むべき項目
各社の提案を比べるには、前提情報と回答形式をそろえておく必要があります。
- 目的と課題：解決したい課題を、定量値とあわせて書きます。
- 業務量：出荷件数、SKU数、拠点数の規模を示します。
- 連携先：ERP・OMS・TMSなど、つながる周辺システムを挙げます。
- 計画とデータ：希望スケジュールと予算の幅を示し、移行データ量とマスターの整備状況も記します。
- 回答形式：初期費用・月額・カスタマイズ費・保守費、移行手順、並行稼働方針、サポート体制を指定します。
データ移行の情報を明記すると、難易度を正しく見積もれます。WMS移行の失敗の約7割はデータに起因すると言われるため、この情報量がRFPの質を左右します。
回答形式を統一すれば横並びで比べられます。一方、自由提案では各社の得意分野が強調され、比べにくくなります。
自社特有要件（例外処理・連携）の伝え方
自社特有の例外処理と連携要件は、RFPに具体的に書き込みます。
- 例外処理：バラ出荷・返品、破損品の論理状態変更、サンプル品の持ち出し記録を処理ごとに示します。
- 連携要件：ERP・OMSは、リアルタイムAPIかCSVバッチかを明示します。
- 機器連携：自動倉庫やAGV・AMRとのWCS/WES連携では、型番・メーカーも書きます。
「特殊な処理はありません」と書くと、聞き漏れによる追加開発費の原因になります。具体的に書いておけば、後工程での認識のずれを減らせます。
マテハン連携は500万円から3,000万円規模の追加開発になることもあります。後から伝えると、見積もりが大きく変わります。
発注先選定での開発力と物流ノウハウの見極め
提案書の見栄えだけで決めると後悔しやすいため、自社に近い規模や業種での移行実績と、物流現場を理解した開発力を確かめます。
提案の段階で具体的な経験と支援体制を聞き、発注先の実力を見極めます。
提案書・実績の見極めポイント
移行実績と提案内容は、質問を重ねて具体的に確かめ、発注先の実力を見極めます。
- 導入実績：社数だけでなく、自社に近い出荷件数や業種での経験を見る材料になります。
- 移行実務：稼働中の倉庫を止めない方法や、データ移行で起きた問題の解決方法を尋ねます。
- 提案内容：例外処理ごとに、標準設定と追加開発を分けて説明できるかを確認します。
可能であれば、導入先の訪問や、担当予定のエンジニアとの面談も依頼します。
連携実績（ERP/OMS/WCS）とデータ移行支援体制の確認
WMSはERPやOMS、TMS、WCS/WESと連携して価値を発揮するシステムです。そのため、発注先の連携実績とデータ移行支援の範囲を確認します。
- 連携経験：ERP・OMS・TMS・WCS/WESそれぞれとの接続実績を、メーカーやAPI仕様まで含めて見ます。
- 障害対応：複数ベンダーにまたがる障害の切り分けルールを、事前に合意できるかを問います。
- データ支援：クレンジングや名寄せ、在庫残高の時点整合性まで、支援の範囲に入るかを確かめます。
「データは貴社で整備してください」とだけ伝える会社に任せると、データに起因する失敗を自社で抱えることになります。
契約・撤退の条項と隠れコスト対策
契約条項と旧システムからの撤退（Exit）は軽視されがちです。機能や費用だけでなく、旧システムを離れるコストも確認します。
データ抽出費用は見積もりに現れず、移行中に追加費用となることがあります。そのため、発注前に現行ベンダーとの契約書を読み直します。
旧DBアクセス権・データ引き上げ費用の確認
旧DBへの直接アクセス権を自社が持たず、現行ベンダーに依頼する契約になっている場合は、データ抽出費用がかかることがあります。
- 現行契約：解約条件、データ所有権、DBアクセス権、引き上げ費用を、今の契約書で押さえます。
- 新契約：エクスポート形式と無償提供の範囲は、条項で明記しておきます。
移行テストやリハーサルでCSV抽出を繰り返すたびに、1回あたり数十万円の費用が請求されることがあります。
抽出が重なると、数百万円規模の想定外コストになります。また、新契約でデータの持ち出しやすさ（可搬性）を契約で定めておくと、将来の乗り換え費用を抑えられます。
5年TCOと解約条件・違約金
初期費用だけで比べると見誤るため、利用期間全体の費目をまとめて比べます。
- SaaS：初期費用0円、月額20万円の場合、5年で1,200万円に達します。
- パッケージ：初期費用100万円、月額10万円の場合、5年で700万円に収まります。
- 端末・保守：ハンディ端末は1台あたり5万円から30万円です。年間保守費は、初期構築費の15〜20%が目安になります。
- 解約・移転：契約期間中の違約金や最低契約期間、旧倉庫の費用も計算に入れます。
従量課金のSaaSは、中長期でオンプレ型やパッケージ型より割高になることがあります。発注時は、目先の単年度の金額よりも、5〜7年の総保有コスト（TCO）で比べます。
倉庫を移転する場合は、早期解約違約金や割増保管料、棚卸費が月額の3〜6ヶ月分になることもあります。これらをTCOに含めないと、予算が狂います。
外注先との役割分担と責任範囲
WMS移行は、発注側と外注先が役割を分担して進めます。その分担を契約時に文書で明確にしておかないと、トラブルのときに責任の押し付け合いが起きます。
データ移行、テスト、並行稼働、本番切替の各段階で、どこまでを誰が受け持つかを具体的に決めます。
データ移行・UATシナリオの責任分界点
データ移行では、クレンジングの基準を決める人と、変換作業をする人を分けておきます。
- 移行基準：過去12ヶ月の実績がないマスターや休止ロケーションを除く基準は、自社が決めます。
- 変換と切替：変換と投入は外注先が担い、在庫残高の時点整合性を保つ方法は両者で決めます。
- 受け入れテスト：自社が通常・例外のシナリオを作り、外注先がテスト環境を用意します。
リハーサルの回数と費用負担は、契約に記載します。テストの合否基準と、不具合修正の責任範囲や対応期限も、事前に決めておきます。
並行稼働・ロールバック責任の取り決め
並行稼働（パラレルラン）は、新旧システムを並べて検証する期間です。この間は現場の入力工数が1.5〜2倍になるため、終了条件を外注先と合意しておきます。
- Exit Criteria：エラー率が0.5%未満になるなど、数値で表した条件を終了の基準にします。
- 指示系統：出荷指示書とピッキングリストは、新システムからのみ出します。
- 切り戻し：判断基準と権限者を決めておき、新稼働後も旧システムと端末は最低3ヶ月残します。
「ERPとのAPI連携が4週間安定稼働」などの基準を設ければ、並行稼働が長引くのを防げます。さらに、本番稼働後は、エラー率や棚卸差異率がどの水準を超えたら旧システムに戻すかを決めておきます。
切り戻しの基準や判断権限が曖昧なままだと、出荷停止の最中に現場が混乱します。旧システムと旧ハンディ端末は、切り戻しの際にすぐ再接続できる状態で残しておきます。
WMS移行の外注でよくある失敗と回避策
外注で起きる失敗の多くは、発注時の準備と取り決めで減らせます。代表的な例と回避策を見ておきます。
ベンダー丸投げと現場教育不足
要件定義から運用設計までベンダー任せにすると、現場で使えないシステムになるおそれがあります。
- プロジェクト管理：発注側の責任者が、定例会で進捗と課題を管理します。
- 現場教育：操作研修やマニュアル整備を範囲に含め、習熟期間を確保します。
繁忙期切替・指示系統二重化のリスク
繁忙期の切替は現場を混乱させます。並行稼働中は入力工数が1.5〜2倍に増えるため、切替の時期と指示系統を決めておきます。
- 切替時期：閑散期を選び、物流現場の繁忙期とは重ならないようにします。
- 作業指示：指示書は新システムからのみ出し、旧システムは検証用として残します。
- 倉庫移転：停止中のバックオーダーに備えた計画を立て、段階的に移転します。
新旧の両方から指示書を出すと、重複ピッキングや誤出荷につながります。
まとめ
WMS移行の発注・外注は、製品選びよりも「事前準備と取り決め」で成否が決まります。まず発注先の4タイプを理解し、現状業務と例外処理を見える化したうえで、Must/Wantを分けます。
次にRFPを作り、近い規模の実績や物流ノウハウ、データ移行の支援体制を確認します。契約前には、旧ベンダーのデータ抽出費用や5年TCO、倉庫移転時の早期解約違約金や割増保管料、棚卸費を洗い出します。
移行やUAT、並行稼働、ロールバックの責任を決め、切替は閑散期に行います。さらに、指示系統を一本化し、旧システムと旧端末は最低3ヶ月保持します。
発注側が準備と取り決めを行うことで、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を創業。