WMSのモダナイゼーションのPoC・プロトタイプ・モックアップ開発について

WMSのモダナイゼーションとは、オンプレミスのサーバーや老朽化したハンディターミナルで長年運用してきた既存WMS（倉庫管理システム）を、クラウドネイティブな環境や最新のアーキテクチャへと刷新する取り組みです。ゼロからWMSを新規に構築する「WMS開発」がグリーンフィールドのプロジェクトであるのに対し、本記事が扱うのは、すでに稼働している既存WMSを前提としたブラウンフィールドの刷新であり、PoC（概念実証）で検証すべき内容も新規導入とは大きく異なります。新規導入のPoCが「ゼロから作る機能が現場業務を満たすか」を検証するのに対し、モダナイゼーションのPoCでは「既存のロケーションマスタ・在庫データを正しく移せるか」「倉庫稼働を止めずに新旧システムを並行稼働させても数値がずれないか」「ハンディターミナルなど現場端末が問題なく動作するか」といった、移行そのものの実現可能性を検証することに主眼が置かれます。この検証を怠ったまま本開発に進むと、稼働直前になって在庫が合わない、現場端末でバーコードが読み取れないといった深刻な問題に直面しかねません。

本記事では、対象システム種別を問わない「システムのモダナイゼーション」総論とは異なり、WMSに対象を限定したうえで、PoC・プロトタイプ・モックアップにフォーカスして解説します。PoCの位置づけと失敗時の影響範囲、ロケーションマスタ・在庫データ移行のPoC、旧システムとの並行稼働検証・カットオーバーリハーサル、現場端末のPoC検証ポイント、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）別に見たPoCの違いまでを体系的に解説します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・WMSのモダナイゼーションの完全ガイド

WMSのモダナイゼーションにおけるPoCの位置づけ

モダナイゼーションのPoCが何を検証するものかを理解するには、新規導入のPoCや総論記事が扱うPoCとの違い、そして失敗した場合の影響範囲を押さえておく必要があります。

「WMS開発」記事が扱う新規導入のPoCは、まだ存在しない業務フローに対して「この機能で本当に現場作業が回るか」「ピッキング動線は現実の倉庫レイアウトに合っているか」を、実データを使って一から検証するものです。一方、「システムのモダナイゼーション」総論が扱うPoCは、対象システムの種類を問わず、選定した技術的アプローチ（5R）が技術的に実現可能かどうかを検証する、いわば移行手法そのものの実現可能性検証に重心を置いています。本記事が扱うWMSのモダナイゼーションPoCは、この両者の中間に位置づけられます。すでに存在するロケーションマスタ・在庫データ・現場のオペレーションルールを前提としつつ、それを新しい環境に正確に移せるか、旧システムで使っていたハンディターミナルや業務端末が新環境でも問題なく機能するか、稼働中の倉庫を止めずに新旧システムを並行稼働させても数値がずれないかという、「移行の正確性」を検証することが最大の目的になります。単に画面が動くかどうかではなく、「今と同じ現場オペレーションが、より新しい環境で再現できるか」を確かめる点が、モダナイゼーションPoC特有の視点です。

WMSのモダナイゼーションでPoCを軽視できないのは、失敗した際の影響範囲が単一システムにとどまらないためです。WMSは上位のOMS（受注管理システム）から出荷指示データを受け取り、出荷完了後には下位のTMS（輸配送管理システム）へ実績データを渡すという連携が正しく機能して初めて、受注から配送までの全体プロセスが成立します。もし移行後のロケーションマッピングにわずかなずれが生じれば、ハンディ端末が誤ったロケーションへ作業者を誘導し、現場作業そのものが混乱します。さらに深刻なのは、システム上の在庫数と実際の棚にある数量が食い違う「在庫差異」という、稼働してすぐには発見しづらい問題として蓄積することです。在庫差異は日々の出荷業務では見過ごされがちですが、月次・年次の棚卸のタイミングで一気に表面化し、欠品による販売機会の損失や、逆に過剰在庫による保管コストの増加という形で経営に直接的な打撃を与えます。新規導入であれば稼働開始前に十分な検証期間を確保しやすい一方、モダナイゼーションでは既存の倉庫業務を止められないという制約の中で検証を行う必要があるため、限られた時間の中でいかに実効性の高いPoCを設計するかが、プロジェクト全体の成否を左右する重要な論点になります。

ロケーションマスタ・在庫データ移行のPoC・リハーサル

モダナイゼーションPoCの中核をなすのが、既存のロケーションマスタ・在庫データを新環境に移すデータ移行の検証です。本番移行での失敗を防ぐために、事前のリハーサルで何を確認すべきかを見ていきます。

データ移行のPoCでまず検証すべきなのが、過去12ヶ月間に一度も入出荷実績がない廃番商品や、使われなくなった休止ロケーションをどこまで自動的に検出し、移行対象から除外できるかという「12ヶ月ルール」に基づくクレンジングの実機検証です。カタログスペックやデモ用の綺麗なダミーデータではなく、実際に運用してきた本番相当のデータを使って検証することで、机上の検討では見えなかった課題が浮かび上がります。この検証を省略して机上の想定だけで本開発に進んでしまうと、新システム稼働後に商品検索が遅延したり、ピッキング担当者が存在しないロケーションへ誘導されたりするトラブルが発生します。PoCの段階で、実際にクレンジングルールを適用してみることで、どの程度のデータが自動処理で整理でき、どの程度が人手による確認を要するのかを定量的に把握でき、この実測値は本開発のスケジュールと費用を精緻化するうえで非常に価値のある情報になります。

データ移行のPoCで次に重要なのが、ロケーションマスタのマッピング精度検証です。旧システムで「A-01-03」のようにテキスト形式で入力されていた棚番を、新システムの「ゾーン-列-段-間口」といった厳密な階層コードへ分解・マッピングする変換仕様が、実際のロケーションデータに対して正しく機能するかを検証します。特にロケーション情報は、倉庫のレイアウト変更や棚の増設のたびに現場で手作業により更新されてきた履歴を持つことが多く、システム上の記録と現物の保管場所にずれが生じているケースが珍しくありません。複数拠点で異なるコード体系を用いていた場合、この名寄せ検証には想定の2〜3倍の工数がかかることも実務上よく見られます。あわせて、旧ベンダーのデータベースへ自社から直接アクセスできない契約になっているケースが多い点にも注意が必要です。移行テストのたびに旧ベンダーへCSV抽出を依頼する必要があり、1回あたり数十万円のスポット費用が発生することもあるため、PoCの計画段階で旧ベンダーとのデータ抽出条件を事前に確認しておくことが望ましい対応です。

旧システムとの並行稼働検証・カットオーバーリハーサル

データが正しく移行できることを確認したら、次は実際の運用に近い形で新旧システムを並行稼働させ、稼働中の倉庫業務を止めずに検証するフェーズに移ります。ここではWMS特有の2つの検証ポイントを解説します。

並行稼働の検証では、新旧両方のシステムに同じ入出庫データを反映させ、在庫数量が一致し続けるかを継続的に監視します。目安となる期間は2〜4週間ですが、二重入力は現場の業務負荷を1.5〜2倍に引き上げるため、入力担当者を限定するなどの工夫が必要です。基幹システム全体の刷新を伴う大規模なプロジェクトでは、月次の締め処理まで検証するために最低3ヶ月間の並行稼働を確保することが推奨されます。並行稼働を成功させる鍵は、検証項目と合格基準（Exit Criteria）をあらかじめ数値で定義しておくことです。「処理エラー率0.5%未満を2週間連続で維持できるか」「API通信が障害なしで4週間連続稼働するか」「在庫の差異率が一定水準以下に収まった状態が一定日数継続するか」といった検証項目を洗い出し、それぞれについてどの数値を満たせば合格とするかを事前に決めておくことで、PoCの結果を感覚ではなく事実に基づいて評価できます。あわせて、出荷などの現場への物理的な指示は新WMSからのみ出す「指示系統の一本化」を並行稼働中も徹底し、どちらのシステムの数字を正として扱うかを現場に明確に伝えておくことも欠かせません。

並行稼働の検証と並行して、万が一致命的な問題が発生した際に旧システムへ切り戻すための「ロールバック計画」もPoCの段階から検証しておく必要があります。棚卸差異率0.1%以内といった品質基準を満たせなかった場合に、業務再開を強行するか旧システムへ戻すかを判断する意思決定権限者をあらかじめ合意しておくことに加え、実際に旧システムへ切り戻す手順そのものが機能するかをリハーサルで確認しておくことが重要です。特に見落とされがちなのが、旧WMSのサーバーや旧ハンディターミナルの回線契約・ネットワーク設定を、新WMS稼働後どのタイミングまで維持しておくかという点です。以前のネットワーク設定を保持した旧端末やライセンス契約を、新WMS稼働後最低3ヶ月は解約せずに残しておくことがBCP（事業継続計画）対策として必須であり、この維持期間中に発生する二重コストも、PoCの段階でプロジェクト予算に織り込んでおく必要があります。

現場端末（ハンディターミナル）のPoC検証ポイント

WMSのモダナイゼーションでは、ソフトウェアの検証だけでなく、現場で実際に使用するハンディターミナルなど端末側の検証も欠かせません。旧WMSがWindows CE専用の端末にしか対応しておらず、新WMSがAndroidベースの端末にしか対応していないといったケースでは、ハードウェアの入替そのものがPoCの対象になります。

新しい端末への入替を伴う場合、画面の見やすさや手袋をしたままでの操作性に加え、通信のレスポンスタイムが重要な検証項目になります。大量のデータ処理が走った際に、ハンディターミナルでバーコードを読み取ってから結果が反映されるまでに時間がかかるようになると、現場作業が停止してしまいます。ネットワーク環境が不安定になりやすい倉庫の奥まったエリアや金属棚が密集するエリアでも安定した通信ができるかを、PoC段階で実機を用いて確認しておくべきです。また、旧システムに慣れた現場作業者が、新しい端末・新しい画面レイアウトにどの程度のストレスなく順応できるかも、PoCの段階で現場の反応を見ながら評価すべきポイントです。

新システムへの移行に合わせてバーコード体系（ITFからGS1-128へ等）を変更する場合は、ラベルの貼り替えやプリンタの設定変更のタイミングを、データ移行スケジュールと完全に同期させる必要があります。PoCの段階で、新旧のバーコード体系が混在する期間が発生しないか、あるいは混在する場合でも現場が混乱なく運用できるかをシミュレーションしておくことが重要です。稼働初日に一部のラベルだけ貼り替えが間に合っていない、あるいは旧ラベルの在庫が新システムで正しく読み取れないといった事態が起きると、現場作業がその場で止まってしまいます。PoCの段階でこうした移行境界のシナリオを具体的に洗い出し、切り替えの手順を現場と共有しておくことが、稼働当日のトラブルを防ぐための実践的な対策です。

技術的アプローチ別に見るPoCの違い・成功のポイント

リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）は、どれを選ぶかによってPoCで検証すべき内容が変わります。あわせて、PoCを成功させるための体制づくりについても解説します。

リホストやリプラットフォームを選ぶ場合、業務ロジックそのものは変更しないため、PoCで確認すべきは主に「移行先の環境でも従来どおりのデータ構造・処理速度で動作するか」という技術的な実現可能性です。既存のロケーションマスタ・在庫データベースを新しいインフラ上に構築し、実際のトランザクション量に近い負荷をかけて処理速度が業務に耐えるかを検証したり、既存のバッチ処理や連携インターフェースが新環境でもエラーなく動くかを確認したりすることが中心になります。これに対して、リファクタリングやリビルドでは、ロケーション管理・引当ロジックといったビジネスロジック自体に手を入れるため、PoCで最も重視すべきは「新システムが旧システムと同じ処理結果を返すか」という機能等価性（回帰検証）です。同一の入出庫データを新旧両方のロジックに投入し、算出される在庫数量やピッキング指示が一致するかを網羅的に検証する必要があり、この検証は手作業では膨大な工数がかかるため、本番相当のデータを自動的に収集し検証スクリプトを自動生成するようなツールやAIを活用し、回帰検証を効率化する動きも広がっています。

WMSのモダナイゼーションにおけるPoCを実りあるものにするには、倉庫現場・情報システム部門・上位下位システム（OMS・TMS）の担当者という3者を早期に巻き込む体制づくりが欠かせません。倉庫現場は端末の操作性やロケーション情報との整合性を、情報システム部門は移行の技術的な正確性を、OMS・TMS側の担当者は連携インターフェースの互換性を、それぞれの専門性から検証する必要があります。特に、実際にハンディ端末を操作する現場担当者がPoCの段階から移行結果を確認することで、システム上は正しく見えても実際の運用実態とはずれているといった、机上の検証だけでは気づけない問題を早期に発見できます。情報システム部門やベンダーだけでPoCを完結させてしまうと、現場の視点が抜け落ち、本開発の途中や稼働後に「これでは現場で使えない」という問題が発覚しがちです。PoCの計画段階から関係者を巻き込み、それぞれの視点で検証項目を設計し、実際の検証にも参加してもらうことが、稼働後の混乱を防ぎ、モダナイゼーションを実務で機能するものにするための前提となります。

まとめ

本記事では、WMSのモダナイゼーションにおけるPoC・プロトタイプ・モックアップについて、PoCの位置づけと失敗時の影響範囲、ロケーションマスタ・在庫データ移行のPoC・リハーサル、旧システムとの並行稼働検証・カットオーバーリハーサル、現場端末のPoC検証ポイント、5つの技術的アプローチ別に見たPoCの違いを体系的に解説しました。WMSのモダナイゼーションのPoCは、新規導入のように「何を作るか」を検証するのではなく、既存のロケーションマスタ・在庫データを正確に移し、現場のハンディターミナルが問題なく機能し、稼働中の倉庫業務と並行運用できるかという「移行の正確性」を検証することに主眼があります。12ヶ月ルールに基づくデータクレンジング、ロケーションマスタのマッピング精度検証、2〜4週間の並行稼働とExit Criteriaの数値定義、現場端末の互換性検証、そして最低3ヶ月の切り戻し計画が、稼働後のトラブルを未然に防ぐための鍵となります。まずは対象を絞ったPoCで自社のロケーションマスタ・在庫データと現場端末の移行手順を検証し、確かな判断材料を得たうえで本開発に進むことをお勧めします。

▼全体ガイドの記事
・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を創業。