WMS移行の進め方/やり方/流れや方法/手法/工程/手順

WMS（倉庫管理システム）の移行は、単に新しいソフトウェアへ乗り換えるだけの作業ではありません。在庫データの整合性、現場オペレーションの切り替え、旧システムからの撤退まで含めた一大プロジェクトであり、進め方を誤ると誤出荷の多発や出荷停止といった事業へ直結する事故を招きます。実際、WMS移行の失敗原因の約7割はデータに起因すると言われており、製品選びよりも移行実務の段取りこそが成否を分けます。

この記事では、WMS移行の全体像から、要件定義・データ移行・並行稼働・本番稼働までの工程を、現場で本当につまずくポイントを交えて手順として体系的に解説します。在庫の時点整合性や例外処理が生むゴースト在庫、並行稼働の終わらせ方など、カタログ情報では語られない「移行のリアル」まで踏み込みますので、これから刷新を検討する物流責任者・情シス担当の方が、失敗を回避しながらプロジェクトを完遂するための実践的な道筋がつかめます。

▼全体ガイドの記事
・WMS移行の完全ガイド

WMS移行の全体像と進め方のステップ

WMS移行を成功させる第一歩は、プロジェクト全体の地図を描くことです。移行は大きく「企画・現状分析」「要件定義・ベンダー選定」「設計・開発」「データ移行」「並行稼働」「本番稼働・定着」という6つのフェーズに分かれます。それぞれのフェーズで関わる部門も成果物も異なるため、最初に全体像を共有しておかないと、後工程で「聞いていない」という手戻りが頻発します。まずは現状のシステムをなぜ変えるのか、その判断基準と全体ステップを押さえておきましょう。

移行プロジェクトを立ち上げる前に、そもそも「今が変えるべきタイミングなのか」を客観的に判断する必要があります。代表的なサインは、システムの保守期限切れ（EOL／EOSL）やOS・ハードウェアのサポート終了、レスポンス低下による業務遅延、そして特定のベテラン担当者しか操作できない属人化の進行です。とくにEC化によって出荷件数が数年で2倍3倍に膨らみ、既存システムの処理能力が頭打ちになっているケースは、刷新の決定的な合図と言えます。

もう一つ見逃せないのが、過度なカスタマイズによるブラックボックス化です。長年の改修を重ねた結果、改修費用がかさむうえに改修の影響範囲が誰にも分からなくなり、軽微な変更にすら数十万円と数週間を要する状態は、維持コストが刷新コストを上回る危険水域です。ERPとのデータ連携がCSVの手動取り込みで二重入力や転記ミスが常態化している場合も、業務効率と精度の両面で限界が近づいています。これらのシグナルが複数重なったら、本格的に移行を検討すべき段階です。

WMS移行は、企画フェーズで現状分析（As-Is）と目標設定（To-Be）を行い、要件定義とRFP作成を経てベンダーを選定するところから始まります。その後、設計・開発、データ移行、新旧システムの並行稼働、そして本番稼働・定着というように、段階を踏んで進みます。提供形態によって期間は大きく変わり、クラウド型（SaaS）であれば数ヶ月、パッケージ型のカスタマイズやフルスクラッチ型では半年から1年以上を見込むのが一般的です。

重要なのは、各フェーズに明確なゴールと判定基準を設けることです。たとえば要件定義フェーズは「RFPと要件定義書の合意」、データ移行フェーズは「移行リハーサルの成功」というように、次に進むための条件を文書化しておきます。こうしたマイルストーンを曖昧にしたまま走り出すと、後半の並行稼働で要件の抜け漏れが噴出し、スケジュールが数ヶ月単位で後ろ倒しになります。全体ステップを地図として共有し、各フェーズの完了条件を握ることが、進め方の土台になります。

要件定義・企画フェーズの進め方

要件定義・企画フェーズは、移行プロジェクト全体の品質を決める最重要工程です。ここで現状業務を正確に棚卸しし、新システムで実現したい姿を具体化できていないと、開発が進んでから「現場の運用と合わない」という致命的な手戻りが発生します。ベンダー丸投げが最も失敗しやすいのもこのフェーズであり、発注側が主体的に要件を整理する姿勢が問われます。現状分析・目標設定・RFP作成の順に、丁寧に進めていきましょう。

まず取り組むべきは、現状業務（As-Is）の徹底的な可視化です。入荷・検品・棚入れ・ピッキング・出荷・返品といった一連の作業を、通常パターンだけでなく例外パターンまで含めて洗い出します。ここで特に注意したいのが、現場が「良かれ」と思って続けている独自運用の例外処理です。セット品を手作業でバラして出荷する、破損品を物理的に隔離するがシステム上のステータスは変えない、といった暗黙のルールを拾い切れないと、移行後に在庫差異となって跳ね返ります。

そのうえで、新システムで達成したい目標（To-Be）を定量的なKPIに落とし込みます。たとえば在庫精度を99.5%以上に引き上げる、誤出荷率を現状の0.3%から0.05%以下に下げる、ピッキング1件あたりの所要時間を20%短縮するといった具体的な数値目標です。KPIを明文化しておくと、経営層への投資判断の説明材料になるだけでなく、本番稼働後に効果を検証する基準にもなります。「便利になる」といった曖昧な目的のまま進めると、投資対効果を示せず、社内の協力も得にくくなります。

整理した要件は、RFP（提案依頼書）としてベンダーへ提示します。RFPには、現状の課題、必須要件（Must）と希望要件（Want）の切り分け、ERPやOMS・TMSとの連携方式、想定する出荷件数や拠点数といった前提条件を明記します。とくに連携要件は曖昧にしやすく、「APIでリアルタイム連携できます」という提案を鵜呑みにすると、実は数時間ごとのバッチ連携だったという食い違いが起こります。連携の頻度・方式・障害時の挙動まで契約前に確認することが重要です。

ベンダー選定では、提案書の見栄えだけでなく、自社と同業種・同規模の移行実績や物流ノウハウの有無を見極めます。あわせて見落とされがちなのが、旧システムからの撤退（Exit）に関する確認です。現行ベンダーとの契約で自社が旧データベースへ直接アクセスできない場合、移行テストのたびにデータ抽出を依頼し、1回あたり数十万円のスポット費用が発生することがあります。選定段階で解約条件やデータ引き上げの費用・手順まで確認しておくと、後から想定外のコストに苦しまずに済みます。

データ移行を成功させる実務（失敗の7割はデータ）

WMS移行のトラブルの大半は、システムの機能不足ではなくデータに起因します。商品マスタや取引先マスタに重複や表記揺れが残ったまま新システムへ投入すると、ピッキング指示が出ない、在庫が引き当たらないといった障害が稼働初日に噴出します。データ移行は地味で工数のかかる作業ですが、ここを丁寧に進められるかどうかが移行全体の成否を決めると言っても過言ではありません。クレンジングと時点整合性の2点を軸に解説します。

長年運用してきたシステムには、使われていないデータが大量に蓄積されています。これらをそのまま移行すると、新システムの動作が重くなるうえ、現場が選択肢の多さに混乱します。そこで有効なのが「12ヶ月ルール」です。過去12ヶ月間に一度も入出荷実績のない商品マスタや、長期間使われていない休止ロケーションは思い切って移行対象から外す、という明確な基準を設けます。残すデータと捨てるデータの線引きを情報システム部門と現場で合意しておくと、移行作業が大幅に軽くなります。

次に必要なのが名寄せ作業です。同じ取引先が「株式会社○○」「(株)○○」「○○商事」と複数のコードで登録されている、といった重複は珍しくありません。これを放置すると在庫や出荷実績が分散し、正確な集計ができなくなります。マッピング表を作成して新旧のコード対応を定義し、表記揺れを統一していきます。クレンジングは一度で完璧にはならないため、テスト移行を複数回繰り返しながら、エラーになったデータを潰し込んでいく地道な作業が前提になります。

WMS移行で最も神経を使うのが、在庫データの「時点整合性」です。倉庫は移行作業中も入荷や出荷で在庫が動き続けるため、データを抽出した時点と新システムへ投入する時点の間にズレが生じます。このタイムラグを処理する方法は大きく2つあります。一つは、業務を止めずに抽出後の差分だけを反映する「差分移行」、もう一つは、週末などに倉庫の業務を完全に止めて一括で切り替える「業務停止一括切替」です。

差分移行は業務を止めずに済む反面、差分の取り込みロジックが複雑になり、抜け漏れのリスクが残ります。一括切替は確実性が高い一方で、出荷を止められる時間が限られるため、土日の数十時間で棚卸と移行を完了させる綿密な段取りが必要です。出荷件数の規模や倉庫の稼働カレンダーを踏まえて、どちらの方式が自社に適しているかを早い段階で決めておきます。いずれの方式でも、移行直前に実地棚卸を行って物理在庫とデータを一致させておくことが、時点整合性を担保する大前提となります。

並行稼働（パラレルラン）の正しい進め方と終わらせ方

新旧のシステムを一定期間同時に動かす並行稼働（パラレルラン）は、新システムの妥当性を本番データで検証できる安全策ですが、進め方を誤ると現場を崩壊させる諸刃の剣でもあります。両方のシステムへデータを入力する必要があるため、現場の工数は1.5倍から2倍に膨らみます。さらに最大の事故は、新旧両方からピッキングリストや送り状が出力される「指示系統の二重化」です。ここでは混乱を防ぐための一本化ルールと、並行稼働をきれいに終わらせる方法を解説します。

並行稼働で守るべき鉄則は、現場が実際に作業に使う物理的な指示書は必ず新システムからのものだけにする「指示系統の一本化」です。データ検証のために旧システムも裏で動かしますが、ピッキングリストや出荷指示書、送り状を新旧の両方から出力してしまうと、同じ商品を二重にピッキングしたり、誤った送り状を貼り付けたりといった事故が連発します。旧システムからの帳票出力は物理的に停止する、もしくは現場に渡らない運用とし、「作業の正は新システム」という原則を全員に徹底します。

旧システムはあくまで結果照合のための裏方と位置づけ、新システムの出荷結果と旧システムの想定値を突き合わせて差異を検証します。この役割分担を曖昧にすると、現場は「どちらの指示に従えばいいのか」と判断に迷い、繁忙時には混乱が一気に拡大します。並行稼働の初日に運用ルールを文書化して現場へ周知し、朝礼などで繰り返し確認することが、二重化事故を防ぐ最も確実な方法です。

並行稼働は「なんとなく安定したから終わり」では危険です。あらかじめ終了条件（Exit Criteria）を数値で定義しておきます。たとえば、出荷エラー率が0.5%未満で2週間継続している、ERPとのAPI連携が4週間以上トラブルなく稼働している、棚卸差異率が基準内に収まっている、といった具体的な合格ラインです。この基準を満たして初めて旧システムを停止すると判断すれば、感覚的な「もう大丈夫だろう」による見切り発車を防げます。

もう一つ極めて重要なのが、切り替えの時期です。並行稼働も最終切替も、出荷量が落ち着く閑散期に行うのが鉄則です。年末商戦やセール期などの繁忙期に切り替えると、ただでさえ1.5倍に増えた工数が処理能力を超え、現場が完全にパンクします。自社の出荷カレンダーを確認し、最も波が穏やかな時期に山場を持ってくるよう、プロジェクト全体のスケジュールを逆算して組み立てましょう。

本番稼働とリスク管理

本番稼働（カットオーバー）の当日と直後は、プロジェクトで最も緊張感の高い局面です。万全に準備したつもりでも、想定外のトラブルで出荷が止まる可能性はゼロにはなりません。だからこそ、何が起きたらどう判断し、誰が決定するのかをあらかじめ決めておくリスク管理が欠かせません。ロールバックの判断基準と権限、そして旧システムをいつまで保持するかという2点が、稼働直後の安全網になります。

本番稼働で深刻なトラブルが起きたとき、新システムでの復旧を試み続けるのか、それとも旧システムへ戻す（ロールバックする）のかは、一刻を争う重大な判断です。この決断を現場の混乱の中で感覚的に下すと、判断が遅れて被害が拡大します。あらかじめ「出荷エラー率が何%を超えたら」「主要機能の停止が何時間続いたら」ロールバックを検討する、という閾値を数値で定めておきます。同時に、その最終判断を下す権限者を一人に明確化し、エスカレーションの連絡経路も決めておきます。

ロールバックを現実的な選択肢として残すには、旧システムへ戻すための手順書とデータの巻き戻し方法を、稼働前にテストしておく必要があります。「いざとなったら戻せる」という安心感があるからこそ、現場は落ち着いて新システムの運用に集中できます。判断基準・権限者・復旧手順の3点をセットで準備することが、稼働直後のリスクを最小化する鍵です。

新システムが稼働したからといって、旧システムや旧ハンディ端末をすぐに破棄してはいけません。稼働直後に重大なトラブルが発覚し、旧システムへ戻そうとしても、旧端末を処分済みでは物理的に再接続できず、出荷が完全に止まってしまいます。実務上は、新システムの稼働後も最低3ヶ月は旧システムのサーバーやライセンス、旧ハンディ端末を保持しておくのが安全策です。月次の締め処理が問題なく完了し、繁忙期を一度乗り越えるまでは、退路を確保しておきます。

保持にはライセンス費やサーバー維持費といったコストがかかりますが、出荷停止による機会損失や信用失墜のリスクと比べれば、安価な保険です。旧システムの停止と契約解除のタイミングも、Exit Criteriaと同様に「稼働後3ヶ月かつ月次決算2回が無事完了したら」といった条件で判断します。ここでも、旧ベンダーとの解約手続きやデータの最終バックアップに想定外の費用や日数がかかることがあるため、早めに段取りを確認しておくことをおすすめします。

WMS移行でよくある失敗と回避策

WMS移行の失敗には、毎回のように繰り返される典型的なパターンがあります。事前に「落とし穴」を知っておけば、同じ轍を踏まずに済みます。ここでは、在庫差異を生む最大の原因である例外処理の反映漏れと、プロジェクト全体を頓挫させやすいベンダー丸投げ・現場教育不足という2つの代表的な失敗を取り上げ、その回避策を解説します。これらは技術の問題ではなく、進め方とコミュニケーションの問題である点が共通しています。

「WMSを入れれば在庫が自動的に合う」という期待は、残念ながら幻想です。在庫が合わなくなる真因の多くは、現場で発生する例外処理がシステムに正しく反映されないことにあります。たとえば、破損した商品を物理的には不良品エリアへ隔離したのに、システム上のステータスを変更し忘れると、出荷できないはずの在庫が引き当て可能なまま残ります。これがいわゆる「ゴースト在庫」で、受注を取ったのに実物がなく欠品クレームにつながる典型例です。

ほかにも、2個1セットの商品から1個だけ返品されたときの単位の食い違いや、展示用サンプルを記録せずに持ち出すといった運用が、じわじわと在庫差異を蓄積させます。回避策は、要件定義の段階でこれらの例外処理を漏れなく洗い出し、システムの操作フローに組み込むことです。あわせて、現場が「面倒だから」とシステム入力を省略しないよう、なぜその記録が必要なのかを教育で腹落ちさせることが、稼働後の在庫精度を支えます。

「専門家に任せれば安心」とベンダーへ要件を丸投げするのも、典型的な失敗パターンです。ベンダーは物流の専門家であっても、自社の倉庫特有の業務やイレギュラーまでは把握していません。発注側が現状業務を言語化して伝えなければ、出来上がったシステムが現場の実態と乖離し、稼働後に多額の追加改修費が発生します。要件定義やテストのシナリオ作成には、必ず現場のキーパーソンを巻き込み、発注側が主体性を持って関与する体制を組むことが回避策になります。

もう一つ軽視されがちなのが、現場スタッフへの教育です。どれほど優れたシステムでも、それを使う人が操作に習熟していなければ、入力ミスや作業遅延が多発します。本番稼働の前に十分なトレーニング期間を確保し、操作マニュアルを整備したうえで、イレギュラー対応も含めた実機演習を行います。パート・アルバイトを含めた全員が迷わず操作できる状態を作って初めて、システム投資が効果として実を結びます。教育を「稼働後にやればいい」と後回しにしないことが、定着の分かれ目です。

まとめ

WMS移行の進め方は、企画・現状分析から要件定義、データ移行、並行稼働、本番稼働・定着までの一連の工程を、各フェーズの完了条件を握りながら段階的に進めることが基本です。とりわけ、失敗の約7割を占めるデータ移行では、12ヶ月ルールによるクレンジングと在庫の時点整合性の確保が肝になります。並行稼働では指示系統を新システムに一本化し、数値で定義したExit Criteriaを満たしてから切り替えることで、現場の混乱と誤出荷を防げます。

さらに、本番稼働ではロールバックの判断基準と権限を明確にし、旧システムと旧端末を最低3ヶ月は保持して退路を確保しておきます。例外処理の反映漏れによるゴースト在庫や、ベンダー丸投げ・現場教育不足といった典型的な失敗は、進め方とコミュニケーションを丁寧に設計すれば回避できます。切り替えは必ず閑散期に行うという原則も忘れないでください。本記事で示した手順とチェックポイントを羅針盤として、自社のWMS移行を着実に成功へ導いていただければ幸いです。

▼全体ガイドの記事
・WMS移行の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。