倉庫管理システム刷新は、社内要件の整理、発注先の選定とRFP（提案依頼書）の作成、契約と移行の役割分担という順に進めます。この順番で進めれば、予期せぬ出費や現場の事故を防げます。
▼全体ガイドの記事
・倉庫管理システム刷新の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
倉庫管理システム刷新の発注前の社内整理
社内の整理より先にベンダーへ相談すると、提案内容に振り回されることがあります。そこで、自社が何を、なぜ、どこまで変えたいのかを、先に言葉にしておきましょう。
現行システムの課題と刷新ゴールの言語化
まずは、現行WMSのどこが限界を迎えているかを、事実として洗い出しておきます。「使いにくい」と漠然と伝えると、外注先は本質的な課題をつかみにくくなります。
- 保守の限界：サポート終了（EOL/EOSL）が迫っている
- 属人化：過度なカスタマイズで、特定の担当者しか改修できない
- 処理能力：EC化で出荷件数が数年前の2倍以上に膨らみ、処理が追いつかない
刷新後のゴールは、KPIで定義しておきます。たとえば、在庫精度を98%から99.9%へ、誤出荷率を0.3%以下へ、月次棚卸の工数を半減するといった目標の例があります。
目標が曖昧だと、ベンダーは無難な標準機能を並べがちです。一方で、ROIに直結するゴールがあれば、各社の提案を客観的に比べられます。さらに、経営層に数千万円の投資を承認してもらう際も、定量目標が投資対効果の説明に役立ちます。
Must要件と希望要件の切り分け
要望をすべて個別開発にすると、費用と納期が跳ね上がります。そのため、見積もりが膨らむ前に、要件へ優先順位をつけておきます。
- Must：業務が止まる必須要件
- Want：あれば便利な希望要件
- Nice to have：将来の検討事項
業種固有の例外処理は、Must要件に正しく置く必要があります。たとえば、アパレルでは色・サイズ別の管理、食品では賞味期限と温度帯の管理が該当します。ロット管理が必要な製造業もあり、こうした要件は標準機能でカバーできないことが多いため、事前に確かめておきます。
汎用的な入出庫管理は、標準に合わせる「Fit to Standard」の発想が有効です。カスタマイズを抑えられるぶん、保守性も高めやすくなります。
この分類を発注前に済ませておくことが、適正な見積もりを引き出す前提になります。
発注・外注先の種類と選び方
発注先には、SaaSベンダーやパッケージ会社、スクラッチ開発会社のほか、コンサルティング会社などがあります。得意分野や契約形態は会社ごとに異なります。そのため、自社の課題に合わない相手を選ぶと、ミスマッチが起きます。
SaaS・パッケージ・スクラッチ・AI駆動開発の発注先タイプ
倉庫の業務と要件を照らし合わせると、提供形態ごとの向き不向きを判断できます。
- クラウド型（SaaS）：初期費用を抑え、数ヶ月で稼働しやすい
- パッケージ型（オンプレ）：業種特化の機能を持つ製品がある
- フルスクラッチ型：自社業務に合わせて構築できる
- AI駆動開発：AIを開発工程に取り入れるスクラッチ開発
SaaSは標準業務に近い倉庫に向きますが、自社特有の要件には柔軟に対応しにくい面があります。オンプレ製品は業種特化の機能が充実しています。ただし、カスタマイズが増えるとブラックボックス化しやすくなります。
フルスクラッチは従来、半年から1年以上の期間と高額な費用が壁でした。一方で、AI駆動開発では工期とコストを30〜70%圧縮できるケースがあります。このため、「スクラッチは高い」という二項対立は崩れつつあります。
さらに、パッケージ並みの予算で自社に100%フィットする可能性もあるため、発注先の比較対象に加える価値があります。
物流ノウハウと開発力の見抜き方
提案書の文面だけでは、各社の実力に差がつきにくいことがあります。そこで、移行実務や周辺連携の経験を、実際に手がけた案件の中身に沿って質問します。
- 移行実績：同規模・同業種の刷新件数
- 並行稼働：設計、発生したトラブル、収束方法
- 連携経験：マテハン（自動倉庫・AGV・AMR）やERP・OMSとの接続実績
- 責任範囲：障害時に、どこまでを誰が受け持つかの説明
倉庫管理システムは単体で完結せず、周辺システムとの連携で価値が出ます。ただし、WCS/WESとの連携は、追加開発が500万円から3,000万円規模になることもあります。
複数ベンダーが関わると、トラブル時の役割の境目が曖昧になりがちです。そこで、実例を具体的に語れるかどうかが、開発力を見極める判断材料になります。
失敗しないRFP（提案依頼書）の書き方
RFP（提案依頼書）は、外注を成功させるための設計図です。精度が低いと各社の提案がばらつき、横並びで比べられなくなります。
丁寧に書かれたRFPは、ベンダーの本気度と理解度を引き出すフィルターにもなります。
丸投げを避けるための記載項目
提案と見積もりの前提をそろえるために、RFPには次の情報を網羅して書き込みます。
- 背景と範囲：プロジェクトの背景・目的、現状業務と課題、対象業務
- 目標と計画：刷新後のKPI、想定スケジュール、予算レンジ
- 評価と連携：評価基準、連携対象システム、移行責任の考え方
- 定量データ：出荷件数、SKU数、拠点数、ピーク時の処理量
定量データがないと、ベンダーは見積もりの前提を置けません。その状態で発注すると、後から「想定外」として追加費用を請求される余地が残ります。
評価基準は、重み付きで事前に開示すると公平に比べられます。たとえば、移行実績には40%、機能適合度には30%の配点を置きます。残りの20%はサポート体制、10%は価格に振り分けます。
移行責任や連携対象を質問項目に含めておくと、丸投げ体質のベンダーを見分けられます。
自社特有の例外処理・連携要件の伝え方
現場の例外処理がシステムに反映されないと、WMS刷新後に在庫差異が起きることがあります。特に、数量の単位や在庫の状態の扱いは、現場の慣習のまま運用されがちです。
- 単位の食い違い：2個1セットの商品が1個だけ返品される
- ゴースト在庫：破損品を隔離しても論理ステータスを変え忘れる
- 無記録の持ち出し：サンプルを記録せずに持ち出す
例外をRFPで漏れなく伝えないと、稼働後の在庫差異が大きくなるおそれがあります。そのため、現場だけが知る例外オペレーションを洗い出し、付録にまとめておきます。
連携要件には、ERPやOMSとの接続方式を書きます。リアルタイムAPIかCSVバッチかに加えて、頻度とタイミングも具体的に決めておきます。曖昧なまま発注すると、稼働直前にリアルタイム連携が追加開発だと判明し、予算と納期が崩れることがあります。
契約・撤退で確認すべき条項（隠れコスト対策）
新システムの条件に加えて、旧システムからの撤退（Exit）条項も発注前に確認しておきます。見積書に出ない隠れコストが潜んでおり、予期せぬ出費が数百万円単位になることもあります。
旧DBアクセス権とデータ引き上げ費用
旧DBに直接アクセスできない場合、移行テストやリハーサルで抽出するたびに、旧ベンダーへ1回数十万円の費用が発生することがあります。この費用は見積書に現れにくいため、契約の段階で、旧DBへの権限と抽出の料金を先に確かめておきます。
- アクセス権：旧DBに直接アクセスできるか
- 抽出費用：データ抽出が1回数十万円のスポット費用か
- 契約条件：解約条件とデータポータビリティの条項
- 持ち出し権：将来、自社でデータを自由に持ち出せるか
移行はテストやリハーサルを繰り返すため、抽出のたびに費用がかさみます。総額が数百万円になることも珍しくありません。
発注側は、旧契約を読み返して、解約条件とデータ引き上げ条項を確認しておきます。新しい契約でも、Exit戦略を最初に定めておけば、ロックインによる将来の高額請求を避けやすくなります。
解約条件・保守費・5年TCOの確認
初期費用だけで比べると、長期の負担を見誤るおそれがあります。そこで、契約期間中の支出と撤退費用も含めて比べます。
- 5年TCO：初期費用と月額費用を合算して比較する
- 端末費：ハンディ端末は1台5万円から30万円
- 年間保守費：オンプレやスクラッチは初期構築費の15〜20%が固定的に発生
- 倉庫移転費：月額の3〜6ヶ月分が上乗せされる場合がある
初期費用が無料のSaaSでも、従量課金が積み上がると中長期では割高になることがあります。たとえば、初期0円で月20万円のSaaSは5年で1,200万円です。一方、初期100万円で月10万円のパッケージは5年で700万円となります。
この例では、5年間の総保有コストで金額が逆転しています。そのため、判断の際は必ず5〜7年の期間で比べます。
倉庫移転と刷新を同時に行う場合は、旧倉庫の出庫作業費や早期解約違約金がかかることがあります。ほかにも、割増保管料や棚卸費が発生する場合があります。こうした隠れコストを契約段階で洗い出し、見積もりに含めておくと、予算超過の防止につながります。
外注先との役割分担と進め方
外注は、発注側とベンダーが分担して進める協業です。担当範囲を契約段階で明確にしておかないと、移行時に責任の押し付け合いが起きます。
データ移行とUATシナリオの責任分担
データ移行と受け入れテスト（UAT）では、業務上の判断と手を動かす作業が混ざると、誰が決めるのかが曖昧になり、作業が止まることがあります。そこで、判断を担う側と作業を担う側を分けて合意しておきます。
- 自社：マスタのクレンジング基準の設定
- ベンダー：データ抽出・変換・投入のツールの開発
- ベンダー：テスト環境とテストデータの準備
- 自社主体：例外を含むシナリオの作成と実行判定
WMS刷新の失敗の約7割はデータに起因すると言われます。自社でしか判断できないデータが多いためです。たとえば、過去12ヶ月に入出荷実績のないマスタや休止ロケーションを捨てる「12ヶ月ルール」では、その線引きを業務に詳しい自社が担います。
在庫の時点を合わせる方法も、事前に決めておきます。差分移行にするか、週末に業務を止めて一括移行にするかを、責任者を含めて合意します。
セット出荷やバラ返品、不良品のステータス変更も、シナリオに含めます。現場の例外をどこまで網羅できるかが、稼働後の在庫差異を防ぐ分かれ目になります。
並行稼働とロールバックの責任範囲
並行稼働と切り戻しでは、出荷指示の管理者、終了条件、判断権限を事前に決めておく必要があります。
- 指示の一本化：物理指示書は新システムだけから出す
- 終了条件：エラー率やAPI連携の安定期間を明文化する
- 切り戻し：旧システムへ戻す数値基準と権限を決める
- 旧環境の保持：旧端末とライセンスを最低3ヶ月保つ
新旧両方からピッキングリストや送り状が出ると、重複ピッキングや誤出荷が起きます。そこで、指示の一本化を担う管理者を、外注先と合わせて決めておきます。
並行稼働は二重入力になるため、工数が1.5〜2倍に膨らみます。終了条件（Exit Criteria）は、エラー率0.5%未満やAPI連携の4週間安定などの数値で定めておきます。
棚卸差異率や出荷エラー率がどの水準を超えたら、誰の判断で旧システムに戻すかを決めておきます。また、旧ハンディ端末を早く破棄すると、旧システムに再接続できず切り戻せないことがあります。
発注後によくある失敗と回避策
発注先を慎重に選び、契約を整えても、進め方を誤れば刷新は失敗します。そこで、発注後に起きやすいリスクを事前に把握し、対策を進めておきます。
例外処理ヒアリング漏れと在庫差異
WMSを導入するだけで在庫が合うとは限りません。在庫を合わせるには、例外処理をシステムに反映させることが欠かせず、反映されなければ稼働後に在庫差異が起きます。
- 例外の聞き取り：現場担当者を要件定義に同席させる
- 在庫状態：物理隔離と論理ステータスを一致させる
- ロケーション設計：現場の作業条件も設計に反映する
破損品を隔離しても論理ステータスを変えないと、引当可能なゴースト在庫が残ります。その結果、欠品クレームにつながります。
管理者と現場担当者では、運用の認識が異なる場合があります。そのため、ベンダー任せにせず、発注側が実務を担う現場の担当者から例外を聞き取ります。
ロケーション設計では、フォークの旋回半径や重量物の配置、作業者の熟練度も考慮に入れます。シミュレーション上で最適に見えても、現場条件を無視すると、ピッキング速度がかえって落ちることがあります。
繁忙期切替・現場教育不足
切替の時期と現場教育を計画に含めておくと、稼働時の混乱を抑えやすくなります。
- 切替時期：物流現場の閑散期に合わせる
- 教育：マニュアルと操作研修を用意する
- 初期支援：稼働初期の現場常駐サポートを確認する
並行稼働は二重入力で工数が1.5〜2倍になります。さらに、繁忙期に切り替えると現場が処理しきれず、出荷が滞るおそれがあります。
そこで、発注側は外注先の予定を物流現場のカレンダーに合わせ、切替を閑散期に設定します。ベンダー都合の納期に引きずられないよう、発注時に共有しておきます。
現場がシステムを使いこなせなければ、導入の効果は生まれません。だからこそ、教育内容がベンダーの提供範囲に含まれるかを確認しておきます。教育を軽視すると、稼働直後に問い合わせが殺到し、旧来のやり方に戻ることもあります。
まとめ
倉庫管理システム刷新では、発注前の社内整理、契約・撤退条件、外注先との役割分担が成功を左右します。まず、現行課題と刷新ゴールをKPIにし、Must要件とWant要件を分けて、比較できるRFPを作ります。
契約では、旧DBへのアクセス権、データ抽出費、5年TCO、旧端末を最低3ヶ月保つ条件を確認します。外注先とは、データ移行、UAT、並行稼働、ロールバックの担当範囲を書面で決め、切替時期は閑散期に合わせます。
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を創業。