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

倉庫管理システム移行の外注は、現状業務の整理、RFP(提案依頼書)による提案依頼、契約と役割分担の確認の順に進めると、移行時のトラブルを防げます。外注で失敗する大きな原因は発注先への丸投げなので、各段階で自社の意図を伝えることが欠かせません。

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

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

倉庫管理システム(WMS)の移行では、委託先のタイプによって費用構造とリスクが変わります。そのため、自社の状況に合う発注形態を選ぶことが出発点になります。

発注先の種類と特徴

WMS移行の発注先は、提供形態や支援範囲によって4タイプに分かれます。タイプごとの違いを比べると、候補を絞り込めます。

  • SaaS型WMSベンダー:月額課金で導入でき、移行の支援内容も標準化されています。
  • パッケージ型WMSベンダー:自社サーバーや専用環境に導入し、必要に応じてカスタマイズする形です。
  • システム開発会社:要件に合わせたスクラッチ開発が得意分野です。
  • ITコンサルティング会社:移行戦略の立案からベンダー選定までを担います。

また、AI駆動開発では、スクラッチ開発の工期とコストを30〜70%圧縮できるケースもあります。「パッケージ並みの予算で自社業務に100%合うWMS」を作る選択肢も出てきています。

発注先を1社に絞る前に、出荷件数、拠点数、マテハン連携の有無を確認しておきます。これらを踏まえると、自社に合うタイプが見えてきます。

委託・依頼の方法と契約形態の違い

契約形態は、請負契約と準委任契約が中心です。どちらが適するかは、要件の固まり具合や移行の進め方で異なります。

  • 請負契約:成果物の完成に責任を負い、要件が固まった移行に向いています。
  • 準委任契約:作業の遂行に対して報酬を払う形で、要件定義や仕様を作りながら進めるAI駆動開発に合います。

契約前に、委託範囲について発注先と認識を合わせます。そのうえで、システム本体とデータ移行支援、現場教育や保守運用まで、一括で委託するか分けて発注するかを決めます。

一括委託は窓口が一本化され、管理が楽になります。一方で、責任の所在が見えにくくなる場合があります。

分割発注はコストを抑えやすいものの、障害時にベンダー間の連携が足りないと、どこまでを誰が受け持つかが曖昧になる恐れがあります。自社の管理リソースを踏まえて、委託範囲と担当者を設計することが欠かせません。

ポイント

業務が標準機能で収まるかどうかが、発注先のタイプを選ぶ際の分かれ目です。標準で収まらない部分が多いほど、開発会社への相談を検討します。

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

例外処理の棚卸しとMust要件・Want要件を3枚のパネルで整理した図
必須機能と希望機能を分けると、カスタマイズの範囲を見定めやすくなります。

相談前の社内整理が曖昧だと、提案を比べられず、ベンダーの言い値で話が進む恐れがあります。だからこそ、要件と優先順位を整えてから発注することが欠かせません。

現状業務の棚卸しとAs-Is/To-Beの整理

発注前に、現状の倉庫業務を棚卸しして、入荷から返品までの流れを一覧にしておくと、後工程のトラブルを防げます。例外処理まで含めて洗い出すと、移行後の要件を具体的に決められます。

  • 返品:セット品をばらして戻すケースを、記録の対象にします。
  • 破損品:物理的に隔離しても、システム上の状態は変えていないケースがないかを確かめます。
  • サンプル品:記録せずに持ち出す運用の有無です。

こうした現場の慣行は在庫差異の原因になります。そのため、現状(As-Is)を示したうえで、新システムでの扱い(To-Be)を決めることが、発注の精度を左右します。

棚卸しが不足すると、要件定義で例外処理を聞き漏らし、稼働後に在庫が合わなくなる恐れがあります。在庫精度の問題は、現場運用と設計のずれに起因することも多くあります。

Must要件とWant要件の線引き

絶対に必要なMust要件と、あれば望ましいWant要件を分けておきます。区分が曖昧だと、カスタマイズが増えて費用と納期が膨らみます。

  • Must要件:賞味期限管理やロット管理など、業務に不可欠な機能です。
  • Want要件:画面の細かなレイアウト調整など、望ましい区分に入ることが多い項目です。

Fit to Standard(標準機能に業務を合わせる)を意識して、本当に必要な部分だけカスタマイズすれば、費用を抑えられます。要件一覧を発注先に示せば、各社の提案を同じ条件で比べられ、過剰なカスタマイズも見抜けます。

現場からは「今のやり方をすべて再現してほしい」という声が必ず上がります。しかし、現行のやり方をそのまま要件にすると、過度なカスタマイズによる属人化を繰り返しかねません。そのため、標準機能に合わせる範囲は経営判断で決め、その理由を現場に説明する姿勢が求められます。

ポイント

Must要件に入れるかで迷ったら、その機能がなくても業務が回るかを基準にします。回るものはWant要件に回すと、カスタマイズによる費用の膨らみを抑えられます。

RFP(提案依頼書)の書き方と発注の進め方

RFPに記載する目的と範囲、要件と連携、条件と依頼事項を並べたチェックリスト図
依頼条件を同じ形で示すと、各社の提案を比較しやすくなります。

外注で失敗する大きな原因は、発注先への丸投げです。RFP(提案依頼書)で意図を伝えると、比較しやすい提案を得られます。

丸投げを避けるRFPの必須項目

RFPに記載する項目をそろえると、提案を比べやすくなります。連携や費用に関わる情報も、具体的に書くことが求められます。

  • 目的と範囲:背景や狙い、現状業務、移行の範囲を記載します。
  • 要件と連携:Must/Want要件や、既存システムとの連携の仕方を盛り込みます。
  • 条件と依頼事項:想定スケジュール、予算感、提案してほしい内容を示します。

ERP、OMS、TMSとの連携は、CSVの手動取込かAPIによるリアルタイム連携かを明記しておく必要があります。曖昧なままだと、二重入力や転記ミスが常態化しかねません。

自動倉庫、AGV、AMRがある場合は、WCS/WESとの連携も記載します。追加開発が500万〜3,000万円規模になることもあるため、機器構成も伝える必要があります。例外処理の一覧と、出荷件数・拠点数・SKU数などの定量データも添付します。

こうした情報は提案の精度を左右します。不足していると、ベンダーは安全側に工数を見積もるため、費用が膨らみがちです。RFPの作成には手間がかかりますが、その作り込みが最終的なコストと品質に直結します。

複数社比較と発注先の見抜き方

同じRFPを使って3社以上から提案を取り、物流ノウハウと移行実務の経験を比べます。その実力は、3つの観点で確かめられます。

  • 移行実績:同業種・同規模でWMSを切り替えた実績を確認します。
  • 移行設計:データ移行と並行稼働の進め方を質問します。
  • 運用理解:在庫の時点整合性や並行稼働の終了条件を尋ねます。

移行条件まで具体的に説明できる会社は、移行実務を理解していると判断できます。一方で、製品機能の説明に終始する会社は、稼働後の運用で苦労する恐れがあります。

見積もりの安さだけで選ばないことも大切です。初期費用無料のSaaSでも、月額の従量課金が積み上がる場合があります。

5〜7年のTCO(総保有コスト)では、オンプレ型より割高になることもあります。たとえば、初期0円・月20万円なら5年で1,200万円、初期100万円・月10万円なら5年で700万円です。

5年で見ると、初期費用が高いほうが総額で安くなる場合もあるため、提案は5年単位のTCOをそろえて比べます。

ポイント

RFPは、ベンダーが安全側に工数を積まずに済む程度まで情報を書きます。例外処理の一覧と定量データが、その目安になります。

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

新システムへの移行に集中するほど、旧システムの契約条件を見落とすことがあります。発注前に、撤退条項も確認しておきます。

旧ベンダーのデータ引き上げ・解約条件

旧データベースへの直接アクセス権が自社にないと、データの抽出を旧ベンダーに頼ることになります。そのため、発注前に旧契約の中身を押さえておく必要があります。

  • 抽出費用:CSV抽出1回につき数十万円のスポット費用がかかる場合があります。
  • 反復コスト:移行テストやリハーサルで抽出を重ねると、数百万円規模になることがあります。
  • 撤退条件:旧契約の解約条件とデータアクセス権を確認します。

移行では抽出を複数回行うため、契約内容を踏まえてExit(撤退)戦略を立てておくことが欠かせません。

倉庫の物理移転がある場合は、出庫作業費と早期解約の違約金を見積もります。割増保管料や棚卸費も、見落とせない費用です。これらを合計すると、月額保管料の3〜6ヶ月分に達することもあります。

これらは新システムの見積もりに含まれないため、別枠で予算を確保しておく必要があります。旧システムと旧倉庫の撤退コストを洗い出しておくと、予算超過を防げます。

見積もりに出ないハードウェア・保守費用

WMS本体以外にも、端末やネットワーク、保守の費用がかかります。初期費用だけでなく運用費も含めて見積もる必要があります。

  • ハンディ端末:1台あたり5万〜30万円で、作業者数分が必要です。
  • 倉庫設備:倉庫内のWi-Fi環境整備と導入支援コンサルティング費用が発生します。
  • 年間保守費:オンプレ型やスクラッチ開発では、初期構築費の15〜20%が毎年固定でかかります。

周辺費用を把握しないまま初期費用だけで決めると、ランニングコストで予算が逼迫しかねません。そのため、発注先には費用の総額を示してもらいます。

本体価格が安くても、周辺費用を含めると逆転する場合があります。だからこそ、意思決定は初期費用ではなく5年TCOで行い、契約時に隠れコストを確かめておきます。

ポイント

旧ベンダーとの契約は、移行計画の日程を組む前に中身を把握しておくと、抽出の回数と費用を見積もりに組み込めます。解約条件を後から知ると、対応が難しくなりかねません。

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

ベンダーの標準テストと自社のUATシナリオ作成を左右に対比した図
現場固有の例外処理は、自社がシナリオ化して検証に加えます。

発注後は、自社と外注先の役割をはっきりさせます。担当が曖昧なまま進むと、責任の押し付け合いにつながります。特に、データ移行とテスト、並行稼働とロールバックは、担当を分けて決めておく必要があります。

データ移行とUATシナリオの責任分担

データ移行は重要な工程です。「移行失敗の7割はデータに起因する」と言われるため、抽出から投入までの基準と担当範囲を決めておきます。

  • マスタ整理:過去12ヶ月間に入出荷実績のないマスタを捨てる基準を決めます。
  • 休止ロケーション:使用していないロケーションを除外する基準を合意します。
  • 在庫移行:差分移行か、週末に業務を止める一括移行かを選びます。

抽出から投入までの間にも在庫は動くため、時点整合性をどう確保するかが論点になります。ベンダーと自社の作業範囲は、契約段階で合意しておきます。

ベンダーは標準テストを行いますが、自社固有の例外処理は現場を知る自社にしかシナリオ化できません。そのため、UAT(受入テスト)のシナリオ作成には、自社が主体的に関わる必要があります。

セット品のばら返品や破損品の状態変更は、シナリオで検証します。検証が不足すると、ゴースト在庫の引当や欠品クレームにつながるため、作成の責任を明確にしておきます。

並行稼働とロールバックの取り決め

並行稼働(パラレルラン)では新旧両システムを動かすため、工数が1.5〜2倍になります。そのため、二重指示を防ぐ運用と終了条件を、事前に合意しておく必要があります。

  • 指示書の出力:出力元を新システムに一本化します。
  • 終了条件:「エラー率0.5%未満」「API連携が4週間安定」を基準として明文化します。
  • 切替時期:二重入力に対応できるよう、閑散期に設定します。

新旧両方からピッキングリストや送り状を出すと、重複ピッキングや誤出荷が起きます。こうした事態を防ぐには、現場への指示書を一本化することが欠かせません。

本番稼働後に出荷が止まるような重大障害に備えて、ロールバック(切り戻し)の基準と権限を決めておきます。エラー率や棚卸差異率を基に、誰が切り戻しを判断するかを明確にします。

切り戻しに備えて、旧システムと旧ハンディ端末は最低3ヶ月保持します。旧端末を処分すると再接続できず、業務が完全に停止する恐れがあります。

危機管理ルールは外注先と共有し、稼働後の役割分担まで決めておくことが、移行を安全に進めるための備えになります。

ポイント

担当を分けるときは、障害の場面で誰が判断し、誰が動くかを基準にします。判断と実行の担当を分けて決めておくと、責任の押し付け合いを防げます。

まとめ|倉庫管理システム移行の発注で押さえる点

発注先の選び方や要件の整理、RFP、契約(撤退条項を含む)と役割分担まで丁寧に進めることが、WMS移行の成否を左右します。丸投げせず、現状業務と例外処理を棚卸しすれば、提案を比べて委託先を選べます。

旧ベンダーの抽出費や倉庫移転費、在庫の時点整合性、例外処理は見落とせない論点です。そのため、並行稼働の終了条件(Exit Criteria)やロールバック基準まで発注先と合意しておき、安全な稼働につなげます。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。