倉庫管理システム（WMS）のリプレイスは、要件の整理、RFPの作成、契約と移行の役割決定の順に進めると、発注後の認識違いや稼働後の混乱を防ぎやすくなります。
発注前の整理、RFPと発注先の選び方、契約と役割分担の順に、各段階で決めておくことを確認します。
▼全体ガイドの記事
・倉庫管理システムリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
倉庫管理システムリプレイスを外注する前の整理事項
自社内の整理が足りないまま相談すると、各社の提案を比べる基準がなくなります。「いい感じに提案してください」と任せる前に、業務の棚卸しと要件の優先順位付けを済ませておきます。
現状業務（As-Is）と課題の棚卸し
入荷から棚卸しまでの業務フローを、担当者や帳票、利用システムと合わせて一覧にします。在庫が合わない原因の多くは、現場が良かれと思って行う例外処理です。そのため、特に在庫差異につながる例外処理を、漏れなく洗い出しておくことが大切です。
- 返品単位：2個1セットの商品を1個だけ返品するケース
- 破損品：物理的に隔離しても論理ステータスが変わらず、ゴースト在庫になるケース
- サンプル持ち出し：記録せずに商品を持ち出すケース
例外処理が漏れていると、要件定義の後半や本番稼働後になって、システムで対応できないと分かりかねません。そこで、ベテラン担当者にも聞き取りを行い、マニュアルにない暗黙のルールまで確認しておきます。
Must要件とWant要件の切り分け
要件はMust（必須）とWant（あれば望ましい）に分けておきます。すべての要望を並べて伝えると、不要なカスタマイズが増えて見積もりが膨らみます。
- Must：欠けると出荷停止や法令違反につながる要件
- Want：欠けても業務効率がやや下がる程度の要件
- 標準機能の活用：独自運用を標準機能で代替できるかの見極め
食品倉庫の賞味期限・温度帯管理や、アパレルの色サイズ管理はMustの例です。一方で、自社固有と思っている運用でも、標準機能で代替できる場合があります。
特定の帳票のレイアウトは、Wantに分類できる場合が多くあります。社内で優先順位を合意しておくと、選定の場面で判断しやすくなります。また、標準機能に業務を合わせる（Fit to Standard）ことが、費用を抑える鍵になります。
RFP（提案依頼書）の書き方と丸投げを避けるコツ
RFP（Request for Proposal＝提案依頼書）は、複数社に同じ条件で提案を求める文書です。精度が低いと、見積もりに大きなバッファが乗るか、必要な要件が抜けた安い見積もりになります。
RFPに必ず盛り込む項目
RFPでは、目的と現状から評価方法まで、区分ごとに提案の前提となる条件を書き込みます。どの区分も、各社が同じ前提で見積もれるように具体的に書くことが要になります。
- 目的と現状：刷新の理由、現行システムの課題、対象業務の範囲
- 規模と要件：出荷件数、品目数、拠点数、Must／Want一覧
- 連携と計画：ERP・OMS・TMSとの連携、希望日程、予算レンジ
- 体制と保守：ベンダーに求める体制、保守内容
- 評価方法：価格、物流理解、移行支援、連携実績、撤退支援
規模の数字が示されていれば、現実的なサーバー構成やライセンス数を見積もりやすくなります。また、配布後に質疑応答の期間を設け、質問と回答を全社に共有すると、公正な比較につながります。
評価項目を点数化したシートを用意しておくと、提案を客観的に比べて発注先を選べます。
自社特有の例外処理・連携要件の伝え方
例外処理は、実際の業務の流れに沿って具体的に伝えます。たとえば、セット品をバラ単位で返品すると在庫が自動でセット在庫へ戻る運用が必要、と書きます。「在庫管理をしっかり」のような抽象的な表現は避けます。
具体例があれば、標準機能で対応できるかカスタマイズが必要かを正確に判断でき、後の要件定義も短くできます。また、ERP連携は、CSVの手動取込にするか、APIでリアルタイム連携するかによって、費用とリスクが変わります。
在庫データの反映を日次バッチにするか、リアルタイム必須にするかを明記します。可能であれば、現行の連携仕様書やデータ項目定義も添付します。これにより、二重入力や転記ミスが解消するかを発注前に見極められます。
発注先の種類と選び方
発注先の形態には、クラウド型（SaaS）やパッケージ型をSIで導入する形などがあります。近年は、AI駆動開発でスクラッチの工期とコストを圧縮できる選択肢も出てきています。進め方や費用の構造はそれぞれ異なるため、要件に合う形を見極めます。
提供形態ごとの発注の特徴
提供形態によって、初期費用や月額、導入期間が異なるうえ、業務への適合度も変わります。自社の標準化のしやすさと、5年TCO（総保有コスト）を並べて比べます。
- SaaS：初期費用を抑え、数ヶ月で稼働しやすい
- パッケージ：業種特化機能があり、導入に半年から1年程度。中堅以上の物流にも適しています
- スクラッチ：自社業務に合わせやすいが、従来は高コスト・長納期
- AI駆動開発：工期とコストを30〜70パーセント圧縮できる場合がある
標準機能に業務を合わせられる企業には、SaaSが向いています。ただし、月額従量課金は長期で割高になる場合があります。たとえば、初期0円・月20万円のSaaSは、5年で1,200万円になります。
一方、初期100万円・月10万円のパッケージは、5年で700万円となり、費用が逆転することもあります。
AI駆動開発を取り入れる会社では、パッケージ並みの予算で、業務に完全に合うシステムを作れる選択肢も生まれています。標準パッケージに収まらない例外処理が多い倉庫では、検討する価値があります。
物流ノウハウと開発力の見抜き方
提案書の体裁だけでなく、物流業務への理解と開発力を質問で確かめます。その際は、具体的な回答や経験談が出てくるかに注目します。
- 刷新実績：同規模・同業種のWMS実績
- 移行経験：過去の失敗とリカバリー
- 切替計画：繁忙期と閑散期を踏まえた設計
- 機器連携：WCS／WESとの実績と責任分界
自動倉庫やAGV・AMRとの連携には、500万円から3,000万円規模の追加開発が生じることがあります。複数社が関わる場合に備えて、障害の切り分けと一次窓口を明確にできる会社を選びます。
契約・撤退で確認すべき条項と隠れコスト対策
WMSの発注では、見積もりに出にくい隠れコストが生じます。そのため、新ベンダーとの条件に加えて、旧システムからの撤退条件も発注前に確認します。
旧DBアクセス権とデータ引き上げ費用
旧ベンダーとの契約にDBアクセス権がないと、移行テストやリハーサルでCSVを抽出するたびに、1回数十万円のスポット費用がかかります。リハーサルは複数回必要になるため、その費用が積み重なっていきます。
新システムを発注する前に、旧ベンダーとの解約条件と、データ引き上げの可否・費用を確認します。関係が良好でない旧ベンダーの場合は、データを引き出せなくなるおそれもあるため、そのリスクにも備えます。
理想は、現行の契約中にデータの所有権が自社にあることと、解約時に標準形式で受け取れることを、書面で確認しておくことです。RFPでも、撤退時のデータ引き上げ支援を評価の対象にします。
解約条件と5年TCOの確認
新システムの契約では、初期費用や月額に加えて、解約の条件と年間保守費の算定方法を確認します。解約の条件には、解約予告期間と中途解約の違約金が含まれます。
- 保守費：オンプレやスクラッチは初期構築費の年15〜20パーセント程度
- 端末費：ハンディ端末は1台5万円から30万円程度
- 移転費：出庫作業費、早期解約違約金、割増保管料、棚卸費
5年分の保守料を見込んでおき、端末の台数は必要な人数分で計画します。倉庫移転も同時に行う場合は、移転関連費が月額保管料の3〜6ヶ月分に達することがあります。
隠れコストを発注段階で洗い出し、5年間の総保有コストで比べれば、「初期費用無料」という見かけの安さに惑わされにくくなります。
外注先と取り決める役割分担とリスク管理
外注する場合でも開発を丸投げせず、データ移行からユーザー受け入れテスト（UAT）、並行稼働、本番切替までの責任範囲を契約時に決めておきます。分担が曖昧だと、問題の際に責任の押し付け合いが起き、復旧遅れにもつながります。
データ移行・UAT・並行稼働の責任の分け方
WMS刷新の失敗の約7割はデータに起因すると言われています。このため、各工程の担当と判断基準を発注前に明確にしておきます。
- データ移行：クレンジング基準は発注側が決め、変換ロジックの設計はベンダーが担う
- 移行対象：実績のないマスタや休止ロケーションを捨てる「12ヶ月ルール」は、発注側が主体となって判断する
- 在庫整合性：差分反映か週末一括切替かの方式と、計画責任者の合意
- UATと並行稼働：例外シナリオは発注側が用意し、ベンダー任せにしない。並行稼働は工数が1.5〜2倍になるため、期間と体制を先に決めておく
- 指示系統：新旧両方から指示書を出すと誤出荷につながるため、指示書は新システムからだけ出す
ロールバック判断とExit Criteriaの取り決め
出荷停止などに備えて、ロールバック（旧システムへの切り戻し）の基準値と判断責任者を、発注時に決めておきます。出荷エラー率や棚卸差異率が基準を超えたとき、現場が迷わず動けるようにするためです。
- 旧環境の保持：旧システムと旧ハンディ端末を本番後も最低3ヶ月保管
- 終了基準：出荷エラー率0.5パーセント未満で安定
- 連携確認：ERPなどとのAPI連携が4週間問題なく稼働
- 切替時期：出荷件数が落ち着く閑散期に設定
旧端末を処分してしまうと、切り戻しの際に旧システムへ再接続できず、業務が止まるおそれがあります。並行稼働の終了条件（Exit Criteria）は外注先と合意したうえで、誰が見ても判断できる基準にしておきます。終了条件が曖昧なままだと、二重運用が長引いて現場が疲弊します。
まとめ
倉庫管理システムの発注は、現状業務と例外処理を洗い出し、MustとWantを分けるところから始まります。そのうえで、業務シナリオを含むRFPを作り、物流知識と開発力を質問で確かめます。
契約では、旧DBやデータ引き上げの費用、保守費、倉庫移転の費用を含めた5年TCOで比べます。移行から切替までの責任分担と終了基準も、外注先と明文化しておきます。これにより、自社に合うWMSへの刷新につなげられます。
▼全体ガイドの記事
・倉庫管理システムリプレイスの完全ガイド
▼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を創業。