WMSのモダナイゼーションでは、開発だけでなく、既存データの移行、現場端末の互換性、倉庫を止めない切替まで含めて、期間と納期を設計する必要があります。
- 移行対象：ロケーションマスタと在庫データの確認
- 現場条件：ハンディターミナルとの互換性の検証
- 切替条件：倉庫の稼働を止めないカットオーバーの計画
WMSのモダナイゼーションとは、老朽化した既存WMS（倉庫管理システム）を、クラウドネイティブな環境や最新のアーキテクチャへ刷新する取り組みです。
本記事は、「システムのモダナイゼーション」総論とは異なり、WMSに対象を絞って開発期間・スケジュール・納期を解説します。工程別の期間配分と、リホストからリプレースまでの5つの技術的アプローチ（5R）別の期間の違いを、具体的な数値とともに示します。あわせて、WMS特有の納期遅延要因と、納期を守る進め方も取り上げます。
老朽化した既存WMSの刷新を検討し始めた物流部門・情報システム部門の方が、現実的なスケジュールを描くための判断軸を身につけられる内容です。本テーマの全体像は、以下の記事で確認できます。
▼全体ガイドの記事
・WMSのモダナイゼーションの完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
WMSのモダナイゼーションの位置づけ（対象範囲の確認）
WMSのモダナイゼーションの開発期間を正しく見積もるには、まず「何を刷新するのか」という対象範囲を、隣接する3つの記事群と切り分けて理解しておく必要があります。
同じ「WMS」「モダナイゼーション」というキーワードでも、新規導入、対象レイヤー、技術手法の総論とでは、プロジェクトの前提がまったく異なるためです。
WMS開発（新規導入）・在庫管理システムのモダナイゼーションとの違い
「WMS開発」の記事は、既製のクラウドサービスやパッケージを一から選定・導入する、グリーンフィールドのプロジェクトを前提にしています。要件定義から始めてロケーション体系や引当ロジックをゼロから設計し、稼働までの期間はクラウド型で最短2週間〜3ヶ月、フルスクラッチ型で最長3年以上という幅で語られます。
一方、本記事が扱うのは、数年〜十数年にわたって稼働してきた既存WMSを前提にするブラウンフィールドの刷新です。多くの場合、既存WMSはオンプレミスのサーバー上で動く古いパッケージで、ハンディターミナルもWindows CE専用機であるなど、ハードウェアとソフトウェアの両面で老朽化が進んでいます。
在庫管理システムのモダナイゼーションは、全社の在庫数量・在庫金額を把握し、販売・生産・購買・会計と連携する経営に近いレイヤーを扱います。これに対しWMSのモダナイゼーションは、入荷から出荷までの倉庫内の現場オペレーションを対象とします。さらに、既存のロケーションマスタ・在庫データと現場のハンディターミナルを新環境へどう引き継ぐかという移行の論点が、新規導入との最大の違いになります。
「システムのモダナイゼーション」総論との違い（技術手法の位置づけ）
「システムのモダナイゼーション」総論は、対象システムの種類を問わず、5つの代表的な技術的アプローチを横断的に解説するものです。本記事では、その5つを便宜的に5Rと呼び、この枠組みを引き継ぎながら、対象をWMSに絞って期間や事例に落とし込みます。
WMSのモダナイゼーションでは、5Rのどれを選ぶかによって、ロケーションマスタ・在庫データをどこまで作り変えるか、現場端末をどこまで刷新するかが変わり、それがそのまま開発期間に直結します。たとえば、サーバーをクラウドに移すだけのリホストでは、現場の操作画面や業務ロジックを変えないため、短期間で完了します。
一方、老朽化したロケーション体系を作り直すリビルドを選ぶと、旧システムで「A-01-03」のようにテキスト入力されていた棚番を、新システムの厳密な階層コードへ変換する再設計が必要になります。このため、期間は大きく延びます。なお、経営層の投資判断や稟議に重心を置く「WMS刷新」は別記事で扱う予定で、本記事は技術的にどう刷新するかに重きを置きます。
開発期間・スケジュールの全体像（工程別の期間配分）
WMSのモダナイゼーションでは、実装フェーズだけでなく、その前後の上流工程と稼働後の定着化フェーズまで含めて、スケジュールを描く必要があります。
特に、既存のロケーションマスタ・在庫データを扱う移行の工程と、現場のハンディターミナルを入れ替える工程は、新規導入にはない独自の時間を要します。
現状アセスメント〜移行方針決定までの上流工程
上流工程は、現状アセスメント・分析（約2〜3ヶ月）、目標設定・移行対象の優先順位決定（約1〜2ヶ月）、方針・技術的アプローチの決定とベンダー選定（約1〜2ヶ月）の3ステップで構成されるのが一般的です。上流工程だけで合計4〜7ヶ月程度を要することが多いものの、省略して実装に急ぐと、移行データの範囲や技術的アプローチを誤り、後工程で大きな手戻りが起きるおそれがあります。
現状アセスメントでは、既存WMSのロケーションマスタ・在庫データの構造、上位のOMS（受注管理システム）・下位のTMS（輸配送管理システム）や基幹システムとの連携範囲、ハンディターミナルのOS・機種を把握します。そのうえで、どこにどれだけの技術的負債があるかを洗い出します。
目標設定では、保守コストの削減率やピッキング作業時間の短縮率といった定量的なKPIを定め、全拠点を一斉に刷新するか、特定の拠点や温度帯から着手するかを決めます。方針決定では、既存データ・現場端末の複雑さと予算・期間の制約を踏まえて、後述する5R（リホスト〜リプレース）のどれを採用するかを選びます。
データ移行・現場端末入替を含む実装〜稼働後定着化の期間
計画が固まった後の実装フェーズは、約6〜18ヶ月が目安で、採用する技術的アプローチや既存データ・現場端末の複雑さによって大きく変わります。期間を見積もるには、移行や端末の入替といった、新規導入にはない作業を含めて考える必要があります。
- 実装の範囲：本体の構築・改修に加えて、既存のロケーションマスタ・在庫データを新環境へ移すデータ移行も必ず含まれます。
- 現場端末の入替：旧WMSがWindows CE専用端末にしか対応しない場合は、移行と同時にAndroidベースの端末へ入れ替えます。
- 移行対象の除外：過去12ヶ月間に一度も入出荷実績がない廃番商品や休止ロケーションは、「12ヶ月ルール」に基づいて移行対象から外します。
- 稼働後の定着化：移行後約6〜12ヶ月は、クラウドのコストを見直し、運用監視の体制を設計し、現場担当者への操作教育を続けます。
現場端末を入れ替える際は、端末の調達と現場教育も進める必要があります。また、除外作業（クレンジング）を怠ると、稼働後に検索遅延や、ピッキング担当者が存在しないロケーションへの誘導といったトラブルが起きます。
WMSは日々の出荷業務と月次の棚卸という業務サイクルを持つため、定着化を見積もりに含めずに「本番稼働＝プロジェクト完了」と捉えると、実質的な定着までの期間を大きく過小評価することになります。
5つの技術的アプローチ別に見る開発期間の違い
WMSのモダナイゼーションでは、5R（リホスト・リプラットフォーム・リファクタリング・リビルド・リプレース）のうちどれを選ぶかによって、開発期間が数ヶ月から数年まで大きく変わります。
期間を左右する最大の分岐点は、ロケーションマスタ・在庫データの構造と現場端末をどこまで引き継ぐかです。アプリケーション層だけを刷新してこれらを放置すると、期待した効果が得られないまま期間だけが延びかねません。
短期で済むマイグレーション系（リホスト・リプラットフォーム）の期間目安
リホスト（リフト＆シフト）は、既存WMSの業務ロジックや操作画面、ロケーションマスタの構造を一切変えず、インフラだけをクラウドに移す手法です。期間は数ヶ月からと最も短く、現場スタッフの操作教育コストを抑えながら、既存の業務フローを保てる点が最大のメリットです。
一方で、既存の手作業プロセスの非効率性もそのまま引き継がれる点には留意が必要です。また、オンプレミスのサーバーは概ね5年周期でハードウェアの老朽化による再購入が必要になるため、その更新時期に合わせてリホストを選ぶ企業も少なくありません。
リプラットフォームは、基本構造のまま在庫データベースをマネージドサービス化し、夜間バッチ処理の一部をコンテナ化する手法で、期間の目安は約4〜10ヶ月です。ロケーション体系や引当ロジックは変えないため、リビルドより検証範囲が狭く、比較的短期で完了します。ただし、どちらも既存の構造や業務ロジックを引き継ぐため、老朽化したロケーション体系や引当ロジックが温存され、保守性に課題が残りやすくなります。
長期化しやすいリファクタリング・リビルド・リプレースの期間目安
リファクタリングは、ロケーション管理や引当ロジックといったビジネスロジックを維持したまま、コードの内部構造を整理し直す手法で、期間の目安は約8〜18ヶ月です。長年の改修で複雑化したピッキングロジックをマイクロサービス化する場合は、既存の処理結果と新しい処理結果が一致するかを確かめる回帰テストに、相応の時間がかかります。
リビルドは、既存WMSを廃棄し、クラウドネイティブなアーキテクチャでゼロから再構築する最も大規模な手法で、要件定義からカットオーバーまで1年半〜3年以上に及ぶこともあります。旧システムで「A-01-03」のようにテキスト入力されていたロケーション体系を、厳密な階層コードへ作り直すようなケースでは、この規模の期間を見込む必要があります。
リプレース（SaaS・パッケージへの移行）は、自社で開発を抱えない分、最短数週間〜3ヶ月という短期間で導入できるケースが多いです。ただし、既存の運用ルールをどこまで標準機能に合わせられるか（Fit to Standard）の社内調整と、ロケーションマスタのデータクレンジングに、想定以上の時間がかかりがちです。いずれの手法でも、テーブル設計と現場端末の刷新範囲が期間を左右します。
WMS特有の納期遅延要因
WMSのモダナイゼーションでは、既存のロケーションマスタ・在庫データと、現場で稼働中のハンディターミナルという物理資産を抱えています。そのため、新規導入とは異なる特有の要因でプロジェクトが停滞し、納期遅延を招きやすくなります。
ここでは、代表的な2つの遅延要因と、それぞれの対策を見ていきます。
ロケーションマスタ・在庫データ移行における遅延リスク
納期遅延の最も典型的な要因は、ロケーションマスタと在庫データの移行工数を過小評価することです。長年運用したWMSには、廃番商品コードや休止ロケーション、拠点ごとに異なるコード体系が溜まっているのが常です。そのため、過去12ヶ月間に一度も入出荷実績がない商品や休止ロケーションを移行対象から除く「12ヶ月ルール」に基づくクレンジングが必須です。
旧システムで「A-01-03」のようにテキスト形式で入力されていた棚番は、新システムの「ゾーン-列-段-間口」といった厳密な階層コードへ分解・マッピングする変換仕様の設計も欠かせません。複数拠点で異なるコード体系を使っていた場合、この名寄せ作業には想定の2〜3倍の工数がかかることが多く、大きな遅延要因になります。
さらに見落とされがちなのが、旧ベンダーのデータベースに自社から直接アクセスできない契約です。移行テストのたびに旧ベンダーへCSV抽出を依頼するため、1回あたり数十万円のスポット費用と依頼ごとの待ち時間が、テストサイクルを遅らせます。対策は、着手と並行して、またはその前に、データの品質評価とクレンジング、旧ベンダーとの抽出条件の確認を済ませることです。
ハンディターミナル等現場端末の互換性問題
もうひとつの典型的な遅延要因は、現場のハンディターミナルなど端末の互換性問題です。旧WMSがWindows CE専用端末にしか対応せず、新WMSがAndroidベースの端末にしか対応しないといったケースは珍しくなく、ソフトウェアの刷新と同時に端末そのものの入替が必要になります。
従来型のハンディターミナルは1台10〜30万円程度が相場ですが、Android搭載のスマートデバイス型なら1台5〜15万円程度で調達でき、月額6,500〜11,000円程度のレンタルを使う企業も増えています。台数が多い現場ほど、端末の調達と設定作業に数週間〜1ヶ月程度のリードタイムがかかり、新しい端末に慣れるための現場教育期間も確保する必要があります。
バーコード体系を変える場合（ITFからGS1-128へ等）は、ラベル貼替とプリンタ設定を移行スケジュールに完全に同期させる必要があります。同期が取れないと、稼働初日からバーコードが読めないという致命的なトラブルになります。対策は、要件定義の初期に端末のOS・機種・バーコード体系を洗い出して互換性を確かめ、調達のリードタイムを開発計画に織り込むことです。
納期を守るための実務的な進め方
期間の目安や遅延要因を踏まえると、納期を守るには、業務を止められない現場に合わせたカットオーバー設計と、発注前の準備の両方を固めておくことが欠かせません。
カットオーバー方式の選択と並行稼働設計
倉庫の稼働を止めない中で、自社の稼働形態に合う切り替え方を選ぶことは、最も重要な設計判断の一つです。方式は、業務停止の時間帯に一気に切り替える一括切替（ビッグバン）方式、拠点や温度帯ごとに進める段階移行方式、棚卸のタイミングでフルデータを移行したあと変動分だけを追従させる差分移行方式の3つです。差分移行は、ECや3PLなど24時間365日稼働する現場向けです。
切り替え後は、同じ入出庫データを新旧両方のシステムに反映して数値の一致を確かめる、パラレルラン（並行稼働）を行います。新旧の二重入力で業務負荷は1.5〜2倍になるため、期間は通常2〜4週間程度に抑え、入力担当者を絞るなどの工夫も必要です。ただし、基幹システム全体の刷新を伴う大規模案件では、月次の締め処理まで検証するため、最低3ヶ月間の並行稼働が推奨されます。
並行稼働中は、出荷などの指示を新WMSからのみ出す「指示系統の一本化」を徹底し、現場の混乱を防ぎます。在庫の突合結果が「棚卸差異率0.1%以内」を満たせない場合に、旧システムへ切り戻すかを判断する権限者を事前に合意しておきます。旧システムのサーバーやハンディターミナルは、稼働後も最低3ヶ月間は解約せずに残しておくと、想定外の事態に備えられます。
発注前の準備と依頼先選定のポイント
発注前には、要件概要書として前提条件をまとめておきます。対象拠点の範囲、移行データの量、現場端末の機種とOSを中心に、連携する周辺システム（OMS・ERP・TMS等）や、稼働中システムを止められない業務時間帯も書き添えます。こうした情報をそろえると、複数のベンダーから比べやすい見積もりとスケジュール提案を得やすくなります。
あわせて、現場のリーダークラスや情報システム部門から、意思決定権を持つキーパーソンをプロジェクト体制に組み込んでおく必要があります。依頼先を選ぶ際は、既存WMSや業界特有の倉庫運用への理解、5Rのどのアプローチにも応じられる提案力、既存データ・現場端末の移行に伴走してきた実績を確かめます。
プロジェクト開始後は、週次などの定例会議で進捗と課題を一覧にします。仕様変更の申し出は口頭で済ませず、変更要求として起票するルールを徹底します。全体工程には10〜20%程度のリスクバッファを組み込んでおくことが、想定外の事象にも稼働時期を守るための備えになります。
まとめ
本記事では、対象範囲を確かめたうえで、工程別の期間配分と5R別の期間の違いを軸に、WMS特有の納期遅延要因と納期を守る進め方まで解説しました。
上流工程だけで合計4〜7ヶ月程度を要することが多いです。実装フェーズは、既存データを引き継ぐリホストの数ヶ月から、ゼロから作り直すリビルドの1年半〜3年以上まで、選ぶアプローチによって大きく変わります。稼働後も6〜12ヶ月の定着化期間が必要です。
既存データの移行、現場端末の互換性、倉庫を止めないカットオーバーという、ブラウンフィールド特有の制約をどう扱うかが、WMSのモダナイゼーションにおける最大の論点です。
ビッグバン方式を避け、拠点や業務単位で段階的に移行を進めるとともに、既存データ・現場端末の移行実績が豊富なパートナーに早めに相談することをお勧めします。
▼全体ガイドの記事
・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を創業。