WMSのモダナイゼーションでPoCを行う目的は、在庫・端末・並行稼働を含めて移行が実現できるかを確かめることです。
- データ：ロケーションマスタと在庫データを正しく移せるか
- 並行稼働：新旧システムで数値がずれないか
- 現場端末：ハンディターミナルが問題なく動作するか
この検証を省いて本開発に進むと、稼働直前になって在庫が合わない、現場端末でバーコードが読み取れないといった深刻な問題に直面しかねません。詳しい全体像は、次の記事をご覧ください。
▼全体ガイドの記事
・WMSのモダナイゼーションの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMSのモダナイゼーションにおけるPoCの位置づけ
WMSのモダナイゼーションは、オンプレミスのサーバーや老朽化したハンディターミナルで運用してきた既存のWMS（倉庫管理システム）を、クラウドネイティブな環境や最新のアーキテクチャへ刷新する取り組みです。すでに稼働しているシステムを前提とするブラウンフィールドの刷新で、ゼロから作る新規構築（グリーンフィールド）とは前提が異なります。
PoCが何を検証するのかは、新規導入や総論のPoCとの違い、そして失敗時の影響範囲を見ると分かります。
新規導入PoC・総論モダナイゼーションPoCとの違い
「WMS開発」の記事で扱う新規導入のPoCは、まだ存在しない業務フローを対象に、「この機能で本当に現場作業が回るか」「ピッキング動線は実際の倉庫レイアウトに合っているか」を実データで一から検証するものです。一方、総論の「システムのモダナイゼーション」が扱うPoCは、選んだ技術的アプローチ（5R）が実現できるかを確かめる、移行手法そのものの検証です。
本記事で扱うWMSのモダナイゼーションのPoCは、この両者の中間に位置づきます。既存のロケーションマスタ・在庫データと現場の運用を前提に、新環境へ正確に移せるか、旧システムで使っていた端末が問題なく機能するか、倉庫を止めずに新旧を並行稼働させても数値がずれないかを確かめます。
移行の正確性を確かめることが最大の目的です。さらに、画面が動くかどうかだけでなく、「今と同じ現場オペレーションが、より新しい環境で再現できるか」を確かめる点が、モダナイゼーションPoC特有の視点です。
失敗時の影響範囲（現場停止・在庫差異・OMS/TMS連携への波及）
WMSのモダナイゼーションでPoCを軽視できないのは、失敗の影響が単一システムにとどまらないためです。WMSは、上位のOMS（受注管理システム）から出荷指示を受け取り、出荷完了後には下位のTMS（輸配送管理システム）へ実績を渡します。この連携が正しく機能して初めて、受注から配送までの全体プロセスが成り立ちます。
移行の失敗は、現場の作業、在庫の数字、そして経営へと順に影響が広がります。
- 現場停止：移行後のロケーションマッピングにわずかでもずれがあると、ハンディ端末が誤った場所へ作業者を誘導し、現場が混乱します。
- 在庫差異：稼働してすぐには発見しづらい問題で、システム上の在庫数と実際の棚の数量が食い違ったまま蓄積し、月次・年次の棚卸で一気に表面化します。
- 経営への打撃：欠品による販売機会の損失や、過剰在庫による保管コストの増加として表れます。
新規導入は稼働前に検証期間を確保しやすい一方、モダナイゼーションは倉庫業務を止められない制約の中で検証します。そのため、限られた時間で実効性の高いPoCを設計できるかが、プロジェクト全体の成否を左右します。
ロケーションマスタ・在庫データ移行のPoC・リハーサル
モダナイゼーションのPoCの中核は、既存のロケーションマスタと在庫データを新環境に移す、データ移行の検証です。本番での失敗を防ぐため、事前のリハーサルで何を確認すべきかを順に見ていきます。
「12ヶ月ルール」によるデータクレンジングの実機検証
データ移行のPoCでまず検証すべきは、「12ヶ月ルール」に基づくクレンジングの実機検証です。過去12ヶ月間に一度も入出荷実績がない廃番商品や、使われなくなった休止ロケーションを、どこまで自動で検出して移行対象から除けるかを確かめます。
実際に運用してきた本番相当のデータで検証すると、カタログスペックや机上の検討では見えなかった課題が浮かび上がります。この検証を省いて想定だけで本開発に進むと、稼働後に商品検索が遅れたり、ピッキング担当者が存在しないロケーションへ誘導されたりします。
PoCの段階でクレンジングルールを実際に適用すると、どの程度が自動処理で整理でき、どの程度が人手の確認を要するかを数字で把握できます。この実測値は、本開発のスケジュールと費用を精緻化するうえで役立ちます。
ロケーションマスタのマッピング精度検証
データ移行のPoCで次に欠かせないのは、ロケーションマスタのマッピング精度の検証です。旧システムで「A-01-03」のようにテキスト形式で入力されていた棚番を、新システムの「ゾーン-列-段-間口」といった厳密な階層コードへ分解・変換する仕様が、実データで正しく機能するかを確かめます。
ロケーション情報は、レイアウト変更や棚の増設のたびに現場で手作業により更新されてきたことが多く、システム上の記録と現物の保管場所がずれているケースも珍しくありません。複数拠点で異なるコード体系を使っていた場合は、この名寄せ検証に想定の2〜3倍の工数がかかることも、実務ではよく見られます。
旧ベンダーのデータベースへ自社から直接アクセスできない契約になっているケースが多く、注意が必要です。移行テストのたびに旧ベンダーへCSV抽出を依頼する必要があり、1回あたり数十万円のスポット費用が発生することもあります。そのため、PoCの計画段階で旧ベンダーとのデータ抽出条件を事前に確認しておくことが望ましいです。
旧システムとの並行稼働検証・カットオーバーリハーサル
データが正しく移れたことを確かめたら、次は実際の運用に近い形で新旧システムを並行稼働させ、稼働中の倉庫業務を止めずに検証します。ここでは、WMS特有の検証ポイントを2つ解説します。
並行稼働時の在庫突合テストとExit Criteria
並行稼働では、新旧両方のシステムに同じ入出庫データを反映し、在庫数量が一致し続けるかを継続して監視します。目安は2〜4週間ですが、二重入力は現場の業務負荷を1.5〜2倍に引き上げるため、入力担当者を限定するなどの工夫が必要です。
並行稼働の合否は、処理エラー率、API通信の安定性、在庫の差異率の3点を、期間を区切った数値で見ます。
- 処理エラー率0.5%未満を2週間連続で維持できるか
- API通信が障害なしで4週間連続稼働するか
- 在庫の差異率が一定水準以下に収まった状態が一定日数続くか
基幹システム全体の刷新を伴う大規模なプロジェクトでは、月次の締め処理まで検証するため、最低3ヶ月間の並行稼働を確保することが推奨されます。また、出荷などの現場への指示は、並行稼働中も新WMSからのみ出す「指示系統の一本化」を徹底し、どちらのシステムの数字を正とするかを現場に明確に伝えておくことも欠かせません。
並行稼働を成功させる鍵は、検証項目と合格基準（Exit Criteria）をあらかじめ数値で定義しておくことです。その数値があれば、PoCの結果を感覚ではなく事実に基づいて評価できます。
切り戻し（ロールバック）計画の検証
並行稼働と並行して、致命的な問題が起きた際に旧システムへ戻すための「ロールバック計画」も、PoCの段階から検証しておく必要があります。棚卸差異率0.1%以内といった品質基準を満たせなかったとき、業務再開を強行するか旧システムへ戻すかを判断する意思決定権限者を、あらかじめ決めておきます。そのうえで、旧システムへ戻す手順そのものが機能するかを、リハーサルで確かめます。
特に見落とされがちなのは、旧WMSのサーバーや旧ハンディターミナルの回線契約・ネットワーク設定を、新WMS稼働後どこまで維持するかという点です。ネットワーク設定を残した旧端末やライセンス契約は、新WMS稼働後も最低3ヶ月は解約せずに残しておくことが、BCP（事業継続計画）対策として必須です。この維持期間中の二重コストも、PoCの段階でプロジェクト予算に織り込む必要があります。
現場端末（ハンディターミナル）のPoC検証ポイント
WMSのモダナイゼーションでは、ソフトウェアの検証だけでなく、現場で使うハンディターミナルなど端末側の検証も欠かせません。
たとえば、旧WMSがWindows CE専用の端末にしか対応せず、新WMSがAndroidベースの端末にしか対応しないケースでは、端末の入れ替えそのものがPoCの対象になります。
操作性・レスポンス速度の検証
端末を入れ替える場合は、画面の見やすさや手袋をしたままでの操作性に加え、通信のレスポンスタイムも確かめます。大量のデータ処理が走ったとき、バーコードを読み取ってから結果が反映されるまでに時間がかかると、現場作業が止まってしまいます。
ネットワークが不安定になりやすい倉庫の奥まったエリアや、金属棚が密集するエリアでも安定して通信できるかを、PoCの段階で実機を使って確認しておくべきです。また、旧システムに慣れた現場の作業者が、新しい端末や画面レイアウトにどの程度ストレスなく順応できるかも、現場の反応を見ながら評価します。
バーコード体系変更の同期検証
新システムへの移行に合わせてバーコード体系（ITFからGS1-128へ等）を変える場合は、ラベルの貼り替えやプリンタ設定の変更を、データ移行のスケジュールと完全に揃える必要があります。PoCの段階で、新旧のバーコード体系が混在する期間が生じないか、混在しても現場が混乱なく運用できるかを、シミュレーションしておきます。
稼働初日に一部のラベルの貼り替えが間に合わなかったり、旧ラベルの在庫が新システムで正しく読み取れなかったりすると、現場作業がその場で止まってしまいます。そこで、PoCの段階で移行境界のシナリオを具体的に洗い出し、切り替えの手順を現場と共有しておくことが、稼働当日のトラブルを防ぐ実践的な対策です。
技術的アプローチ別に見るPoCの違い・成功のポイント
リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）は、どれを選ぶかによってPoCで検証すべき内容が変わります。あわせて、PoCを成功させるための体制づくりも欠かせません。
マイグレーション系とリファクタリング・リビルドでのPoCの違い
リホストやリプラットフォームは業務ロジックを変えないため、PoCで主に確かめるのは、移行先でも従来のデータ構造と処理速度で動くかという技術的な実現可能性です。具体的には、既存のロケーションマスタと在庫データベースを新しいインフラ上に構築し、実際の取引量に近い負荷で処理速度が業務に耐えるかを検証します。バッチ処理や連携インターフェースがエラーなく動くかも確認します。
一方、リファクタリングやリビルドはビジネスロジック自体に手を入れるため、PoCで最も重視すべきは「新システムが旧システムと同じ処理結果を返すか」、つまり機能等価性（回帰検証）です。
同じ入出庫データを新旧両方のロジックに投入し、在庫数量やピッキング指示が一致するかを網羅的に確認します。手作業では工数が膨大になるため、本番相当のデータを自動で集め、検証スクリプトを生成するツールやAIを使って、回帰検証を効率化する動きも広がっています。
PoCを成功させるための体制づくり
PoCを実りあるものにするには、倉庫現場・情報システム部門・上位・下位システム（OMS・TMS）の担当者という3者を、早い段階から関わらせる体制が欠かせません。倉庫現場は端末の操作性やロケーション情報との整合性を、情報システム部門は移行の技術的な正確さを、OMS・TMS側の担当者は連携インターフェースの互換性を、それぞれの専門性から検証します。
特に、ハンディ端末を実際に操作する現場担当者が、PoCの段階から移行結果を確認すると効果的です。システム上は正しく見えても運用の実態とずれている問題など、机上の検証では気づけない課題を早期に見つけられます。
一方、情報システム部門やベンダーだけでPoCを完結させると、現場の視点が抜け落ち、本開発の途中や稼働後に「これでは現場で使えない」という問題が見つかりがちです。PoCの計画段階から関係者を巻き込み、検証項目の設計と検証への参加を求めることが、稼働後の混乱を防ぐ前提になります。
まとめ
ここまで、WMSのモダナイゼーションにおけるPoC・プロトタイプ・モックアップについて、PoCの位置づけと失敗時の影響範囲、データ移行、旧システムとの並行稼働、現場端末、5Rごとの違いを見てきました。
WMSのモダナイゼーションのPoCは、「何を作るか」より「移行が正確にできるか」を確かめるものです。既存のロケーションマスタ・在庫データを正しく移せるか、ハンディターミナルが機能するか、稼働中の倉庫業務と並行運用できるかが、主な確認点になります。
稼働後のトラブルを防ぐ鍵は、12ヶ月ルールに基づくデータクレンジングと、ロケーションマスタのマッピング精度の検証です。加えて、2〜4週間の並行稼働とExit Criteriaの数値定義、現場端末の互換性検証、最低3ヶ月の切り戻し計画も欠かせません。
まずは対象を絞ったPoCで、自社のロケーションマスタ・在庫データと現場端末の移行手順を検証し、そのうえで確かな判断材料を得てから本開発に進むことをお勧めします。
▼全体ガイドの記事
・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を創業。