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