WMSリプレイスは、現状分析、要件定義、データ移行、並行稼働、本番稼働の順に進めると、出荷を止めずに安全に切り替えられます。
また、移行トラブルの約7割はデータに起因するといわれ、並行稼働は始め方より終わらせ方が難しいとされます。全体像は、WMSリプレイスの完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・WMSリプレイスの完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMSリプレイスの全体ステップ（企画から稼働まで）
WMSリプレイスは、企画・現状分析から要件定義、開発、移行テスト、並行稼働を経て、本番稼働へ進みます。期間は、SaaS型なら数ヶ月、カスタマイズやスクラッチ開発を伴う場合は半年から1年以上かかるのが一般的です。
全体像と所要期間を先に押さえておけば、繁忙期と切替時期が重なるスケジュールのミスを避けられます。なかでもつまずきやすいのは、企画・現状分析と要件定義の2フェーズです。
As-Is/To-Be分析とKPI設定
まず、現行業務を棚卸しし、現場に張り付いて実務を洗い出して、今の業務の流れを押さえます。
- As-Is分析：入荷から棚卸までの担当者、帳票、処理を行う時点
- 例外処理：セット品のバラ返品、破損品の隔離、サンプルの持ち出し
- To-BeとKPI：在庫精度99.5%以上など、達成したい数値目標を定める
とくに例外処理を拾い損ねると、後工程で要件の漏れが起きます。
また、KPIを決めておくと、ベンダーへの要件が明確になります。たとえば「誤出荷率0.1%未満」や「ピッキング生産性20%向上」といった数値を目標に置き、稼働後の効果を検証する物差しにも使えます。
削減人件費をもとにしたROIは、数千万円規模の投資を承認してもらう際の説得材料になります。企画フェーズのゴールは、なぜ今リプレイスするのかを数字で説明できる状態です。
RFP作成とベンダー選定
要件が固まったら、RFP（提案依頼書）を作成し、複数社の提案を同じ条件で比べます。
- 要件の区分：Must（必須要件）とWant（希望要件）に分けて示す
- 自社要件：例外処理やERP・OMSとの連携に関する要件
- 選定基準：同業種・同規模の実績、マテハン連携、移行支援の有無
現行業務をそのまま再現させる前提で、ベンダーに丸投げするのは禁物です。RFPの粒度が粗いと、提案書は良く見えても、開発力や物流ノウハウの実力は見抜けません。
特に、ERPとのAPI連携がリアルタイムで動くかは、デモや既存事例で確かめます。契約前の確認が不足すると、稼働後の在庫データ不整合につながります。
発注・外注の具体的な進め方は、後述の関連記事もあわせてご覧ください。
データ移行を成功させる実務（失敗の7割はデータ）
移行トラブルの約7割はデータに起因するといわれています。システムの機能が優れていても、移行データが汚れていれば正しく動きません。そのため、商品・取引先・ロケーションの各マスタと在庫残高を、正確に移す準備が欠かせません。
マスタクレンジングの基準（12ヶ月ルール・名寄せ）
使われていないマスタや休止中のロケーションをそのまま移すと、検索性や処理速度が落ち、ピッキングミスの原因にもなります。
- 12ヶ月ルール：過去12ヶ月に入出荷実績のないマスタや休止ロケーションを移行対象から外す
- 名寄せ：重複商品や取引先名の表記ゆれ
- コード移行：新旧コード体系の対応づけと、重複の統合
移行対象を絞れば、データ量を抑えられ、テストの精度も上げられます。また、名寄せを怠ると在庫が分散し、正しい引当ができません。
クレンジングと名寄せは想定以上に工数がかかるため、要件定義と並行して早めに着手します。
在庫の時点整合性（差分移行か業務停止一括か）
倉庫では営業中も在庫が動くため、データを抽出した時点から実在庫とのずれが生じます。
- 業務停止一括移行：週末などに業務を止めて、まとめて移す方式
- 差分移行：抽出後に発生した在庫の変化だけを後から反映する
一括移行は手順が簡単で整合性も取りやすい一方、出荷を止められる事業者に限られます。差分移行は出荷を止めずに済みますが、抽出から投入までの在庫変動を確実に拾う仕組みが必要です。
そこで、本番と同等のデータを使い、移行リハーサルを複数回行います。棚卸で実在庫と照合し、差異ゼロを確かめてから本番に進みます。
なお、旧システムのDBに自社で直接アクセスできない契約では、リハーサルのたびに旧ベンダーへ抽出費用を支払うことになります。発注側は、データ抽出の権限と費用を事前に確認しておきます。
並行稼働（パラレルラン）の正しい進め方と終わらせ方
切替リスクを抑えるため、新旧システムを一定期間同時に動かすのが一般的です。ただし、並行稼働は始め方より終わらせ方が難しく、判断を誤ると現場が立ち行かなくなるおそれがあります。
二重入力で工数が1.5倍から2倍に膨らむため、並行稼働は長引かせないのが鉄則です。このため、終了条件をあらかじめ明確にしておくことが、並行稼働を成功させる最大のポイントです。
指示系統の一本化ルール
新旧の両方から出荷指示書やピッキングリスト、送り状が出ると、二重ピッキングや誤った伝票による出荷が起きます。
- 現場の指示書：オペレーターが使う紙は、新システムからのみ出力する
- 旧システム：結果照合のための確認用に限り、印刷物を現場に出さない
この状態を放置すると、現場が混乱し、誤出荷が続いてしまいます。そのため、指示は新システムに一本化し、関係者全員で共有してから稼働に入ります。
Exit Criteria（終了条件）の決め方
旧システムを停止する時期は、事前に定めた数値で判断します。
- 出荷エラー：エラー率0.5%未満を連続して維持すること
- API連携：ERPやOMSとの連携が、4週間以上欠損なく安定していること
- 棚卸差異：差異率があらかじめ定めた基準値以下に収まる
稼働前に条件を定めておき、すべて満たした時点で旧システムの停止を判断します。判断の基準がないまま切り上げると、後から隠れた不具合が表面化するおそれがあります。
合格ラインを設けておけば、現場と経営層がそろって納得したうえで進められます。この条件は、どこまでを誰が受け持つかにも関わるため、提案・契約の段階でベンダーと合意しておきます。
切替時期の選び方（閑散期を優先）
並行稼働と本番切替は、物量の少ない閑散期に設定します。繁忙期に二重入力が重なると、現場が回らなくなります。
- 避ける時期：年末商戦、セール期、月末の出荷集中日
- 優先する条件：ベンダーの開発日程より、現場の業務カレンダー
開発日程を優先して日程を組むと、失敗の確率が大きく高まります。開発が遅れても、繁忙期に無理に切り替えるより、閑散期まで待つほうが安全です。
そのため、本番を迎える前に、リハーサルと現場教育の時間を十分に確保しておきます。
本番稼働とリスク管理
本番稼働はプロジェクトのゴールであると同時に、最も緊張する場面です。とくに、切替直後に出荷が止まれば、その日のうちに顧客への影響が広がります。
そのため、問題が起きたときの対応は稼働前に決めておくことが欠かせません。旧環境へ戻す判断基準と保持期間も、この段階で確認しておきます。
ロールバック判断基準と権限の明確化
重大なトラブルが起きた際に旧システムへ戻すロールバック（切り戻し）は、一刻を争う判断です。
- 判断基準：出荷エラー率、棚卸差異率、レスポンス時間
- 判断者と期限：誰がいつ決めるか、復旧見込みを含めた期限
たとえば、出荷エラー率が一定値を超え、2時間以内に復旧の見込みが立たなければ、物流責任者の判断で戻すといった基準を定めておきます。
判断を先送りして「様子を見る」と粘ると、被害が拡大し、取り返しがつかなくなります。判断者の権限と連絡体制も、稼働手順書に記載しておきます。
旧システム・旧端末の保持期間（最低3ヶ月）
切り戻しに備えて、旧環境の保持期間と廃棄の条件を、稼働前に決めておきます。
- 保持期間：旧システムのライセンスと旧ハンディ端末を、本番稼働後も最低3ヶ月保持すること
- 解約・廃棄の条件：新システムの安定稼働とExit Criteriaの達成が確認できた後
旧端末を先に破棄すると、旧システムへ再接続できず、業務が止まるおそれがあります。
また、旧システムの解約には、違約金やデータ引き上げ費用がかかる場合があります。このため、契約条件を事前に確認し、安全な橋渡し期間を確保しておきます。
WMSリプレイスでよくある失敗と回避策
「WMSを入れれば在庫は合う」という思い込み、ベンダーへの丸投げ、現場教育の不足は、よくある失敗です。
どれも進め方の段階で手を打てば、十分に避けられます。とくに在庫精度と現場定着に関わる失敗は、要件定義と現場教育の両面から対策することが大切です。
例外処理漏れによるゴースト在庫
在庫が合わない原因の多くは、現場の例外処理がシステムに反映されないことにあります。
- 破損品：隔離後の状態変更を忘れると、出荷不可の在庫が引当対象に残り、欠品クレームの原因になる
- セット品の返品：2個1セットの片方だけが返品されると、単位のずれから在庫差異が生じる
- サンプル：記録のない持ち出しは、在庫差異の要因
- 回避策：要件定義で例外処理を洗い出し、現場への聞き取りをもとに処理フローへ組み込む
ベンダー丸投げと現場教育不足
自社業務をもっともよく知っているのは現場です。だからこそ、要件の取捨選択やテストシナリオの作成には、発注側も主体的に関わります。
- UAT（受入テスト）：返品や緊急出荷などのシナリオを自社で用意し、例外も検証すること
- 現場教育：稼働前の訓練と操作マニュアル
- 稼働直後の支援：ベンダーや情シスが現場で支える
正常系だけで検証を終えると、本番で例外に出会ったとき、現場が対応に迷います。そのうえで、現場が使いこなせるよう、十分な訓練期間を設けます。
近年はAI駆動開発によって工期やコストを圧縮でき、自社業務に100%フィットする構築の選択肢も広がっています。そのため、パッケージかスクラッチかの二者択一にとらわれず、進め方を検討する価値があります。
まとめ
WMSリプレイスは、企画・現状分析から本番稼働まで、段階ごとの勘所を押さえて進めることが大切です。
データ移行では、12ヶ月ルールと在庫の時点整合性が要点です。移行トラブルの約7割はデータに起因するといわれています。
並行稼働では、指示系統を一本化し、数値で定めたExit Criteriaに沿って終わらせることが現場の混乱を防ぎます。また、本番稼働では、ロールバック基準を文書にまとめ、旧システムと旧端末を最低3ヶ月保持します。
現場の例外処理を要件に反映し、発注側がUATに関わって現場教育を行うことが大切です。さらに、費用相場やベンダーの選び方、発注の進め方など、より詳しいテーマは関連記事もあわせてご覧ください。
▼全体ガイドの記事
・WMSリプレイスの完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。