WMS更改は、保守契約・端末リース・EOS/EOLの期限から逆算して、現場を止めずに更新かリプレースかを決める取り組みです。導入・移行の期間は規模によって3〜18ヶ月かかるため、中規模以上の倉庫では、EOS/EOLの1年〜1年半前に着手するのが現実的な目安です。
- 期限の種類：保守契約の満了、端末リースの期限、EOS/EOL。
- 現場への影響：ハンディターミナルを含む業務継続性の確認。
- 移行の見通し：ベンダー選定から開発・移行までを、期限から逆算して組む。
WMS更改の全体像は、下記の記事にまとめています。
▼全体ガイドの記事
・WMS更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
WMS更改の位置づけ（モダナイゼーション・刷新との違い）
WMS更改とは、自社の経営判断とは無関係に外部から到来する期限を起点に、現在利用しているWMS（倉庫管理システム）を刷新するかどうかを判断・実行する取り組みです。その期限には、保守サポート契約の満了、オンプレミスサーバーやハンディターミナルといったハードウェアのリース期限、ベンダーが定めるEnd of Support（EOS）・End of Life（EOL）があります。
WMS更改の開発期間を正しく見積もるには、まず「更改」が指す意味を、隣接する2つの記事群と切り分けて理解しておく必要があります。同じWMSの刷新でも、何を意思決定の起点にするかによってスケジュールの組み方がまったく異なるからです。
WMSのモダナイゼーション・刷新との違い
「WMSのモダナイゼーション」は、稼働中のWMSを前提に技術的な手法を選ぶ、情報システム部門・エンジニア視点の考え方（HOW）です。具体的には、リホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つのアプローチのどれを選ぶかを検討します。ロケーションマスタの再設計やハンディターミナルの互換性確保など、技術面の論点に重心があります。
「WMS刷新」は、誤出荷率の悪化やピッキング作業の生産性低下がもたらす経営インパクトを定量化し、稟議承認と部門間の合意を進める、経営層・物流部門責任者視点の内発的な意思決定プロセス（WHY・WHEN）です。技術的な手法はモダナイゼーションの記事に、定量化や合意形成の進め方は刷新の記事に譲ります。
本記事が扱う「更改」は、保守サポート契約の満了通知やリース期限、EOS/EOLのアナウンスなど、自社の意向とは無関係に到来する期限が起点です。モダナイゼーションや刷新は主体的に考える余地があるのに対し、更改は「いつまでに対応するか」がすでに固定されています。そのため、限られた期間で現実的なスケジュールを組む逆算思考が求められます。本記事では、この期限管理に焦点を当てて見ていきます。
更改のトリガーとなる期限（保守契約満了・ハンディターミナル等のリース満了・EOS/EOL）
WMS更改のトリガーは、大きく3種類の期限に整理できます。1つ目は保守サポート契約の満了で、オンプレミス型のパッケージ製品や自社開発のWMSの多くは、ベンダーと年単位の保守契約を結んでいます。満了時には、自動更新するか、契約内容を見直すか、他システムへ乗り換えるかを判断する必要があります。
2つ目はハードウェアのリース期限で、WMSが稼働するサーバー機器に加え、現場のハンディターミナルのリース満了も判断材料になる点がWMS特有です。3つ目はベンダーが公表するEOS・EOLで、ここで見落とされがちなのが、WMS本体だけでなく現場端末にも固有のライフサイクルがあるという点です。
ハンディターミナルの多くはWindows CEを搭載しており、そのOSのサポート終了に伴い、業界全体でAndroidベースの端末への移行が進んでいます。ただし、旧WMSがWindows CE専用の構成だと、端末だけを入れ替えられず、WMSソフトウェア全体のリプレイスが避けられません。まずは、自社のWMSと現場端末の期限を正確に一覧にすることが、更改プロジェクトの出発点です。
期限から逆算するスケジュール設計の全体像
WMS更改のスケジュールは、動かせない期限から逆算して着手日を決める発想で組み立てる必要があります。通常の新規導入では、着手日から積み上げて完成日を決めるため、考え方の向きが逆になります。この逆算思考が、更改特有のスケジュール管理の要になります。
「1年〜1年半前」に着手すべき理由
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を維持して契約だけを延長する「ロールオーバー」のどちらを選ぶかを判断することになります。判断では、初期費用だけを見るより、「複数年間のTCO（総所有コスト）」で比べるほうが役立ちます。
TCOには、既存のWMS・現場端末を延命した場合の保守費用や再リース費用の高騰と、新システムの初期費用・月額利用料・ハンディターミナル調達費などを合算します。この試算は、物流部門・情報システム部門・経理部門が協力して作り、経営層に説明する必要があります。そのため、稟議決裁とは別に、一定の検討期間を見込んでおくことが欠かせません。
特にWMSは倉庫の出荷業務を日々支えているため、コスト比較だけでなく、現場作業員の操作習熟度や、稼働を止められない業務サイクルといった非金銭的な要素も判断材料に加える必要があります。そのぶん、論点の整理に想定以上の時間がかかるケースも少なくありません。
ベンダー選定〜開発・移行にかかる期間の目安
更改（リプレース）を選ぶと、プロジェクトでは性質の異なる2つの期間を見込む必要があります。ベンダー選定の期間と、開発・データ移行・稼働までの期間です。
RFI〜PoC〜契約精査という選定プロセスの期間（約1.5〜2.5ヶ月）
更改先のベンダー・製品を選ぶ工程は、大きく3つのステップに分けられます。Step1は技術適合評価とRFI（情報提供依頼）の送付で、候補を数社に絞り込むまでに1〜2週間かかります。Step2は自社データや現場端末を使ったPoC等の実地検証で3〜6週間、Step3はセキュリティ監査や契約条件の交渉といったコンプライアンス・契約精査で1〜2週間を要します。
これらを合算すると、ベンダーの比較・選定だけで約1.5〜2.5ヶ月が必要になる計算です。契約満了やEOS/EOLのデッドラインが迫る更改案件では、この選定に数ヶ月単位の時間をかけることは現実的に難しくなります。そのため、早い段階で候補を2〜3社に絞り込み、限られた期間で効率よく比べる工夫が求められます。
期限が決まっている更改のPoCは、新機能を探すよりも、新WMSが既存の出荷業務を止めずに代替できるかを確かめることに絞り込みます。なお、PoCやプロトタイプ開発の詳しい進め方は、別の記事で扱います。
規模別に見る開発・データ移行・稼働までの期間目安
ベンダーが決まった後の開発・移行フェーズも、SKU数や拠点数によって大きく変わります。規模別の目安は、小規模（1,000SKU未満）で3〜6ヶ月、中規模（1,000〜10,000SKU）で6〜12ヶ月、大規模（10,000SKU以上・複数拠点）で12〜18ヶ月です。
この期間には、システム本体の構築・設定に加えて、ロケーションマスタ・在庫データの移行と、ハンディターミナルの調達・設定・現場教育が含まれます。なかでもデータ移行と現場端末の準備は、WMS特有の工程です。また、ERP・OMS・WCS等とのAPI連携の再検証にかかる時間も、見積もりに含めておく必要があります。
特にSaaS・パッケージ製品へのリプレースでは、入出庫業務を標準機能に合わせる「Fit to Standard」のアプローチを取れるかどうかで、この期間を大きく短縮できる可能性があります。標準機能への適合度が高いほど、カスタマイズの開発工数が減り、現実的な期間内に稼働までこぎつけやすくなります。
WMS特有の納期遅延要因
更改プロジェクトが期限直前まで着手されず、駆け込みの対応を余儀なくされるケースは珍しくありません。WMS特有の代表的な遅延要因は2つあり、判断の先送りや現場端末ライフサイクルの見落としと、移行工数の過小評価です。
判断の先送り・現場端末ライフサイクルの見落とし
更改プロジェクトの遅延で最も多いのは、「まだ期限まで時間がある」という感覚から、ロールオーバーか更改かの判断が先送りされることです。保守契約は自動更新の条項を含むことも多く、担当者の異動などを機に、更改の要否が誰の検討課題にもならないまま放置されるケースも見られます。
さらにWMS更改では、本体の保守契約は台帳で管理していても、現場のハンディターミナルのリース契約やOSサポート方針は別部門・別台帳で管理されていることも少なくありません。そのため、WMS本体のEOSと現場端末のOSサポート終了がほぼ同時期に来ていることに、直前まで気づかないという遅延が典型的に起こります。
この見落としが積み重なると、1年〜1年半前に始めるべきプロジェクトが、期限の数ヶ月前に動き出すことになります。その結果、ベンダー選定やPoCに時間を割けず、見切り発車で更改先を決めるリスクが高まります。対策には、保守契約と現場端末の期限を1つの台帳で管理し、期限の1年前・半年前にアラートが上がる仕組みを作ることが有効です。
ロケーションマスタ・在庫データ移行工数の過小評価
もうひとつは、ロケーションマスタと在庫データの移行工数を低く見積もってしまうケースです。見積もりではベンダーのテンプレート工数をそのまま採用しがちですが、長年運用したWMSには、過去12ヶ月間に一度も入出荷実績がない廃番商品や休止ロケーションが必ずといっていいほど蓄積されています。そのため、これらを移行対象から除外する「12ヶ月ルール」に基づくクレンジングが必須です。
加えて、旧システムで「A-01-03」のようにテキスト形式で入力していた棚番を、新システムの「ゾーン-列-段-間口」といった厳密な階層コードへ分解・マッピングする変換仕様の設計が欠かせません。また、見落とされやすいのが、旧ベンダーのデータベースへ自社から直接アクセスできない契約になっているケースです。
その場合は、テストのたびに旧ベンダーへCSV抽出を頼む必要があり、1回あたり数十万円の高額なスポット費用と待ち時間が、テストを遅らせます。EOS/EOLの期限が固定されると開発期間を延ばせないため、過小評価の発覚時には、コア部分に機能を絞るか延命策で時間を稼ぐかの二択になります。だからこそ、クレンジングと旧ベンダーとの抽出条件の確認は、開発と並行するか着手前に終えておくことが不可欠です。
期限内に更改を完了させるための実務的な進め方
期間の目安と遅延要因を踏まえると、納期を守るには、現場の稼働を止めないための移行方式を設計することと、発注前の準備を早く固めることの両方が欠かせません。
段階移行・パイロット移行によるリスク分散
デッドラインが固定された更改では、全拠点・全ロケーションを一度に切り替える「一括移行（ビッグバン方式）」を避け、リスクを分散させる移行方式を選ぶことが求められます。一括移行は作業がシンプルで短期間に見えますが、トラブルの影響が倉庫全体の出荷業務に及ぶため、期限直前に問題が見つかっても立て直す時間がありません。
代わりに、特定の拠点や温度帯に絞って先行導入する「パイロット移行」と、入荷検品・ピッキングなどのコア機能から切り替える「段階移行」を組み合わせる方法があります。複雑な棚卸ロジックなどの周辺機能は期限後に追加すれば、トラブルの影響を局所化しつつ、最低限守るべき出荷機能を期限内に確実に間に合わせることができます。
この考え方は、EOS/EOLという動かせない期限に対して「全機能を完璧に移行しきる」ことよりも「倉庫業務が止まらない状態を期限内に確保する」ことを優先する、更改ならではの現実的な割り切りです。
発注前の準備とベンダー選定のポイント
発注前に要件概要書をまとめておくと、限られた期間でも複数のベンダーから比べられる提案を得やすくなります。要件概要書には、保守契約・リース・EOS/EOLの正確な期日、移行するロケーションマスタ・在庫データの量、現場端末の機種・OS・台数を書きます。あわせて、連携する周辺システム（OMS・ERP・WCS等）と、最低限守るコア機能の範囲も入れます。
ベンダーを選ぶ際は、価格や機能の豊富さだけでなく、期限への感度の高さを重視すべきです。具体的には、タイトな日程でPoCから契約締結、開発・移行、現場端末の調達までを確実に進められる実績を持っているかが問われます。
また、契約書やリース契約書に記載された期限を、物流・情報システム・経理・法務の各部門で早期に共有し、いつまでに何を判断し、誰が承認するかを一覧にしておく必要があります。プロジェクト開始後は、残り日数を意識して進捗を管理し、遅れが見つかったら機能範囲を絞るかどうかを早く決められる体制を整えることが、納期を守るための要になります。
まとめ
ここまで、期限の種類と逆算の考え方から、各工程の期間と遅延要因、実務上の進め方まで見てきました。SKU数や拠点規模に応じて、開発・移行に3〜18ヶ月、ベンダー選定に約1.5〜2.5ヶ月を見込むことになります。
中規模以上であれば少なくとも1年、余裕を持たせるなら1年半前からの着手が現実的な目安です。2つの遅延要因（現場端末ライフサイクルの見落としと、移行工数の過小評価）を避けることが大切です。加えて、一括移行を見送り、パイロット移行や段階移行でリスクを分散させれば、期限内の成功に近づけます。
保守契約満了通知やEOS/EOLのアナウンスを受け取ったら、まず自社WMSと現場端末の期限を正確に一覧にし、早めにパートナー選定へ進むことをお勧めします。
▼全体ガイドの記事
・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を創業。