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