倉庫管理システムのリアーキテクチャは、企画・要件定義→設計・開発→データ移行→並行稼働→本番稼働の5工程で進みます。この順で進めると在庫精度の向上につながります。
刷新の判断から、工程ごとの進め方、データ移行、稼働後のリスク管理まで、落とし穴とあわせて説明します。
▼全体ガイドの記事
・倉庫管理システムのリアーキテクチャの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
倉庫管理システムのリアーキテクチャの全体像
着手前に、なぜ変えるのか、どこまで変えるのかを言葉にしておきます。目的が曖昧なままだと、現在の業務をそのまま新システムに移すだけになり、費用をかけたのに現状維持で終わるおそれがあります。
リアーキテクチャとリプレイスの違い
刷新の目的を決めるには、製品を取り替えるのか、構造を設計し直すのかを分けて考えます。この違いによって要件定義の深さと費用が変わるため、最初に区別しておきます。
- リプレイス：古くなった製品を、新しい製品に置き換える方法
- リアーキテクチャ：システムの構造そのものを設計し直すこと
リアーキテクチャでは、一枚岩のレガシーWMSを在庫、入出庫、ロケーション、連携などの機能ごとに分けます。そのうえで、API連携を前提とする疎結合な構造へ作り替えるのが、この方法の特徴です。
従来は、自社に合わせるスクラッチ開発は高額で長期になり、費用を抑えるパッケージは業務に妥協が必要になる、という二択で考えられてきました。一方、AI駆動開発では、設計・実装の工期とコストを30〜70%圧縮できるケースがあります。そのため、パッケージ並みの予算で業務に100%合う構築も選択肢に入ります。初期段階から検討対象に含めておきます。
着手を判断すべき4つのサイン
次のような症状が複数重なっているなら、リアーキテクチャの検討を本格化させる時期です。
- サポート終了：EOL／EOSLが告知され、セキュリティパッチが止まる状態
- 属人化：改修できる担当が一人だけで、仕様書もなくブラックボックス化している。
- 処理性能の低下：EC化で出荷件数が数年で2〜3倍になり、ピーク時に処理が遅れる。
- 手作業の連携：ERPとの連携をCSVの手動取込で行い、二重入力や転記ミスが常態化している。
OSやミドルウェアのサポートが切れた状態では、情報漏えいや業務停止のリスクを抱えたまま運用することになります。サポート終了に出荷増や手作業連携の課題が重なっていないかを見て、刷新の必要性を判断します。
リアーキテクチャの進め方（全体ステップ）
全体は、企画・現状分析から本番稼働までの順に進みます。この節では、前半の企画から開発までを扱います。前半の精度は、後半のデータ移行や並行稼働の負荷を大きく左右します。
As-Is／To-Be分析とKPI設定
現状の業務（As-Is）は、例外処理も含めて洗い出します。そのうえで、あるべき姿（To-Be）と改善のKPIを決めておくと、投資判断や稼働後の効果検証に使える基準になります。
- 作業の洗い出し：入荷から返品までの流れを、作業ごとに追う
- 例外の把握：非公式な運用や、在庫差異が生じる原因を拾う
- KPI設定：在庫精度や誤出荷率に、具体的な目標値を設ける
現場の各作業について、例外処理まで確認します。たとえば、セット品をばらして出荷する運用や、破損品を隔離してもシステム上の状態を変えない運用は、在庫差異の原因になります。
目標の例として、在庫精度を98%から99.9%に、誤出荷率を0.3%から0.05%以下に、ピッキング1行あたりの時間を15%短縮する、といった水準が挙げられます。数千万円の投資は、こうしたKPIの改善見込みとROIを示して理由を説明します。
RFP作成とベンダー選定
要件が固まったら、提案依頼書（RFP）を作ってベンダーに提示します。提案を比べられるようにし、精度の高い見積もりを得るには、業務要件や前提条件の明記が欠かせません。
- 前提条件：出荷件数、品目数、拠点数、連携方式、機器の有無
- 要件の優先度：Must要件とWant要件に分けて示す
- 撤退条件：解約条件と、データへのアクセス権の扱い
「最適なシステムを提案してください」のような依頼では、各社の提案を比べにくく、自社固有の例外処理も抜け落ちてしまいます。そのため、前提条件は数値で具体的に示し、ERP、OMS、TMSとの連携方式やマテハン機器の有無も書き添えます。
選定の際は、物流の業務ノウハウと開発力の両方を確認します。特に注意したいのは、DBへの直接アクセス権が自社になく、移行テストのたびにCSVの抽出を1回数十万円で旧ベンダーに頼む契約です。こうした契約は、隠れたコストになります。
設計・開発フェーズの進め方
設計・開発では、業務フローをシステムに落とし込みます。そのとき、カスタマイズする範囲と、標準機能に業務を合わせる範囲を分けて考えます。
- 競争力の源泉：必要な業務に限って、カスタマイズを行う
- 標準機能：それ以外の業務は、Fit to Standardの考え方で標準機能に合わせる
- 機器連携：責任分界点と障害時の切り分けを、文書で合意しておく
現行業務をすべて再現しようとすると、開発費が膨らみ、将来のバージョンアップも難しくなります。このため、どこまで業務に合わせるかの判断が、コストと保守性の両立を左右します。
自動倉庫やAGV・AMRと連携する場合は、WCS／WESとの連携開発が別途必要になります。規模によっては、500万〜3,000万円程度の追加開発が発生します。
複数のベンダーが関わる場合、障害時にどこまでが誰の担当かが曖昧になりがちです。設計段階で責任分界点と切り分けのルールを定め、文書にしておきます。
データ移行を成功させる実務（失敗の7割はデータ）
移行するマスターデータと在庫データの品質が、成否を分けます。失敗の約7割はデータに起因するとされ、なかでもマスタクレンジングと在庫の時点整合性が難所になります。
マスタクレンジングの基準（12ヶ月ルールと名寄せ）
移行の前にマスタを整理し、不要なデータを新システムに持ち込まないようにします。そのためには、対象の基準と表記を統一するルールを先に決めておく必要があります。
- 12ヶ月ルール：過去12ヶ月に入出荷実績がない商品マスタは、原則として移行対象から外す
- 名寄せ：半角と全角の違いや表記ゆれによる重複を、ひとつに統一する
商品コードや休止ロケーション、表記ゆれで重複した取引先などは、長年の運用で少しずつ蓄積しています。これを整理せずに移すと、刷新が汚れたデータの引っ越しで終わってしまいます。
基準が明確であれば、「念のため残したい」という現場との押し問答を減らせます。休止ロケーションにも同じ考え方を当てはめます。また、名寄せのルールを定め、誰が判断しても同じ結果になるようにしておきます。
在庫の時点整合性（差分移行か業務停止一括か）
移行作業の最中も、在庫は動き続けます。抽出から投入までの入出荷を反映できないと、新システムの在庫と実在庫がずれ、稼働初日から棚卸差異が生じてしまいます。
- 業務停止一括：在庫を凍結して、その時点のデータをまとめて移す方法
- 差分移行：移行中の入出荷を、差分として追加で反映する方法
業務停止一括は確実な方法ですが、出荷を止められる業態に限られます。一方で、差分移行は停止時間を抑えられる反面、差分を取りこぼすおそれがあります。
差分移行を選ぶ場合は、リハーサルを複数回行って手順を固めます。そのうえで、出荷を止められる時間と在庫の動く速さを踏まえ、どちらの方法にするかを決めます。
並行稼働（パラレルラン）の正しい進め方と終わらせ方
並行稼働は、新旧のシステムを同時に動かし、新システムの正しさを検証する工程です。この工程では、指示の出し元を一本化することと、終了条件を事前に決めておくことが欠かせません。
指示系統の一本化ルール
現場に出す指示書を新旧の両方から発行すると、二重ピッキングや誤出荷につながります。そのため、現場向けの出力元は新システムに統一します。
- 新システム：出荷指示書など、現場向けの帳票を発行する役割
- 旧システム：裏側でデータを突き合わせて、検証するために使う
出荷指示書、ピッキングリスト、送り状を両方のシステムから出力すると、作業者が混乱します。在庫精度を上げるための刷新が、かえって誤出荷を増やしかねません。
並行稼働中は二重入力になるため、作業工数が1.5〜2倍に膨らみます。そこで、応援要員と残業計画を事前に用意し、現場の負担を抑えます。
Exit Criteriaの決め方と閑散期切替
感覚で並行稼働を終えると、判断の根拠がなく危険です。終了条件（Exit Criteria）を数値で定め、条件を満たした時点で旧システムを停止します。
- エラー率：誤出荷などの割合を、0.5%未満に保つこと
- API連携：ERP連携が4週間連続で正常に動いている状態
- 棚卸差異率：あらかじめ定めた基準値の範囲内に収まっていること
終了条件があれば、声の大きさや感覚ではなく、データで切替を判断できます。そのため、終了条件は事前に関係者で明文化しておきます。
切替は閑散期に設定します。繁忙期は二重入力の工数が増え、現場が混乱しやすいため、年間の繁閑カレンダーや月末、季節要因を見て時期を逆算します。
本番稼働とリスク管理
本番稼働は、リアーキテクチャの集大成となる工程です。トラブルが起きたときに、誰がどの数値をもとに判断するかを決めておくと、被害の拡大を抑えられます。
ロールバック判断基準と権限
出荷が止まりかけたときに判断が遅れると、遅延が翌日以降に広がってしまいます。そのため、稼働前に旧システムへ切り戻す基準を数値で定めておきます。
- エラー率：出荷処理のエラー率が、設定値を上回ること
- 処理状況：特定の時刻までに、当日出荷の処理が設定した割合に届かない場合
- 決定権限：切り戻しの最終決定者を、あらかじめ明確にしておく
切り戻しの判断には、上に挙げた指標を用います。具体的なしきい値は、稼働前に決めておきます。
現場責任者、情シス、ベンダーのどこが判断を担うかを、先に示しておきます。判断者、連絡経路、手順は稼働判定基準書にまとめ、関係者で共有します。
旧システム・旧端末の保持期間
新システムが安定するまでは、旧システムと端末を残しておきます。保持期間は、切り戻しへの備えと二重のコストを比べて決めます。
- 保持期間：旧システムと旧端末を、最低3ヶ月程度は残しておく
- 停止判断：安定稼働を確認したうえで、正式な停止基準に沿って撤退する
稼働直後に旧システムを解約したり、ハンディ端末を破棄したりすると、切り戻しが必要になったときに業務が止まるおそれがあります。
保持している間は、旧システムのライセンス費や端末のリース費が二重にかかります。ただし、これは業務停止のリスクに備える費用と捉え、停止の基準もあらかじめ定めておきます。
よくある失敗と回避策
失敗の多くは、技術よりも業務設計や人の運用に原因があります。そのため、代表的な落とし穴を把握し、対策を各工程に組み込んでおきます。
例外処理漏れが生むゴースト在庫
WMSを導入しても、現場の例外処理がシステムに反映されなければ、在庫は合いません。システム上の状態と実物の状態がずれることが、その原因になります。
- 単位の食い違い：2個1セットの商品を出荷したあと、1個だけ返品される場合
- 状態の未更新：破損品を隔離しても、論理状態を更新しないこと
- 無記録の持出し：サンプル品の移動が、記録に残らないこと
実在しない在庫を引き当てると、欠品のクレームにつながります。そこで、例外処理を要件定義の段階で洗い出し、システム上の状態遷移に組み込んでおきます。
正常な作業だけでなく、イレギュラーな運用も現場に確認します。例外処理の設計は、稼働後の在庫精度を大きく左右します。
ベンダー丸投げと現場教育不足
自社の業務知識を整理しないままベンダーに任せると、現場とかけ離れたシステムになり、稼働後に使えないという声が出ます。
- 自社の関与：現場担当が、要件定義や受入テスト（UAT）に主体的に加わること
- 現場教育：マニュアルを整えたうえで、端末リハーサルや繁忙期を想定した模擬出荷を行う
リアーキテクチャは、自社の業務改革でもあります。さらに、移行の対象はシステムだけでなく、人と業務も含みます。稼働直前に教育が不足すると、操作に習熟できず、初日の作業が滞ってしまいます。
まとめ
リアーキテクチャは、現状分析とKPI設定から始めます。そのうえで、Must要件を明記したRFPでベンダーを選び、データ移行、並行稼働、本番稼働へと段階的に進めます。
移行では、12ヶ月ルールで不要なマスタを整理し、在庫の時点整合性を確保します。並行稼働では、指示系統を一本化し、Exit Criteriaを明文化します。
本番稼働では、切り戻しの基準と権限を決め、旧システムと端末を最低3ヶ月保持します。また、例外処理の把握、現場の参加、教育も、在庫精度の向上に欠かせません。
物流カレンダーに合わせて無理のない計画を立て、工程ごとに手順を踏んで進めます。
▼全体ガイドの記事
・倉庫管理システムのリアーキテクチャの完全ガイド
▼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を創業。