倉庫管理システム（WMS）の改修は、単に古くなった仕組みを新しくするだけの作業ではありません。出荷件数の増加やEC化、ERPとの連携分断、過度なカスタマイズによる属人化など、現場が抱える課題を解きほぐしながら進める必要があり、その多くを外部の開発会社へ発注・外注して進めるのが一般的です。ところが「どこに」「何を」「どこまで」依頼すればよいのかが曖昧なまま発注してしまい、要件の食い違いや追加費用、現場の混乱に直面する企業は少なくありません。
この記事では、倉庫管理システム改修を外注・委託する際の進め方を、発注前の要件整理からRFP（提案依頼書）の書き方、契約・撤退時に確認すべき条項、外注先との役割分担、よくある失敗の回避策まで体系的に解説します。とくにWMS特有の「在庫」や「データ移行」「並行稼働」の論点は、汎用的なシステム刷新とは異なる注意点が多く存在します。読み終えるころには、発注先に何を伝え、どこで主導権を握るべきかが具体的にイメージできるはずです。
▼全体ガイドの記事
・倉庫管理システム改修の完全ガイド
倉庫管理システム改修を外注する前に整理すべきこと
発注で失敗する企業の多くは、社内の整理が不十分なまま外注先に相談を持ちかけています。「何を解決したいのか」が曖昧だと、提案を受けても良し悪しを判断できず、結果としてベンダー任せの丸投げになりがちです。発注前にやるべきは、改修の目的の明確化と、要件の優先順位付けの2点に尽きます。
改修の目的とゴールを数値で定義する
最初にやるべきは、改修によって何をどこまで良くしたいのかを数値で定義することです。たとえば「誤出荷率を現状の0.3%から0.05%以下に下げたい」「出荷キャパシティを1日3,000件から6,000件へ倍増させたい」「ERPへの在庫データ反映を翌朝バッチからリアルタイムにしたい」といった形です。目的が数値化されていれば、外注先からの提案がその目標を達成できるかどうかで評価でき、不要な機能に予算を割く事態を避けられます。
逆に「現場が使いにくいから新しくしたい」といった漠然とした動機のまま発注すると、ベンダーは安全策として汎用的な提案を出すしかなく、自社の課題に刺さらない高額な見積もりが返ってくることになります。経営層への予算説明の場面でも、ROI（投資対効果）を語るには数値目標が不可欠です。改修にかける数千万円を正当化するためにも、まずは定量的なゴール設定から着手しましょう。
必須要件（Must）と希望要件（Want）を切り分ける
次に取り組むべきは、機能要件を「絶対に外せない必須要件」と「あれば望ましい希望要件」に切り分ける作業です。現場からヒアリングすると要望はいくらでも出てきますが、すべてをスクラッチで作り込めば費用も期間も膨らみます。賞味期限・温度帯管理（食品）や色・サイズの在庫管理（アパレル）のような業種特有の必須要件は妥協できませんが、画面の細かな操作性などは標準機能で代替できることも多いものです。
この切り分けが甘いと、本来パッケージの標準機能（Fit to Standard）で済む部分まで個別開発の対象になり、見積もりが当初想定の1.5倍に膨らむケースが頻発します。要件を一覧化し、各項目に「Must／Want」のラベルを付けたうえで外注先に渡すだけでも、提案の精度と見積もりの妥当性は大きく変わります。発注前のこの一手間が、後の追加費用を抑える最大の防御策になります。
発注・外注先の種類と選び方
発注先を選ぶ前に、改修の実現方式そのものを理解しておく必要があります。提供形態によって発注先の性質も契約形態も大きく異なるため、自社の要件に合った方式を選んだうえで、その方式を得意とするパートナーを探すのが正しい順序です。
SaaS・パッケージ・スクラッチ・AI駆動開発の選択肢
WMSの改修方式は大きく4つに分かれます。クラウド型（SaaS）は初期費用を抑えて数ヶ月で導入できる一方、自社業務を標準機能に合わせる必要があります。パッケージ型（オンプレ）は業種特化型を選べばフィット率が高い反面、半年から1年以上の期間と相応の初期投資が必要です。フルスクラッチ型は100%自社業務に合わせられますが、従来は最も高額で長期になる選択肢でした。
近年はここにAI駆動開発という選択肢が加わりました。生成AIを活用した開発手法では、スクラッチ開発の工期とコストを30〜70%圧縮できるケースが報告されており、「パッケージか、スクラッチか」という従来の二項対立が崩れつつあります。パッケージ並みの予算で自社に100%フィットしたシステムを構築できる可能性があるため、発注先を検討する際は、こうした最新の開発手法に対応できる会社かどうかも判断材料に加えるとよいでしょう。riplaのようにコンサルティングから開発まで一気通貫で支援できる会社であれば、方式選定の段階から相談できます。
物流ノウハウと開発力をどう見抜くか
提案書はどの会社のものも一見すると魅力的に映りますが、WMS改修で本当に問われるのは「物流現場のノウハウ」と「技術的な開発力」の両輪です。技術力だけが高くても、フォークリフトの旋回半径や繁忙期の作業導線といった現場のリアルを理解していなければ、シミュレーション上は最適でも現場で使えないロケーション設計になってしまいます。逆に物流に詳しくてもシステム連携の技術が弱ければ、ERPやマテハン機器との接続でつまずきます。
見抜くコツは、自社と同規模・同業種の倉庫での改修実績を具体的に質問することです。「出荷件数がどれくらいの倉庫で」「どんな例外処理に対応したか」「データ移行で何件のマスタを扱ったか」を尋ね、抽象論ではなく具体的な数字とエピソードで答えられるかを確認します。発注先の選び方は重要な論点が多いため、別記事で詳しく整理しています。
▶ 詳細はこちら：倉庫管理システム改修でおすすめの開発会社6選と選び方
丸投げを避けるRFP（提案依頼書）の書き方
RFP（提案依頼書）は、外注先に自社の要件を正確に伝え、各社の提案を同じ土俵で比較するための土台となる文書です。RFPの完成度が低いと、各社がバラバラの前提で見積もりを出すため比較できず、結果として価格だけで選んでしまう失敗につながります。丸投げを避けるには、何を委託し、何を自社で担うのかを明文化することが欠かせません。
RFPに必ず盛り込むべき項目
RFPには、改修の背景と目的、現状システムの課題、対象業務の範囲、必須要件と希望要件の一覧、想定する予算とスケジュール、評価基準を盛り込みます。とくに重要なのが、現行の業務量を具体的な数字で示すことです。1日あたりの出荷件数、SKU数、ロケーション数、拠点数、ERP・OMS・TMSなど連携対象システムの一覧を提示すれば、ベンダーは精度の高い見積もりを出せます。
あわせて、評価基準を事前に明記しておくと選定の透明性が高まります。価格・実績・技術力・サポート体制・移行支援の手厚さなどに重み付けをしておけば、社内の合意形成もスムーズになり、後から「なぜこの会社に決めたのか」を説明できます。RFPは外注先のためだけでなく、自社の意思決定の拠り所としても機能します。
自社特有の例外処理・連携要件の伝え方
WMS改修で見積もり後のトラブルが最も起きやすいのが、例外処理の伝達漏れです。2個1セットで出荷した商品が1個だけ返品される、破損品を物理的に隔離したのにシステム上のステータスを変えていない、サンプル品を記録せず持ち出すといった現場の「良かれ」の例外処理は、在庫差異やゴースト在庫の温床になります。これらをRFPの段階で洗い出して伝えておかないと、要件定義のやり直しで追加費用が発生します。
連携要件も具体的に記載すべき項目です。ERPとの在庫データ連携を「リアルタイムなのか日次バッチなのか」「API連携かCSV連携か」まで明示し、自動倉庫やAGV・AMRといったマテハン機器（WCS/WES）との接続が必要なら、その機種名と連携方式も伝えます。マテハン連携は500万〜3,000万円規模の追加開発になることもあるため、後出しにすると予算計画が根本から崩れます。例外処理と連携要件は、現場担当者へのヒアリングを通じて漏れなく言語化しておきましょう。
契約・撤退で確認すべき条項
発注時に見落とされがちなのが、新システムへの「入口」だけでなく、旧システムからの「出口」に関する条項です。倉庫管理システムは長く使う基幹システムだからこそ、将来また乗り換える日が来ます。契約段階で撤退時の条件を確認しておかないと、想定外の隠れコストに苦しめられることになります。
旧DBアクセス権とデータ引き上げ費用
今回改修する新システムでもっとも注意したいのが、データベースへの直接アクセス権を自社が持てるかどうかです。旧システムでこの権利が自社になく、データ抽出をベンダーに依頼する契約だったために、移行テストやリハーサルでCSVを抽出するたびに1回数十万円のスポット費用を請求されるケースが実際にあります。改修プロジェクトでは何度もデータを抽出するため、こうした費用は積み重なると数百万円規模に達します。
新たに発注する際は、自社データへのアクセス権、契約終了時のデータエクスポート方法とその費用、データ形式（標準的なCSVやSQLダンプか、独自フォーマットか）を契約書に明記してもらいましょう。「データは自社の資産であり、いつでも標準形式で引き上げられる」という条項を入れておくことが、将来のExit戦略の生命線になります。発注前のこの確認を怠ると、次の刷新時にベンダーロックインで身動きが取れなくなります。
解約条件と保守・SLAの取り決め
解約条件の確認も欠かせません。SaaSの最低利用期間や、オンプレ・スクラッチの早期解約違約金の有無を発注前にチェックします。あわせて見落としやすいのが保守費用です。オンプレやスクラッチでは年間保守費が初期構築費の15〜20%程度かかるのが一般的で、5年使えば構築費とほぼ同額の保守費が発生する計算になります。月額制のSaaSも、従量課金が積み上がると中長期ではオンプレより割高になることがあるため、5〜7年のTCO（総保有コスト）で比較する視点が重要です。
運用フェーズの品質を担保するSLA（サービス品質保証）も契約に盛り込みましょう。障害発生時の一次対応時間、復旧目標時間、サポート窓口の対応時間帯、年間のシステム稼働率の保証値などを具体的な数値で取り決めておけば、稼働後に「連絡してもなかなか対応してもらえない」というトラブルを防げます。倉庫は止まると出荷が止まる現場ですから、SLAの数値は事業の継続性に直結します。
外注先と握るべき役割分担と進行管理
外注は「丸投げ」ではありません。発注側にしかできない作業が必ず存在し、その役割分担を曖昧にしたままプロジェクトを始めると、責任の押し付け合いで進行が停滞します。とくにデータ移行・テスト・並行稼働のフェーズでは、誰が何をどこまで担うのかを契約段階で明確に握っておくことが成功の分かれ目になります。
データ移行・UATシナリオの責任分担
WMS刷新の失敗の約7割はデータに起因すると言われます。マスタデータのクレンジングや名寄せは、現場業務を知る発注側でなければ判断できない部分が多く、「過去12ヶ月間に入出荷実績のないマスタや休止ロケーションは廃棄する」といった12ヶ月ルールの基準づくりは自社主導で行うのが現実的です。一方でデータの変換・投入ツールの開発はベンダーの担当です。どちらがクレンジングの判断をし、どちらが技術的な移行作業を担うのかを線引きしておきましょう。
UAT（受入テスト）のシナリオ作成も発注側の重要な役割です。ベンダーが用意するテストは正常系が中心になりがちで、前述の例外処理やイレギュラーな業務パターンは、現場を知る自社でなければ網羅できません。セット品のバラ返品、破損品処理、急な出荷指示の変更など、実際に起こりうるシナリオを自社で洗い出し、それを使って受入テストを行う体制を整えることが、稼働後のトラブルを未然に防ぎます。
並行稼働とロールバックの責任境界
新旧システムを並行稼働させる期間は、二重入力で現場の工数が1.5〜2倍に膨らみます。最大の事故は、新旧両方から出荷指示書やピッキングリストを出力してしまう「指示系統の二重化」で、これが起きると重複ピッキングや誤出荷が連発します。物理的な指示書は新システムのみから出力すると一本化のルールを決め、それを発注側と外注先の双方で徹底することが鉄則です。
あわせて、並行稼働をいつ終わらせるかのExit Criteria（終了条件）と、トラブル時のロールバック判断基準を事前に握っておきます。「エラー率0.5%未満」「API連携が4週間安定稼働」といった終了条件を数値で定め、「棚卸差異率が一定を超えたら旧システムへ切り戻す」というロールバック基準とその判断権限者を明確にします。判断のたびに合議していては出荷が止まるため、誰がどの数値を見て即断するのかまで決めておくことが、現場崩壊を防ぎます。
発注でよくある失敗と回避策
倉庫管理システムの改修プロジェクトには、発注の段階で踏みやすい典型的な落とし穴があります。多くは事前に知っていれば避けられるものばかりです。ここでは代表的な失敗パターンと、その回避策を整理します。
ベンダー丸投げと現場ヒアリング不足
最も多い失敗が、要件整理を外注先に任せきりにする「丸投げ」です。ベンダーは現場の暗黙のルールまでは把握できないため、ヒアリングが不十分だと例外処理が抜け落ち、稼働後に在庫が合わなくなります。回避策は、発注側にプロジェクトの主導権を持つ専任担当者を置き、現場のキーパーソンを巻き込んだヒアリングを発注前から行うことです。現場が「自分たちのシステム」と感じられるかどうかが、稼働後の定着を左右します。
現場教育の不足も見過ごせません。新システムは操作方法が変わるため、稼働直前に慌てて研修しても定着しません。発注時の契約に、操作マニュアルの整備や現場向けトレーニングの実施を業務範囲として含めてもらい、稼働前に十分な習熟期間を確保する計画を立てておきましょう。
繁忙期切替と隠れコストの見落とし
切替のタイミングを誤る失敗も深刻です。出荷が集中する繁忙期にシステム切替や並行稼働を重ねると、ただでさえ忙しい現場が二重入力でパンクし、出荷遅延やミスが多発します。並行稼働と本番切替は必ず閑散期に設定するのが鉄則で、物流現場のカレンダーを踏まえてスケジュールを組むことが、現場崩壊を防ぐ最大の保険になります。
隠れコストの見落としも要注意です。ハンディ端末は1台5万〜30万円かかり、台数分の購入費が必要になります。WMS刷新と倉庫移転を同時に進める場合は、旧倉庫からの出庫作業費・割増保管料・棚卸費などで月額保管料の3〜6ヶ月分に相当する移動手数料が発生することもあります。さらに、切り戻しに備えて旧システムや旧端末は新稼働後も最低3ヶ月は保持すべきで、これを早々に破棄すると緊急時に業務が止まります。費用に関する詳細は、見積相場の記事もあわせて確認してください。
▶ 詳細はこちら：倉庫管理システム改修の見積相場・費用
まとめ
倉庫管理システム改修の発注・外注は、社内の準備と外注先との役割分担の精度で成否が決まります。最後に、発注を成功させるための要点を振り返ります。
発注前チェックリスト
発注前には次の点を確認しておきましょう。
・改修の目的とゴールを数値で定義したか
・必須要件（Must）と希望要件（Want）を切り分けたか
・現場の例外処理と連携要件をRFPに漏れなく記載したか
・旧DBアクセス権・データ引き上げ費用・解約条件を契約で確認したか
・データ移行・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を創業。