WMSのモダナイゼーションの開発期間・スケジュール・納期について

WMSのモダナイゼーションとは、オンプレミスのサーバーや、Windows CE専用のハンディターミナルにしか対応していないような老朽化した既存WMS（倉庫管理システム）を、クラウドネイティブな環境や最新のアーキテクチャへと刷新する取り組みを指します。ゼロからWMSを新規に構築・導入する「WMS開発」がグリーンフィールド（更地）のプロジェクトであるのに対し、本記事が扱うのは、すでに稼働している既存WMSを土台にした刷新、いわゆるブラウンフィールドのプロジェクトです。同じ倉庫・物流領域のモダナイゼーションでも、全社の在庫数量・在庫金額を可視化する「在庫管理システムのモダナイゼーション」が経営に近いレイヤーを扱うのに対し、WMSのモダナイゼーションは入荷検品・ロケーション管理・ピッキング・棚卸・出荷梱包といった倉庫内の物理オペレーションを対象とした、より現場に近いレイヤーの刷新です。刷新にあたっては、既存のロケーションマスタ・在庫データをどう新環境へ移行するか、倉庫の稼働を止められない中でどうカットオーバーを設計するか、そしてハンディターミナルなど現場端末との互換性をどう確保するかという、新規導入にはない固有の論点が発生します。

本記事では、対象システム種別を問わない「システムのモダナイゼーション」総論とは異なり、WMSに対象を限定したうえで、開発期間・スケジュール・納期にフォーカスして解説します。工程別の期間配分、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）別に見た期間の違い、ロケーションマスタ移行や現場端末の互換性がもたらすWMS特有の納期遅延要因、そしてカットオーバーを含めた納期を守るための実務的な進め方までを、具体的な数値とともに体系的にお伝えします。老朽化した既存WMSの刷新を検討し始めた物流部門・情報システム部門の方にとって、現実的なスケジュールを描くための判断軸が身に付く内容です。

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

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

WMSのモダナイゼーションの位置づけ（対象範囲の確認）

WMSのモダナイゼーションの開発期間を正しく見積もるには、まず「何を刷新するのか」という対象範囲を、隣接する3つの記事群と切り分けて理解しておく必要があります。同じ「WMS」「モダナイゼーション」というキーワードでも、新規導入・対象レイヤー・技術手法の総論とではプロジェクトの前提がまったく異なるためです。

「WMS開発」というキーワードで解説される記事は、既製のクラウドサービスやパッケージを一から選定・導入する、いわゆるグリーンフィールドのプロジェクトを前提としています。要件定義から始めてロケーション体系や引当ロジックをゼロから設計し、稼働開始までの期間もクラウド型で最短2週間〜3ヶ月、フルスクラッチ型で最長3年以上というレンジで語られます。これに対して本記事が扱う「モダナイゼーション」は、すでに数年〜十数年にわたって稼働してきたWMSが存在することが前提です。多くの場合、その中身はオンプレミスのサーバー上で動く古いパッケージであり、現場のハンディターミナルもWindows CE専用機であるなど、ハードウェア・ソフトウェアの両面で老朽化が進んでいます。また、同じ「モダナイゼーション」でも、全社の在庫数量・在庫金額を可視化し、販売・生産・購買・会計と連携する経営に近いレイヤーを扱う「在庫管理システムのモダナイゼーション」に対し、WMSのモダナイゼーションはあくまで倉庫という物理空間の中で「モノがどこにあり、誰が、どの順番で、どう動かすか」という現場オペレーションの刷新に特化している点が大きな違いです。既存のロケーションマスタ・在庫データ、そして現場のハンディターミナルという物理資産をどう新環境に引き継ぐかという移行の論点が、新規導入との最大の違いとして加わります。

「システムのモダナイゼーション」総論は、対象システムの種類を問わず、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの代表的な技術的アプローチ（本記事では便宜的に5Rと呼びます）を横断的に解説するものです。本記事はこの5Rという枠組みを引き継ぎつつ、対象をWMSに限定して、より具体的な期間や事例に落とし込んで解説します。WMSのモダナイゼーションでは、5Rのどれを選ぶかによって「ロケーションマスタ・在庫データをどこまで作り変えるか」「ハンディターミナルなど現場端末をどこまで刷新するか」が変わり、それがそのまま開発期間に直結します。たとえば単にサーバーをクラウドに移すだけのリホストであれば現場の操作画面・業務ロジックは変更しないため短期間で完了しますが、老朽化したロケーション体系そのものを作り直すリビルドを選べば、旧システムで「A-01-03」のようにテキスト入力されていた棚番を、新システムの厳密な階層コードへ変換する再設計が必要になり、期間は大きく延びます。なお、経営層がなぜ・いつ刷新に踏み切るべきかという投資判断や稟議プロセスに重心を置いた「WMS刷新」というテーマは別記事で扱う予定であり、本記事はあくまで技術的にどうモダナイズするかというHOWの解説に軸足を置いています。

開発期間・スケジュールの全体像（工程別の期間配分）

WMSのモダナイゼーションは、実装フェーズだけでなく、その前後に発生する上流工程と稼働後の定着化フェーズまで含めてスケジュールを描く必要があります。特に既存のロケーションマスタ・在庫データを扱う移行系の工程と、現場のハンディターミナルの入替を伴う工程は、新規導入にはない独自の時間を要します。

上流工程は、現状アセスメント・分析（約2〜3ヶ月）、目標設定・移行対象の優先順位決定（約1〜2ヶ月）、方針・技術的アプローチの決定とベンダー選定（約1〜2ヶ月）の3ステップで構成されるのが一般的です。現状アセスメントでは、既存WMSがどのようなデータ構造でロケーションマスタ・在庫データを保持しているか、上位のOMS（受注管理システム）・下位のTMS（輸配送管理システム）や基幹システムとどの範囲でどう連携しているか、そして現場のハンディターミナルがどのOS・機種で稼働しているかを可視化し、どこにどれだけの技術的負債があるかを洗い出します。目標設定フェーズでは、保守コストの削減率やピッキング作業時間の短縮率といった定量的なKPIを設定し、全拠点を一斉に刷新するのか、特定の拠点や温度帯から着手するのかという優先順位を決めます。方針決定フェーズでは、後述する5R（リホスト〜リプレース）のどれを採用するかを、既存データ・現場端末の複雑さと予算・期間の制約を踏まえて選定します。WMSのモダナイゼーションはこの上流工程だけで合計4〜7ヶ月程度を要することが多く、ここを省略して実装に急ぐと、移行対象のデータ範囲や技術的アプローチの選定を誤り、後工程で大きな手戻りが発生するリスクが高まります。

計画が固まった後の実装フェーズは約6〜18ヶ月が目安ですが、これは選択する技術的アプローチと、既存データ・現場端末の複雑さによって大きく変動します。実装フェーズには、システム本体の構築・改修に加えて、既存のロケーションマスタ・在庫データを新環境に移すデータ移行という工程が必ず含まれます。長年運用したWMSには、過去12ヶ月間に一度も入出荷実績がない廃番商品や使われなくなった休止ロケーションが蓄積されていることが多く、これらを移行対象から除外する「12ヶ月ルール」に基づくクレンジングを怠ると、新システム稼働後に検索遅延やピッキング担当者が存在しないロケーションへ誘導されるといったトラブルが発生します。あわせて、旧WMSがWindows CE専用ハンディターミナルにしか対応していないケースでは、新WMSへの移行と同時にAndroidベースの端末へ入れ替える必要があり、この端末調達・現場教育も実装フェーズの重要な要素になります。実装が完了し本番稼働した後も、それで終わりではありません。稼働後の運用最適化・定着化フェーズとして、移行後約6〜12ヶ月にわたり、クラウドコストの最適化、運用監視体制の設計、現場担当者への操作教育を継続して行う必要があります。WMSは日々の出荷業務と月次の棚卸という業務サイクルを持つため、この定着化フェーズを見積もりに含めずに「本番稼働=プロジェクト完了」と捉えてしまうと、実質的な定着までの期間を大幅に過小評価することになります。

5つの技術的アプローチ別に見る開発期間の違い

WMSのモダナイゼーションでは、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ（5R）のうちどれを選ぶかによって、開発期間が数ヶ月から数年まで大きく変わります。ロケーションマスタ・在庫データの構造と現場端末をどこまで引き継ぐかが、期間を左右する最大の分岐点です。

リホスト（リフト＆シフト）は、既存WMSの業務ロジックや操作画面、ロケーションマスタの構造を一切変更せず、インフラだけをクラウドに移す手法で、期間は数ヶ月からと最も短くて済みます。現場スタッフの操作教育コストを抑えられ、既存の業務フローを壊さずに短期間で移行できる点が最大のメリットですが、既存のレガシーな手作業プロセスの非効率性もそのまま引き継がれてしまう点には留意が必要です。オンプレミスのサーバーは概ね5年周期でハードウェアの老朽化による再購入が必要になるため、その更新タイミングに合わせてリホストを選ぶ企業も少なくありません。リプラットフォームは、WMSの基本構造は維持しつつ、在庫データベースをマネージドサービス化したり、夜間バッチ処理の一部をコンテナ化したりする手法で、期間の目安は約4〜10ヶ月です。ロケーション体系や引当ロジックそのものには手を入れないため、リビルドやリファクタリングに比べて検証すべき範囲が限定され、比較的短期間で刷新を完了できます。ただし、どちらの手法も既存のデータ構造・業務ロジックをそのまま引き継ぐ性質上、老朽化したロケーション体系や複雑化しすぎた引当ロジックそのものは温存されるため、稼働後の保守性という観点では課題が残りやすい点に留意が必要です。

リファクタリングは、ロケーション管理や引当ロジックといったビジネスロジックを維持しながら、コードの内部構造を整理し直す手法で、期間の目安は約8〜18ヶ月です。長年の改修で複雑化したピッキングロジックを整理し、マイクロサービス化を進める場合には、既存の処理結果と新しい処理結果が一致するかを確認する回帰テストに相応の時間がかかります。リビルドは、既存WMSを廃棄し、クラウドネイティブなアーキテクチャでゼロから再構築する最も大規模な手法で、期間は要件定義からカットオーバーまで1年半〜3年以上に及ぶこともあります。旧システムで「A-01-03」のようにテキスト入力されていたロケーション体系を、厳密な階層コードへ作り直すようなケースでは、この規模の期間を見込む必要があります。リプレース（SaaS・パッケージへの移行）は、自社で開発を抱えない分、最短数週間〜3ヶ月という短期間で導入できるケースが多いものの、既存の運用ルールをどこまで標準機能に合わせられるか（Fit to Standard）の社内調整と、ロケーションマスタのデータクレンジングに想定以上の時間がかかりがちです。いずれの手法でも、WMSでは「ロケーションマスタ・在庫データのモデル（テーブル設計）の見直しをどこまで行うか」と「現場のハンディターミナルをどこまで刷新するか」が期間を左右する共通の変数であり、アプリケーション層だけを刷新してこれらを放置すると、期待した効果が得られないまま期間だけが延びる結果になりかねません。

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・機種・バーコード体系の現状棚卸を行い、新システムとの互換性を早期に確認したうえで、端末調達のリードタイムを開発スケジュールに正しく織り込んでおくことが欠かせません。

納期を守るための実務的な進め方

ここまで見てきた期間の目安や遅延要因を踏まえると、WMSのモダナイゼーションで納期を守るためには、業務を止められない現場に合わせたカットオーバー設計と、発注前の準備の両方をしっかり固めることが欠かせません。

倉庫の稼働を止められない中でどう切り替えるかは、WMSのモダナイゼーションにおいて最も重要な設計判断の一つです。カットオーバー方式には、週末など業務停止のタイミングを利用して一気に切り替える「一括切替（ビッグバン）方式」、拠点や温度帯ごとに段階的に切り替える「段階移行方式」、そしてECや3PLなど24時間365日稼働する現場向けに、棚卸のタイミングでフルデータを移行しその後の変動分だけを追従させる「差分移行方式」の3つがあり、自社の稼働形態に合わせて選ぶ必要があります。切り替え後は、新旧システムに同じ入出庫データを反映させて数値の一致を確認するパラレルラン（並行稼働）を行いますが、新旧二重入力は現場の業務負荷を1.5〜2倍に引き上げるため、期間は通常2〜4週間程度に抑え、入力担当者を限定するなどの工夫が必要です。ただし、基幹システム全体の刷新を伴うような大規模なプロジェクトでは、月次の締め処理まで検証するために最低3ヶ月間の並行稼働を確保することが推奨されます。並行稼働中は、出荷などの現場への物理的な指示は新WMSからのみ出す「指示系統の一本化」を徹底することが、現場の混乱を防ぐ鉄則です。あわせて、在庫の突合結果が「棚卸差異率0.1%以内」といった品質基準を満たせなかった場合に旧システムへ切り戻すかどうかを判断する権限者を事前に合意し、旧システムのサーバーやハンディターミナルの契約は稼働後最低3ヶ月間は解約せずに維持しておくことが、想定外の事態に備えるための現実的な対策です。

発注前の段階で、対象拠点の範囲、移行が必要なロケーションマスタ・在庫データの量、現場のハンディターミナルの機種とOS、連携が必要な周辺システム（OMS・ERP・TMS等）、稼働中システムを止められない業務時間帯といった前提条件をまとめた要件概要書を作成しておくと、複数のベンダーから比較可能な見積もりとスケジュール提案を得やすくなります。あわせて、現場のリーダークラスや情報システム部門から意思決定権を持つキーパーソンをプロジェクト体制に組み込んでおくことも重要です。依頼先を選ぶ際は、対象となる既存WMSや業界特有の倉庫運用への理解、5R（リホスト〜リプレース）のいずれのアプローチにも対応できる提案力、そして既存データ・現場端末の移行に伴走できる実績を確認しましょう。プロジェクト開始後は、週次などの定例会議で進捗と課題を可視化し、仕様変更の申し出があった場合は口頭で済ませず変更要求として起票するルールを徹底し、全体工程には10〜20%程度のリスクバッファを組み込んでおくことが、想定外の事象が発生した際にも稼働時期を守るための備えになります。

まとめ

本記事では、WMSのモダナイゼーションにおける開発期間・スケジュール・納期について、対象範囲の確認、工程別の期間配分、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチ別の期間の違い、WMS特有の納期遅延要因、そして納期を守るための実務的な進め方を体系的に解説しました。上流工程だけで4〜7ヶ月、実装フェーズは既存データを引き継ぐリホストの数ヶ月から、ゼロから作り直すリビルドの1年半〜3年以上まで、選択するアプローチによって大きく変動し、稼働後も6〜12ヶ月の定着化期間が必要です。既存のロケーションマスタ・在庫データの移行と、現場のハンディターミナルなど端末の互換性、そして倉庫稼働を止められない中でのカットオーバー設計というブラウンフィールド特有の制約をいかにコントロールするかが、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を創業。