入出庫管理システムの移行は、現状分析→要件定義→設計・開発→データ移行→並行稼働→本番稼働の順に進めます。工程を一つずつ踏んでいくと、現場への影響を抑えながら切り替えられます。
▼全体ガイドの記事
・入出庫管理システム移行の完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
入出庫管理システム移行の全体像
移行の目的とゴールを先に決めておくことは、製品選定を含むすべての工程の出発点になります。目的が曖昧なまま製品を選ぶと、現場の課題が残ったまま投資が無駄になるおそれがあります。
移行が必要となるサインと判断基準
移行が必要かどうかは、まず保守の状況と処理能力を見て判断します。そのうえで、業務が特定の担当者に偏っていないか、他システムとの連携が手作業になっていないかも確認しておく必要があります。
- 保守終了：障害の復旧やセキュリティパッチへの対応に不安がある
- 処理能力の限界：出荷の増加でレスポンスが落ち、繁忙期には作業が滞る
- 属人化：過度なカスタマイズで仕様が読み解けず、扱える担当者が限られる
- 手作業の連携：ERPとの連携がCSVの手動取込になっており、二重入力や転記ミスが続く
たとえば、出荷件数が数年で2倍、3倍に増えると、旧システムの能力では処理が追いつかなくなることがあります。
移行手段の種類と特徴
移行先の形態は、カスタマイズがどれだけ必要か、費用と期間の条件はどうかで選びます。
- クラウド型（SaaS）：初期費用を抑えやすく、短期間で導入できる
- パッケージ型（オンプレミス）：業種特化型であれば、専門的な要件にも対応しやすい
- フルスクラッチ型：自社業務に100%合わせられる一方、従来は高額で期間も長くなりやすい
汎用的な業務であれば、クラウド型は数ヶ月で稼働できますが、独自の業務に細かく対応するには限界があります。
パッケージ型は、アパレルの色サイズ管理や食品の賞味期限・温度帯管理に対応しやすい形態です。
近年は、AI駆動開発によって工期とコストを30〜70%圧縮できるケースもあります。
パッケージ並みの予算で、フルフィットのスクラッチを選べる可能性も出ています。
入出庫管理システム移行の進め方・全体ステップ
現状分析と要件定義で決めた内容は、設計・開発以降の作業の前提になります。設計・開発から本番の切り替えまでは、次の順に進めます。
- 設計・開発
- データ移行
- 並行稼働
- 本番稼働
企画から本番稼働まで、移行には一般的に半年〜1年以上かかります。そのため、各工程で何を決めるか、誰が責任を持つかを明確にしておくと、プロジェクトの迷走を防げます。
企画・現状分析（As-Is/To-Be）とKPI設定
企画では、まず現行の業務を一覧にして、移行後に達成する目標を数値で定めます。
- As-Is分析：入荷・検品・格納・ピッキング・出荷・棚卸の業務と例外処理を把握する
- To-BeとKPI：在庫精度98%以上など、達成目標を数値にしておく
- 投資効果：人件費や誤出荷のクレーム対応費を数字で表す
現場への聞き取りでは、マニュアルに載っていない例外処理も洗い出しておきます。ここで漏れがあると、後になって在庫差異につながります。
KPIの例として、誤出荷率0.1%以下やピッキング生産性20%向上が挙げられます。
ROIを示しておけば、経営層の投資承認を得る材料にもなります。
要件定義とRFP作成・ベンダー選定
まず要件を優先度で分け、標準機能とカスタマイズの境界を決めます。そのうえで、整理した要件をもとにベンダーへ提案を依頼します。
- 要件の区分：Must（必須）とWant（希望）に分けて整理する
- 機能の選択：標準機能に業務を寄せ、競争力に直結する部分だけを個別に調整
- 提案の比較：価格に加えて、現場の知識や同業種の移行実績も比べる
カスタマイズを増やしすぎると、費用が膨らむうえに、保守もしにくくなります。
標準機能を活用するFit to Standardの考え方は、費用と品質のバランスを取るうえで欠かせません。
RFP（提案依頼書）には、現行の出荷件数、SKU数のほか、拠点数・連携システムを記載し、正確な見積もりを得るために複数のベンダーに提示します。
設計・開発・テストフェーズ
設計・開発では、システムの仕様が倉庫内の実際の作業に合っているかを検証します。
- 設計：ロケーションとピッキング動線を決める
- テスト：UATで正常系と例外ケースを確かめる
基本設計と詳細設計を経て、開発に進みます。あわせて設計段階で、フォークリフトの旋回半径や重量物の配置、作業員の熟練度といった現場の条件も、現地で確認します。
フリーロケーションは、シミュレーション上では最適に見えても、現場ではピッキングが遅くなることがあります。そのため、机上の設計と実態をすり合わせておく必要があります。
UAT（受入テスト）は、ベンダーの単体・結合テストに加えて、発注側が主体となって実施します。
テストでは、セット品のバラ出荷や不良品の返品も対象にして、実運用に近い条件で確かめます。
事前にこうした検証を重ねておくことが、本番後のトラブルを減らします。
データ移行を成功させる実務
システム移行の失敗のおよそ7割は、データに起因すると言われています。
移行で難しいのは、商品・取引先・ロケーションの各マスタと、変動する在庫を正確に引き継ぐことです。
マスタクレンジングの基準（12ヶ月ルール）
移行するマスタは、まず整理しておきます。何を対象から外すか、名寄せをどの基準で行うかは、次のとおり決めます。
- 移行対象：過去12ヶ月間に入出荷実績がないマスタや休止ロケーションは、原則として除外する
- データ整理：取引先名の表記ゆれや商品コードの重複を、名寄せでまとめる
未使用のマスタなどのゴミデータをそのまま移すと、検索性が落ちるうえ、誤引当の原因にもなります。
クレンジングの基準は文書にまとめ、現場と情シスが合意したうえで進めます。この整理の丁寧さが、新システムの使い勝手と品質を左右します。
在庫の時点整合性（差分移行 vs 一括移行）
移行方法は、出荷を止められるかどうかと、差分を確実に追えるかどうかで選びます。
- 一括移行：業務を一時停止して在庫を確定させ、まとめて移す
- 差分移行：抽出後に変動した在庫を反映しながら、業務を止めずに進める
抽出から新システムへの投入までの間にも、入荷や出荷で在庫は変動します。この差を見過ごすと、稼働後の在庫数が現物と合わなくなります。
一括移行は確実性が高い一方、出荷を止められる業態でなければ採用できません。差分移行は、取りこぼしを防ぐための厳密な手順が必要になります。
どちらが現実的かは、自社の出荷カレンダーを見ながら早い段階で判断します。
並行稼働（パラレルラン）の正しい進め方と終わらせ方
並行稼働（パラレルラン）は移行リスクを下げられますが、運用を誤ると、誤出荷や現場の混乱につながります。そのため、開始と終了の条件をあらかじめ設計しておきます。
指示系統の一本化ルール
二重指示による誤出荷を防ぐため、現場が使う出荷指示は一本化しておきます。
- 新システム：現場へ渡す指示書、ピッキングリスト、送り状を出力する
- 旧システム：結果照合のため、裏側で動かしておく
新旧両方から指示書や送り状が出ると、同じ商品を二重にピッキングしたり、現場が指示に迷ったりします。
現場が手に取る紙やハンディの指示は、新システムに一本化します。これにより、二重入力の工数も抑えられます。
Exit Criteriaの決め方と閑散期切替
二重運用を長引かせず安全に切り替えるには、終了条件と時期を事前に決めておく必要があります。
- 終了条件：出荷エラー率などの基準を満たした時点で、旧システムを止める
- 切替時期：年間の出荷カレンダーをもとに、閑散期を選ぶ
たとえば、出荷エラー率が0.5%未満の状態が2週間続くことや、ERPとのAPI連携が4週間安定することを、終了条件に設定できます。また、棚卸差異率も基準にできます。
並行稼働中は二重入力で工数が1.5〜2倍になります。繁忙期に切り替えると現場の負担がさらに大きくなるため、出荷が落ち着く時期を確保しておきます。
本番稼働とリスク管理
本番稼働（カットオーバー）は移行のゴールである一方、リスクが集中する場面でもあります。出荷が止まると、売上機会の損失や納期遅延につながります。
稼働後に問題が起きた場合に備えて、旧システムへ戻す判断基準と環境を事前に整えておきます。
ロールバック判断基準と権限
ロールバック（切り戻し）を遅らせないため、発動の基準と判断者を明確にしておきます。
- 判断基準：「出荷エラー率が一定値を超えた」「基幹業務が一定時間以上停止した」などの状況を、基準として定める
- 判断権限：プロジェクト責任者が、その場で判断できる状態にする
具体的な数値基準は事前に設けておき、権限委譲のルールとあわせて稼働前に文書にします。
判断権限が曖昧なままだと、現場、情シス、経営層が互いに様子を見ているうちに、被害が広がります。そのため、基準と権限は関係者で共有しておきます。
旧システム・旧端末の保持期間
切り戻しや過去データの参照に備えて、旧環境と過去データへのアクセスを保っておきます。
- 旧環境：新システムが安定するまで、端末とライセンスを保持する
- 旧ベンダー契約：DBアクセス権を失う時期を確認したうえで、解約する
稼働後すぐに旧システムやハンディ端末を処分すると、切り戻しの際に再接続できず、業務が止まるおそれがあります。
旧システムや旧端末、ライセンスの保持期間は、最低でも3ヶ月を見ておくことをおすすめします。
契約の解約を急ぐと、移行後に過去データが必要になった際、旧DBのアクセス権を失うことがあります。そのため、保持期間と解約時期は稼働状況を見ながら、段階的に判断します。
入出庫管理システム移行の費用相場と隠れコスト
システム本体の費用のほかにも、さまざまな費用がかかります。見積もりの段階で隠れコストを含めておくかどうかが、予算超過を防げるかの分かれ目になります。
形態別の費用と5年TCO
提供形態を比べるときは、初期費用だけでなく、長期の総額も確かめます。
- SaaS：初期0円、月額20万円の場合は、5年で1,200万円
- パッケージ：初期100万円、月額10万円の場合は、5年で700万円
- 保守費：オンプレミスやスクラッチでは、初期構築費の年15〜20%程度
クラウド型は初期費用を抑えやすい反面、出荷件数に応じた従量課金のため、中長期では負担が増えることがあります。
5年TCO（総保有コスト）で見ると、費用が逆転するケースも珍しくありません。そのため、初期費用だけでなく、5年〜7年のTCOで比べます。
費用の詳しい内訳は、別の記事で掘り下げて解説しています。
見積もりに出てこない隠れコスト
システム本体以外にも、データ抽出や端末、倉庫移転の費用が発生します。これらも、予算に含めておく必要があります。
- 旧ベンダーの抽出費：旧DBに直接アクセスできない契約では、テストなどのCSV抽出が1回数十万円に及ぶこともある
- ハンディ端末：1台5万〜30万円のものが、人数分必要になる
- 倉庫移転：移動手数料として、月額保管料の3〜6ヶ月分がかかる場合もある
倉庫移転では、出庫作業費や割増保管料、棚卸費なども発生します。これらを見積もりに織り込んでおくと、稟議後の追加申請を避けやすくなります。
契約時にDBアクセス権や解約条件を確かめておくことが、隠れコストを防ぐ手がかりになります。
入出庫管理システム移行でよくある失敗と回避策
よくある失敗とその対策を先に知っておくと、移行プロジェクトのリスクを下げられます。
例外処理漏れによる在庫差異
例外処理は要件定義の段階で把握し、新システムの業務フローに反映しておきます。
- 返品単位：2個1セットの商品を1個だけ返品するケースを確認する
- 破損品：物理的に隔離したうえで、論理ステータスの変更も忘れず管理する
- サンプル：無記録で持ち出されるケースの扱い
現場の例外処理が、在庫不一致の原因になることがあります。「WMSを入れれば在庫が合う」とは、必ずしも言えません。
ゴースト在庫が引当に回ると、在庫があるはずなのに出荷できず、欠品クレームにつながります。そのため、設計の段階で扱いを決めておきます。
ベンダー丸投げと現場教育不足
発注側が要件定義から稼働後まで関わることで、現場に合ったシステムを定着させられます。
- 発注側の参加：要件定義とUATに主体的に関わる
- 現場教育：研修、マニュアル、稼働後の支援を計画しておく
ベンダーに任せきりにすると、自社の業務を理解しないまま標準機能だけで構築され、現場で使えなくなるおそれがあります。
自社の業務知識は、プロジェクトに反映させます。ベンダーは技術の専門家ですが、現場を最も知っているのは発注側です。
操作に慣れていないと、稼働直後にミスが起きます。そのため、本番前のハンズオン研修とマニュアル整備に取り組みます。
稼働後しばらくは、現場にサポート要員を置いて、定着するまで見届けます。
まとめ
移行は、現状分析→要件定義→設計・開発→データ移行→並行稼働→本番稼働の順に進めます。各工程を着実に実行することが、成功の条件です。
移行実務で押さえたい要点は、データの時点整合性、並行稼働での指示一本化とExit Criteria、本番後のロールバック体制です。
費用は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を創業。