入出庫管理システムの移行を外注するときは、まず要件を整理し、次に発注先を選びます。そのうえでRFPで比較し、契約と役割分担を確認する流れで進めます。
この流れを踏めば、認識のずれや在庫差異を防ぎやすくなります。移行全体の進め方は、入出庫管理システム移行の完全ガイドでも確認できます。
▼全体ガイドの記事
・入出庫管理システム移行の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
入出庫管理システム移行の外注前に整理する項目
発注先を探す前に、移行の目的と現状の課題を自社の言葉で書き出しておきます。整理が甘いまま外注すると、ベンダーのパッケージ機能に業務を合わせるだけになり、解決したい課題が残るおそれがあります。
発注の質は、依頼前に社内でどこまで整理できたかで大きく変わります。
移行の目的と現状課題の棚卸し
まずは現行システムの課題を洗い出し、移行を決めた要因を整理します。
- サポート終了：メーカーのサポート終了（EOL/EOSL）が迫っている
- 属人化：長年の追加カスタマイズで運用が複雑になっている
- 出荷増加：EC化で出荷件数が増え、現行システムでは対応しにくい
要因が複数重なる場合も、「老朽化」とひとくくりにせず、誤出荷率、月次の在庫差異、繁忙期の処理のボトルネックといった数値で課題を把握します。
課題を数値にしておくと、移行後の効果を測る基準（KPI）を設定できます。たとえば、誤出荷率を0.5パーセントから0.1パーセント以下へ、棚卸差異率を3パーセントから1パーセント以内へ下げる目標を立てます。
目標が明確であれば、ベンダーへの要求も伝わり、提案内容を比較しやすくなります。一方、「とりあえず新しくしたい」という依頼では目的が曖昧なため、ベンダーも具体的な提案をしにくくなります。
必須要件と希望要件の切り分け
要件は、絶対に外せない必須要件（Must）と、実現できれば望ましい希望要件（Want）に分けます。譲れない要件は業種によって異なるため、自社の業務に即して判断します。
- 共通要件：ロット・賞味期限・シリアル番号管理、引当ロジック
- アパレル：色・サイズ展開の管理を優先する
- 食品：温度帯と賞味期限の管理を優先する
- 製造業：ロットトレーサビリティの確保を優先
商材の特性に直結する要件は明文化し、優先順位を社内で合意しておきます。
すべてを必須にすると見積りが膨らみ、標準機能で足りる部分まで過剰にカスタマイズする結果になります。
一方、現場の例外処理を希望要件として軽く扱うと、稼働後に在庫が合わなくなる原因になります。そのため、Fit to Standard（標準機能への業務適合）を意識し、自社の競争力に直結する部分だけをカスタマイズの対象にします。
発注先の種類と選び方
入出庫管理システムの発注先は、提供形態によって性格が異なります。
タイプを理解しないまま見積りだけで比べると、初期費用は安くても中長期では割高になったり、業務に合わなかったりします。
SaaS・パッケージ・スクラッチ開発会社の違い
発注先を比べる際は、初期費用と業務適合性の条件をそろえます。保守費用と利用期間は、同じ前提で比べます。
- SaaS：初期費用を抑えやすく、短期間で導入できる
- パッケージ：業種特化機能があり、一定範囲のカスタマイズに対応する
- スクラッチ：自社業務に100パーセント合わせられるが、従来は工期とコストが大きい
SaaSは、自社の業務を標準機能に合わせることが前提になります。
月額利用料は利用期間に応じて積み上がります。
出荷件数が多く、長く利用する企業では、5年間の総保有コスト（TCO）がオンプレ型パッケージを上回ることがあります。たとえば、初期費用ゼロで月額20万円のSaaSは5年で1,200万円になり、初期100万円で月額10万円のパッケージは5年で700万円です。このように、数年で費用が逆転する例は珍しくありません。
パッケージ型（オンプレ）では、年間の保守費用が初期構築費の15〜20パーセント程度かかるのが一般的です。
一方、近年はAI駆動開発で工期・コストを30〜70パーセント圧縮できるようになりました。そのため、パッケージ並みの予算で自社に最適なシステムを構築する選択肢も、現実的になってきています。
物流ノウハウと開発力を見抜くポイント
提案書だけでは実力を判断しにくいため、具体的な質問を投げかけて、現場の理解度を確かめます。
- 現場対応：在庫の時点整合性、セット品のバラ返品や破損品の管理
- システム連携：ERP、OMS、TMSとのAPI・EDIによる接続の実績
- 機器連携：自動倉庫、AGV、AMRなどマテハン機器（WCS/WES）との接続経験
- 移行実績：同規模・同業種の移行を完遂した実績（数値や体制を含む）
判断材料になるのは、現場の例外処理まで踏み込んだ回答です。機能の説明に終始するベンダーは、稼働後につまずくリスクがあります。
マテハン連携は、500万〜3,000万円規模の追加開発になることがあります。また、複数のベンダーが関わると、障害時に誰がどこまで責任を持つかが曖昧になりがちです。
RFP（提案依頼書）の書き方と発注の進め方
発注先の候補が見えたら、RFP（提案依頼書）を作成し、複数社に提案を依頼します。RFPは、各社の提案を同じ基準で比べるための文書で、発注書とは役割が異なります。また、要件が曖昧なまま依頼すると、丸投げの状態になり、認識のずれや追加費用、納期の遅れを招きます。
丸投げを避けるRFPの構成
RFPには、ベンダーが工数を見積もるための前提情報をそろえて記載します。
- 移行の前提：目的とKPI、現状の業務フローと課題
- 要件と計画：必須・希望要件、連携要件、データ範囲、日程、予算、評価基準
- 定量情報：1日あたりの入出庫件数、SKU数、ロケーション数、端末台数を提示
- 例外処理：サンプル品の無記録持ち出しやセットのばら返品を共有
前提を書いておけば、提案段階で対応方針を確かめられ、稼働後の在庫差異を防ぎやすくなります。ただし、RFPは完璧な仕様書である必要はありません。大切なのは、正しく見積もるための前提情報を欠かさないことです。
複数社コンペと見積比較のポイント
提案を受けたら、総額だけで判断せず、費用の内訳と各社の対応範囲をそろえて比べます。
- 初期構築費：システム構築にかかる費用
- データ移行費：移行対象データの抽出や変換にかかる費用
- 連携開発費：既存システムとの接続にかかる費用
- 年間保守費：稼働後の保守にかかる費用
- ハードウェア費：ハンディ端末などの費用
安く見える見積りでも、データ移行やテストの工数、稼働後の保守が含まれていないと、後から費用が膨らむことがあります。移行テストやリハーサルで旧システムからデータを抽出するたびに費用が発生しないかを、確かめておきます。追加要望が出たときの変更管理（チェンジリクエスト）の単価と進め方は、あらかじめ押さえておきます。
3社程度を比べると、相場感がつかめます。
一方で、安さだけで選ぶと、現場対応力に欠けるベンダーを選ぶおそれがあります。そのため、提案の具体性と担当者の物流理解度も含めて評価するとよいでしょう。
契約・撤退時の確認条項
旧システムからの撤退と、新システムから将来乗り換える際の条件は、見落とされがちです。契約時に撤退（Exit）の条件を確かめないと、想定外のスポット費用が発生したり、データを自由に取り出せなかったりします。
旧DBアクセス権とデータ引き上げ費用
旧システムのデータベースに自社が直接アクセスできない契約では、データを抽出するたびに費用がかかることがあります。
- 旧DBへのアクセス：自社に直接アクセス権があるかどうか
- 抽出費用：旧ベンダーへの依頼が1回あたり数十万円の場合がある
- 現行契約：新しい発注先を選ぶ前の、解約条件とデータ抽出の扱い
- 将来の引き上げ：標準形式での出力と、終了時の返却・削除手続きの明文化
テストやリハーサルで抽出を繰り返すと、費用が積み重なって予算を圧迫します。事前に条件を定めておけば、特定のベンダーへの過度な依存（ベンダーロックイン）を避けられます。
解約条件と知的財産・保守範囲
契約では、解約条件と知的財産の帰属、保守の対応範囲を確かめておきます。
- 解約条件：最低利用期間、中途解約時の違約金、保守契約の更新条件
- 知的財産：スクラッチ開発の著作権とソースコードを、どちらに帰属させるか
- 保守範囲：障害対応時間、対応速度の目安（SLA）、機能改修の扱い
ソースコードを自社で保有できれば、別のベンダーへ保守を切り替えられます。
また、入出庫管理は出荷停止が事業に直結するため、繁忙期の障害対応の速さも重要です。
外注先との役割分担とリスク管理
外注するときこそ、自社とベンダーの役割を明確にし、リスクを事前に共有しておきます。そのうえで、データ移行、並行稼働、本番切替の各段階で、誰が判断し、誰が実行するのかを決めておきます。
データ移行と並行稼働の責任分界
移行プロジェクトの失敗の約7割は、データに起因すると言われています。
- データ整備：クレンジング、名寄せ、在庫残高の時点整合性の担当範囲
- 移行対象：過去12ヶ月に実績のないマスタや休止ロケーションを外す基準は、自社で決める
- ツール作成：抽出・変換ツールはベンダーが担うなど、役割を文書にまとめる
- 指示系統：二重化は最大の事故要因のため、物理指示書は新システムだけにする
- 終了基準：誤出荷率0.5パーセント未満、API連携の4週間安定稼働などを合意する
UATシナリオとロールバック責任
受け入れテスト（UAT）は、ベンダーに任せきりにせず、自社が主体となって進めます。
- テスト範囲：正常系に加えて、ばら返品、破損品の状態変更、緊急の出荷取消
- 例外処理：漏れなくテストし、稼働後のゴースト在庫や欠品クレームを防ぐ
- 切り戻し判断：エラー率や棚卸差異率の基準、旧システムへ戻す判断者
- 機器の保持：稼働後も最低3ヶ月、旧システムと旧ハンディ端末を残す
端末を早く処分すると、旧システムに再接続できず、業務が止まるおそれがあります。
入出庫管理システム移行の外注でよくある失敗と回避策
外注時に起こりやすい失敗は、事前の対策でほとんど防げます。
ベンダー丸投げによる例外処理漏れ
最も多い失敗は、要件定義を丸投げしたまま、現場の例外処理が仕様に入らず稼働してしまうことです。
- 起こりやすい漏れ：例外作業が仕様に入らず、在庫差異が残る
- 具体例：破損品を隔離しても状態を変えず、ゴースト在庫が引当に回る
- 社内の役割：業務担当者と現場リーダーによる例外の洗い出しと、ベンダーへの共有
- ベンダー選定：例外処理を仕様に反映でき、在庫精度を守れる会社かどうか
開発の専門性は外注で借りられますが、自社の業務理解まで手放さないようにします。
現場教育不足と費用の見落とし
教育体制と、システム本体以外の費用を、発注前に洗い出しておきます。
- 教育：稼働直後は効率が落ちるため、マニュアルや研修支援の有無と期間を確かめる
- 切替時期：閑散期に設定し、二重入力で工数が1.5〜2倍になる繁忙期は避ける
- 端末費用：ハンディ端末は1台あたり5万〜30万円で、必要台数分を見込む
- 倉庫移転費用：旧倉庫の出庫作業費、早期解約違約金、割増保管料
- 費用規模：移転を伴う場合は、上記の費用が月額保管料の3〜6ヶ月分になることもある
発注前の予算に織り込んでおかないと、後から資金繰りに苦しむおそれがあります。
まとめ
移行を外注するにあたっては、目的と課題を数値で整理し、必須要件と希望要件を切り分けることが出発点になります。提供形態ごとの特徴を理解したうえで、物流ノウハウと開発力を質問で見極めます。
RFPで要件を伝え、見積りの範囲をそろえて比べることで、丸投げによる失敗を避けやすくなります。契約前には、旧DBへのアクセス、データ引き上げ費用、解約条件などを確かめておきます。
データ移行と並行稼働は、どこまでを誰が受け持つかを外注先と決めておきます。UATやロールバックの責任についても、あらかじめ取り決めておきます。そのうえで、例外処理の漏れ、現場教育の不足、隠れコストの見落としを防ぎ、発注計画に反映しておきましょう。
▼全体ガイドの記事
・入出庫管理システム移行の完全ガイド
▼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を創業。