WMSのモダナイゼーションは、「企画・要件定義」から「本番稼働・定着」までの4フェーズで進めます。
EC化、サポート終了（EOSL）、属人化といった課題を一度に解決できる機会ですが、進め方を誤ると在庫が合わなくなり、並行稼働の現場が崩壊し、隠れコストも膨らみます。
▼全体ガイドの記事
・WMSのモダナイゼーションの完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMSモダナイゼーションの全体ステップと進め方の前提
全体の期間は、クラウドSaaSの導入で3〜6ヶ月、パッケージのカスタマイズやスクラッチ開発では半年から1年以上が一般的な目安です。
まず押さえたいのは、進め方の順番を守ることです。
あわせて、「なぜ今刷新するのか」という目的を、KPIの数値で示しておくことも欠かせません。
As-Is/To-Be分析とKPI設定
最初に行うのは、現行業務（As-Is）の棚卸しです。入荷から棚卸までの一連の作業フローを、例外処理まで含めて一覧にします。
特に大切なのは、現場が「良かれ」と思って独自に行っている運用を漏れなく拾うことです。たとえば、セット品をバラで返品する処理、破損品の隔離、サンプル品の持ち出しは、システム化されていない暗黙の運用です。こうした運用こそ、後の在庫差異の温床になります。
- As-Is/To-Be分析：あるべき姿（To-Be）の描き方とKPIの置き方
- 実務要点：対象範囲と役割分担の整理
そのうえで、As-Is、To-Be、During、Afterの各状態を並べながら、あるべき姿（To-Be）を描きます。その際は、KPIを必ず数値で設定します。たとえば、「誤出荷率を0.1%以下に」「在庫精度を99.5%以上に」「ピッキング生産性を1.3倍に」といった目標を置きます。
経営層に数千万円規模の投資を承認してもらううえで、この数値目標がROIの根拠になります。
逆に、KPIが曖昧なまま進めると、稼働後に「結局何が良くなったのか」を誰も説明できず、プロジェクトの評価が下がってしまいます。
RFP作成とベンダー選定
To-Beが固まったら、RFP（提案依頼書）を作成し、ベンダーを選定します。RFPには、現状の課題、必須要件（Must）と希望要件（Want）、想定する出荷件数や拠点数を明記します。ERPやOMSとの連携要件、予算とスケジュールも、あわせて書いておきます。
丸投げのRFPでは、各社の提案がどれも似たり寄ったりに見え、本当の実力を見抜けません。一方で、自社特有の例外処理や繁忙期の処理ピークといった「うちならではの条件」を具体的に書くことで、提案の質に差が出ます。
- RFP作成とベンダー選定：RFPの記載事項と、提案の見極め方
- 実務要点：対象範囲と役割分担の整理
ベンダー選定で見落としがちなのが、撤退時の条件です。
選定の前に、旧システムの解約条件と、旧データベースへの直接アクセス権の有無を確認しておくことが欠かせません。
自社にアクセス権がなく旧ベンダーに依存している場合、移行テストのたびに、データ抽出のスポット費用として1回数十万円を請求されるケースがあります。
発注側は、新しいベンダーとの契約に、将来また乗り換える際のデータ引き上げ対応を含められるかも確認しておきます。
データ移行を成功させる実務(失敗の7割はデータに起因)
WMS刷新の失敗の約7割は、システムの不具合ではなく、データ移行に起因すると言われます。
新しいシステムの機能が高くても、移行したマスタデータが汚れていれば、在庫は合わず現場も混乱します。
データ移行は、開発と並行して早めに始め、十分な検証期間を確保することが進め方の鉄則です。
マスタクレンジングの基準(12ヶ月ルールと名寄せ)
旧システムには、長年の運用で蓄積された不要データが大量に眠っています。これをそのまま移行すると、新システムでも検索が遅くなり、誤った引当の原因になります。そこで有効なのが「12ヶ月ルール」です。
過去12ヶ月間に入出荷実績のない商品マスタや、使われていない休止ロケーションは、思い切って移行対象から外します。クレンジングの本質は、捨てる判断をためらわないことにあります。
- マスタクレンジングの基準：12ヶ月ルールに当てはまるデータの扱い
- 実務要点：対象範囲と役割分担の整理
あわせて、同じ商品が複数のコードで登録されている重複（名寄せ）も解消します。
取引先コードや商品コードの表記ゆれを統一し、一意のマスタに集約します。
マスタクレンジングは地味な作業ですが、現場の業務知識がないと判断できません。
情シスやベンダーだけでなく、現場担当者を巻き込んで進めることが成功の鍵となります。
在庫の時点整合性(差分移行 vs 業務停止一括切替)
倉庫は24時間動き続けるため、データを抽出した瞬間から在庫数は変わります。この「時点整合性」をどう保つかが、WMS移行特有の最大の難所です。アプローチは大きく2つあります。
1つは、週末や連休に業務を完全に止めて在庫を確定させ、一括で移行する方法です。シンプルで整合性を取りやすい反面、出荷を止められる業態でなければ採用できません。
- 在庫の時点整合性：業務停止一括切替と差分移行の比較
- 実務要点：対象範囲と役割分担の整理
もう1つは、ある時点で基準データを抽出し、その後に発生した入出荷を差分として反映する「差分移行」です。出荷を止めずに切り替えられます。ただし、差分の取りこぼしがあると在庫がずれるため、運用設計と検証が複雑になります。
どちらを選ぶ場合も、切替直前に必ず実地棚卸を行い、システム上の理論在庫と現物を一致させてからカットオーバーに臨みます。
後の在庫差異を防ぐうえで、この一手が決め手になります。
並行稼働(パラレルラン)の正しい進め方と終わらせ方
並行稼働（パラレルラン）は、新旧システムを一定期間同時に動かし、新システムの結果が正しいかを検証する工程です。
リスクを抑える有効な手段ですが、進め方を誤ると現場が最も崩壊しやすいフェーズでもあります。
二重入力で現場の工数は1.5〜2倍に膨らむため、期間と終了条件をあらかじめ決めておくことが欠かせません。
指示系統の一本化ルール
並行稼働で最大の事故が、新旧両方のシステムから出荷指示書やピッキングリストが出力される「指示系統の二重化」です。
現場の作業者は2枚の指示書を見て混乱し、同じ商品を二重にピッキングしたり、誤出荷が連発したりします。これを防ぐ鉄則は、現場に渡す物理的な指示書を必ず新システムのみから出力する、という一本化です。
- 指示系統の一本化ルール：指示書の出力元を新システムに限る決まり
- 実務要点：対象範囲と役割分担の整理
旧システムは、あくまで新システムの結果を裏側で照合するための検証用として動かします。現場が実際に手を動かす指示を1系統に絞れば、二重作業による混乱を防げます。
並行稼働は「裏で答え合わせをすること」であり、現場を二重に動かすものではありません。関係者全員の認識をこの点で揃えておくことが大切です。
Exit Criteria(終了条件)の決め方
並行稼働は、「なんとなく大丈夫そうだから終わり」とすると危険です。そこで、終了条件（Exit Criteria）を数値で定めておきます。
たとえば、「出荷エラー率0.5%未満が連続稼働で達成」「ERPとのAPI連携が4週間以上安定して稼働」「棚卸差異率が基準内に収まる」といった条件です。
これらをクリアして初めて旧システムを止める、という判断軸を、事前に関係者で合意しておきます。
- Exit Criteria（終了条件）：数値で定める終了条件の例
- 実務要点：対象範囲と役割分担の整理
終了条件を決めないまま並行稼働を始めると、現場の負担が重いまま期間がずるずると延び、二重入力の疲れから入力ミスが増えるという悪循環に陥ります。逆に、明確なゴールを示せば、現場のモチベーションを保つことにもつながります。
切替時期の選び方（閑散期）
切替のタイミングは、物流現場のカレンダーに合わせて閑散期を選ぶのが大原則です。繁忙期に切り替えると、ただでさえ多い出荷量に二重入力の負荷が重なり、現場は確実に崩壊します。
年末商戦やセール時期、決算期の出荷ピークを避け、出荷件数が落ち着く時期を狙って、スケジュールを逆算します。
計画は、システムの都合よりも、現場が安全に新システムへ移れる時期を最優先に組むことが大切です。
- 切替時期の選び方：出荷ピークを避けたスケジュールの逆算
- 実務要点：対象範囲と役割分担の整理
本番稼働とリスク管理
カットオーバー（本番切替）は、プロジェクトで最も緊張する瞬間です。万が一トラブルが起きても出荷を止めないために、リスク管理の準備をどこまで詰められているかが、成否を分けます。
本番稼働では、「うまくいくはず」と楽観するより、「うまくいかなかったらどうするか」を具体的に決めておくことが核心です。
ロールバック判断基準と権限
本番稼働後にシステムが正常に動かない場合は、旧システムへ戻す「ロールバック（切り戻し）」を行うかどうかの判断が必要になります。その判断基準と権限を、事前に明文化しておくことが大切です。
- ロールバック判断基準と権限：切り戻しの判断基準と、その権限者
- 実務要点：対象範囲と役割分担の整理
トラブル発生時は現場が混乱し、誰も決断できずに時間だけが過ぎてしまいがちです。そこで、判断基準と権限者をあらかじめ決めておけば、いざというときに迷わず行動でき、被害を最小限に抑えられます。
切り戻しは「失敗」ではなく、事業を止めないための正当な選択肢として準備しておくべきものです。
旧システム・旧端末の保持期間(最低3ヶ月)
本番稼働の直後に旧システムやハンディ端末を破棄すると、切り戻しが必要になったときに旧システムへ再接続できず、業務が完全に止まってしまいます。
新システムが安定するまで、旧システムのライセンスと旧ハンディ端末は、最低でも3ヶ月は保持しておくことをおすすめします。
- 旧システム・旧端末の保持：ライセンスと旧端末を残しておく期間
- 実務要点：対象範囲と役割分担の整理
旧端末を保持するコストは、保守費やライセンス費として月数万円から発生します。一方で、万が一の業務停止による損失に比べれば、安全のための保険といえます。
新システムで繁忙期を一度乗り越え、Exit Criteriaを安定して満たしたことを確認してから、旧環境の撤去を計画的に進めます。
WMS刷新でよくある失敗と回避策
WMSのモダナイゼーションには、多くの企業が共通して陥る失敗パターンがあります。これらを事前に知っておくだけで、回避できるトラブルは少なくありません。
特に、在庫精度に直結する失敗と、予算面で見えにくい隠れコストの落とし穴を取り上げます。
例外処理の漏れが生むゴースト在庫
「WMSを入れれば在庫が合う」という期待は、よくある思い込みです。在庫が合わない真因の多くは、現場の例外処理がシステムに反映されていないことにあります。
たとえば、破損品を物理的に隔離したのに論理ステータスの変更を忘れると、システム上は出荷可能な在庫として残り続けます。これが「ゴースト在庫」となり、引当に使われて欠品クレームを引き起こします。
- 例外処理の漏れが生むゴースト在庫：在庫の不一致を生む例外処理の取りこぼし
- 実務要点：対象範囲と役割分担の整理
ほかにも、2個1セットの商品を1個だけ返品したときの単位の食い違いや、サンプル品を記録せずに持ち出す運用が、在庫差異を生みます。
回避策は、要件定義の段階でこれらの例外処理を洗い出し、システムの業務フローに正しく組み込むことです。現場ヒアリングの精度が、稼働後の在庫精度を左右すると言っても過言ではありません。
見積もりに出てこない隠れコスト
予算策定でつまずきやすいのが、提案書の見積もりには載らない隠れコストです。1、5、30、15〜20%、30万円を確認します。これらを見落とすと、稼働後に想定外の支出が積み上がります。
- 見積もりに出てこない隠れコスト：見積もり外で発生する支出の洗い出し
- 実務要点：対象範囲と役割分担の整理
さらに注意したいのが、SaaSの「初期費用無料」というキャッチコピーです。月額の従量課金が積み上がるため、中長期ではオンプレやパッケージより、かえって割高になることがあります。
たとえば、初期0円で月20万円なら5年で1,200万円、初期100万円で月10万円なら5年で700万円となり、5〜7年のTCO（総保有コスト）で逆転します。
費用は、必ず複数年のTCOで比べることが、後悔しない選択の前提です。
まとめ
製品選びよりも、移行実務と撤退戦略という泥臭い部分にこそ、成否が隠れています。
特に、倉庫管理特有の「在庫の壁」は、例外処理の作り込みと現場ヒアリングの精度で決まります。隠れコストは5年TCOで見抜き、切替は必ず閑散期に行うことを忘れないでください。
手順を一つずつ着実に踏めば、現場を崩さずに、在庫精度の向上と業務効率化という本来の目的を実現できます。本記事が、自社のWMS刷新を成功へ導く道しるべになれば幸いです。
▼全体ガイドの記事
・WMSのモダナイゼーションの完全ガイド
開発を相談する前に読みたい無料ホワイトペーパー
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。