倉庫管理システムのモダナイゼーションは、まず現状分析と企画を行い、要件定義とベンダー選定、設計・開発へ進みます。そのあと、データ移行と並行稼働を経て、カットオーバーで本番に切り替えます。
各段階で決めたことを形に残しておけば、後工程の手戻りを防げます。
▼全体ガイドの記事
・倉庫管理システムのモダナイゼーションの完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
倉庫管理システムのモダナイゼーションが必要になる背景と全体像
今の時点で刷新する理由を明確にしておくと、経営層への予算説明にも、現場の協力を得るためにも役立ちます。
刷新を判断すべきサイン（老朽化・EOSL・属人化・EC化）
刷新を検討するサインは、基盤の老朽化、業務量の変化、運用の属人化に表れます。
- サポート終了：OSやミドルウェア、ハードウェアのEOL/EOSLが迫っている
- 業務変化：1日の出荷増や多品種少量化で、旧システムが業務量に追いつかない
- 属人化：改修できる人が限られ、仕様書もない
サポートが切れた基盤では、セキュリティパッチを当てられないため、ランサムウェアなどの標的にされかねません。特に、出荷を止められない現場では、基盤の問題がそのまま事業継続に関わります。
EC化により、出荷件数が数百件から数千件へ増えたり、店舗とECで在庫を一元管理する必要が出たりします。また、多品種少量化でロケーション管理が追いつかなくなると、旧システムが業務のボトルネックになります。
カスタマイズが重なり、特定のベテランや旧ベンダーにしか改修できない状態にあるのも、注意すべき状況です。さらに、改修の見積もりが高額になったときや、担当者が退職したときも、刷新を検討するサインです。
モダナイゼーションの主な手法（クラウド移行・パッケージ・AI駆動開発）
刷新の手法は、費用、導入期間、自社業務への適合度を見比べて選びます。
- クラウド型（SaaS）：初期費用を抑えて、短期間で導入しやすい
- パッケージ型（オンプレ）：業種特化型なら、倉庫業務に合わせやすい
- フルスクラッチ：自社業務に100%合わせられるが、従来は高コストで長期間かかる
- AI駆動開発：開発工期とコストを30〜70%圧縮できるケースがある
業種特化型パッケージは、アパレルの色・サイズや食品の賞味期限・温度帯の管理に対応できます。一方、SaaSは自社独自の運用に合わせにくい面があります。
近年は、AI駆動開発によるスクラッチの見直しも注目されています。「パッケージか、スクラッチか」という二択を広げる選択肢で、パッケージ並みの予算で、自社業務に100%フィットするシステムを構築する方法として検討できます。
どの手法を選ぶ場合も、先に解決したい課題を決めておきます。手法を先に決めてしまうと、現場に合わず、Excel運用へ戻るおそれがあります。
倉庫管理システム刷新・移行の全体ステップ
刷新は5段階で進み、現状分析と企画で始まって、カットオーバーで本番に切り替わります。その間の3段階では、前の段階で決めたことを土台に、次の作業を進めます。
- 要件定義とベンダー選定
- 設計・開発
- データ移行と並行稼働
前半の企画から開発までは、段階ごとに決めることを一つずつ固めていく流れです。そのため、各フェーズで決めたことを成果物として残しておくと、後工程の手戻りを防げます。
As-Is/To-Be分析とKPI設定（企画フェーズ）
企画では、現場業務を洗い出したうえで、刷新後の姿と、その達成度を測るKPIを決めます。
- As-Is分析：入荷から棚卸まで、現在の実作業を洗い出す
- 例外処理の把握：マニュアルにない非公式の運用も、見える形にする
- To-BeとKPI：刷新後の姿と数値目標を設定する
現場独自の例外処理は、在庫差異やシステム不適合の原因になりやすいため、作業の流れに沿って確かめます。
KPIの例としては、在庫精度を98%から99.9%へ高めることや、誤出荷率を0.3%から0.05%へ下げることです。ピッキング生産性なら、1人1時間あたり120行から180行へ高める目標を立てられます。なお、数値目標があれば、数千万円を投じる理由を経営層に説明でき、稼働後の効果検証にも使えます。
RFP作成とベンダー選定（要件定義フェーズ）
RFP（提案依頼書）に必要な条件を書き、各社の提案と実績を比べて、ベンダーを選びます。
- 目的と要件：現状の課題と、Must・Wantの要件を分ける
- 計画：予算、スケジュール、ERP/OMS/TMS連携を示す
- 実績と体制：同規模の刷新や移行支援の経験を確認する
RFPの記載が曖昧だと、各社の提案を同じ条件で比べられず、ベンダーへの丸投げにつながります。なかでも、ERPとのAPIリアルタイム連携の経験と、データ移行支援の体制は、提案の段階で具体的に確かめます。
発注する側は、契約前に、データ抽出の費用と、撤退時に自社でデータを引き上げる権利を確かめておくと、隠れコストを防げます。
設計・開発フェーズと周辺システム連携
設計・開発の段階では、業務フローと仕様を固めたうえで、個別開発をどこまで行うか、連携時の責任をどこが持つかを決めます。
- カスタマイズ：競争力に直結する業務を優先する
- 標準機能：それ以外は、業務を機能に合わせる
- 障害対応：切り分けのルールと一次対応者を文書にまとめる
「Fit to Standard」の考え方で範囲を絞ると、コストと保守性の釣り合いを取りやすくなります。逆に、カスタマイズを増やしすぎると、次回の刷新時に属人化やブラックボックス化を招きます。
WMSはERP、OMS、TMSと連携し、自動倉庫やAGV・AMRを使う場合には、WCS/WESとの連携も加わります。
複数のベンダーが関わる場合は、障害が起きたときにどこまでを誰が受け持つかが曖昧になりやすいため、設計段階で対応ルールを決めておきます。
データ移行を成功させる実務（失敗の7割はデータに起因）
データ移行では、古いマスタを整理することと、移行の最中も動き続ける在庫の数字を合わせることが課題になります。
マスタクレンジングの基準（12ヶ月ルール・名寄せ）
移行の前に不要なデータを除き、重複を整理しておくと、新システムでの検索や精度を保てます。
- 商品マスタ：過去12ヶ月入出荷のないものは移行しない
- 休止ロケーション：半年以上使われていないものは廃棄する
- 名寄せ：重複する品番や取引先名を統合する
廃棄基準をルール化しておけば、担当者の感覚に頼らず移行対象を絞れます。商品マスタの12ヶ月ルールは、その基準の一例です。
名寄せは、在庫の二重計上や引当ミスを防ぐための土台になります。そのため、現場の担当者にも加わってもらい、生きているデータと不要なデータを一緒に仕分けます。
在庫の時点整合性（差分移行と業務停止の一括切替）
抽出から新システムへの投入までの間も、在庫は動き続けます。数量が現実とずれると欠品や過剰引当につながるため、移行方式は、その在庫の動きをどう扱うかで決めます。
- 差分移行：抽出後の在庫変動を後から反映する
- 一括切替：出荷を止め、在庫を固定してから移行する
差分移行は、業務を止めずに進められるのが利点です。一方、一括切替は確実性が高いものの、出荷停止の調整が必要になります。
出荷を止められないか、週末に止められるかを、出荷カレンダーに照らして判断します。どちらの方式でも、移行直後に実地棚卸を行い、在庫と現物を照合します。
並行稼働（パラレルラン）の正しい進め方と終わらせ方
並行稼働は安全に見えますが、事故が起きやすい局面でもあります。二重入力のため工数は1.5〜2倍になり、長引くほど現場が疲弊します。そのため、始め方より先に、終わらせ方を設計しておきます。
指示系統の一本化ルール（誤出荷を防ぐ鉄則）
新旧の両方から出荷指示書、ピッキングリスト、送り状が出ると、二重ピッキングや重複出荷につながります。
- 新システム：現場用の指示書や送り状を出力する
- 旧システム：裏側で結果を照合する検証用にする
旧システムは現場の作業に登場させないため、二重入力の負担は残るものの、現場への指示は一つに絞れて誤出荷を防げます。
Exit Criteria（終了条件）の決め方と閑散期切替
並行稼働を終える条件は数値で決め、切替時期は繁忙カレンダーに合わせます。
- 出荷エラー：0.5%未満を2週間継続
- ERP連携：API連携が4週間ノーエラーで安定
- 棚卸差異：差異率が事前の基準値以下
条件を満たさないまま期限だけで切り替えると、不安定なシステムに全面的に移すおそれがあります。
並行稼働と本番切替は、閑散期に行います。年末商戦やセール期を避け、出荷量が落ち着く時期を選びます。
本番稼働とリスク管理（切り戻し計画）
本番切替の当日と直後は、出荷が止まると納品の遅れに直結するため、切り戻しの判断基準と旧環境の保持期間を、あらかじめ決めておきます。
ロールバック判断基準と権限の明確化
トラブルの際に迷わないよう、切り戻しを始める数値と判断者を、事前に決めておきます。
- 出荷エラー率：事前に定めた上限を超える
- 棚卸差異率：基準を超過する
- システム停止：所定の時間を超えて続く
また、判断権限者には、プロジェクト責任者と業務部門長を明示しておきます。判断する人が不在のままだと、現場が我慢を続けることになり、被害が広がるおそれがあります。
旧システム・旧端末の保持期間（最低3ヶ月）
新システムの稼働後も、安定して動くことを確かめるまでは、旧環境をすぐに撤去しません。
- 保持期間：旧システム、旧端末、関連ライセンスを最低3ヶ月保持
- 撤去判断：月次締め処理や棚卸を一巡してから、段階的に進める
旧ベンダーとの保守契約も、旧環境の保持期間を見込んで、解約時期を調整します。
よくある失敗と回避策
失敗の多くは、どの現場でも繰り返し起きる典型的な形をとります。例外処理と組織の側の落とし穴に分けて知っておけば、事前に避けられます。
例外処理の反映漏れが生むゴースト在庫
在庫を合わせるには、現場の例外処理をシステムに反映させることが欠かせません。反映されないままだと、在庫差異が起きます。
- セット品：2個1セットの商品が1個だけ返品される
- 破損品：隔離後に論理ステータスを変更し忘れる
- サンプル：記録せずに持ち出す
破損品が引当可能な在庫として残れば、欠品クレームにつながります。要件定義で例外を洗い出して業務フローに組み込み、現場任せにしないことで在庫精度を守れます。
ベンダー丸投げと現場教育不足
現場が主体的に関わらず、本番の前後の教育体制も不足していると、稼働後に混乱を招きます。
- 要件定義：業務を知る現場担当者が参加する
- 事前教育：操作訓練と対応手順を準備する
- 稼働初期：ベンダーや情シスが現場を支援する
要件をベンダー任せにすると、現場の実態に合わず、不満が残ります。また、訓練期間や操作マニュアル、例外手順が足りないと、操作ミスや入力漏れが在庫差異につながります。
費用相場と見積もりで見落とせない隠れコスト
刷新費用は提供形態によって大きく変わり、見積書に載らない隠れコストも総額を押し上げます。そのため、初期費用だけでなく、長期の総額で比べます。
形態別の費用相場と5年TCOの逆転
提供形態ごとに、初期費用、月額費用、導入期間が異なるので、5〜7年のTCO（総保有コスト）で比べます。
- SaaS：初期費用を抑えやすいが、出荷件数や拠点数に応じた従量課金が積み上がる
- パッケージ・スクラッチ：初期構築費が大きく、月額は比較的安定
- 導入期間：SaaSは数ヶ月、他方式は半年から1年以上
たとえば、初期0円・月額20万円のSaaSは5年間で約1,200万円、初期100万円・月額10万円のパッケージは同期間で約700万円です。このように、初期費用が無料でも長期では逆転する場合があります。5〜7年の期間で複数の案を比べ、目先の金額だけでは決めないようにします。
見積もりに出てこない隠れコスト
移行や運用、倉庫移転に伴う費用も、見積もりに含めて総予算を組みます。
- 旧データ抽出：移行テストやリハーサルのたびに依頼が必要で、1回あたり数十万円かかることもある
- 端末と通信：ハンディ端末は1台5万〜30万円で、人数分に加えてWi-Fi整備費も必要
- 年間保守：オンプレ・スクラッチでは初期構築費の15〜20%程度
- 倉庫移転：刷新と移転を同時に行うと、移動手数料が月額保管料の3〜6ヶ月分になる場合がある
旧DBへのアクセス権が自社になければ、データの抽出を旧ベンダーに頼むことになります。そのため、契約時にデータへのアクセス権を確かめておきます。
倉庫移転では、出庫作業費と早期解約違約金が発生するほか、割増保管料や棚卸費も加わります。これらを含めておけば、予算超過を防げます。
まとめ
WMS刷新は、As-Is/To-Be分析とKPI設定から始まり、要件定義と設計・開発、移行と並行稼働を経て、本番稼働へ進みます。
成功させるには、移行の実務と旧システムの撤退計画が欠かせません。切替は閑散期を目指し、現場の出荷カレンダーに合わせて準備します。
データの12ヶ月ルールや在庫の時点整合性を含めたデータの扱い、並行稼働の指示系統と終了条件、例外処理への対応を、事前に決めておきます。切り戻し基準と旧端末の3ヶ月保持も、計画に組み込みます。
費用は5年TCOと隠れコストまで見通すことで、投資効果につなげられます。
▼全体ガイドの記事
・倉庫管理システムのモダナイゼーションの完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。