WMS更改とは？｜考え方/特徴/仕組み/目的を解説

現在稼働している倉庫管理システムについて、そろそろ入れ替えの検討が必要だと分かっていても、着手のタイミングを決めかねている情報システム部門や物流部門の担当者は少なくありません。保守サポート契約の満了通知やハンディターミナルのリース更新案内が届くたびに、そのまま契約を延長すべきか、システムごと入れ替えるべきか、判断の先送りが続いているケースも見受けられます。こうした保守契約の満了やハードウェアのライフサイクル満了、ベンダーのサポート終了を起点に、既存の倉庫管理システムを見直し入れ替える取り組みが、WMS更改です。

本記事では、WMS更改の基本的な考え方と、WMSモダナイゼーション・WMS刷新との違い、更改が必要になるきっかけ、更改の進め方と業務フロー、見直すべき主要機能、導入目的、他システムとの違いを順に解説します。保守契約やハードウェアの期限が迫っている担当者の方が、自社が今どの段階にあり、何から着手すべきかを判断できるよう、実務の流れに沿って整理します。

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

▼全体ガイドの記事
・WMS刷新の完全ガイド

WMS更改とは何か？全体像とモダナイゼーション・刷新との違い

WMS更改は、単にソフトウェアのバージョンを上げる作業ではなく、保守契約やハードウェアの期限という外部から到来する制約の中で、既存の入出荷・在庫管理の仕組みを継続するか入れ替えるかを判断し、実行するプロジェクトです。同じ「既存WMSを見直す」取り組みでも、着眼点によって呼び方と重心が異なります。

WMS更改が扱うのは、ソフトウェアライセンスや保守契約だけではありません。ハンディターミナルなどの現場端末、サーバーやネットワーク機器、周辺システムとの接続、そして現場の運用ルールまでを含めた現行環境全体が対象です。契約更新の通知を受け取った時点で、更新後も同じ体制で運用を続けられるか、それとも新しい仕組みへ移行すべきかを検討することになります。

この検討では、現行システムでできていること・できなくなっていることを棚卸しし、保守サポート終了後のリスクと、更改にかかる費用・期間を比較する視点が欠かせません。判断を先送りにしたまま契約満了日を迎えると、選択肢が限られた状態で意思決定を迫られることになります。

契約更新のタイミングでまず問われるのが、現行システムをそのまま契約更新（ロールオーバー）するか、新しい仕組みへ更改するかという二択です。現行システムが業務要件を満たし、ベンダーのサポートも継続される見込みであれば、ロールオーバーを選び、更改の検討時期を先送りすることも合理的な判断になり得ます。

一方、ハンディターミナルの多くを占めるWindows CE搭載機はOSサポートが既に終了しており、端末をAndroidベースの機種へ切り替える動きが進んでいます。旧WMSがWindows CE専用の構成で作られている場合、端末だけをAndroidに入れ替えることができず、WMSソフトウェア全体のリプレイスが避けられなくなります。現場端末のライフサイクルがWMS本体の更改トリガーになる点は、WMSに特有の構造といえます。

WMS更改が必要になるきっかけ・トリガー

WMS更改の起点は、自社の経営判断というより、外部から到来する期限であることが多い点が特徴です。保守サポート契約、ハードウェアのリース、ベンダーのサポート終了という3つの期限を押さえておくと、更改を検討すべきタイミングを見誤りにくくなります。

多くのWMSは、ソフトウェアの保守サポート契約とは別に、ハンディターミナルやプリンターなどの現場端末を数年単位のリース契約で調達しています。保守契約とリース契約は更新時期が一致するとは限らないため、どちらか一方の期限が近づいた段階で、両方の契約を合わせて見直すかどうかを判断する必要があります。

保守契約の満了だけを理由に安易に契約更新を続けると、老朽化したシステムに気づかないまま運用を継続してしまうことがあります。契約更新の案内を受け取った時点で、現状の課題と残りの契約期間を照らし合わせ、更改を検討すべき時期かどうかを確認する習慣が重要です。

ベンダーがハードウェアやソフトウェアのEnd of Support（EOS）・End of Life（EOL）を迎えると、セキュリティパッチが提供されなくなり、脆弱性が放置された状態で運用を続けることになります。長年にわたる場当たり的なカスタマイズが積み重なったシステムでは、軽微な修正であっても影響範囲の調査に数日を要するなど、保守コストが膨らみやすくなる傾向があります。

延長保守契約を結んで対応する方法もありますが、通常の保守費用の1.5倍から数倍に高騰するのが一般的な相場とされています。目先の費用だけを見て延長保守を選び続けると、更改にかかる費用を上回るコストを長期的に支払い続けることにもなりかねません。

WMS更改の進め方と業務フロー

WMS更改は、現状分析、要件整理、ベンダー選定、データ移行、稼働確認という順に進みます。前工程の結果を次工程に引き継ぎながら、期限から逆算したスケジュールの中で各作業を進める点が、通常の新規導入プロジェクトとの違いです。

最初に、現行WMSの機能、連携している基幹システムやハンディターミナルの構成、現場の運用ルールを棚卸しします。そのうえで、更改後にどこまでを標準機能でまかない、どこを自社独自の運用として残すかというTo-Be像を整理します。この工程には、一般的に約3ヶ月程度を要するとされています。

現状分析を省略して製品選定を先に進めると、デモを見て良さそうだと感じた機能が、実は自社の運用には合わないという食い違いが後工程で発覚しやすくなります。現場担当者へのヒアリングを含めた棚卸しを先に行うことが、手戻りを防ぐ近道です。

ベンダー選定は、RFIによる技術適合評価に1〜2週間、PoCなど実地検証に3〜6週間、コンプライアンス・契約精査に1〜2週間という3ステップで、合計おおむね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刷新・他システムとの違い

「更改」という言葉は、「モダナイゼーション」や「刷新」といった近い言葉と混同されやすいものです。着眼点の違いを整理しておくと、自社が今取り組むべきプロジェクトの性質を見誤りにくくなります。

WMSモダナイゼーションは、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術手法（5R）に代表される、老朽化したシステムをどのような技術手法で移行するかというHOWに重心を置く取り組みです。ロケーションマスタの移行手順やカットオーバー設計、現場端末の互換性といった技術的な論点が主軸になります。

これに対しWMS更改は、モダナイゼーションで扱われる技術手法を実行する「きっかけ」が、保守契約満了やハンディターミナルのリース満了、EOS・EOLという外圧型のデッドラインである点に焦点を当てています。技術手法そのものはモダナイゼーションの論点と重なる部分がありますが、更改では期限からの逆算スケジュールが検討の出発点になります。

WMS刷新は、誤出荷率や物流コスト比率といった経営インパクトの定量化、稟議・予算執行のゲート設計、部門間の合意形成など、内発的な経営判断としてなぜ・いつ入れ替えるかというWHY・WHENに重心を置く取り組みです。繁忙期を避けたタイミング設計など、社内の意思決定プロセスが主な論点になります。

一方、WMS更改は自社の経営判断とは無関係に、外部から強制的に到来する期限が起点になる点が刷新と異なります。契約更新のタイミングで「そのまま契約更新するか、更改するか」を判断する意思決定プロセスと、その期限から逆算したスケジュール・費用・検証・開発手法の設計に焦点を当てます。

倉庫制御システム(WCS)は自動倉庫やAGVなどのマテリアルハンドリング機器を直接制御するシステムであり、受注管理システム(OMS)は顧客からの注文情報を管理するシステムです。WMSはこれらと連携しながら、入出荷・在庫・ロケーションという倉庫内オペレーションの中核を担います。

更改の検討では、WMS単体の機能だけでなく、WCSやOMSとの連携仕様がどこまで新システムに引き継げるかを確認する必要があります。連携先のシステムが更改の対象外であっても、接続方式やデータ形式の変更がないかを事前にすり合わせておくことが欠かせません。

WMS更改導入前に確認しておきたいポイント

WMS更改を検討する際には、いつ着手すべきか、ロールオーバーとの判断基準、フルスクラッチが向くかどうかなど、実務担当者から繰り返し挙がる論点があります。ここでは、その代表的なポイントを整理します。

中規模以上の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更改の選定ポイント・選び方・種類で解説していますので、あわせてご確認ください。既製パッケージやクラウド型WMSで標準化できる部分と、自社独自の入出庫ロジックのように既製品では吸収しきれない部分を見極めることが、更改後の運用を左右します。riplaはフルスクラッチ開発の立場から、既存システムとの連携を含めた要件整理や、独自ロジックの構築支援を行っています。

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