WMS更改の選定ポイント/選び方/種類

WMS更改の検討を始めると、契約更新の案内を待つだけでよいのか、SaaS型のクラウドWMSへ移行すべきなのか、あるいは自社独自の入出庫ロジックを活かすために個別開発すべきなのか、いくつもの選択肢が同時に浮かび上がります。WMS更改の選び方とは、保守契約やハードウェアの期限という動かせない制約の中で、自社の業務範囲と現場の実情に合った選択肢を、限られた検討期間内に絞り込むプロセスを指します。機能一覧の見た目や営業担当者の説明のわかりやすさだけで選んでしまうと、稼働後に現場のハンディターミナル操作が旧システムより煩雑になったり、想定していた基幹システム連携が実は追加開発扱いだったりと、選定段階では見えにくかった問題が表面化しやすくなります。

本記事では、更改前に整理すべき自社の課題、ロールオーバー・SaaS移行・個別開発という3つの選択肢、製品やベンダーを比較する7つの評価軸、期限から逆算したスケジュールとベンダー選定の進め方、RFPとPoCの具体的な進め方、選定で陥りやすい失敗を解説します。これから検討を始める担当者の方が、比較の切り口をそろえ、自社に合う選択肢を絞り込めるようまとめました。

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

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

WMS更改を検討する前に整理すべき自社の課題

製品カタログを集める前に、まず確認すべきは、保守契約とハードウェアのどちらの期限が先に到来するか、そして現行WMSのどこに不満や制約が集中しているかです。この2点を切り分けておくことで、比較すべき選択肢と評価軸が明確になります。課題が曖昧なまま製品資料を集め始めると、営業担当者から提示される機能一覧に判断基準を委ねてしまい、結果として自社の業務に合わない製品を選んでしまうリスクが高まります。

保守サポート契約の満了日と、ハンディターミナルなど現場端末のリース期限、ベンダーが公表するEOS・EOLの時期は、必ずしも同時に到来するとは限りません。ハンディターミナルの調達期限が保守契約の満了より先に来る場合、端末単体の入れ替えでは済まず、WMS本体の入れ替えを前倒しで検討する必要が生じます。まずは自社の各期限を一覧化し、最も早く到来する期限から逆算して検討スケジュールを組み立てます。契約書やリース明細を担当部門ごとにばらばらに管理していると、期限の把握そのものが遅れる原因になるため、情報システム部門と物流部門が共通の一覧表を持つことから始めるとよいでしょう。

現行WMSが基幹システム(ERP)、受注管理システム(OMS)、自動倉庫やAGVを制御する倉庫制御システム(WCS)とどの程度密接に連携しているか、ロケーションコードがどの程度自由記述で運用されているかによって、移行の難易度は大きく変わります。連携が単純でロケーション構造も整理されている場合はSaaS型への移行がしやすく、逆に独自の連携や複雑なロジックが多い場合は、個別開発やハイブリッドな進め方を検討する必要が出てきます。長年の運用で積み重なった個別カスタマイズの一覧を作成し、そのうち標準機能で代替できるものと、独自ロジックとして残す必要があるものを仕分けておくと、後工程の評価軸で判断がぶれにくくなります。

WMS更改における3つの選択肢

更改の選択肢は、大きく分けてロールオーバー(契約更新)、SaaS型クラウドWMSへの移行、個別開発(フルスクラッチ・セミスクラッチ)の3つです。それぞれ、必要な期間と費用の構造が異なります。

現行ベンダーとの契約をそのまま延長するロールオーバーは、追加の移行作業なしに稼働を継続できる選択肢です。ただし、EOS・EOL後の延長保守費用は通常の1.5倍から数倍に高騰するのが一般的な相場観とされており、ハンディターミナルの再リースも故障時の修理費が高額化しやすく、代替機を調達できなくなるリスクを伴います。ロールオーバーは、次の更改までの準備期間を確保するための一時的な選択肢と位置づけ、その間に本格的な検討を進める前提で選ぶことが重要です。何も検討を進めないままロールオーバーを繰り返すと、次の契約更新時にも同じ判断を先送りしてしまい、結果としてEOS・EOLのリスクを長期間抱え続けることになりかねません。

SaaS型のクラウドWMSは最短2週間〜1ヶ月程度で導入でき、初期費用も抑えやすいため、期限までの猶予が少ない場合や、標準的な入出荷業務が中心の現場に向いています。運用保守費用は初期費用無料〜100万円程度、月額1万〜20万円程度が一つの相場観とされていますが、自社の入出庫ロジックが標準機能から大きく外れている場合、追加のカスタマイズ費用や運用回避策が必要になることがあるため、事前のフィット&ギャップ確認が欠かせません。

自社独自の入出庫ロジックや棚卸し方式が競争優位の源泉になっている場合は、フルスクラッチでの構築に意義があります。ただし、要件定義からゼロで構築するフルスクラッチは初期費用3,000万〜1億円以上、開発期間1〜2年(大規模なら3年以上)を要するため、EOS・EOLという動かせない期限に対しては、標準パッケージの機能を活かしつつ独自ロジックのみを追加開発する「セミスクラッチ型」や、在庫管理・入出荷管理など必要最小限の機能(MVP)に絞った先行リリースといった折衷案の方が、期限内に収まる現実的な選択肢になることが多くあります。

製品・ベンダーを比較する7つの評価軸

選択肢の方向性が定まったら、候補となる製品やベンダーを同じ条件で比較します。印象や営業説明の分かりやすさに左右されないよう、確認方法まで含めて記録することが重要です。評価担当者が複数部門にまたがる場合は、同じ質問票と検証シナリオを全員で共有し、個人の主観に頼らない比較結果を残すことも欠かせません。

第一に、入荷、格納、ピッキング、検品、出荷、棚卸しといった一連の業務のうち、どこまでが標準機能でカバーされるかを確認します。第二に、自社が使用しているハンディターミナルの機種やOS(Windows CEかAndroidか)に対応しているか、対応していない場合は端末の入れ替えも合わせて必要になるかを確認します。第三に、WCS・OMS・基幹システムとのAPIまたはCSV連携について、対象データ、同期方向、エラー時の復旧方法まで確認します。「標準対応」という回答だけで終わらせず、実際にどのデータ項目まで自動連携できるのか、連携が失敗した際に誰がどう気づき、どう復旧するのかまで質問すると、稼働後の運用負荷を事前に見積もりやすくなります。

第四に、旧WMSからのロケーションマスタや在庫データの移行について、どこまでをベンダーが支援するか、旧ベンダーへのデータ抽出依頼が別途スポット費用として発生するかを確認します。第五の料金体系では、初期費用と月額費用に加えて、ユーザー数やロケーション数に応じた従量課金の境界、サポート費用まで含めたTCOで比較します。第六に、権限管理や操作ログ、障害時のサポート体制、契約終了時のデータ返却条件を確認します。料金が非公開の項目を推測で比較表に入れることは避け、確認できた事実だけを記録します。

期限からの逆算スケジュールとベンダー選定の進め方

WMS更改は、期限に間に合わせることが前提のプロジェクトです。逆算したスケジュールに沿って、ベンダー選定のプロセスを計画的に進める必要があります。着手が遅れるほど選択肢が狭まり、期限直前になって十分な比較検討ができないまま製品を決めざるを得なくなるという事態にもつながりかねません。

WMSの導入・移行期間の目安は、小規模(1,000SKU未満)で3〜6ヶ月、中規模(1,000〜10,000SKU)で6〜12ヶ月、大規模(10,000SKU以上・複数拠点)で12〜18ヶ月とされます。これに現状課題分析とTo-Be像策定の約3ヶ月、RFP作成からベンダー選定までの約3ヶ月を加えると、中規模以上のWMSでは、EOSやEOLの1年〜1年半前には検討を始動する必要があります。ハンディターミナルの調達やロケーションマスタの移行という工程が多い分、情報系システムの更改より長めのリードタイムを見込んでおくことが重要です。

ベンダー選定のプロセスは、RFIによる技術適合評価に1〜2週間、PoCなどの実地検証に3〜6週間、コンプライアンスや契約内容の精査に1〜2週間という3ステップで構成され、合計1.5〜2.5ヶ月程度が目安になります。この期間をあらかじめ確保したうえで、複数ベンダーへ同時に声をかけ、同じ質問と検証シナリオで比較することで、個別に問い合わせを重ねるより短期間で絞り込めます。

RFP作成とPoCの進め方

比較表やRFPの段階で条件をそろえておくことが、後工程のPoCを効率化させます。条件があいまいなままPoCへ進むと、各ベンダーがそれぞれ異なる前提でデモを準備してしまい、後になって比較のやり直しが必要になることもあります。

RFPには、対象拠点数、SKU数、現行の連携先システム(ERP・OMS・WCS)、使用中のハンディターミナルの機種とOS、保守契約とハードウェアそれぞれの期限、解決したい課題を記載します。要件は「必須」「望ましい」「将来対応」の3段階に分け、すべてを必須にして候補を狭めすぎないようにします。

PoCでは、API連携の疎通確認や在庫引当ロジックの整合性確認に加えて、実際の倉庫のWi-Fi環境下でハンディターミナルを操作し、スキャン速度や画面遷移を現場作業員が検証することが欠かせません。机上のデモ画面だけでは分からない運用負荷を、期限内に収まる3〜6週間のタイムボックスの中で確認します。

WMS更改の選定で陥りやすい失敗

更改特有の失敗は、期限を軽視した検討スケジュールと、現場端末の検証不足から生じることが多くあります。いずれも、選定の早い段階で見落とされやすく、稼働直前になって表面化する点が共通しています。

機能比較や料金交渉に時間をかけすぎて、気づけばEOSやハンディターミナルのリース期限まで数ヶ月しか残っていない、という事態は珍しくありません。検討開始と同時に、譲れない期限をまず確定させ、そこから逆算した各工程の締め切りを先に決めておくことが、後工程での焦った判断を防ぎます。具体的な候補製品を確認したい場合は、WMS更改のパッケージ・クラウド製品一覧を参照すると、比較の出発点として活用できます。

管理画面のデモだけで導入を決めてしまうと、実際の現場でスキャン速度が遅い、Wi-Fi環境で通信が不安定になる、といった問題が稼働後に判明することがあります。PoCの段階で現場作業員に実機を操作してもらい、問題があれば契約前に代替案を検討します。また、データ移行費用を過小に見積もり、旧ベンダーへのデータ抽出依頼費用を後から追加で請求されるケースもあるため、見積もり段階で確認しておく必要があります。

WMS更改の選び方に関して確認しておきたいポイント

最後に、選定を進める中で判断に迷いやすい論点を整理します。いずれも一つの正解があるわけではなく、自社の期限・業務範囲・独自ロジックの重要度に応じて判断が変わる論点です。

現行WMSの稼働に大きな不満がなく、ハンディターミナルの調達にも猶予がある場合は、ロールオーバーを選び、その間に本格的な更改検討を進めるという判断も現実的です。ただし、延長保守費用の高騰や現場端末の調達難易度を定期的に確認し、次の判断時期を先送りしすぎないようにします。

独自の入出庫ロジックや棚卸し方式が事業の競争優位に直結している場合は個別開発を検討する価値がありますが、単に「今の使い勝手を変えたくない」という理由だけでは、期限内に収めるリスクに見合わないことがあります。標準パッケージで対応できる範囲と、独自開発が必要な範囲を切り分けたうえで判断します。

API連携や在庫引当ロジックといったシステム面の検証に加え、ハンディターミナルの実機を使った現場検証、請求・帳票など周辺業務への影響まで含めて確認します。正常系だけでなく、契約変更や返品といった例外処理も試すことで、稼働後のトラブルを減らせます。

まとめ

WMS更改の選び方は、保守契約とハードウェアの期限という動かせない制約の中で、ロールオーバー、SaaS型への移行、個別開発という3つの選択肢から、自社の業務範囲と現場の実情に合うものを絞り込むプロセスです。業務範囲・現場端末対応・システム連携・データ移行性・料金体系・セキュリティ・保守体制という7つの評価軸で候補を比較し、期限から逆算したスケジュールに沿ってベンダー選定とPoCを進めることが重要です。どの選択肢を取るにしても、判断の起点になるのは自社の期限と現行システムの制約を正確に把握することであり、この整理を丁寧に行うほど、後工程の比較検討がスムーズに進みます。

まずは、保守契約とハンディターミナルそれぞれの期限を確認し、最も早く到来する期限から逆算して検討スケジュールを組み立ててください。標準パッケージで対応できる業務範囲を見極めたうえで、独自の入出庫ロジックや基幹システムとの連携が競争優位に直結する部分については、個別開発やハイブリッドな構成も選択肢になります。riplaはフルスクラッチ開発の立場から、既製WMSでは吸収しきれない業務要件の整理や、基幹システム・WCSとの連携を含む構築を支援しています。具体的な製品を確認したい場合はWMS更改のパッケージ・クラウド製品一覧を、基本的な考え方は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を創業。