入出庫管理システムの更改は、現状分析と要件定義から始め、ベンダー選定、設計・開発、データ移行、並行稼働を経て本番稼働へ進みます。
この順序で進めると、在庫差異と出荷停止を防げます。
▼全体ガイドの記事
・入出庫管理システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
入出庫管理システム更改の全体像と更改すべきサイン
更改の動機をはっきりさせておくと、要件が膨らむことによる予算超過や納期遅れを防げます。
更改が必要になる主なサイン
更改するかどうかは、いまのシステムの保守状況と、倉庫業務の変化を見て判断します。
- 保守の限界：OSのサポート終了や担当者の退職で、保守や改修が難しくなっている状態。
- 処理能力の限界：EC化で1日数百件から数千件に増え、ピッキングリスト発行や在庫引当が数十秒遅れてしまう。
- 連携と運用の分断：手作業の連携や過度なカスタマイズが、ミスや仕様の不透明さを招いている。
サポートが終わると、セキュリティパッチが提供されないため、情報漏えいやランサムウェアのリスクが高まります。
出荷件数が急に増えたときや、店舗とEC在庫をまとめて管理したくなったときも、更改を考えるきっかけになります。
更改の選択肢と方向性の決め方
更改方式は、費用や期間の条件と、自社独自の運用をどこまで取り込むかで選びます。
- クラウド型（SaaS）：初期費用を抑えやすく、保守を任せて数ヶ月で導入できます。
- パッケージ型（オンプレミス）：自社サーバーに導入し、一定のカスタマイズを加えられます。
- フルスクラッチ型：自社の業務に100％フィットするシステムを、ゼロから構築します。
フルスクラッチは従来、半年から1年以上と数千万円規模を要しました。
AI駆動開発では、工期とコストを30〜70％圧縮できる場合があり、パッケージ並みの予算も選択肢になっています。
汎用型か業種特化型かによっても、選定の結果は変わります。たとえば、アパレルの色・サイズ、食品の賞味期限・温度帯、製造業のトレーサビリティといった項目を、標準機能で満たせるかを確認します。そのうえで、例外処理の多さと、業務をどこまでシステムに反映させるかを基準に、方向性を絞り込みます。
入出庫管理システム更改の進め方（全体ステップ）
企画から本番稼働までの6つの工程は、前の工程で固めた内容を次へ引き継ぐ順に並んでいます。この流れを順序立てて進めると、手戻りや予算超過を抑えられます。
- 現状分析と要件定義
- RFP（提案依頼書）の作成とベンダー選定
- システムの設計・開発
- データ移行
- 新旧システムの並行稼働
- カットオーバーと本番稼働
現状分析（As-Is）・要件定義（To-Be）・KPI設定
新しい要件を決める前に、今の業務がどう動いているかを正確につかんでおく必要があります。
- As-Is：入荷から出荷までの実際の流れを、検品、ピッキング、梱包などの工程ごとに書き出します。
- 例外処理：セット品のバラ出荷、不良品の隔離、サンプルの持ち出しを、現場の担当者から聞き取ります。
更改後の姿は、在庫精度99.9％以上、誤出荷率0.1％未満、ピッキング生産性20％向上の3つをKPIにして描きます。
KPIが曖昧だと、稼働後に効果があったかどうかを判断できません。
経営層を説得するときは、KPIをROI（投資対効果）に置き換えて示します。たとえば、誤出荷1件の再配送・返品対応を2,000円とすると、月100件から10件に減らせれば、年間約216万円の削減になります。この数字があれば、「なぜ今、数千万円をかけるのか」という決裁者の疑問に答えられます。
RFP作成とベンダー選定
RFP（提案依頼書）には、現状の課題と更改の目的を書き、複数社が同じ条件で提案できるようにします。
- 要件の優先度：必須要件（Must）と希望要件（Want）を分けておきます。
- 規模・連携：出荷件数や拠点数、ERP・OMSとの連携条件を書きます。
- 計画条件：想定予算と納期を示し、自社固有の要件も具体的にします。
ベンダーを選ぶときは、同業種・同規模のWMS導入実績、データ移行の支援経験、ERPやマテハン（自動倉庫・AGV）との連携経験を確認します。
旧システムからデータを引き上げられるかは、契約の前に確かめます。
設計・開発フェーズの進め方
設計では、個別の対応が本当に必要かを見極めたうえで、周辺機器との連携条件を決めます。
- 個別対応とFit to Standard：個別対応が要る業務と、標準機能で足りる業務を見分け、後者は運用を変えます。
- システム連携：ERP・OMS・TMSはAPIかCSVかを選び、応答性とコストを考慮します。
- 機器連携：自動倉庫、AGV、AMRと接続する場合は、WCS／WESとの間で、どこまでを誰が受け持つかを取り決めておきます。
現行業務をすべて再現すると開発費が膨らみ、将来のバージョンアップも難しくなります。
障害が起きたときの切り分け担当は、契約に明記しておきます。
データ移行の実務（失敗の7割はデータ）
更改の失敗は、約7割がデータに起因するといわれます。その理由は、マスタや在庫数量が不正確だと、稼働初日から差異が生じるためです。
マスタクレンジングの基準（12ヶ月ルール・名寄せ）
移行の前に、使われていない商品マスタや休止ロケーションを整理しておきます。そのまま持ち込むと、運用が複雑になるうえ、誤った引当の原因にもなります。
過去12ヶ月に入出荷実績のない商品マスタや未使用の休止ロケーションは、原則として移行の対象から外します。明確な数値の基準があれば、「念のため残す」という判断をなくし、移行するデータの量を絞り込めます。
また、同じ商品が複数のコードで登録されている場合は、名寄せして1つにまとめます。重複を解消しておくことは、稼働後の在庫精度にも関わります。
在庫の時点整合性（差分移行 vs 業務停止一括切替）
在庫を移行するときは、データを抜き出してから投入するまでに動いた在庫を反映し、時点をそろえます。
- 差分移行：初回に一括で移行したあと、切替の直前に入出荷の差分を反映します。
- 業務停止一括切替：週末や連休に入出荷を止めて在庫を確定し、そのうえで移行します。
差分移行は業務を止めずに済む一方、差分の管理が複雑です。一括切替は確実ですが、出荷を止めている間に溜まるバックオーダーを消化する計画が必要です。
どちらが現実的かは、自社の出荷量と停止できる時間を比べて、早い段階で決めます。
並行稼働（パラレルラン）の正しい進め方と終わらせ方
並行稼働とは、新旧のシステムを同時に動かして、新システムを検証する工程です。
安全を確かめるうえでは有効ですが、二重入力で現場の工数が1.5〜2倍になります。そのため、開始の方法に加えて、終了の条件も決めておく必要があります。
指示系統の一本化ルール
並行稼働の期間中も、現場へ出す物理的な指示書は新システムに一本化します。
旧システムにも検証用として並行入力し、新旧の在庫数と出荷結果は管理者が照合します。新旧の指示を作業者が取り違えると、重複ピッキングや誤出荷につながります。
Exit Criteria（終了条件）の決め方と閑散期切替
Exit Criteria（終了条件）は、数値で事前に定めておきます。
- 出荷エラー率：0.5％未満の状態を2週間維持します。
- ERP連携：API連携を4週間連続で安定して稼働させます。
- 在庫差異率：あらかじめ定めた基準値以下に収めます。
3つの条件をすべて満たした時点で、旧システムを停止します。終了の条件がないと並行稼働が長引き、二重入力で現場が疲弊します。
並行稼働と本番切替は、物流の閑散期に行います。繁忙期に行うと、二重入力で増えた工数に出荷のピークが重なり、ほぼ確実に現場が崩壊します。そのため、年末商戦やセール期を避け、出荷量が落ち着いた時期を選びます。
本番稼働とリスク管理
本番稼働後のトラブルに備えて、切り戻しの基準と旧システムの保持期間を決めておきます。
ロールバック判断基準と権限
出荷が止まるような事態を想定して、ロールバック（切り戻し）の数値基準を定めます。
- 出荷エラー：出荷の誤りの割合が、定めた基準値を超えた場合。
- 棚卸差異：実在庫とシステム上の在庫のずれの割合が、基準を上回った場合。
- 業務停止：業務が止まっている時間が、定めた時間を超えた場合。
判断する人が不在だと、初動が遅れてしまいます。そのため、プロジェクトオーナーや物流責任者など、即断できる責任者を1人定め、権限をその人に集めておきます。
旧システム・旧端末の保持期間（最低3ヶ月）
切り戻しができるように、旧システムと端末、ライセンス、旧契約の条件を確認しておきます。
- 保持期間：旧システム本体、端末、ライセンスを、最低3ヶ月は残しておきます。
- データ抽出費：旧DBに直接アクセスできない場合、データを取り出すたびに数十万円かかります。
- 撤退条件：新しいベンダーを選ぶ前に、旧契約の解約とデータの引き上げ条件を確かめます。
端末を処分してしまうと旧システムに再接続できず、切り戻しの際に業務が止まるおそれがあります。そのため、事前に撤退（Exit）戦略を立てておきます。
入出庫管理システム更改の費用相場と隠れコスト
費用は提供形態によって変わり、見積もりに出にくい隠れコストも総額を押し上げます。
形態別の費用相場と5年TCO
費用を比べるときは、提供形態による違いと、中長期でかかる総額の両方を見ます。
- クラウド型（SaaS）：初期費用を抑えられる一方、従量料金が増える場合があります。
- パッケージ・スクラッチ型：初期構築費がかかりますが、月々の費用は比較的安定しています。
- 5〜7年のTCO：0円・月20万円のSaaSは5年で1,200万円、初期100万円・月10万円のパッケージは5年で700万円になります。
「初期費用無料」のSaaSでも、中長期では従量課金が積み上がり、パッケージより割高になる逆転が起こり得ます。
発注する側は、出荷件数の増加に伴う料金上昇も含めて、目先の初期費用だけでなく、総保有コスト（TCO）を試算します。
見積もりに出てこない隠れコスト
見積もりを見るときは、機器費用や保守費用など、初期費用以外の支出も確かめます。
- ハンディ端末：1台5万〜30万円で、作業者の人数分が必要です。
- 年間保守：オンプレミスやスクラッチでは、初期構築費の15〜20％がかかります。
- 倉庫移転：移転を伴う場合は、月額保管料の3〜6ヶ月分が上乗せされます。
旧DBに直接アクセスできない場合は、データを取り出すたびに数十万円かかります。抽出費用は、見積もりの段階で必ず確かめておきます。
倉庫移転の上乗せ分には、出庫作業費と早期解約違約金、割増保管料、棚卸費などがあります。見積もりの段階で洗い出しておかないと予算が崩れるため、詳しい費用の構造は別記事も合わせて確認してください。
よくある失敗と回避策
在庫差異や体制の問題は、更改プロジェクトで繰り返し起きる失敗です。
例外処理漏れによるゴースト在庫
「WMSを入れれば在庫は自然に合う」という期待は、しばしば幻想に終わります。在庫が合わない原因は、現場で良かれと思って行われてきた例外処理にあります。
在庫差異を防ぐには、発注する側が例外処理と在庫状態の変更ルールを要件定義の段階で確かめておきます。
- セット品の返品：2個1セットのうち1個だけ戻されると、在庫の単位がずれてしまいます。
- 破損品：隔離したあともシステム上の状態を変えないと、破損した品が出荷可能な在庫として引き当てられてしまいます。
- サンプル：記録せずに持ち出すと、システム上の在庫と実在庫に差が生じます。
ゴースト在庫とは、システム上は在庫があるのに実際には出荷できない状態のことです。この状態で受注を受けると、欠品のクレームにつながります。
ベンダー丸投げと現場教育不足
更改をベンダー任せにせず、要件の整理と稼働前の現場教育は、自社が主導して進めます。
- 要件整理：現場から例外処理を聞き取り、RFPで必須要件と希望要件を具体化します。
- 操作訓練：稼働前に練習の期間を設け、入力ミスや作業の遅れを防ぎます。
- 受入テスト：自社が主体となり、イレギュラーを含めてUATで操作を確かめます。
担当者しか知らない運用が反映されないと、現場とシステムが乖離します。移行の対象はシステムだけでなく、人と業務も含みます。
まとめ
更改は、現状分析から本番稼働まで、6つの工程を順に進めることが基本です。
移行では、12ヶ月ルールによる整理と在庫の時点整合性を重視します。並行稼働では指示を一本化し、数値の終了条件を満たしてから閑散期に切り替えます。
本番稼働後は切り戻しの基準を定め、旧環境を最低3ヶ月保ちます。費用は、5年のTCOと隠れコストまで含めて比べます。
例外処理の確認と現場教育を行えば、在庫差異やベンダー任せの失敗を防ぎやすくなります。AI駆動開発も、自社に合う方式を検討する際の選択肢になります。
▼全体ガイドの記事
・入出庫管理システム更改の完全ガイド
▼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を創業。