入出庫管理システムのモダナイゼーションは、自社で完結させにくく、多くの企業が開発会社やベンダーへの発注・外注を前提に進めます。全体の流れは、要件整理、発注先の選定、RFPの作成、契約と撤退条件の確認、役割分担の順です。ただし、依頼前の整理が曖昧だと、追加費用や現場の混乱が起きます。
▼全体ガイドの記事
・入出庫管理システムのモダナイゼーションの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
入出庫管理システムの刷新で外注前に整理する事項
発注で失敗する企業の多くは、自社の課題と要件を整理しないまま「とりあえず提案をください」とベンダーに相談を始めます。要件が固まっていないと、提案を比べる基準が定まりません。その結果、営業トークの巧みさや初期費用の安さだけで発注先を決めてしまいがちです。外注に出す前に、まず自社で整理すべき事柄を押さえておきます。
現状(As-Is)の棚卸と刷新目的・KPIの言語化
最初に行うのは、現行の入出庫業務の棚卸です。入荷、検品、格納、ピッキング、出荷、棚卸といった一連の流れのうち、どこに非効率やミスが集中しているのかを定量的に把握します。
自社で、誤出荷率、棚卸差異、ERP連携の現状を数値で整理します。
- KPI：在庫精度や誤出荷率などの刷新目標
- 確認：刷新目的とKPIの数値目標（在庫精度・誤出荷率など）
刷新によって何を達成したいのかは、KPIで言い表します。たとえば、在庫精度を99.5%以上にする、誤出荷率を0.1%未満に下げる、出荷リードタイムを半日短縮するといった数値目標を立てておきます。
目標が数値で決まっていれば、ベンダーへの要求が明確になり、提案の良し悪しを客観的に評価できます。逆に、目的が曖昧なまま発注すると、開発会社も判断基準を持てず、的外れな機能が積み上がってしまいます。
必須(Must)と希望(Want)の切り分け
要件をすべて「必須」として発注すると、見積もりは膨れ上がり、フルスクラッチに近い高額開発に向かってしまいます。そこで、要件を「これがなければ業務が回らない必須(Must)要件」と「あれば望ましい希望(Want)要件」に切り分けておきます。
たとえばロット管理や賞味期限管理は、食品倉庫では必須ですが、汎用物流ではWantに分類できる場合があります。
- 例外対応：例外処理の優先度と追加開発の要否
- 確認：例外処理ごとの優先度と追加開発の要否
この切り分けは、後述するFit to Standardの判断にも直結します。Want要件は、パッケージの標準機能で代替できないかを検討します。標準で吸収できる業務は、あえて自社のやり方を変えることが、コストと開発期間を抑える鍵になります。
Must要件だけを明確にしておけば、複数社から見積もりを取ったときに、「どこまでが標準で、どこからが追加開発か」を正確に比べられます。
発注先の種類と選び方
入出庫管理システムの発注先は、提供形態によって性格が大きく異なります。発注先には、クラウド型(SaaS)、パッケージ型(オンプレミス)、フルスクラッチ型、近年台頭しているAI駆動開発によるスクラッチがあります。
形態によって、コスト構造、カスタマイズの自由度、開発期間が変わります。そのため、自社のMust要件と予算に照らして、どの形態に強いベンダーへ発注するかを見極めることが第一歩です。
提供形態ごとの発注先の特徴
SaaS型は、初期費用を抑えて数ヶ月で稼働できる反面、自社特有の業務に合わせた細かいカスタマイズが難しいのが特徴です。そのうえ、月額の従量課金が中長期で積み上がります。
パッケージ型は業種特化の機能が充実しており、アパレルの色・サイズ管理や食品の温度帯・賞味期限管理など、業界標準の要件をカバーしやすいことが強みです。
フルスクラッチ型は、自社業務に100%フィットする一方で、開発期間が半年から1年以上に及び、費用も最も高くなりがちです。
- 選定軸：費用・自由度・期間と自社要件の適合度
- 確認：各形態の費用・自由度・期間の比較
近年注目されているのが、AI駆動開発を活用したスクラッチ開発です。AIによるコード生成やテスト自動化を取り入れると、従来のスクラッチ開発に比べて工期・コストを30〜70%圧縮できるケースが出てきています。
これにより、パッケージ並みの予算で自社に100%フィットしたシステムを作るという、従来は両立が難しかった選択肢が現実的になりつつあります。新しい開発手法への対応力も、発注先の選定で確かめます。
物流ノウハウと開発力を見抜く方法
提案書は、どの会社も魅力的に見えるため、真の実力を見抜くには質問の仕方が大切です。返品や破損品の処理方法といった現場の例外を尋ね、その回答から物流ノウハウを確認します。
カタログのような回答しか返ってこない会社は、実装段階で現場の実態に対応できないリスクがあります。
- 連携実績：マテハン・ERP連携の実績と責任分界点
- 確認：マテハン・ERP連携ごとの担当範囲
開発力は、過去のWMS刷新の実績件数だけでなく、ERPやOMS、TMSとのAPI連携の経験で見ます。自動倉庫やAGV・AMRといったマテハン機器との連携実績も、あわせて確認します。
とくにマテハン連携は、500万〜3,000万円規模の追加開発になることもあります。担当の境目が曖昧だと、障害時の切り分けで揉めることになります。
連携を担当するベンダーが複数になる場合は、障害発生時の一次切り分けルールを発注前に決めておくことが欠かせません。
丸投げを避けるRFP(提案依頼書)の書き方
RFP(提案依頼書)は、ベンダーへの丸投げを防ぎ、各社から同じ条件で比べられる提案を引き出すための最重要の書類です。RFPの精度が低いと、各社が想定する前提がバラバラになり、見積金額を比べることすらできません。逆に、過不足なく書かれたRFPは、ベンダーの提案力と物流理解度を測る試金石にもなります。
RFPに必ず盛り込むべき項目
提案依頼書には、プロジェクトの背景と目的、達成したいKPI、現行システムの構成と課題、必須要件と希望要件の一覧を入れます。
想定する出荷件数や拠点数といった規模情報、連携が必要な周辺システム、希望スケジュールと予算レンジも、提案依頼書に書き込みます。
とくに出荷件数や品目数、ロケーション数といった定量データは、ベンダーが工数とコストを見積もる前提になります。そのため、必ず実績値を記載します。
- 比較条件：予算・スケジュール・移行範囲の共通前提
- 確認：各社の見積もりに使う前提の統一
データ移行の対象範囲や並行稼働の有無、本番切替の希望時期も、あわせて明記します。これらは費用と工数に直結するため、RFPに書いておかないと、後から追加見積もりが発生する原因になります。
提案フォーマットや見積もりの内訳の粒度を指定しておくと、各社の提案を同じ形式で比べられ、評価作業が格段に楽になります。
自社特有要件・例外処理の伝え方
入出庫管理システムの刷新で在庫が合わなくなる最大の原因は、現場の例外処理がシステムに反映されていないことです。
たとえば、セット品を1個だけ返品されたときの単位処理や、破損品を物理的に隔離しただけで論理ステータスの変更を忘れて生じるゴースト在庫があります。サンプルの無記録持ち出しなど、現場には数多くの例外運用が存在します。
発注する側が現場の例外をRFPで伝えないと、稼働後に在庫差異が大きく膨らみます。
- 受入検証：RFPの例外シナリオとUATの要件抜け
- 確認：RFPへの例外シナリオの明記と、UATでの要件抜けの検証
例外処理を伝えるときは、「どんなケースで」「現状どう処理しているか」「あるべき姿はどうか」を一覧にして、RFPに添付すると効果的です。
現場の担当者にヒアリングを行い、文書に残っていない運用を発注前に洗い出しておきます。
この準備を怠ると、要件定義の段階で例外処理の追加が次々と見つかり、追加開発による予算超過とスケジュール遅延を招くことになります。
契約・撤退時の条項と隠れコスト
発注時に見落とされやすいのは、新しいベンダーとの契約に加えて、旧システムから「撤退」する際のコストと条項です。
多くの企業は新システムの導入費用ばかりに目を向け、旧システムから離れる際の隠れコストを見積もりに織り込んでいません。そのため、撤退戦略を発注前に設計しておくことが、総額を抑える決め手になります。
旧DBアクセス権とデータ引き上げ費用
旧システムのデータベースへの直接アクセス権が自社にない契約では、移行テストやリハーサルでデータをCSV抽出するたびに、旧ベンダーへ1回あたり数十万円のスポット費用を支払うことになります。
移行のリハーサルは通常複数回行うため、この費用が積み重なると、百万円単位の予期せぬ出費になりかねません。
旧ベンダーとの契約書を見直し、解約条件とデータ引き上げの取り扱いを、発注前に確かめておく必要があります。
- 移行費用：CSV抽出費用・解約条件・開示範囲
- 確認：旧ベンダーの契約書にある抽出費用と解約条件の中身
あわせて、新しいベンダーとの契約でも、将来の乗り換えに備えてデータを持ち出せるようにしておきます。
具体的には、契約終了時に自社が標準的な形式でデータを取り出せること、DBの構造仕様を開示してもらえることを、契約条項に盛り込みます。
一度ベンダーにロックインされると、次の刷新でも再び高額なデータ抽出費用を払う構図が繰り返されます。そのため、出口戦略を最初から織り込む発想が欠かせません。
解約条件・5年TCO・保守範囲の確認
「初期費用無料」をうたうSaaSは魅力的に映りますが、従量課金が積み上がると、中長期ではオンプレミスやパッケージより割高になることがあります。
たとえば、初期0円で月額20万円のSaaSは5年で1,200万円、初期100万円で月額10万円のパッケージは5年で700万円になります。5年の総保有コスト(TCO)で比べると、費用の大小が逆転する場合があります。
発注時は、必ず5〜7年のTCOで比べます。そのうえで、月額費用の値上げ条件も契約で確かめます。
- 契約条件：保守費率と解約時のデータ引き上げ条件
- 確認：保守費率と解約時のデータ引き上げ条件の中身
保守費用も見落とせない固定コストです。オンプレミスやスクラッチ開発では、年間の保守費が初期構築費の15〜20%程度かかるのが一般的で、毎年継続して発生します。
ハンディ端末も、1台あたり5万円から30万円かかり、利用人数分が必要です。
発注する側は、Wi-Fi環境の整備や導入支援のコンサル費といった周辺コストまで含めて見積もりを精査しないと、稼働後に「想定より高かった」という事態に陥ります。
外注先との役割分担と進め方
外注は、自社とベンダーが役割を分けて共同で進めるものです。とくにデータ移行と並行稼働の段階では、どちらがどこまで責任を持つかが曖昧だと、トラブル時に責任の押し付け合いになります。
復旧が遅れると、出荷停止という最悪の事態を招きます。そこで、発注時に役割分担表を作り、合意しておくことが肝心です。
データ移行・UATシナリオの責任分担
過去12ヶ月に入出荷実績のないマスタや休止ロケーションを捨てる「12ヶ月ルール」を定めておきます。その基準は自社が決め、ベンダーに渡します。
- 受入条件：受入基準と不具合対応の責任者
- 確認：受入基準と不具合対応の責任者の合意
受け入れテスト(UAT)のシナリオ作成も、自社の重要な役割です。
正常系だけでなく、セット出荷、バラ返品、破損品処理といったイレギュラーなケースを網羅したテストシナリオを用意し、現場の実務に耐えるかを検証します。
テストシナリオの作成主体、テストデータの準備、不具合の管理方法は、発注時に取り決めておきます。そうすれば、テストフェーズでの手戻りを減らせます。
並行稼働とロールバックの権限設計
並行稼働(パラレルラン)では、新旧両方のシステムを動かすため、現場の工数が1.5〜2倍に膨らみます。
最大の事故は、新旧両方からピッキングリストや送り状を出力する指示系統の二重化です。この二重化が、重複ピッキングや誤出荷を連発させます。
発注時に、物理的な指示書は新システムからのみ出力するという一本化ルールを、ベンダーと現場の双方で合意しておくことが鉄則です。
- 復旧体制：判断権限と旧環境の保持期間
- 確認：判断権限と旧環境の保持期間の事前合意
本番切替では、ロールバックの判断基準と権限を明文化します。たとえば、エラー率0.5%超過などをExit Criteriaとして定めます。API連携が4週間安定したら、並行稼働を終了します。
旧システムと旧端末は最低3ヶ月保持し、切替は閑散期に行います。
発注で失敗しないためのチェックポイント
ここまでの内容を踏まえ、発注で失敗しないための要点を整理します。よくある失敗パターンを知っておくと、同じ失敗を繰り返すリスクを大きく減らせます。発注前のチェックリストとして、ぜひ活用してください。
よくある失敗パターンと回避策
代表的な失敗は、ベンダーへの丸投げです。要件を整理せず提案任せにすると、現場の例外処理が抜け落ち、稼働後に在庫差異が頻発します。次に多いのが、例外処理のヒアリング漏れと現場教育の不足です。
新システムの操作に現場が慣れないまま本番を迎えると、入力ミスや運用の回避が増え、せっかくのシステムが形骸化します。そのため、発注時に教育と定着支援の範囲を決めておくことが、回避策になります。
- 回避策：教育範囲と段階的な移転計画
- 確認：発注時に決めておく教育範囲と移転計画
もう一つの重大な失敗は、WMS刷新と物理的な倉庫移転を同時に進めてしまうことです。
倉庫移転には、出庫作業費や早期解約違約金のほか、割増保管料や棚卸費などがかかります。その額は月額の3〜6ヶ月分になり、そこにシステム刷新が重なると、リスクは一段と大きくなります。
やむを得ず同時に行う場合は、段階的移転とバックオーダー消化計画を、ベンダーと綿密に詰めておく必要があります。
発注前の最終チェックリスト
発注前に、現状の課題とKPIを数値で示しておきます。あわせて、必須要件、例外処理、旧ベンダーの条件、5年TCOを確かめておきます。
- 役割分担：契約・UAT・切替・ロールバックの担当
- 確認：契約、UAT、切替、ロールバックそれぞれの担当の取り決め
役割分担と権限は、データ移行からロールバックまで、契約に明記しておきます。マテハン連携の担当の境目や、切替時期が閑散期かどうかも確かめます。
これらをチェックリストとして確認しておけば、発注後の手戻りや追加費用を大幅に減らせます。発注は、プロジェクト全体の設計そのものだと捉えることが成功への近道です。
まとめ
入出庫管理システムのモダナイゼーションを外注・委託する際は、発注前の要件整理から始め、提供形態に応じて発注先を選ぶ流れになります。
発注する側は、RFPの作成、契約・撤退時の条項の確認、外注先との役割分担まで、一連の流れを設計しておくことが成功の鍵です。
とくに、現場の例外処理の洗い出しと、旧ベンダーからのデータ引き上げや5年TCOといった隠れコストへの目配りが、後悔しない発注につながります。
データ移行・並行稼働・ロールバックの責任分担を明確にします。切替を閑散期に行う進め方を押さえると、刷新プロジェクトのリスクを下げられます。
近年はAI駆動開発によって、パッケージ並みの予算で自社に100%フィットしたシステムを構築する選択肢も広がっています。
本記事のチェックリストを活用し、自社の業務とコストに最適なパートナーへの発注を実現してください。
▼全体ガイドの記事
・入出庫管理システムのモダナイゼーションの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。