倉庫管理システム移行の発注/外注/依頼/委託方法について

倉庫管理システム（WMS）の移行は、単なるソフトウェアの入れ替えではなく、在庫精度や出荷スピードといった物流現場の生命線を左右する一大プロジェクトです。とりわけ自社にシステム開発のリソースが乏しい場合、外部の開発会社やベンダーへの発注・外注をどう進めるかが、移行成功の8割を決めると言っても過言ではありません。発注先の選び方や契約条件の詰め方を誤ると、移行テストのたびに旧ベンダーへ数十万円を支払う羽目になったり、稼働後に在庫が合わない事態を招いたりします。

この記事では、倉庫管理システム移行を外注・委託する際の発注の進め方を、現場で本当に問題になる論点に絞って体系的に解説します。外注前に整理すべき要件の切り分け、丸投げを避けるRFP（提案依頼書）の書き方、契約・撤退時に必ず確認すべき条項、そして外注先と握るべき役割分担まで、具体的な数字と判断基準を交えてお伝えします。これから発注先の検討に入る物流部門の責任者や情シス担当の方が、後悔のない委託先選定とトラブルのない発注ができるよう、実務目線でまとめました。

▼全体ガイドの記事
・倉庫管理システム移行の完全ガイド

倉庫管理システム移行の外注・委託の全体像と発注先の選択肢

倉庫管理システムの移行を外注すると言っても、誰に何を頼むのかは選択肢が複数あります。発注先のタイプによって費用構造もリスクも大きく変わるため、まずは自社の状況に合った発注形態を理解することが第一歩です。ここでは外注の全体像と、代表的な発注先の種類を整理します。

WMS移行の発注先は、大きく分けて4つのタイプがあります。1つ目はSaaS型WMSを提供するベンダーで、月額課金で素早く導入でき、移行支援も標準メニュー化されているのが特徴です。2つ目はパッケージ型WMSを扱うベンダーで、自社サーバーや専用環境にカスタマイズしながら導入します。3つ目は要件に合わせてゼロから作るスクラッチ開発を得意とするシステム開発会社、4つ目は移行戦略の立案からベンダー選定までを支援するITコンサルティング会社です。

近年はAI駆動開発の進展により、スクラッチ開発の工期とコストが30〜70%圧縮できるケースも出てきました。これにより「パッケージ並みの予算で自社業務に100%フィットしたWMSを作る」という選択肢が現実味を帯びています。発注先を1社に絞る前に、自社の出荷件数や拠点数、マテハン連携の有無を踏まえて、どのタイプが最適かを見極めることが重要です。

外注の契約形態は、主に請負契約と準委任契約の2種類です。請負契約は成果物の完成に対して責任を負う形で、要件が固まっている移行プロジェクトに向いています。一方の準委任契約は、作業の遂行そのものに対して報酬を支払う形で、要件定義段階やAI駆動開発のように仕様を作りながら進めるプロジェクトに適しています。どちらが良いかは移行の進め方によって異なるため、契約前に発注先と認識を合わせておく必要があります。

また、WMS移行では「システム本体の開発・導入」と「データ移行支援」「現場教育」「保守運用」を分けて発注するか、一括で委託するかという判断も生じます。一括委託は窓口が一本化されて管理が楽になる反面、責任の所在が見えにくくなることがあります。分割発注はコスト最適化しやすい一方で、ベンダー間の連携不足が障害時の責任分界を曖昧にするリスクをはらみます。自社の管理リソースと合わせて、どこまでを誰に委託するかを設計しましょう。

外注前に整理すべきこと｜要件と必須・希望の切り分け

発注先にいきなり相談を持ちかける前に、自社内で整理しておくべきことがあります。ここが曖昧なまま外注すると、提案の比較ができず、結果的にベンダーの言い値で進むことになりかねません。発注の質を高めるための事前準備を解説します。

外注前にまず行うべきは、現状の倉庫業務の棚卸しです。入荷から検品、格納、ピッキング、出荷、返品までの一連の流れを、現場の例外処理も含めて可視化します。ここで特に重要なのが例外処理の洗い出しです。セット品をバラで返品するケース、破損品を物理的に隔離するだけでシステム上のステータスを変えていないケース、サンプル品を記録なしで持ち出すケースなど、現場の「良かれと思った運用」が在庫差異の温床になります。これらをAs-Is（現状）として可視化し、新システムでどう扱うか（To-Be）を整理することが、発注精度を決定づけます。

業務の棚卸しを怠ると、要件定義の段階で例外処理のヒアリングが漏れ、稼働後に「在庫が合わない」という最悪の事態を招きます。在庫精度の問題の多くは、システムの性能ではなく現場運用とシステム設計の乖離に起因します。発注前に自社で業務フローを整理しておくことが、後工程のトラブルを防ぐ最大の保険になります。

要件を整理する際は、絶対に必要なMust要件と、あれば望ましいWant要件を明確に切り分けます。この線引きが曖昧だと、すべてをカスタマイズで実現しようとして費用が膨らみ、納期も延びます。たとえば賞味期限管理やロット管理がMustであっても、画面の細かいレイアウト調整はWantに分類できる場合が多いものです。Fit to Standard（標準機能に業務を合わせる）の発想で、本当にカスタマイズが必要な部分だけを見極めることが、コスト最適化の鍵になります。

Must要件とWant要件を整理した一覧を発注先に提示できれば、各社の提案を同じ土俵で比較でき、過剰なカスタマイズ提案も見抜けます。現場からは「今のやり方をすべて再現してほしい」という声が必ず上がりますが、それをそのまま要件にすると過度なカスタマイズによる属人化を新システムでも繰り返すことになります。経営判断としてどこまでを標準に合わせるかを決め、現場への説明責任を果たす姿勢が求められます。

RFP（提案依頼書）の書き方と発注の進め方

外注で失敗する最大の原因は「丸投げ」です。RFP（提案依頼書）を適切に作成し、自社の意図を正確に伝えることで、各社から質の高い提案を引き出せます。ここではRFPの書き方と、複数社を比較しながら発注先を決めるプロセスを解説します。

RFPには、プロジェクトの背景と目的、現状業務の概要、移行のスコープ、Must/Want要件、既存システムとの連携要件、想定スケジュール、予算感、提案してほしい内容を明記します。特にWMS移行で抜けやすいのが連携要件です。ERPやOMS、TMSとのデータ連携をCSV手動取り込みで済ませているのか、API連携でリアルタイムに行いたいのかを明確にしないと、稼働後に二重入力や転記ミスが常態化します。自動倉庫やAGV、AMRといったマテハン機器がある場合は、WCS/WESとの連携が500万〜3,000万円規模の追加開発になることもあるため、現状の機器構成を必ず記載します。

RFPに自社特有の要件をどこまで書き込めるかが、提案の精度を左右します。前述した例外処理の一覧や、出荷件数・拠点数・SKU数といった定量データを添付すると、ベンダーは現実的な工数と費用を見積もれます。逆にこれらが欠けたRFPでは、各社が安全側に大きなバッファを積むため、見積もりが膨らみがちです。手間はかかりますが、RFPの作り込みが最終的なコストと品質に直結します。

発注先は最低でも3社程度から提案を取り、同じRFPに対する回答を比較します。提案書はどれも良く見えるものですが、見抜くべきは「物流ノウハウ」と「移行実務の経験」です。具体的には、過去の同業種・同規模のWMS移行実績があるか、データ移行やパラレルラン（並行稼働）をどう設計するかを質問します。在庫の時点整合性の扱いや並行稼働の終了条件まで踏み込んで語れる会社は、移行のリアルを理解しています。逆に製品機能の説明に終始する会社は、移行後の運用で苦労する可能性があります。

見積もりの安さだけで選ぶのは禁物です。初期費用無料をうたうSaaSでも、月額の従量課金が積み上がると、5〜7年のTCO（総保有コスト）でオンプレ型より割高になるケースがあります。たとえば初期0円・月20万円なら5年で1,200万円、初期100万円・月10万円なら5年で700万円と逆転します。提案を比較する際は、必ず5年単位のTCOで横並びにすることが重要です。

契約・撤退で確認すべき条項と隠れコスト対策

発注時に見落とされがちなのが、旧システムからの「撤退」に関する条項です。新システムへの移行ばかりに目が向き、旧ベンダーとの契約条件を確認しないと、移行作業のたびに想定外の出費が発生します。発注前に必ず確認すべき契約のポイントを解説します。

WMS移行で最も見えにくい隠れコストが、旧システムからのデータ抽出費用です。旧データベースへの直接アクセス権が自社になく旧ベンダーに依存している場合、移行テストやリハーサルでCSVを抽出するたびに、1回あたり数十万円のスポット費用を請求されることがあります。移行プロジェクトでは抽出を何度も繰り返すため、これが積み重なると数百万円規模の想定外コストになります。新システムの発注前に、旧ベンダーとの契約書で解約条件とデータアクセス権を必ず確認し、Exit（撤退）戦略を立てておくことが不可欠です。

倉庫の物理移転を伴う場合は、さらに注意が必要です。旧倉庫からの出庫作業費、早期解約の違約金、割増保管料、棚卸費などを合算すると、月額保管料の3〜6ヶ月分に達することもあります。これらは新システムの見積もりには一切含まれないため、別枠で予算を確保しておく必要があります。発注の検討段階で、旧システム・旧倉庫からの撤退コストを洗い出すことが、トータルでの予算超過を防ぎます。

WMS本体の費用以外にも、見積もりに表れにくいコストがあります。ハンディ端末は1台あたり5万〜30万円で、現場の作業者人数分が必要です。これに加えて倉庫内のWi-Fi環境整備や、導入支援コンサルティング費用も発生します。オンプレ型やスクラッチ開発では、年間保守費として初期構築費の15〜20%が固定で発生し続けます。これらを発注前に把握しておかないと、初期費用だけを見て判断し、ランニングコストで予算が逼迫する事態になります。

契約時には、これらの周辺費用も含めた総額を発注先に明示してもらいましょう。「システム本体は安いが周辺費用で逆転する」というケースは珍しくありません。発注の意思決定は、初期費用ではなく5年TCOで行うことが鉄則です。隠れコストを契約段階で可視化しておくことが、稼働後の「こんなはずではなかった」を防ぎます。

外注先と握るべき役割分担とリスク管理

発注して終わりではなく、外注先と自社の役割分担を明確にすることが、移行成功の分かれ目です。特にデータ移行、テスト、並行稼働、ロールバックといった重要工程で「どちらが何をやるか」を曖昧にすると、責任の押し付け合いが起きます。リスク管理の観点から握るべきポイントを解説します。

「移行失敗の7割はデータに起因する」と言われるほど、データ移行は重要工程です。マスタデータのクレンジングでは、過去12ヶ月間に入出荷実績のないマスタや休止中のロケーションは思い切って捨てる、といった具体的な基準を発注先と合意します。在庫の時点整合性も論点で、抽出から投入までの間に在庫が動くため、差分を反映する差分移行にするか、週末に業務を止めて一括移行するかを決めておく必要があります。これらの作業範囲を、どこまでベンダーが担い、どこから自社が担うのかを契約段階で握ります。

UAT（受入テスト）のシナリオ作成は、自社が主体的に関わるべき領域です。ベンダーは標準的なテストは行いますが、自社特有のイレギュラーケース、たとえばセット品のバラ返品や破損品のステータス変更といった例外処理は、現場を知る自社しかシナリオ化できません。UATで例外処理を網羅的に検証しておかないと、稼働後にゴースト在庫が引き当てられて欠品クレームを招きます。テストシナリオの作成責任を明確にし、自社が担うべき範囲を見落とさないことが重要です。

並行稼働（パラレルラン）の期間中は、新旧両方のシステムを動かすため工数が1.5〜2倍になります。ここで最大の事故が、新旧両方からピッキングリストや送り状を出力してしまう「指示系統の二重化」です。これが起きると重複ピッキングや誤出荷が連発します。現場に渡す物理的な指示書は新システムのみから出す「一本化」を鉄則とし、並行稼働の終了条件（Exit Criteria）として「エラー率0.5%未満」「API連携が4週間安定」といった数値基準を発注先と明文化しておきます。切替のタイミングは、二重入力に耐えられるよう必ず閑散期に設定します。

本番稼働後に出荷が止まるような重大障害が起きた場合の、ロールバック（切り戻し）の判断基準と権限も事前に決めておきます。どの数値（エラー率や棚卸差異率）で、誰がロールバックを判断するのかを明確にします。注意点として、切り戻しに備えて旧システムと旧ハンディ端末は最低3ヶ月は保持します。旧端末を破棄してしまうと、いざという時に旧システムへ再接続できず、業務が完全に停止してしまいます。これらの危機管理ルールを外注先と共有し、稼働後の役割分担まで握っておくことが、移行プロジェクトの安全網になります。

まとめ｜倉庫管理システム移行の発注を成功させるために

倉庫管理システム移行の発注・外注は、発注先のタイプ選びから始まり、要件の切り分け、RFPの作り込み、契約・撤退条項の確認、役割分担の明確化という一連のプロセスをいかに丁寧に進めるかで成否が決まります。丸投げを避け、自社で現状業務と例外処理を棚卸ししたうえで発注すれば、各社の提案を正しく比較でき、後悔のない委託先選定ができます。

特にWMS移行では、旧ベンダーのデータ抽出費用や倉庫移転コストといった見積もりに表れない隠れコスト、在庫の時点整合性や例外処理といったWMS特有の論点が、稼働後のトラブルに直結します。これらを発注前に把握し、外注先と役割分担やExit Criteria、ロールバック基準まで握っておくことが、移行を安全に着地させる最大のポイントです。本記事を発注先選定の実務にお役立ていただければ幸いです。

▼全体ガイドの記事
・倉庫管理システム移行の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。