WMS移行は、現状分析と要件定義から始めて、データ移行、並行稼働、本番稼働の順に進めると、手戻りや誤出荷を防ぎながら着実に完了できます。
全体像はWMS移行の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・WMS移行の完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMS移行の全体像と進め方のステップ
WMS移行は、企画・現状分析から本番稼働・定着まで、段階を追って進みます。段階ごとに、何を決め、何を作り、何を確かめるかを押さえておくと、全体の流れが見通せます。
- 企画・現状分析：変更理由と現状業務を洗い出す。
- 要件定義・ベンダー選定：目標と必要な機能を決める。
- 設計・開発：要件に沿って新システムを用意する。
- データ移行：新システムへ移すデータを整備する。
- 並行稼働：新旧システムの結果を照合する。
- 本番稼働・定着：新システムへ切り替え、その後の運用に入る。
各フェーズで関わる部門も、そこで作るものも異なるため、全体像を関係者で共有しておかないと、後工程で手戻りが起こりやすくなります。
WMS移行が必要になるサイン
発注側は、移行を始める前に現行システムを変える時期かどうかを客観的に判断します。判断の材料になるのは、次のような兆候です。
- サポート終了：システムの保守期限やOS・機器のサポートが切れている。
- 処理能力の不足：レスポンスの低下や業務の遅延が出ている。
- 属人化：特定のベテラン担当者にしか操作できない。
- 過度なカスタマイズ：改修費がかさみ、影響範囲も分からない。
- 手作業の連携：ERPとのやり取りがCSV取込に頼り、二重入力や転記ミスが当たり前になっている。
たとえば、EC化で出荷件数が数年で2倍、3倍となり、既存システムの処理能力が限界に達する例もあります。また、軽微な変更に数十万円と数週間かかるようなら、維持コストが刷新コストを上回るおそれがあります。こうしたサインが複数重なったら、本格的な移行を検討します。
移行プロジェクトの全体ステップ
発注側は、各フェーズの順序と期間を先に押さえ、無理のない計画を立てます。
- 企画：As-Is分析とTo-Beの目標設定まで行う。
- 要件定義：RFPを作成し、ベンダーを選定する。
- 設計から切替：開発、データ移行、並行稼働を経て、本番稼働に移る。
期間の目安は、クラウド型（SaaS）で数ヶ月、カスタマイズ型やフルスクラッチ型で半年から1年以上が一般的です。
次へ進む条件は、RFPと要件定義書の合意や移行リハーサルの成功などを、文書にして残しておきます。特に条件が曖昧なままだと、並行稼働の段階で漏れが見つかり、数ヶ月単位の遅延につながります。
要件定義・企画フェーズの進め方
要件定義と企画は、移行プロジェクト全体の品質を左右する工程です。たとえば、現状業務と新システムの姿を曖昧にしたまま開発に入ると、現場と合わず手戻りが生じます。発注側が主体となり、まず現状を分析し、次に目標を決めて、最後にRFPを作成します。
As-Is/To-Be分析とKPI設定
まず現状業務（As-Is）を書き出し、新システムの目標（To-Be）をKPIとして数値で定めます。
- 業務の洗い出し：入荷から返品まで、通常の作業と例外の作業を記録する。
- 在庫精度：目標は99.5%以上。
- 誤出荷率：現状0.3%から0.05%以下への低減を目指す。
- 作業時間：ピッキング1件あたり20%の短縮が目標。
セット品の手作業での分解や、破損品を隔離してもシステム上の状態を変えない運用も、あわせて記録しておきます。特に例外を見落とすと、移行後に在庫差異が起こります。
KPIは、投資判断を説明する材料になるほか、本番稼働後に効果を検証するためにも使えます。たとえば「便利になる」のような目標では、効果を示せず、社内の協力も得にくくなります。
RFP作成とベンダー選定
発注側は、要件をRFP（提案依頼書）にまとめ、候補のベンダーに提示します。
- 前提条件：課題、出荷件数、拠点数を明記する。
- 要件の優先度：必須要件（Must）と希望要件（Want）を分ける。
- 連携要件：ERP、OMS、TMSとの方式を記載する。
- 連携の確認：頻度、方式、障害時の挙動を契約前に確かめる。
「APIでリアルタイム連携」と提案されても、実際は数時間ごとのバッチ処理ということもあります。だからこそ、連携の実態を確かめておきます。さらに、提案書の内容だけでなく、同業種・同規模の移行実績や物流のノウハウも確認します。
旧システムの解約条件や、データ取得の費用と手順も、選定の段階で調べておきます。旧データベースに直接アクセスできない契約では、抽出のたびに依頼が必要になります。その場合、移行テストで1回あたり数十万円の費用が発生することもあります。
データ移行を成功させる実務（失敗の7割はデータ）
WMS移行の失敗原因は、約7割がデータに起因すると言われています。商品や取引先のマスタに重複や表記揺れがあると、ピッキング指示や在庫引当が止まることがあります。移行初日の障害を防ぐため、移行前にデータを整えておきます。
マスタクレンジングの基準（12ヶ月ルール・名寄せ）
まず不要データを整理し、重複したマスタを統合して、移行の対象を絞り込みます。
- 12ヶ月ルール：過去一年間に入出荷がない商品マスタは除外する。
- 休止ロケーション：長期間使われていない場所は対象外にする。
- 名寄せ：同一取引先の複数コードを一つにまとめる。
- コード対応：新旧の対応表（マッピング表）を用意する。
残すデータの基準は、情報システム部門と現場で合意しておきます。不要なデータまで移すと動作が重くなるうえ、選択肢が増えて現場も混乱します。
「株式会社○○」「(株)○○」「○○商事」のような表記揺れは統一しておきます。そのまま放置すると、実績が分散して正確に集計できなくなります。
クレンジングは、テスト移行を複数回行ってエラーを直しながら進めます。一度で完全に整えられるとは限らないため、この繰り返しを前提に計画を立てます。
在庫の時点整合性（差分移行 vs 業務停止一括切替）
抽出後も在庫は動くため、抽出した時点と新システムへ投入する時点でずれが生じます。
- 差分移行：業務を止めず、抽出後の差分を新システムに反映する。
- 業務停止一括切替：週末などにまとめて切り替え、その間は業務を止める。
差分移行は業務を止めずに済みますが、取込処理が複雑で、漏れのリスクがあります。一括切替は確実性が高い一方で、停止できる時間が限られます。
一括切替では、土日の数十時間で棚卸と移行を終える段取りが必要になります。そのため、出荷件数と稼働カレンダーを踏まえて、早めに方式を決めます。どちらの方式でも、切替の直前に実地棚卸で現物を数え、物理在庫とデータを一致させます。
並行稼働（パラレルラン）の正しい進め方と終わらせ方
並行稼働（パラレルラン）は、本番データを使って新システムを検証する安全策です。ただし、新旧システムを並行して動かすため、現場の工数は1.5倍から2倍になります。
指示系統の一本化ルール
現場が使う作業指示は、新システムだけに統一します。旧システム側の帳票は、停止するか現場へ渡さない運用にします。特に、新旧の両方から帳票が出ると、二重ピッキングや誤った送り状の貼付が起こります。
- 新システム：ピッキングリストや出荷指示書、送り状を出す。
- 旧システム：結果照合のために、裏側で動かしておく。
- 帳票管理：帳票の出力元を新システムの一つに絞る。
担当者は、旧システムの想定値と新システムの出荷結果を照合し、差異を検証します。
役割分担は初日に文書にまとめ、朝礼などで繰り返し伝えます。ルールが曖昧なままだと現場が迷い、繁忙時には混乱が広がります。
Exit Criteria（終了条件）と切替タイミング
並行稼働を終える条件（Exit Criteria）は、事前に数値で決めておきます。
- 出荷エラー：誤りの割合が0.5%未満の状態が2週間続く。
- ERP連携：APIでの接続が4週間以上問題なく動く。
- 棚卸差異：ずれの割合があらかじめ決めた基準内に収まる。
基準を満たしてから旧システムを止めれば、「もう大丈夫」という感覚だけで切り替える見切り発車を防げます。
並行稼働と最終切替は、出荷量が落ち着く閑散期に行います。特に年末商戦やセール期は、1.5倍に増えた工数が処理能力を超えるおそれがあります。そのため、出荷カレンダーを確認し、出荷が落ち着いた時期に切替を合わせるよう、逆算して計画します。
本番稼働とリスク管理
本番稼働（カットオーバー）の直後は、想定外のトラブルで出荷が止まるおそれがあります。そのため、ロールバックの判断基準と権限、旧システムの保持期間を事前に決め、稼働直後の備えを整えます。
ロールバック判断基準と権限
深刻な障害が起きた場合に、新システムで復旧するか旧システムへ戻すかを、あらかじめ決めておきます。
- 判断基準：エラー率や主要機能停止の時間を閾値にする。
- 決定権限：最終判断を下す責任者を一人に定める。
- 連絡経路：障害時のエスカレーション手順を決める。
判断を現場任せにすると、対応が遅れて被害が広がるおそれがあります。あわせて、旧システムへ戻す手順書とデータの巻き戻し方法は、稼働前にテストしておきます。復旧の準備が整っていれば、現場も新システムの運用に集中できます。
旧システム・旧端末の保持期間
稼働直後の障害に備えて、旧システムと端末はすぐに処分しないようにします。
- 保持期間：稼働後、最低3ヶ月は旧環境を残す。
- 終了条件：稼働後3ヶ月かつ月次決算2回が無事完了し、繁忙期を一度越える。
旧環境には、サーバー、ライセンス、旧ハンディ端末が含まれます。特に端末を処分すると旧システムに再接続できず、出荷が止まることがあります。保持には費用がかかりますが、出荷停止による機会損失や信用失墜のリスクに備えられます。
旧システムの停止と契約解除は、上の条件を満たしてから判断します。解約手続きや最終バックアップには、想定外の費用や日数がかかることがあるため、早めに確認しておきます。
WMS移行でよくある失敗と回避策
WMS移行で起こりやすい失敗は、例外処理が反映されないことと、ベンダー任せや現場教育の不足です。いずれも技術の問題というより、進め方とコミュニケーションに関わる問題です。
例外処理漏れが生むゴースト在庫
現場の例外処理がシステムに反映されないと、帳簿上の在庫と実物がずれます。
- 破損品：隔離後にシステムの状態を変え忘れる。
- 分割返品：2個1セットから1個だけ戻り、単位がずれる。
- 展示サンプル：記録せず持ち出し、在庫差異になる。
破損品が引当可能なまま残ると、受注後に実物がなく、欠品クレームにつながります。こうした在庫を「ゴースト在庫」と呼びます。
対策として、要件定義の段階で例外処理を洗い出し、操作の流れに組み込みます。あわせて、記録が必要な理由も現場に教え、入力の省略を防ぎます。
ベンダー丸投げと現場教育不足
ベンダー任せにせず、発注側が関わる場面と現場担当者の役割を、計画の段階で決めておきます。
- 要件定義：倉庫固有の業務や例外を発注側が伝える。
- テスト：現場のキーパーソンとシナリオを作る。
- 操作教育：全員が実機で通常・例外対応を練習する。
現場の事情が伝わらないままだと、稼働後に実態とずれて、追加の改修費が発生します。そのため、稼働前に訓練期間を設け、マニュアルと実機演習を準備します。対象は、パート・アルバイトを含む全員です。
教育を後回しにすると、操作ミスや作業の遅れが起こります。イレギュラー対応まで練習しておくと、稼働後の定着につながります。
まとめ
WMS移行は、各工程の完了条件を決めたうえで、企画から本番稼働まで段階的に進めます。データ移行では、12ヶ月ルールによる整理と在庫の時点整合性の確保が欠かせません。並行稼働では、指示を一本化し、数値の終了条件を満たしてから切り替えます。
本番稼働では、ロールバックの条件と権限を決め、旧システムと端末を最低3ヶ月保持します。例外処理の反映、発注側の関与、現場教育を徹底し、切替時期は閑散期に合わせます。手順を一つずつ踏んで、移行を進めましょう。
▼全体ガイドの記事
・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を創業。