入出庫管理システムリプレイスの発注は、変える理由と必須要件を社内で整理するところから始まります。そのうえでRFPを使って発注先を比べ、契約と移行の役割を決めていきます。
この流れに沿って、発注前の整理、発注先とRFPの選び方、契約と移行時の確認事項の順に見ていきます。
▼全体ガイドの記事
・入出庫管理システムリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
入出庫管理システムリプレイスを外注する前の整理
開発会社に問い合わせる前に、変更理由と必須要件、妥協できる要件を、自社の言葉で説明できるようにしておきます。準備が曖昧なままだと、提案に振り回されて、費用や移行リスクが膨らんでしまいます。
「変えるべきサイン」と発注目的の言語化
現行システムを見直すサインは、現場の事象に表れます。そのため、発注の目的につながる事象を、現場の状況から洗い出します。
- 保守終了：ベンダーのサポート終了（EOL/EOSL）が迫っている。
- 処理遅延：出荷件数の増加により、バッチ処理が夜間に終わらない。
- 手作業連携：ERPとのデータ連携を、CSVの手動取り込みで行っている。
- 仕様の属人化：度重なる改修で、仕様を把握している担当者が一人だけになっている。
各事象に損失額や工数を添えると、目的を数字で示せます。たとえば、ERP連携の手動取り込みで毎日2名が1時間転記し、月2〜3回の入力ミスで在庫差異が起きる場合があります。
この例であれば、年間で数百時間の工数と誤出荷への対応コストとして、経営層に説明できます。
「在庫精度を99.5%以上にし、転記工数を月40時間削減する」のように目標を数字で立てておくと、提案を同じ基準で評価できます。「老朽化を解消する」のような目標では、基準が曖昧なままです。目的が曖昧だと、現行踏襲の提案になり、課題が残るおそれがあります。
Must要件とWant要件の切り分け
MustとWantを分けるには、自社の業務のどこが必須要件かを見極めます。
- 在庫管理：ロット・賞味期限管理、ロケーション管理。
- 現場作業：ハンディ端末でのピッキング。
- 外部連携：ERPやOMSとのAPI連携。
すべてをMustにすると、フルスクラッチが前提になり、費用と期間が増えてしまいます。また、標準機能で足りる業務まで個別開発すると、新システムでも属人化やブラックボックス化を招きます。
そこで有効なのが、競争力に直結する業務だけをMustとし、それ以外は標準仕様に業務を合わせる「Fit to Standard」です。たとえば、アパレルなら色・サイズ別の引当、食品なら賞味期限の先入れ先出しをMustにできます。
自社では、汎用的な入荷検品のフローをパッケージの標準に寄せるなど、要件の優先度を決めていきます。「ここは必須、ここは標準でよい」と開発会社に伝えておくと、見積もりと提案の精度が上がります。
発注先の選択肢とタイプ別の特徴
外注先は、クラウドSaaS、オンプレ型パッケージ、フルスクラッチ開発会社の3タイプに大別されます。タイプごとに費用の構造や移行リスク、拡張性が異なるため、Must/Want要件と照らして選ぶ必要があります。さらに、AI駆動開発も加わったことで、「パッケージかスクラッチか」という二項対立は崩れつつあります。
SaaS・パッケージ・スクラッチの違い
提供形態によって、初期費用や継続費用、業務への適合方法は異なります。比較の際は、各形態の特徴を押さえておきます。
- クラウドSaaS：初期費用を抑えやすく、数ヶ月で稼働できる。
- パッケージ：標準機能を基礎に、必要に応じてカスタマイズできる。
- フルスクラッチ：自社業務に合わせられるが、費用と期間が大きい。
SaaSは自社業務をシステムに合わせる必要があり、月額の従量課金が積み上がると、中長期では割高になる場合があります。たとえば、初期0円・月20万円であれば、5年間で1,200万円になります。
一方、初期100万円・月10万円のパッケージなら、5年で700万円です。5〜7年のTCO（総保有コスト）で比べないと、安いつもりが逆転することがあります。
そのため、発注時には、この期間で見たコスト試算を開発会社に必ず示してもらいます。
パッケージには物流業務のベストプラクティスが標準で搭載されており、カスタマイズによって自社の要件に寄せられます。
フルスクラッチは自社業務に100%フィットさせられますが、費用と期間はいずれも最も大きく、半年から1年以上かかるのが一般的です。
汎用製品か業種特化型かも、あわせて比べます。アパレルの色・サイズや、食品の温度帯・賞味期限に特化した製品は、標準機能で業務に合うため、結果的に安く済む場合があります。
AI駆動開発という新しい選択肢
AI駆動開発は、スクラッチ開発の設計・コーディング・テストにAIを活用する開発方法です。従来のスクラッチ開発と比べ、工期とコストを30〜70%圧縮できるケースがあります。
このため、自社業務に合わせながらも、パッケージ並みの予算で開発する選択肢が現実味を帯びています。例外処理や独自の引当ロジックが競争力の源泉なら、標準パッケージより定着しやすい場合もあります。
発注先には、AI駆動開発を行う会社も含め、自社業務のどこを標準に寄せ、どこを個別に開発するかを提案してもらいます。こうすれば、「パッケージかスクラッチか」の二択にとらわれず比べられます。
丸投げを防ぐRFP(提案依頼書)の書き方
RFP（提案依頼書）は、複数の外注先を同じ基準で比べ、丸投げによる失敗を防ぐための最重要文書です。口頭での相談だけでは各社の前提がそろわず、見積もりを比べられません。
要件を追加すると費用は膨らみますが、細かく書きすぎると提案の自由度が下がります。そのため、解決したい課題を中心に、比較に必要な要点を書きます。
RFPに必ず盛り込むべき項目
提案の条件と比較の基準をそろえるため、RFPには入荷・検品・格納・ピッキング・出荷の流れを示します。あわせて、取扱規模や要件を具体的に伝えます。
- 目的・業務：プロジェクトの狙いとKPI、入荷から出荷までの現状業務。
- 規模：取扱品目、1日あたりの入出荷件数、拠点数。
- 要件・環境：Must/Want、ERP・OMS・TMS・マテハンとの連携。
- 条件：想定スケジュール、予算レンジ、保守・運用要件。
件数や品目数など規模を示す数字は、見積もりの精度を左右します。そのため、曖昧にせず実数を書きます。
提案依頼には、移行方式とデータ移行の進め方を含めます。また、並行稼働の考え方や体制、スケジュールも示してもらいます。
評価基準には、機能の適合度と費用を中心に、実績やサポート体制も明記します。先に示しておけば、各社の提案を横並びで比べられます。さらに、採用を決める基準を社内で合意しておけば、発注後の判断がぶれにくくなります。
自社特有の例外処理・連携要件の伝え方
日常的な例外処理を伝えないと、稼働後に想定外の運用となり、在庫が合わなくなるおそれがあります。現場で起きている例外は、洗い出して開発会社に伝えておきます。
- 返品：2個1セットの商品のうち、1個だけが戻ってくる。
- 破損品：物理隔離後に論理在庫の変更を忘れ、引当が走る。
- サンプル：記録せずに持ち出す。
例外ごとに、発生の頻度と現在の対応方法を書き添えます。こうした例外は在庫差異の最大の発生源です。たとえば破損品の引当は欠品クレームにつながります。
ERPやOMSとの連携は、リアルタイムのAPIか日次バッチかを明示します。連携項目やタイミング、エラー時の動作まで書くと、追加費用を防ぎやすくなります。
マテハン（WCS/WES/AGV）と連携する場合は、責任の分かれ目も示して、見積もりの漏れを防ぎます。
契約・撤退時に確認すべき条項と隠れコスト
新しい外注先との契約と同時に、旧システムからの撤退（Exit）も設計しておく必要があります。撤退の段取りを見落とすと、旧ベンダーへのスポット費用が隠れコストとなり、予算を圧迫します。
旧ベンダーからのデータ引き上げと隠れコスト
旧システムのDBに直接アクセスできない契約では、在庫やマスタデータの抽出を旧ベンダーに頼むことになります。
移行は一度では終わらず、テストとリハーサルの段階で何度も抽出が発生します。
- データ抽出：CSVでの取り出しは1回あたり数十万円かかる。
- 倉庫移転：月額の3〜6ヶ月分の移動手数料がかかる場合がある。
- 契約条件：DBアクセス権、抽出費用、解約予告期間を確認する。
その積み重ねは、数百万円規模の費用になることもあります。だからこそ、新規の発注先を選ぶ前に、旧契約の条件を確認しておきます。
旧倉庫から移転する場合は、出庫作業費や早期解約違約金、割増保管料、棚卸費なども移動手数料に含まれることがあります。こうした費用も含めて、Exit条件を洗い出し、撤退コストを予算に織り込みます。
契約形態と検収・瑕疵対応の取り決め
稼働後の責任を明確にするため、契約書の内容は一つずつ確かめておきます。内容が曖昧なままだと、不具合が出たときに誰が対応するのかがはっきりしません。
- 契約形態：請負か準委任か。
- 検収・保守：完成基準、不具合対応、メンテナンスの範囲と期間。
- 権利・引き渡し：ソースコードや設計ドキュメントをどちらが持つか、引き渡し方法。
検収の基準、つまりどの状態を完成とみなすかを決めたうえで、稼働後の不具合への対応も契約に書き込みます。
稼働直後に出荷が止まると事業への打撃が大きいため、障害が起きたときの一次対応時間をSLAとして決めておきます。
ソースコードや設計資料をどちらが持つかと、引き渡し方法を定めておけば、次の乗り換え時にデータを引き上げられない事態を避けやすくなります。
外注先と握るべき役割分担とリスク管理
データ移行やテスト、並行稼働では、自社だけが持つ業務知識が欠かせません。そのため、全作業を外注先に任せきることはできません。
そこで、自社とベンダーの作業範囲を役割分担表に書き出し、発注の段階で合意しておきます。こうしておけば、移行が止まるリスクを抑えやすくなります。
データ移行とUATの担当の切り分け
移行作業では、作業ごとに誰が判断し、誰が手を動かすかを分けておく必要があります。
- 自社：移行対象データの選定と妥当性検証。
- ベンダー：移行ツールの作成とデータ投入。
- 自社主体：例外処理も含むUATシナリオの設計。
移行プロジェクトの失敗は、約7割がデータに起因すると言われます。そのため、移行対象を絞る基準を早めに決めておきます。たとえば「12ヶ月ルール」では、過去12ヶ月間に入出荷実績のない品目や休止ロケーションを対象外にします。
クレンジングの基準や名寄せのルールは、現場の業務を知る自社側で決めます。
抽出から投入までの間も在庫は動くため、差分を後から新システムに反映するか、週末に業務を止めて一括で切り替えるかを決めておきます。これが在庫の時点整合性の方針にあたります。
UAT（受入テスト）では、正常系だけでなく例外処理も確かめる必要があります。シナリオに抜けがあると稼働後のトラブルに直結するため、自社が中心になって設計します。
並行稼働とロールバックの責任範囲
並行稼働の進め方を発注時に決めておかないと、現場は新旧どちらの指示に従えばよいか迷い、混乱が生じます。
- 指示系統：物理的な指示書は、新システムからだけ出す。
- 終了条件：Exit Criteriaとして、誤出荷率0.5%未満やAPI連携4週間安定などの基準を定める。
- 切り戻し：判断に使う数値と権限者。
- 切替時期：繁忙期を避けた閑散期を選ぶ。
並行稼働中は二重入力が発生するため、現場の工数は1.5〜2倍に増えます。さらに、新旧両方からピッキングリストや送り状が出ると、指示が二重になり、誤出荷が続くおそれがあります。
本番切替後に出荷が止まったときは、エラー率や棚卸差異率を見て、現場責任者と情シスのうち誰が判断するかを決めておきます。旧システムと旧ハンディ端末は、新稼働後も最低3ヶ月は保持し、切り戻しの際に接続できる状態を保ちます。
まとめ
発注前には、変更理由と目標を数字で示し、Must/Wantを切り分けておきます。そのうえで発注先の形態を比べ、RFPに同じ比較基準を示すと、価格や営業トークだけに流されにくくなります。
新規発注と旧システムからの撤退は一体で設計し、データ抽出費や解約条件を契約で確認します。また、データ移行、UAT、並行稼働、ロールバックについて、どこまでを誰が受け持つかも合意しておきます。
入出庫管理は在庫と直結するため、例外処理や時点整合性といったWMS特有の論点を、外注先と早い段階で共有します。こうした準備が、移行後の在庫差異を防ぎます。
▼全体ガイドの記事
・入出庫管理システムリプレイスの完全ガイド
▼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を創業。