WMS更改の進め方/やり方/流れや方法/手法/工程/手順

WMS更改は、目的とKPIを定め、要件を固めたうえで、データ移行と並行稼働を経て本番に切り替える流れで進めます。この順番を守ると、在庫精度の向上と業務効率化につながります。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

WMS更改の全体像と進め方の前提

WMS更改では、まず更改の目的を関係者全員で共有しておくことが前提になります。そのうえで、業務を動かしながら在庫データを新しい基盤へ移す実務を進めることになります。特に、目的が曖昧なまま製品を選ぶと、現行業務の不満を解消するだけで終わり、数千万円を投じても効率がほとんど変わらない場合があります。

WMS更改が必要になる主なサイン

更改を判断する目安は、システムの状態や業務の変化として、おもに次のような形で表れます。

• 老朽化：ベンダーのサポート終了（EOL/EOSL）やサーバーOSの保守切れが迫っている状態。
• 業務変化：EC化による出荷の増加、多品種少量化、オムニチャネルへの対応に、既存システムが追いつかない。
• 属人化：過度なカスタマイズにより、改修のたびに見積もりが高額になるうえ、仕様を特定の担当者しか把握していない。

ERPとWMSの連携をCSVの手動取り込みに頼る現場では、二重入力や転記ミスが起きやすく、在庫差異やリードタイムの遅延につながります。

担当者が在庫データを毎日アップロードするなど、業務がシステムを補っている状態であれば、更改を本格的に検討する時期です。

更改で得られる効果とゴール設定

ゴールは、あとから数値で測れるKPIとして定めておきます。たとえば、次のような指標が考えられます。

• 在庫精度：98%以上を目標にする。
• 誤出荷率：0.05%未満に抑える。
• ピッキング生産性：20%向上させる。

現状値を起点に改善幅を決めておけば、投資対効果（ROI）を経営層に説明できます。

具体的には、再出荷の物流費や人件費、信用損失を含めた誤出荷1件あたりの対応コストを仮に1万円と見積もるとします。その場合、年間500件から200件へ減らせれば、年間300万円の削減効果を見込めます。

ゴールを金額に換算しておくと、数千万円規模の投資判断に説得力が生まれます。さらに、計画のぶれも抑えられます。

WMS更改プロジェクトの全体ステップ

WMS更改は、次の工程を順に進めます。なかでも成否を分けやすいのは、要件定義までの上流工程です。

1. 企画・現状分析
2. 要件定義
3. 設計・開発
4. データ移行
5. テスト
6. 並行稼働
7. 本番稼働

全体の期間は提供形態によって異なります。SaaSなら数ヶ月で、パッケージのカスタマイズやスクラッチ開発なら半年から1年以上が一般的です。

As-Is/To-Be分析とKPI設定

As-Is/To-Be分析は、今の業務からあるべき姿までを、順を追って整理する作業です。

1. 現状業務（As-Is）：入荷・検品・格納・保管・ピッキング・流通加工・出荷の各作業を、例外処理も含めて可視化する。
2. 現場運用の確認：マニュアルに載っていない実際のやり方を洗い出し、後工程の品質を高める。
3. あるべき姿（To-Be）：現状とのギャップと、その解消に必要な対応を書き出す。
4. KPI設定：業務プロセスに紐づけ、要件の優先順位を決める材料にする。

現場ヒアリングには、最低2〜4週間を確保しておきます。

複数拠点がある場合は、拠点ごとに運用が異なる点も確かめます。

RFP作成とベンダー選定

RFP（提案依頼書）は、ベンダーへの丸投げを防ぎつつ、各社の提案を比較するために使う文書です。

• 業務量と要件：1日の出荷件数、SKU数、拠点数を示したうえで、必須要件と希望要件を分けて記す。
• 連携と時期：ERP・OMSとの連携方式や、希望する稼働のタイミングを具体的に書く。
• 導入実績：同業種・同規模での経験があるかを確かめ、業種特有の対応を質問する。
• 支援と撤退：移行を支える体制に加え、撤退時にデータを引き上げられるかも確認する。

提案の中身が現場に合っているかは、具体的な業務への対応を見ると判断できます。アパレルなら色・サイズ展開、食品なら賞味期限や温度帯管理への対応が、その判断の目安になります。

カスタマイズとFit to Standardの線引き

過去のシステムが属人化した最大の原因は、過剰なカスタマイズにあります。

• Fit to Standard：標準機能に業務を合わせ、競争優位に直結する業務に限って必須のカスタマイズを残す。
• AI駆動のスクラッチ開発：工期とコストを30〜70%圧縮できるケースがある。
• 新たな選択肢：パッケージ並みの予算で、自社に100%フィットするシステムを作る方法も検討の対象になる。

開発手法は、自社業務のどこが特殊かを見極めたうえで選ぶことが大切です。

データ移行を成功させる進め方

WMS更改の失敗のうち約7割は、データが原因だと言われています。製品の機能比較には時間をかける一方で、肝心のデータ移行は軽視されがちです。そこで、マスターデータと在庫の時点整合性を計画の段階から押さえておきます。

マスタクレンジングの基準（12ヶ月ルール・名寄せ）

未使用の商品マスタや休止中のロケーションをそのまま移すと、検索性が落ちるうえ、誤った引当の原因にもなります。

• 12ヶ月ルール：過去1年間に入出荷実績がないマスタや休止ロケーションは、移行の対象から外す。
• 名寄せ：同じ商品の表記ゆれや旧コードの重複をまとめ、在庫が分散するのを防ぐ。

クレンジングは工数がかかるため、要件定義と並行して早めに着手します。

廃棄するか維持するかの基準は、関係部門で合意しておくことが肝心です。

在庫の時点整合性（差分移行 vs 業務停止一括）

倉庫の在庫は移行作業中も動き続けるため、抽出から新システムへの投入までの間に入出荷があると、移行後の在庫数と現物がずれてしまいます。

この問題は「時点整合性」と呼ばれます。その対処法として、差分移行と業務停止後の一括切替があります。

• 差分移行：抽出後に生じた変更を後から追加で反映する。業務を止めずに済む一方、手順は複雑になる。
• 業務停止後の一括切替：週末などに業務を止めて一度に切り替える。整合性は取りやすいが、出荷停止の期間が生じる。

どちらを選ぶかは、出荷を止められる時間と、データ量や複雑さを踏まえて決めます。

本番移行の前には必ず、本番相当のデータでリハーサルを行い、所要時間と差異の発生箇所を確かめます。

並行稼働（パラレルラン）の正しい進め方と終わらせ方

並行稼働は、新旧のシステムを一定期間同時に動かして、新システムが正しく動くかを確かめる工程です。

安全策に見えても、進め方を誤ると現場がもっとも崩れやすい期間になります。そのため、終了の方法は最初に決めておきます。

指示系統の一本化ルール

新旧の両方から指示書が出ると、作業者が混乱し、重複ピッキングや誤出荷を起こしてしまいます。これは運用ルールの設計ミスです。

• 現場の指示書・送り状：出力元を新システムだけにする。
• 旧システム：データ整合性の照合だけに使い、現場の作業では使わない。

二重入力が続くと工数は1.5〜2倍に膨らみ、現場が疲弊します。

Exit Criteria（終了条件）の決め方と閑散期切替

終了の判断を感覚に任せると、不具合が起きたあとに責任の所在が曖昧になります。

• 終了条件：出荷エラー率0.5%未満の維持と、ERPとのAPI連携の4週間連続の安定稼働を定める。達成後に旧システムを止める。
• 切替時期：必ず出荷量の少ない閑散期を選び、季節やセールで変わる業務量を踏まえて日程を決める。

繁忙期に二重入力の負荷が重なると、現場はパンクしかねません。

本番稼働とリスク管理の進め方

本番稼働（カットオーバー）は、プロジェクトのゴールであると同時に、もっとも緊張感の高い工程です。

出荷が止まれば、顧客への納品が遅れてしまいます。そのため、切り戻しの計画と旧環境の保持期間を事前に決めておきます。

ロールバック判断基準と権限

重大なトラブル時のロールバックは一刻を争います。このため、誰がどの数値を見て、いつまでに判断するかを事前に決めておきます。

• 判断基準：出荷エラー率や棚卸差異率のしきい値を設定し、時間と数値で条件を書き表す。
• 判断例：稼働後3時間で出荷処理が計画の50%に届かなければ、ロールバックを検討する。
• 権限と連絡：プロジェクト責任者と現場責任者に判断の役目を持たせ、誰に知らせるかの経路を関係者で共有する。

時間と数値で条件を明確にしておくと、感情に流されず、事実に基づいて冷静に判断できます。

旧システム・旧端末の保持期間

新システムが安定しても、旧システムや旧ハンディ端末をすぐに破棄しないようにします。処分したあとで戻す必要が生じると、再接続ができず、業務が止まるおそれがあるためです。

• 保持期間：稼働後、最低3ヶ月は旧環境・旧端末・ライセンスを残しておくことを推奨する。
• 安定性の確認：月次・四半期の締め処理を新システムで一巡させ、問題が出ないかを確かめる。
• 撤退判断：サーバーやライセンスの費用は、業務停止のリスクに比べて安価な保険とみなし、安定を数値で確かめてから決める。

WMS更改でよくある失敗と回避策

典型的な失敗を事前に知っておくと、同じ問題を避けやすくなります。特に多いのは、例外処理の漏れによる在庫差異と、ベンダー任せや現場教育の不足です。

例外処理漏れによる在庫差異

WMSを導入しても在庫が自動的に合うわけではありません。現場の例外処理がシステムに反映されないままだと、差異が生じます。

• セット返品：2個で1組の商品のうち1個だけ返品されると、組と単品の管理単位が食い違う。
• 破損品：隔離後に論理ステータスの変更を忘れると、ゴースト在庫が引き当てられ、欠品のクレームにつながる。
• サンプル：記録をせずに持ち出すと、在庫差異の原因になる。

在庫精度を守るには、要件定義の段階で現場の例外処理を一つずつ洗い出し、新システムでの扱いを設計に盛り込んでおく必要があります。

ベンダー丸投げと現場教育不足

WMS更改は、ベンダーと自社が二人三脚で進めるものです。ベンダーに丸投げすると、現場の知見が抜け落ち、完成したシステムが実態から離れてしまいます。さらに、教育が不足していると、稼働時の混乱を招きます。

• 自社の関与：要件の取りまとめとテストシナリオの作成に、担当者が主体的に加わる。
• 現場教育：マニュアルを整えたうえで、本番に近い環境のハンズオン研修を複数回行う。
• 操作習熟：画面と端末の使い方を覚える時間を、稼働前に確保しておく。

新システムへの不安を減らしておくことが、稼働初日の事故防止につながります。

費用相場とスケジュールの目安

見積書に載らない隠れコストが、後から加わることもあります。そのため、予算を立てるときは、費用とスケジュールの目安を確かめ、見積もりの外にある負担も含めて考えます。

形態別の費用と期間の目安

初期費用と期間は、提供形態ごとの目安を比べながら検討すると、判断の材料になります。

• クラウド型（SaaS）：初期費用を抑えやすく、月額の利用料で使える。導入は数ヶ月で、対象は小〜中規模の倉庫。
• カスタマイズ・スクラッチ：初期費用は数百万円から数千万円規模で、半年から1年以上かかる。その代わり、業務への適合度を高められる。

「初期費用無料」という点だけで判断しないことが大切です。SaaSは従量課金が積み重なり、オンプレやパッケージより中長期で割高になる場合があります。

たとえば、初期0円・月額20万円の場合は5年で1,200万円、初期100万円・月額10万円の場合は5年で700万円になります。

5〜7年のTCO（総保有コスト）で比べることが、健全な投資判断の前提になります。

見積もりに出ない隠れコスト

予算超過を防ぐには、見積書に表れにくい費用も契約前に把握しておくことが必要です。

• 旧データ抽出：旧DBへ直接アクセスできない契約では、テストやリハーサルでデータを取り出すたびに、旧ベンダーへ1回数十万円のスポット費用がかかることがある。
• 端末：1台5万〜30万円のハンディ機器が、利用する人数分必要になる。
• 年間保守：オンプレやスクラッチでは、初期構築費の15〜20%が毎年固定で発生する。
• 倉庫移転：同時に移転する場合、出庫作業費・早期解約違約金・割増保管料・棚卸費などがかかり、月額の3〜6ヶ月分が加わることもある。

契約前に費用を洗い出し、TCOに織り込んでおくことが、予算管理の要になります。

まとめ

WMS更改は、目的とKPIの明確化から始まり、As-Is/To-Be分析、RFP作成、ベンダー選定を経て進みます。その後はデータ移行、並行稼働へと進み、最後は本番稼働を迎えます。

成否を分けるのは、移行実務の精度です。なかでも、データ整備と在庫の時点整合性、指示系統の一本化が要になります。加えて、ロールバックの判断基準を数値で定めておくことも欠かせません。

現場の例外処理を設計に反映し、隠れコストを把握したうえで、閑散期に切り替えることが、プロジェクトの安定につながります。

工程や確認事項を、自社の業務量と現場の実態に合わせて具体化すれば、在庫精度の向上と業務効率化を目指せます。

各工程の費用や発注の詳細は、関連記事もあわせてご覧ください。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。