倉庫管理システム（WMS）のリプレイスは、企画・現状分析から本番稼働・定着までの一連の工程をたどって進みます。特に、企画・現状分析、要件定義、データ移行の順に進めると、移行後の混乱を抑えやすくなります。
▼全体ガイドの記事
・倉庫管理システムリプレイスの完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
倉庫管理システムリプレイスの全体ステップと流れ
企画から本番稼働・定着までは、次の6つの工程を順に進めます。
- 企画・現状分析
- 要件定義・ベンダー選定
- 設計・開発
- データ移行
- 並行稼働
- 本番稼働・定着
期間の目安は、形態によって異なります。SaaS型なら数ヶ月、パッケージのカスタマイズやフルスクラッチなら半年から1年以上が一般的です。
企画の段階で全体像とゴールを描けるかどうかが、その後の成否を左右します。現行業務をそのまま新システムに載せ替えると、移行でつまずくことがあります。長年のカスタマイズや属人的な例外処理が、移行の妨げになるためです。
リプレイスの出発点は、まず現状の業務を洗い出し、残すものと捨てるものを決めることです。
As-Is/To-Be分析とKPI設定
まず、現状の業務（As-Is）を一覧にして、刷新後の姿（To-Be）とKPIを決めます。
- 業務フロー：入荷、検品、格納、ピッキング、出荷、棚卸までの流れ
- 例外処理：セット品のバラ出荷、破損品の隔離、サンプル持ち出し
- KPI：在庫精度99.5%以上、誤出荷率0.1%未満、ピッキング1件あたりの作業時間を20%短縮など
業務フローを書き出すときは、手作業や紙、Excelによる二重管理の箇所も併せて見えるようにします。
例外処理をシステムの外に残したままにすると、新システムでも在庫差異が生じる原因になります。
KPIは投資対効果（ROI）に結びつけ、人件費や誤出荷対応コストの削減効果を数字で示します。数千万円規模の投資となると、「業務効率化」という言葉だけでは判断材料として弱いため、この数字が欠かせません。
RFP作成とベンダー選定
要件が固まったら、RFP（提案依頼書）を作成し、ベンダーに提示します。
- 業務量：出荷件数、品目数、拠点数
- 連携要件：ERPやOMSとの連携
- 独自要件：自社特有の例外処理
RFPには、各項目を必須要件と希望要件に分けて明記します。そうすると、ベンダーの提案内容がそろい、比べやすくなります。
要件を「現行踏襲」の一言で済ませると、提案書から開発力や物流ノウハウを見抜けません。
ベンダーを選ぶときは、機能だけでなく、同業界・同規模での移行実績を確かめます。ERPやマテハン機器との連携経験も見ておき、データの引き上げ条件は契約前に詰めます。
たとえば、旧DBへの直接アクセス権が自社にない場合、移行テストのたびに旧ベンダーへ1回数十万円のスポット費用を支払うことは珍しくありません。
将来ほかのベンダーに乗り換えるときに備えて、新しい契約には、データの所有権とアクセス権を明記しておきます。
データ移行を成功させる実務（失敗の7割はデータ）
WMSのリプレイスで失敗する原因のおよそ7割は、データにあると言われます。移行マスタが汚れていると、優れたシステムであっても、稼働初日から在庫が合わず、現場が混乱します。
データ移行は、終盤に行う単純作業として扱わず、要件定義と並行して早期に着手します。
移行の対象には、商品・取引先・ロケーションの各マスタ、在庫残高、入出荷実績などがあります。
データ移行は単なるコピーで済ませず、次の工程を丁寧に進めることが成功の鍵です。
- クレンジング：不要なデータの除去
- マッピング：項目同士の対応付け
- 名寄せ：重複データの統合
マスタクレンジングの基準（12ヶ月ルール・名寄せ）
長年使ったWMSには、未使用の商品マスタや休止中のロケーションが残っています。そのまま移行すると、検索性が落ちるだけでなく、誤った引当の原因にもなります。
移行対象と名寄せの基準は、次のとおり決めておきます。
- 12ヶ月ルール：過去12ヶ月に入出荷実績のないマスタや未使用ロケーションは対象から外す
- 名寄せ：商品コードの重複や取引先名の表記揺れを整理し、在庫の分散を防ぐ
- 判断基準：現場と合意した廃棄・統合の基準の文書化（誰もが同じ判断をできるようにするため）
クレンジングは手間のかかる作業です。ただし、妥協すると稼働後に問題が起きます。
在庫の時点整合性（差分移行 vs 業務停止一括）
在庫残高を抽出した後も、現場では入荷や出荷が続くため、在庫は刻一刻と動いていきます。
この時間差を放置すると、稼働初日に帳簿在庫と実在庫が合わず、欠品クレームや過剰引当が起きてしまいます。
この時間差への対処法には、差分移行と業務停止一括移行があります。
- 差分移行：抽出後の入出荷を差分として反映する方式
- 業務停止一括移行：週末や連休に業務を止めての一括切替
差分移行は出荷を止めずに済む一方で、差分の取り込みの仕組みが複雑になります。
一括移行はシンプルで確実ですが、停止中のバックオーダーを消化する計画も必要になります。そのため、出荷量と許容できる停止時間を踏まえて、現実的な方式を早めに決めておきます。
並行稼働（パラレルラン）の正しい進め方と終わらせ方
並行稼働（パラレルラン）は、新旧のシステムを一定期間同時に動かし、新システムが正しく動くかを検証する工程です。
準備が十分でないまま始めると、現場が崩壊し、プロジェクト全体が頓挫しかねません。
並行稼働は事故が起きやすい工程です。そのため、「始め方」より先に「終わらせ方」を設計しておきます。
新旧両方に入力することになるため、現場の工数は1.5倍から2倍に膨らみます。この負荷を軽く見ると、入力漏れや遅延が積み重なり、データの信頼性が損なわれます。
並行稼働の期間は必要最小限にとどめ、終了条件を満たしたら旧システムを切り離します。
指示系統の一本化ルール
指示系統が二重になると、誤出荷を連発させるおそれがあります。
誤出荷を防ぐために、指示と照合の役割を次のように分けておきます。
- 現場への指示：ピッキングリスト、出荷指示書、送り状の出力元は新システムだけ
- 旧システム：結果照合のみに限定し、現場のオペレーションには関わらせない
- 出力照合：バックオフィスによる新旧出力の突き合わせ
指示の役割が曖昧なままだと、並行稼働そのものが誤出荷の原因になります。
Exit Criteria（終了条件）の決め方と閑散期切替
並行稼働をいつ終えるかは感覚で決めず、Exit Criteria（終了条件）を数値で定めておきます。
たとえば、次のような具体的な条件を設定します。
- 出荷エラー率：0.5%未満が連続2週間
- ERPとのAPI連携：4週間安定稼働
- 棚卸差異率：基準値以内
すべての条件を満たした時点で、責任者の承認を得たうえで、旧システムを停止します。
切替は必ず閑散期に行います。繁忙期に二重入力が重なると、現場がパンクしてしまうためです。
繁忙期と閑散期の区切りは、物流現場が把握している年間カレンダーに基づいて決めます。スケジュールを組むときも、そのカレンダーを優先し、無理な時期の切替は避けます。
本番稼働とリスク管理（撤退戦略）
本番稼働は、リスク管理が始まる節目です。倉庫の出荷が止まれば、取引先への納品遅延となり、ビジネスに直接の損害を与えてしまいます。
新システムは止まらないという前提で進めると危険です。そのため、問題が起きたときの判断方法と、旧システムへ戻す手順を稼働前に用意しておきます。
判断権限と旧環境の保持期間もあらかじめ定めておけば、緊急時にも冷静かつ迅速に対応できます。
ロールバック判断基準と権限
本番稼働後に迷わないよう、ロールバックの数値基準を事前に決めておきます。
たとえば、次のようなトリガーを定めます。
- 出荷：エラー率が定めた値を超えた場合
- 棚卸：差異率が許容範囲を逸脱
- 基幹連携：連携が一定時間以上止まった場合
あらかじめ定めたトリガーに達したら、ロールバックを判断します。
プロジェクト責任者、情シス、現場マネージャーのうち、誰が最終判断者になるかを事前に合意しておきます。
判断者が不在でも対応が遅れないように、エスカレーション経路もあわせて用意しておきます。
旧システム・旧端末の保持期間（最低3ヶ月）
新システムが稼働した後も、旧システムや旧端末をすぐに破棄してはいけません。
撤退できる状態を保つために、次の項目を確認しておきます。
- 端末の接続：旧ハンディ端末を返却・廃棄すると、ロールバック時に再接続できず業務が止まるおそれがある
- 保持期間：目安は本番後の最低3ヶ月。旧システム、旧端末、関連ライセンスを保持することを推奨
- 撤去判断：在庫精度と連携の安定性を見極め、繁忙期を一度越えた後に旧環境を撤去
- 契約確認：旧ベンダーとの解約条件とデータの引き上げ費用を再確認し、想定外の費用を防ぐ
旧システムへの再接続の手段を失うことは、撤退の選択肢を手放すことと同じです。
費用相場と見積もりで見えにくい隠れコスト
費用の構造を把握して、初期費用だけで判断しないことが大切です。
SaaSは初期費用を抑えやすい一方で、月額費用が積み上がっていきます。これに対し、パッケージ型やフルスクラッチは初期投資が大きくなりますが、中長期では割安になる傾向があります。
形態を選ぶときは、後から思わぬ費用に直面しないよう、期間を通した総額で比べます。
5年TCOで見る本当のコストと逆転の分岐点
費用は、初期費用ではなく、5年程度のTCO（総保有コスト）で比べます。
- SaaSの例：初期0円、月額20万円なら5年で1,200万円
- パッケージの例：初期100万円、月額10万円なら5年で700万円
この例では、中長期でコストが逆転しています。特に、「初期費用無料」であっても、従量課金が積み上がって割高になることがあります。
オンプレやスクラッチでは、年間保守費が初期構築費の15〜20%程度で、毎年固定的に発生します。
出荷規模と運用期間を前提に、何年目で有利になるかを試算してから、形態を選びます。
見積もりに出てこない隠れコスト
旧システムからのデータ抽出費用は、見積書に現れにくいコストの一つです。
見積もりを見るときは、次の費用も確認して予算に含めておきます。
- データ抽出：旧DBに直接アクセスできない契約では、移行テストやリハーサルで抽出するたび、旧ベンダーへ1回あたり数十万円を支払うことになる
- 端末：ハンディ端末は1台5万円から30万円程度で、現場の人数分が必要
- 環境・支援：Wi-Fi環境の整備や導入支援コンサルの費用
- 倉庫移転：WMS刷新と同時に移転すると、出庫作業費、早期解約違約金、割増保管料、棚卸費などで、月額保管料の3〜6ヶ月分の移動手数料が発生することもある
見積もりの段階で費用を洗い出し、予算に織り込んでおくと、後の予算超過を防げます。
よくある失敗と回避策
リプレイスでは、事前に知っておくことで避けられる失敗が多くあります。
例外処理漏れによる在庫差異の爆発
WMSを導入しても、在庫が自動的に合うとは限りません。在庫差異の原因は、現場の例外処理がシステムに反映されていないことにあります。
- セット品：2個1セット出荷後に1個返品され、セットとバラの単位がずれる
- 破損品：物理的に隔離しても論理ステータスを変えず、ゴースト在庫が引当に乗る
- サンプル：記録せずに持ち出す
ゴースト在庫が引当に使われると、実在しない在庫に対して出荷指示が出され、欠品クレームにつながります。
要件定義の段階で例外処理を漏れなく聞き取り、システムのステータス管理に反映します。
現場の運用実態に合わないシステムでは、在庫差異が生じます。
ベンダー丸投げと現場教育不足
ベンダーへの丸投げは、現場に合わないシステムを生む典型的な失敗です。
発注側と現場が担う役割と、開発方法の検討点は、次のように整理できます。
- 役割分担：現場は業務を理解し、ベンダーがシステム化を担う。要件、データ、業務ルールは発注側が主体となり、両者で進める
- 現場教育：十分なトレーニング期間とマニュアルの用意、繁忙期前に習熟できる計画
- AI駆動開発：工期・コストを30〜70%圧縮し、パッケージ並みの予算で自社に100%フィットしたスクラッチ開発を実現する選択肢もある
- 方式検討：「パッケージかスクラッチか」に限らず、最新の開発手法も視野に入れる
現場が使いこなせなければ、システムの導入効果は出ません。そのため、現場教育は早い段階から計画に入れておきます。
まとめ
企画・現状分析から旧システムの撤退まで、一連の流れを途切れなく設計することが成功の条件です。
データ移行では、12ヶ月ルールでクレンジングを行い、在庫の時点整合性を確保します。並行稼働では、指示系統を一本化したうえで、数値の終了条件を満たしてから、必ず閑散期に切り替えます。
稼働後は、ロールバックの基準と権限を定め、旧システムと端末を最低3ヶ月保持します。費用は5年TCOで比べ、旧ベンダーのデータ抽出費や移動手数料も予算に含めます。
最後に、例外処理を要件に入れ、現場教育を行うことで、在庫差異や誤出荷のリスクを下げます。この記事をチェックリストとして、自社の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を創業。