倉庫管理システム(WMS)の更改を検討し始めたものの、「そもそもどの会社に、どこまでをどう任せればよいのか」が分からず、発注の一歩を踏み出せずにいる物流部門や情報システム担当の方は少なくありません。WMSの更改は単なるソフトの入れ替えではなく、入出庫の現場オペレーション、在庫精度、ERPやマテハン機器との連携までを巻き込む大規模プロジェクトです。だからこそ、発注・外注のやり方を誤ると、稼働後に在庫が合わない、誤出荷が増える、想定外の追加費用が膨らむといった事故につながります。発注先選びと同じくらい、「発注の仕方」そのものが成否を分けると言っても過言ではありません。
本記事では、倉庫管理システム更改を外注・委託する際の進め方を、要件整理からRFP(提案依頼書)の書き方、契約・撤退時の条項確認、外注先との役割分担、よくある失敗の回避策まで体系的に解説します。特に、競合記事ではあまり語られない「旧ベンダーからのデータ引き上げ費用」「並行稼働の終わらせ方」「5年TCOで見たコスト逆転」といった、発注前に知っておかないと数百万円単位で損をしかねない実務上の落とし穴を、具体的な数字とともに掘り下げます。この記事を読み終える頃には、自社が何を準備し、何を握って発注すべきかが明確になっているはずです。
▼全体ガイドの記事
・倉庫管理システム更改の完全ガイド
倉庫管理システム更改の発注・外注の全体像
倉庫管理システムの更改を外注する流れは、大きく「現状と目的の整理」「発注先の選定」「契約」「要件定義・開発」「データ移行・並行稼働」「本番稼働」という工程をたどります。発注で失敗する企業の多くは、最初の「整理」を曖昧にしたまま開発会社に相談へ行き、相手の提案ペースに流されてしまいます。まずは発注の全体像と、自社が主体的に決めるべき領域を押さえておきましょう。
発注前に押さえるべき「なぜ更改するのか」
発注を成功させる出発点は、更改の目的を社内で言語化することです。サポート終了(EOL/EOSL)による老朽化対応なのか、EC化で出荷件数が増えて処理能力が限界に達したのか、過度なカスタマイズで属人化・ブラックボックス化が進んでいるのか、目的によって最適な発注先も投資規模も変わります。たとえば「在庫精度を上げたい」が真の目的であれば、システムの機能比較よりも、現場の例外処理をどう業務設計へ落とし込めるかが論点になります。目的が曖昧なまま発注すると、開発会社が用意したパッケージの標準機能に業務を合わせるだけになり、肝心の課題が解決されないまま稼働を迎えてしまいます。
目的を整理する際は、現場が「これ以上は限界」と感じているシグナルを具体的に拾い上げてください。ピーク時のレスポンス低下、特定担当者しか操作できない画面、ERPとのCSV手動取り込みによる二重入力と転記ミスの常態化などは、いずれも更改を正当化する明確な根拠になります。これらを定量データとして整理しておけば、経営層への投資稟議でも、発注先への要件説明でも一貫した軸として機能します。
発注先となる開発会社の主な4タイプ
WMS更改の発注先は、大きく4つのタイプに分けられます。1つ目はクラウド型(SaaS)WMSを提供する事業者で、初期費用を抑えて数ヶ月でスモールスタートできる一方、カスタマイズの自由度には制約があります。2つ目はパッケージ型(オンプレ)ベンダーで、業種特化の機能が豊富ですが、導入には半年から1年以上かかるケースが一般的です。
3つ目はフルスクラッチ開発を手がけるシステム会社で、自社業務に100%フィットさせられる反面、費用と期間がかさみやすいという課題がありました。そして4つ目が、近年台頭しているAI駆動開発を取り入れた開発会社です。AI駆動開発では設計やコーディングの一部をAIが支援することで、従来のスクラッチ開発に比べて工期とコストを30〜70%圧縮できる事例も出てきており、「パッケージ並みの予算でフルフィットの仕組みを持つ」という新しい選択肢として注目されています。発注先を選ぶ前に、自社の更改規模と求めるフィット度から、どのタイプを軸に検討するかを定めておくことが重要です。
外注前に整理すべき要件と「必須・希望」の切り分け
発注先に丸投げせず、自社で先に整理しておくべきものが「要件」です。要件があいまいなまま開発会社に相談すると、各社の提案がどれも良く見えてしまい、比較の物差しを持てません。ここでは、現状業務の可視化と、要件の優先順位付けという2つの作業を解説します。
As-Is/To-Be分析で現状業務を可視化する
外注の精度は、現状業務(As-Is)をどれだけ細かく棚卸しできているかに比例します。入荷検品、格納、ピッキング、出荷検品、棚卸といった主要フローだけでなく、現場が「良かれと思って」行っている例外処理まで洗い出すことが肝心です。2個1セットで出荷した商品が1個だけ返品されたときの在庫単位の扱い、破損品を物理的に隔離しただけでシステム上のステータスを変えていないケース、サンプル品を記録せず持ち出すケースなど、これらの例外がWMS稼働後にゴースト在庫(実在しない引当可能在庫)を生み、欠品クレームの温床になります。
その上で、更改後のあるべき姿(To-Be)を、達成すべきKPIとセットで描きます。在庫精度を現状の95%から99.5%へ、誤出荷率を月10件から1件以下へ、といった数値目標を置くことで、開発会社に伝える要件が具体化し、稼働後の効果検証の基準にもなります。As-IsとTo-Beの差分こそが、まさに今回の発注で実現したい範囲そのものです。
Must要件とWant要件を線引きする(Fit to Standard)
洗い出した要件は、必ず「Must(必須)」と「Want(希望)」に分類してください。すべてを必須として開発会社に求めると、カスタマイズが膨らんで費用と期間が跳ね上がり、属人化という前システムの失敗を再生産してしまいます。逆に、標準機能で代替できる業務はあえてシステムに合わせる「Fit to Standard」の発想を持つことで、コストを抑えながら保守性の高い仕組みを実現できます。
線引きの目安は、「その要件がなければ業務が止まるか」「自社の競争力に直結するか」という問いです。賞味期限管理や温度帯別ロケーションのように業種特有で欠かせないものはMust、画面の色や帳票の細かなレイアウトのように運用で吸収できるものはWantに振り分けます。この優先順位を発注前に固めておけば、開発会社との要件定義で現場から際限なく出てくる要望にも、ぶれずに判断を下せるようになります。
丸投げを防ぐRFP(提案依頼書)の書き方
RFP(提案依頼書)は、発注先に「何を実現したいか」を正確に伝え、各社を同じ土俵で比較するための設計図です。RFPの完成度が低いと、開発会社は無難で曖昧な提案しか出せず、結果として「提案書がどれも良く見える」状態に陥ります。ここでは、丸投げを避けるためにRFPへ盛り込むべき項目と、自社固有要件の伝え方を整理します。
RFPに必ず盛り込むべき項目
WMS更改のRFPには、最低限おさえるべき項目があります。プロジェクトの目的と背景、対象拠点と業務範囲、出荷件数やSKU数などの規模情報、Must/Wantに分類した機能要件、ERP・OMS・TMSやマテハン機器との連携要件、希望スケジュールと予算レンジ、そして提案・見積の様式です。とくに規模情報は見積金額に直結するため、ピーク日の出荷件数や拠点数を正確に記載してください。
あわせて、移行と稼働に関する条件も明記しておくと、各社の実力差が提案に表れます。具体的には、データ移行の対象範囲、並行稼働の想定期間、切替時期の制約(繁忙期は避けたい等)、本番稼働後のサポート体制などです。これらを問えば、物流現場を理解している会社は移行リスクへの具体策を返し、理解の浅い会社は機能説明に終始するため、提案を見るだけで開発力と物流ノウハウを見抜く手がかりになります。
例外処理・連携要件という「自社固有」を言語化する
RFPで最も差がつくのが、自社固有の例外処理と連携要件をどこまで言語化できるかです。前段で洗い出したセット品のバラ返品、破損品のステータス管理、サンプル持ち出しといった例外は、標準的なパッケージでは想定されていないことが多く、RFPに書かれていなければ提案にも見積にも反映されません。これらを「業務シナリオ」として文章で具体的に記述しておくことで、稼働後の在庫差異という最も深刻な事故を未然に防げます。
連携要件については、ERPやOMSとリアルタイム連携なのか日次バッチなのか、APIなのかCSV/EDIなのかを明確にします。自動倉庫やAGV・AMRといったマテハン機器との連携がある場合は、その機器の制御を担うWCS/WESとの責任分界点を必ず問うてください。連携部分の追加開発は500万〜3,000万円規模になることもあり、複数ベンダーが介在すると障害時の責任の所在が曖昧になりがちなため、RFPの段階で切り分けの考え方を確認しておくことが欠かせません。
契約・撤退時に確認すべき条項
発注先を新たに選ぶときに見落とされがちなのが、現在使っている「旧システム」からの撤退条件です。新システムの契約内容ばかりに目が向き、旧システムを安全に終わらせるためのコストを見積もっていないと、移行段階で想定外の請求が発生します。新旧両方の契約を見据えた条項確認が、トータルコストを左右します。
旧システムの「データ引き上げ」コストを契約前に潰す
WMS更改で最も見過ごされやすい隠れコストが、旧システムからのデータ引き上げ費用です。旧システムのデータベースに自社で直接アクセスする権限がない契約の場合、移行テストやリハーサルのたびに旧ベンダーへCSV抽出を依頼することになり、1回あたり数十万円のスポット費用を請求されるケースがあります。移行には複数回のテストが付きものですから、これだけで百万円単位の予備費が必要になりかねません。
この事態を避けるには、新システムの発注を決める前に、旧ベンダーとの契約書で「データの所有権」「DBへのアクセス権」「解約時のデータ提供条件と費用」を確認しておくことが重要です。自社にデータを取り出す権利が確保されていれば、抽出のたびに費用を取られることはありません。撤退(Exit)を見据えた条件確認は、発注の意思決定そのものに織り込むべきプロセスです。
解約条件・保守費・知的財産権の取り決め
新たに発注する側の契約でも、稼働後を見据えた条項を詰めておく必要があります。とくにオンプレ型やスクラッチ開発では、年間保守費が初期構築費の15〜20%程度かかるのが一般的で、5年分を合算すると初期費用と同等の負担になることもあります。保守の範囲(障害対応のみか、法改正対応や軽微な改修まで含むか)と費用を契約段階で明文化しておきましょう。
あわせて確認したいのが、開発した成果物の知的財産権の帰属と、将来の改修・乗り換えのしやすさです。ソースコードの権利が自社にあるか、ドキュメントが引き渡されるかによって、次回更改時に同じベンダーへ縛られるリスクが変わります。倉庫の物理移転を同時に行う計画がある場合は、旧倉庫の出庫作業費・早期解約違約金・割増保管料・棚卸費が月額の3〜6ヶ月分に達することもあるため、これらの周辺コストも契約検討の段階で見積もりに入れておくと安心です。
外注先と握るべき役割分担とリスク管理
外注は「任せきり」ではなく、自社と発注先で役割を明確に分担してこそ成功します。とくにデータ移行と並行稼働は、責任の所在が曖昧だと現場が混乱し、誤出荷や業務停止という最悪の事態を招きます。発注前に、どの工程を誰が担うかを握っておきましょう。
データ移行とUATの責任分界点
「WMS移行の失敗の7割はデータに起因する」と言われるほど、データ移行は重要かつ難しい工程です。発注先はマッピングや投入ツールの提供を担えますが、移行元データのクレンジングと正しさの判断は自社にしかできません。たとえば「過去12ヶ月間入出荷実績のないマスタや、休止しているロケーションは移行対象から外す」といった12ヶ月ルールのような取捨選択基準は、現場の事情を知る自社が決める領域です。
稼働前の受け入れテスト(UAT)も、自社が主体的に担うべき工程です。発注先任せにせず、通常業務だけでなくセット品のバラ返品や破損品処理といったイレギュラーを含むテストシナリオを自社で用意し、想定どおり動くかを検証します。在庫が移行中も動き続けるため、抽出から投入までのタイムラグをどう埋めるか(動いた分を差分で反映するのか、週末に業務を止めて一括で切り替えるのか)も、発注先と方式を合意しておく必要があります。
並行稼働とロールバックの責任を明文化する
新旧システムを一定期間並行して動かす並行稼働(パラレルラン)は、安全に見えて最も事故が起きやすい工程です。最大の落とし穴は、新旧両方から出荷指示書やピッキングリストを出力してしまう「指示系統の二重化」で、これが重複ピッキングや誤出荷を連発させます。現場に出す物理的な指示書は必ず新システムのみに一本化し、二重入力による工数増(通常1.5〜2倍)を見込んだ要員計画を立てることが鉄則です。
並行稼働を「いつ終わらせるか」を曖昧にすると、現場が疲弊し続けます。そこで、終了条件(Exit Criteria)を事前に数値で定義してください。たとえば「出荷エラー率0.5%未満」「ERPとのAPI連携が4週間連続で安定稼働」といった基準を満たしたら新システムへ完全移行する、と決めておきます。さらに、稼働後にトラブルが起きた際の切り戻し(ロールバック)についても、どの数値(出荷エラー率や棚卸差異率)を超えたら誰の権限で判断するかを明文化し、旧システムや旧ハンディ端末は新稼働後も最低3ヶ月は保持しておくことで、いざというときに業務が止まる事態を防げます。
倉庫管理システム更改の発注でよくある失敗と回避策
WMS更改の発注では、毎回のように繰り返される典型的な失敗パターンがあります。先人がつまずいたポイントを知っておくだけで、回避できるリスクは少なくありません。ここでは代表的な2つの失敗と、その回避策を解説します。
ベンダー丸投げによる要件漏れ
最も多い失敗が、要件整理を発注先に丸投げしてしまうケースです。「プロに任せれば良いものができる」という期待で要件定義を委ねると、開発会社は自社の現場を完全には把握できないため、例外処理や繁忙期特有のオペレーションが抜け落ちます。その結果、稼働後に「現場の実態に合わない」「結局Excelで二重管理している」といった事態に陥ります。
回避策はシンプルで、本記事で述べてきた要件の可視化とRFP作成を自社が主体となって行うことです。発注先はあくまで実現手段の専門家であり、何を実現したいかの当事者は自社です。現場のキーパーソンを早い段階からプロジェクトに巻き込み、要件定義の場に同席させることで、要件漏れと稼働後の現場反発の双方を抑えられます。
見積もりに出てこない隠れコストの見落とし
もう1つの典型的な失敗が、提示された見積金額だけで発注先を決め、隠れコストを見落とすことです。とくに「初期費用無料」をうたうSaaS型は魅力的に見えますが、従量課金が積み上がると中長期ではオンプレ型より割高になることがあります。たとえば初期0円+月20万円のSaaSは5年で1,200万円、初期100万円+月10万円のパッケージは5年で700万円となり、長期で見るとコストが逆転するのです。発注判断は単年の費用ではなく、5年間の総保有コスト(TCO)で比較することが欠かせません。
見積に表れにくい費用は他にもあります。バーコードを読み取るハンディ端末は1台あたり5万〜30万円で、現場の人数分が必要です。前述した旧ベンダーのデータ抽出スポット費用、年間保守費、倉庫移転に伴う移動手数料なども含め、システム本体以外の費用をあらかじめリスト化しておきましょう。なお、フィット度を高めつつコストを抑えたい場合は、工期とコストを30〜70%圧縮できるAI駆動開発に対応した会社を比較対象に加えることで、従来は予算面で諦めていたフルフィットの選択肢が現実的になるケースもあります。
まとめ
倉庫管理システム更改の発注・外注は、発注先を選ぶ前の「準備」で大半が決まります。ここまでの要点を振り返り、自社が次に取るべきアクションを整理しておきましょう。
発注を成功させるための要点
発注を成功させる鍵は、(1)更改の目的とKPIを言語化する、(2)As-Is/To-Beを棚卸しし要件をMust/Wantに分類する、(3)例外処理と連携要件を盛り込んだRFPで丸投げを防ぐ、(4)旧システムのデータ引き上げ条件や保守費・知的財産権を契約前に確認する、(5)データ移行・UAT・並行稼働・ロールバックの役割分担と終了条件を明文化する、という5つに集約されます。これらを自社が主体的に整えておけば、開発会社の提案を正しく評価でき、稼働後の在庫差異やコスト超過といった事故を未然に防げます。
更改を「投資」に変えるために
倉庫管理システムの更改は、単なるコストではなく、在庫精度の向上や誤出荷の削減、人件費の最適化といったリターンを生む投資です。だからこそ、切替は必ず閑散期を選び、繁忙期の切替で現場が崩壊するリスクを避けること、そして5年TCOで本当のコストを見極めることが、投資対効果を最大化します。発注のやり方を磨くことが、更改プロジェクト全体の成否と投資回収を左右すると言えるでしょう。本記事を、自社の発注準備のチェックリストとして役立てていただければ幸いです。
▼全体ガイドの記事
・倉庫管理システム更改の完全ガイド
株式会社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を創業。