WMS更改の開発期間・スケジュール・納期について

WMS更改とは、現在利用しているWMS（倉庫管理システム）の保守サポート契約の満了、オンプレミスサーバーやハンディターミナルといったハードウェアのリース期限、あるいはベンダーが定めるEnd of Support（EOS）・End of Life（EOL）という、自社の経営判断とは無関係に外部から強制的に到来する期限を起点として、システムを刷新するかどうかを判断・実行する取り組みを指します。同じ「WMSを刷新する」というテーマでも、「WMSのモダナイゼーション」がリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチをどう使い分けるかという技術手法（HOW）に軸足を置き、「WMS刷新」が誤出荷率の悪化や作業効率低下という経営インパクトをどう定量化し、稟議を通して経営判断を進めるか（WHY・WHEN）に軸足を置くのに対し、本記事が扱う「更改」は、契約書やベンダーのサポートポリシー、あるいはハンディターミナルのOSサポート方針に明記された「動かせない期限（デッドライン）」がすでに決まっているという前提のもとで、そのデッドラインから逆算してスケジュールを設計するという、他の2つとは根本的に異なる制約条件を持っています。

本記事では、対象システム種別を問わない一般論ではなく、WMSに対象を限定したうえで、保守契約満了・ハンディターミナル等のリース満了・EOS/EOLという期限から逆算した開発期間・スケジュール・納期の考え方にフォーカスして解説します。更改のトリガーとなる期限の種類とWMS特有の現場端末事情、契約更新のタイミングでそのまま更新（ロールオーバー）するか更改（リプレース）するかを判断する意思決定プロセスの期間、ベンダー選定から開発・移行までの期間の目安、そして期限直前化を招く納期遅延要因と、それを回避するための実務的な進め方までを、具体的な数値とともに体系的にお伝えします。保守契約やハンディターミナルのリース満了通知を受け取り、対応期限に頭を悩ませている物流部門・情報システム部門の方にとって、現実的なスケジュールを描くための判断軸が身に付く内容です。

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

▼全体ガイドの記事
・WMS更改の完全ガイド

WMS更改の位置づけ（モダナイゼーション・刷新との違い）

WMS更改の開発期間を正しく見積もるには、まず「更改」という言葉が指す固有の意味を、隣接する2つの記事群と切り分けて理解しておく必要があります。同じWMSの刷新プロジェクトでも、何が意思決定の起点になるかによってスケジュールの組み方がまったく異なるためです。

「WMSのモダナイゼーション」は、すでに稼働しているWMSを前提に、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチのどれを選ぶかという、情報システム部門・エンジニア視点の技術手法論（HOW）です。ロケーションマスタの再設計やハンディターミナルの互換性確保といった技術的な論点に重心を置いています。「WMS刷新」は、誤出荷率の悪化やピッキング作業の生産性低下がもたらす経営インパクトをどう定量化して経営層に説明し、稟議承認・物流部門とIT部門の合意形成を進めるかという、経営層・物流部門責任者視点の内発的な意思決定プロセス（WHY・WHEN）です。これに対して本記事が扱う「更改」は、保守サポート契約の満了通知、オンプレミスサーバーやハンディターミナルのリース期限、ベンダーが公表するEOS/EOLのアナウンスといった、自社が「刷新したい」と思うかどうかとは無関係に外部から一方的に到来する期限が起点になっている点が最大の違いです。モダナイゼーションや刷新が「どう変えるか」「なぜ・いつ変えるべきか」を主体的に考える余地を持つのに対し、更改は「いつまでに対応しなければならないか」という制約条件がすでに固定されており、その制約の中でいかに現実的なスケジュールを組むかという、逆算思考が要求される点に特徴があります。技術的なアプローチの詳細はモダナイゼーション記事、経営インパクトの定量化や合意形成プロセスの詳細は刷新記事にそれぞれ譲り、本記事では更改特有の「期限管理」に焦点を当てて解説します。

WMS更改のトリガーは、大きく3種類の期限に整理できます。1つ目は保守サポート契約の満了です。オンプレミス型のパッケージ製品や自社開発のWMSの多くは、ベンダーと年単位の保守契約を結んでおり、契約満了のタイミングで自動更新するか、契約内容を見直すか、他システムへ乗り換えるかを判断する必要があります。2つ目はハードウェアのリース期限で、WMSが稼働するサーバー機器だけでなく、現場のハンディターミナルという物理資産のリース満了も同時に判断材料となる点がWMS特有です。3つ目がベンダーの公表するEOS・EOLです。ここで見落とされがちなのが、WMS本体だけでなく現場のハンディターミナルにも固有のライフサイクルが存在するという点です。長年利用されてきたハンディターミナルの多くはWindows CEを搭載していますが、このOS自体のサポート終了に伴い、業界全体でAndroidベースのスマートデバイス型端末への移行が進んでいます。旧WMSがWindows CE専用の構成で作られている場合、端末だけをAndroidに入れ替えることができず、結果としてWMSソフトウェア全体のリプレイスが避けられなくなります。つまりWMSでは、システム本体の契約満了だけでなく、現場端末のライフサイクルそのものが更改の引き金になり得るという、他システムにはない固有の構造があります。まずは自社のWMSと現場端末がそれぞれどの期限をいつ迎えるのかを正確に棚卸しすることが、更改プロジェクトの出発点になります。

期限から逆算するスケジュール設計の全体像

WMS更改のスケジュールは、通常の新規導入プロジェクトのように「着手日から積み上げて完成日を決める」のではなく、「動かせない期限から逆算して着手日を決める」という発想で組み立てる必要があります。この逆算思考こそが、更改特有のスケジュール管理の要諦です。

WMSの導入・移行にかかる期間は、取扱商品数（SKU数）や拠点規模によって大きく異なり、小規模（1,000SKU未満）であれば3〜6ヶ月、中規模（1,000〜10,000SKU）であれば6〜12ヶ月、大規模（10,000SKU以上・複数拠点）であれば12〜18ヶ月が目安です。これに加えて、現状の課題分析やTo-Be像の策定に約3ヶ月、RFP（提案依頼書）の作成からベンダー選定に至るまでに約3ヶ月、合計で約6ヶ月の検討期間を見込む必要があります。これらを合算すると、中規模以上の倉庫であれば、ベンダー選定と導入期間を足し合わせて「最低でもEOS/EOLの1年〜1年半前」にはリプレースプロジェクトを始動させなければ、期限に間に合わない計算になります。情報系システムである見積管理システム等の更改が「半年前〜1年前」の着手で足りるのに対し、WMSはロケーションマスタ・在庫データという物理資産の移行と、ハンディターミナルという現場端末の調達・入替が加わる分、より長いリードタイムが必要になる点が特徴です。実務上は、この計算上のラインぎりぎりで着手すると、途中で想定外の遅延が発生した際にバッファがまったくない状態でデッドラインを迎えることになるため、余裕を持った着手が推奨されます。

期限が到来したからといって、必ずしも更改（リプレース）を選ばなければならないわけではありません。既存のWMSを維持したまま契約だけを延長する「ロールオーバー」という選択肢も残されています。この判断を下す際に重視すべきなのが、初期費用の安さだけで比較するのではなく、既存WMS・現場端末を延命した場合にかかる保守費用や再リース費用の高騰と、新システムの初期費用・月額利用料・ハンディターミナル調達費などを合算した「複数年間のTCO（総所有コスト）」でシミュレーションする方法です。ロールオーバーかリプレースかの判断そのものには、物流部門・情報システム部門・経理部門が協力してTCO試算を作成し、経営層に説明するプロセスが必要になるため、単純な稟議決裁とは別に一定の検討期間を見込んでおく必要があります。特にWMSは倉庫の日々の出荷業務を支えているため、単なるコスト比較だけでなく、現場作業員の操作習熟度や、稼働を止められない業務サイクルといった非金銭的な要素も判断材料に加える必要があり、この論点整理に想定以上の時間がかかるケースも少なくありません。

ベンダー選定〜開発・移行にかかる期間の目安

更改（リプレース）を選択した場合、実際にプロジェクトを進める段階では、ベンダー選定のプロセスと、開発・データ移行・稼働までのプロセスという、性質の異なる2つの期間を見込む必要があります。

更改先のベンダー・製品を選定するプロセスは、大きく3つのステップに分解できます。Step1は技術適合評価とRFI（情報提供依頼）の送付で、候補となるベンダー・製品を数社に絞り込む工程に1〜2週間、Step2は自社データ・現場端末を用いたPoC等の実地検証で3〜6週間、Step3はセキュリティ監査や契約条件の交渉といったコンプライアンス・契約精査で1〜2週間を要します。これらを合算すると、ベンダーの比較・選定だけで約1.5〜2.5ヶ月の期間が必要になる計算です。契約満了やEOS/EOLというデッドラインが迫っている更改案件では、この選定プロセスに数ヶ月単位の時間をかけることは現実的に不可能であるため、早い段階で候補を2〜3社に絞り込み、限られた期間の中で効率的に比較検討を進める工夫が求められます。なお、PoC・プロトタイプ開発の詳細な進め方については別記事で扱いますが、期限が決まっている更改では、PoCの位置づけそのものが「新機能の模索」ではなく「新WMSが既存の出荷業務を止めずに代替できるかの確証を得ること」に特化する点を押さえておく必要があります。

ベンダーが決まった後の開発・移行フェーズにかかる期間は、前述のとおりSKU数・拠点数の規模によって大きく変動し、小規模（1,000SKU未満）で3〜6ヶ月、中規模（1,000〜10,000SKU）で6〜12ヶ月、大規模（10,000SKU以上・複数拠点）で12〜18ヶ月が目安です。この期間には、システム本体の構築・設定に加えて、既存のロケーションマスタ・在庫データを新環境に移すデータ移行、そして現場のハンディターミナルの調達・設定・現場教育という、WMS特有の工程が含まれます。特にSaaS・パッケージ製品へのリプレースを選ぶ場合は、自社の入出庫業務プロセスを標準機能に適合させる「Fit to Standard」のアプローチを取れるかどうかで、この期間が大きく短縮できる可能性があります。標準機能への適合度が高いほど、カスタマイズにかかる開発工数が減り、EOS/EOLというデッドラインの中でも現実的な期間内に稼働開始までこぎつけやすくなります。なお、WMSは基幹システム（ERP）や受注管理システム（OMS）、自動倉庫・AGVを制御する倉庫制御システム（WCS）等と複雑に連携しているケースが多く、これら周辺システムとのAPI連携の再検証にかかる時間も、開発・移行フェーズの見積もりに含めておく必要があります。

WMS特有の納期遅延要因

更改プロジェクトが期限直前まで着手されず、駆け込みでの対応を余儀なくされるケースは決して珍しくありません。ここではWMS特有の代表的な2つの遅延要因を見ていきます。

更改プロジェクトの遅延で最も多い原因は、「まだ期限まで時間がある」という感覚から、ロールオーバーか更改かの判断そのものが先送りにされることです。保守契約は自動更新の条項が含まれていることも多く、担当者が異動するタイミングなどで、更改の要否そのものが誰の検討課題にもならないまま放置されてしまうケースも見られます。WMS更改ではさらに、WMS本体の保守契約は台帳で管理していても、現場のハンディターミナルのリース契約やOSサポート方針は別部門・別台帳で管理されており、WMS本体のEOSと現場端末のOSサポート終了がほぼ同時期に到来していることに直前まで気づかないというケースが典型的な遅延要因になります。この見落としが積み重なると、本来であれば1年〜1年半前から着手すべきプロジェクトが、期限の数ヶ月前になって初めて本格的に動き出すという事態に陥り、ベンダー選定やPoCに十分な時間を割けないまま、見切り発車で更改先を決めざるを得なくなるリスクが高まります。対策としては、WMS本体の保守契約とハンディターミナル等現場端末のリース契約・OSサポート方針を一元管理する台帳を整備し、期限の1年前・半年前といった節目で自動的にアラートが上がる仕組みを作っておくことが有効です。

もうひとつの典型的な遅延要因が、ロケーションマスタと在庫データの移行工数の過小評価です。更改プロジェクトはデッドラインが明確であるがゆえに、見積もり段階では「ベンダーが提示するテンプレート工数」をそのまま採用してしまいがちですが、長年運用してきたWMSには、過去12ヶ月間に一度も入出荷実績がない廃番商品や、使われなくなった休止ロケーションが必ずといっていいほど蓄積されており、これらを移行対象から除外する「12ヶ月ルール」に基づくクレンジングが必須です。これに加えて、旧システムで「A-01-03」のようにテキスト形式で入力されていた棚番を、新システムの「ゾーン-列-段-間口」といった厳密な階層コードへ分解・マッピングする変換仕様の設計も欠かせません。さらに見落とされがちなのが、旧ベンダーのデータベースへ自社から直接アクセスできない契約になっているケースで、移行テストのたびに旧ベンダーへCSV抽出を依頼する必要があり、1回あたり数十万円という高額なスポット費用と、依頼のたびに発生する待ち時間が、テストサイクルを遅らせる要因になります。EOS/EOLの期限が固定されている更改案件では、開発期間を後ろにずらす余地がないため、この移行工数の見誤りが発覚した時点で対応できる選択肢は「機能を絞り込んでコア部分だけ期限内に間に合わせる」か「一時的な延命策で時間を稼ぐ」かのいずれかに限られてしまいます。開発着手と並行して、あるいは着手前に、ロケーションマスタ・在庫データの品質評価とクレンジング、そして旧ベンダーとのデータ抽出条件の確認を先行して完了させておくことが不可欠です。

期限内に更改を完了させるための実務的な進め方

ここまで見てきた期間の目安や遅延要因を踏まえると、WMS更改で納期を守るためには、倉庫の稼働を止められない現場に合わせたリスク分散の移行方式の設計と、発注前の準備を早期に固めることの両方が欠かせません。

デッドラインが固定されている更改プロジェクトほど、全拠点・全ロケーションを一度に切り替える「一括移行（ビッグバン方式）」を避け、リスクを分散させる移行方式を選ぶことが重要です。一括移行は移行作業そのものはシンプルで短期間に見えますが、トラブルが発生した際の影響範囲が倉庫全体の出荷業務に及ぶため、期限直前に問題が発覚した場合に立て直す時間的余裕がありません。代わりに、特定の拠点や温度帯に絞って先行導入する「パイロット移行」や、入荷検品・ピッキングといったコア機能から優先的に切り替え、複雑な棚卸ロジックなど周辺機能は期限後に段階的に追加していく「段階移行」を組み合わせることで、トラブル発生時の影響を局所化しながら、最低限守るべき出荷機能だけは確実に期限内へ間に合わせることができます。この考え方は、EOS/EOLという動かせない期限に対して「全機能を完璧に移行しきる」ことよりも「倉庫業務が止まらない状態を期限内に確保する」ことを優先する、更改プロジェクトならではの現実的な割り切りといえます。

発注前の段階で、保守契約満了・リース満了・EOS/EOLの正確な期日、対象拠点の範囲、移行対象となるロケーションマスタ・在庫データの量、現場のハンディターミナルの機種・OS・台数、連携が必要な周辺システム（OMS・ERP・WCS等）、そして最低限守るべきコア機能の範囲をまとめた要件概要書を作成しておくと、限られた期間の中でも複数のベンダーから比較可能な提案を得やすくなります。ベンダーを選ぶ際は、単に価格や機能の豊富さだけでなく、期限に対する感度の高さ、すなわちタイトなスケジュールの中でPoCから契約締結、開発・移行、現場端末の調達までを確実に遂行できる実績を持っているかを重視すべきです。また、契約書やリース契約書に記載された正確な期限を、物流部門・情報システム部門・経理部門・法務部門といった関係者間で早期に共有し、「いつまでに何を判断し、誰が承認するか」というマイルストーンを可視化しておくことも欠かせません。プロジェクト開始後は、期限までの残り日数を常に意識した進捗管理を行い、当初計画からの遅延が発覚した場合は、機能範囲を絞り込むかどうかを早期に判断できる体制を整えておくことが、WMS更改において納期を守るための最後の砦になります。

まとめ

本記事では、WMS更改における開発期間・スケジュール・納期について、モダナイゼーション・刷新との位置づけの違い、更改のトリガーとなる期限とWMS特有の現場端末事情、期限から逆算するスケジュール設計、ベンダー選定〜開発・移行にかかる期間の目安、WMS特有の納期遅延要因、そして期限内に完了させるための実務的な進め方を体系的に解説しました。保守契約満了・ハンディターミナル等のリース満了・EOS/EOLという外部から強制される期限に対して、SKU数・拠点規模に応じて3〜18ヶ月の開発・移行期間、約1.5〜2.5ヶ月のベンダー選定期間を要することを踏まえると、中規模以上であれば少なくとも1年、余裕を持たせるなら1年半前からの着手が現実的なラインです。現場端末ライフサイクルの見落としとロケーションマスタ・在庫データの移行工数の過小評価という2つの遅延要因を避け、一括移行ではなくパイロット移行・段階移行でリスクを分散させながら進めることが、WMS更改を期限内に成功させるための鍵となります。保守契約満了通知やEOS/EOLのアナウンスを受け取ったら、まずは自社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を創業。