WMS更改とは、保守契約の満了やハードウェアのライフサイクル満了、ベンダーのサポート終了を起点に、既存の倉庫管理システムを見直して入れ替える取り組みです。
満了通知が届くたびに判断を先送りしがちですが、着手時期と現行業務への影響を整理し、計画に落とし込む必要があります。
- WMS更改の全体像とモダナイゼーション・刷新との違い
- 更改が必要になるきっかけ・トリガー
- WMS更改の進め方と業務フロー
- 主要機能、目的・効果、導入前の確認事項
▼全体ガイドの記事
・WMS刷新の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMS更改の全体像と、モダナイゼーション・刷新との違い
WMS更改は、保守契約やハードウェアの期限という外部から到来する制約の中で、既存の入出荷・在庫管理の仕組みを続けるか入れ替えるかを判断し、実行するプロジェクトです。単にソフトウェアのバージョンを上げる作業とは異なります。同じ既存WMSの見直しでも、着眼点によって呼び方と重心が変わります。
更改の対象は現行システムの契約とライフサイクル全体
WMS更改が扱うのは、ソフトウェアライセンスや保守契約だけではありません。ハンディターミナルなどの現場端末やサーバー、ネットワーク機器のほか、周辺システムとの接続や現場の運用ルールも含む、現行環境全体が対象です。
契約更新の通知を受け取った時点で、更新後も今の体制で運用を続けられるか、新しい仕組みへ移行すべきかを検討することになります。その際は、現行システムでできていること・できなくなっていることを洗い出し、保守サポート終了後のリスクと、更改にかかる費用・期間を比べることが欠かせません。判断を先送りにしたまま契約満了日を迎えると、選べる選択肢が限られたなかで決断を迫られます。
ロールオーバーか更改かの判断
契約更新のタイミングでまず問われるのは、現行システムをそのまま契約更新（ロールオーバー）するか、新しい仕組みへ更改するかという二択です。現行システムが業務要件を満たし、ベンダーのサポートも継続される見込みであれば、ロールオーバーを選び、更改の検討時期を先送りすることも合理的な判断になり得ます。
一方、ハンディターミナルの多くを占めるWindows CE搭載機はOSサポートが既に終了しており、端末をAndroidベースの機種へ切り替える動きが進んでいます。旧WMSがWindows CE専用の構成で作られていると、端末だけをAndroidに入れ替えることはできません。そのため、WMSソフトウェア全体のリプレイスが避けられなくなります。
現場端末のライフサイクルがWMS本体の更改を引き起こす点は、WMSに特有の構造といえます。
WMS更改が必要になるきっかけ・トリガー
WMS更改の起点は、自社の経営判断というより、外部から到来する期限であることが多いのが特徴です。
保守サポート契約、ハードウェアのリース、ベンダーのサポート終了の3つの期限を押さえておくと、更改を検討すべき時期を見誤りにくくなります。
保守契約満了とハードウェアのリース期限
多くのWMSは、ソフトウェアの保守サポート契約とは別に、ハンディターミナルやプリンターなどの現場端末を数年単位のリース契約で調達しています。保守契約とリース契約は更新時期が一致するとは限らないため、どちらか一方の期限が近づいた段階で、両方の契約をあわせて見直すかどうかを判断する必要があります。
保守契約の満了だけを理由に契約更新を続けると、老朽化したシステムに気づかないまま運用を続けてしまうことがあります。そのため、契約更新の案内を受け取った時点で、現状の課題と残りの契約期間を照らし合わせる習慣が大切です。
ベンダーのEOS・EOL放置が招く保守コストとセキュリティのリスク
ベンダーがハードウェアやソフトウェアのEnd of Support（EOS）・End of Life（EOL）を迎えると、セキュリティパッチが提供されなくなります。その結果、脆弱性を放置したまま運用を続けることになります。
また、長年にわたる場当たり的なカスタマイズが積み重なったシステムでは、軽微な修正でも影響範囲の調査に数日かかることがあり、保守コストが膨らみやすくなる傾向があります。延長保守契約を結んで対応する方法もありますが、通常の保守費用の1.5倍から数倍に高騰するのが一般的な相場とされています。
目先の費用だけで延長保守を選び続けると、更改にかかる費用を上回るコストを、長期にわたって払い続けることになりかねません。
WMS更改の進め方と業務フロー
WMS更改は、現状分析、要件整理、ベンダー選定、データ移行、稼働確認という順に進みます。
前工程の結果を次の工程に引き継ぎながら、期限から逆算したスケジュールの中で各作業を進めます。ここが、通常の新規導入プロジェクトとの違いです。
現状分析とTo-Be像の策定
最初に、現行WMSの機能、連携する基幹システムやハンディターミナルの構成、現場の運用ルールを洗い出します。
そのうえで、更改後にどこまでを標準機能でまかない、どこを自社独自の運用として残すかを決め、To-Be像にまとめます。この工程には、一般的に約3ヶ月程度を要するとされています。
現状分析を省いて製品選定を先に進めると、デモで良さそうに見えた機能が自社の運用に合わず、食い違いが後工程で見つかりやすくなります。だからこそ、現場担当者へのヒアリングを含めて先に洗い出すことが、手戻りを防ぐ近道です。
RFI・PoC・契約精査の3ステップによるベンダー選定
ベンダー選定は、RFI・PoC・契約精査の3ステップで進めます。RFIによる技術適合評価に1〜2週間、PoCなどの実地検証に3〜6週間、コンプライアンス・契約精査に1〜2週間を要します。合計はおおむね1.5〜2.5ヶ月程度で、これが一般的な進め方です。
RFP作成からベンダー選定までを合わせると、約3ヶ月程度を見込む必要があります。
現状分析とベンダー選定を合わせると、検討フェーズだけでおよそ6ヶ月かかる計算になります。ここに導入・移行期間を加えて逆算すると、着手すべき時期が具体的に見えてきます。
ロケーションマスタと在庫データの移行
旧WMSから新WMSへの移行では、ロケーションマスタの移行が特に手間のかかる工程になります。その理由は、「A-01-03」のような自由記述で管理されていたロケーションコードを、ゾーン・列・段・間口の階層を持つ厳密なコード体系へ変換するマッピング作業が必要になるからです。
あわせて、廃番商品や休止中のロケーションを一定の基準で整理しておくと、移行後のデータが整った状態で新システムを始められます。なお、自社が旧WMSのデータベースに直接アクセスできない場合は、旧ベンダーへのデータ抽出依頼が1回数十万円程度のスポット費用になるケースもあります。
在庫残高は、移行時点の整合性を保つ必要があります。そのため、週末などに完全停止して一括移行するビッグバン方式にするか、24時間稼働の現場では差分移行方式にするかを、業務停止が許容できる時間帯とあわせて検討します。
WMS更改で引き継ぐ・見直すべき主要機能
更改では、現行システムの機能をそのまま引き継ぐ部分と、この機会に見直す部分を切り分けることが大切です。
入出荷・在庫・ロケーションといった基本機能に加えて、他システムとの連携範囲も改めて決め直す必要があります。
入出荷・在庫・棚卸などの基本機能の再確認
入荷検品から出荷検品まで、在庫照会や棚卸も含めた基本機能は、多くのWMSに共通して備わっています。
更改にあたっては、これらの基本機能が現行と同等以上の水準で提供されるかを確認します。あわせて、現場のハンディターミナルでの操作の流れが、旧システムからどの程度変わるかも把握しておく必要があります。
実際の入出荷業務で使われている例外処理（欠品時の代替出荷、返品の再入庫処理など）が、新システムでどう扱われるかまで確認しないと、稼働後に現場からの問い合わせが集中しかねません。
基幹システム・受注管理・倉庫制御システムとの連携範囲の再定義
WMSは、基幹システム（ERP）、受注管理システム（OMS）、自動倉庫やAGVを制御する倉庫制御システム（WCS）など、複数のシステムと連携しながら動いています。更改では、これらとのAPI連携の仕様、在庫引当ロジックの整合性、データの同期タイミングを一つずつ確認する必要があります。
旧システムでは個別カスタマイズで実現していた連携が、新システムの標準機能でどこまで代替できるかによって、追加開発の要否と費用が大きく変わります。連携範囲の見直しを後回しにすると、稼働直前になって想定外の追加開発が見つかるリスクが高まります。
WMS更改の目的と期待できる効果
WMS更改の目的は、老朽化したシステムを新しくすること自体ではありません。出荷が止まるリスクを避け、保守コストの膨張を抑え、現場の運用効率を維持・向上させることにあります。
デッドライン超過による出荷停止リスクの回避
保守契約やハードウェアの期限が過ぎてもWMSの入れ替えが完了していない状態は、最悪の場合、倉庫の出荷業務そのものが止まるリスクにつながります。
特にフルスクラッチでの再構築は、要件定義から開発に1〜2年、大規模なら3年以上かかることもあります。動かせない期限に対して、デッドラインを超えるリスクが構造的に高くなります。
この構造的なミスマッチを避けるため、期限内に収まる現実的な選択肢を検討する必要があります。たとえば、既存パッケージの標準機能を活かしつつ独自ロジックのみを追加開発する「セミスクラッチ型」があります。また、在庫管理・入出荷管理など必要最小限のコア機能に絞って先行リリースし、段階的に機能を追加していく進め方も、有効とされています。
保守コストの膨張とセキュリティリスクの抑制
更改後のクラウド型（SaaS）WMSは、初期費用無料から100万円程度、月額1万〜20万円程度が相場とされています。一方、オンプレミス・スクラッチ型では、初期開発費用の5〜20%程度が年間の保守費用の目安とされています。
比較は、5年間程度のランニングコストを含めたTCOで行うことが重要です。初期費用だけで比べると、判断を誤りやすくなります。
EOS・EOLを放置した場合のセキュリティインシデントは、フォレンジック調査費用や損害賠償、緊急再構築費用などを合わせると、数千万円から数億円規模の対応費用につながる可能性があります。更改にかかる費用を大きく上回る経営リスクとして捉える必要があります。
WMSモダナイゼーション・WMS刷新・他システムとの違い
「更改」という言葉は、「モダナイゼーション」や「刷新」といった近い言葉と混同されやすいものです。着眼点の違いを整理しておくと、自社が今取り組むべきプロジェクトの性質を見誤りにくくなります。
モダナイゼーションの重心は技術手法（HOW）
WMSモダナイゼーションは、老朽化したシステムをどの技術手法で移行するかというHOWに重心を置く取り組みです。代表的な手法は、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースの5つ（5R）です。
ロケーションマスタの移行手順やカットオーバー設計、現場端末の互換性といった技術的な論点が主軸になります。
これに対しWMS更改は、技術手法を実行する「きっかけ」に焦点を当てています。そのきっかけは、保守契約満了やハンディターミナルのリース満了、EOS・EOLという外圧型のデッドラインです。技術手法そのものはモダナイゼーションの論点と重なる部分がありますが、更改では期限からの逆算スケジュールが検討の出発点になります。
刷新の重心は経営判断（WHY・WHEN）
WMS刷新は、内発的な経営判断として、なぜ・いつ入れ替えるかというWHY・WHENに重心を置く取り組みです。誤出荷率や物流コスト比率で経営インパクトを数字にし、稟議・予算執行の段取りや部門間の合意形成を組み立てます。繁忙期を避けたタイミング設計など、社内の意思決定プロセスが主な論点になります。
WMS更改は、自社の経営判断とは関係なく、外部から強制的に到来する期限が起点になる点が刷新と異なります。
契約更新のタイミングで「そのまま契約更新するか、更改するか」を判断する意思決定プロセスと、その期限から逆算したスケジュール・費用・検証・開発手法の設計に焦点を当てます。
倉庫制御システム(WCS)・受注管理システム(OMS)との管理対象の違い
倉庫制御システム(WCS)は自動倉庫やAGVなどのマテリアルハンドリング機器を直接制御するシステムであり、受注管理システム(OMS)は顧客からの注文情報を管理するシステムです。WMSはこれらと連携しながら、入出荷・在庫・ロケーションという倉庫内オペレーションの中核を担います。
更改の検討では、WMS単体の機能に加えて、WCSやOMSとの連携仕様が新システムにどこまで引き継げるかを確認する必要があります。連携先が更改の対象外であっても、接続方式やデータ形式の変更がないかを事前にすり合わせておくことが欠かせません。
WMS更改の導入前に確認したいポイント
WMS更改を検討する際には、実務担当者から繰り返し挙がる論点があります。着手の時期、ロールオーバーとの判断基準、フルスクラッチが向くかどうかです。
着手時期の目安はEOS・EOLの1年〜1年半前
中規模以上のWMS更改では、現状分析・To-Be像策定に約3ヶ月、RFP作成からベンダー選定までに約3ヶ月、合計で検討フェーズだけで約6ヶ月を要するのが一般的です。
導入・移行期間は、小規模（1,000SKU未満）で3〜6ヶ月、中規模（1,000〜10,000SKU）で6〜12ヶ月、大規模（10,000SKU以上・複数拠点）で12〜18ヶ月が目安とされています。
これらを合算すると、中規模以上であれば少なくとも、EOS・EOLの1年〜1年半前には検討を始める必要があります。現場端末の調達やロケーションマスタ・在庫データの移行が絡むWMSは、情報系システムの更改に比べてリードタイムが長めに必要になる点に留意してください。
ロールオーバーの妥当性と現行システムの制約
現行システムが業務要件を満たし、ベンダーのサポートも当面継続される見込みであれば、ロールオーバーを選ぶことも合理的です。
一方、ハンディターミナルのOSサポート終了、頻発するカスタマイズ対応、保守コストの継続的な上昇といった兆候が重なる場合は、更改を前提に検討を進めた方が、結果的にコストと出荷停止リスクを抑えられる可能性があります。
フルスクラッチが向くかと独自ロジックの競争優位性
自社独自の入出庫ロジックが競争優位の源泉になっている場合は、フルスクラッチでの再構築に意義があります。
ただし、期限が動かせない更改では、開発期間の長さがデッドライン超過のリスクに直結します。そのため、既存パッケージの標準機能を活かしつつ独自ロジックのみを追加開発するセミスクラッチ型など、期限内に収まる折衷案を検討することが現実的です。
まとめ
WMS更改は、保守契約の満了や現場端末のリース期限、ベンダーのEOS・EOLといった外部の期限を起点に、既存の倉庫管理システムをロールオーバーするか入れ替えるかを判断し、実行する取り組みです。
モダナイゼーションは技術手法、刷新は経営判断に重心があり、着眼点が異なります。この違いを押さえることが、自社の状況を正しく整理する第一歩です。
期限からの逆算スケジュール
検討フェーズに約6ヶ月、導入・移行期間に規模に応じて3ヶ月〜18ヶ月程度を要するWMS更改では、EOS・EOLという動かせない期限から逆算したスケジュール設計が欠かせません。
ロケーションマスタや在庫データの移行、現場のハンディターミナルでの実機検証まで含めて、期限内に収まる現実的な計画を立てることが重要です。
現状の棚卸しから着手
まずは現行WMSの機能、保守契約とリース期限、連携状況を洗い出し、ロールオーバーか更改かを確認してください。既製品で標準化できる部分と独自の入出庫ロジックの見極めが、更改後の運用を左右します。評価軸はWMS更改の選定ポイント・選び方・種類で解説しています。riplaはフルスクラッチ開発の立場から、既存システムとの連携を含む要件整理を支援しています。
▼全体ガイドの記事
・WMS刷新の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。