入出庫管理システム刷新の発注/外注/依頼/委託方法について

入出庫管理システム刷新を外注するときは、現状の業務と要件を整理し、RFP(提案依頼書)を作り、契約と役割分担を固める順で進めます。この順で進めると、見積もりの精度が上がります。

外注前の準備から発注先の選び方、RFPの作成、契約と費用の確認まで、順に見ていきます。

▼全体ガイドの記事
・入出庫管理システム刷新の完全ガイド

入出庫管理システム刷新を外注する前の整理

発注の成否は、社内の業務をどこまで言葉にできているかで大きく変わります。要件が固まらないまま相談を始めると、見積もりの精度が下がり、総コストにも影響します。

現状業務の棚卸しとAs-Is整理

まず、誰が、いつ、どの端末で何を入力するかまで業務を分解します。そのうえで、入荷から返品までの流れを工程ごとに書き出し、システム外の運用も一覧にします。

  • 入荷検品、棚入れ、ロケーション管理
  • ピッキング、出荷検品、返品処理
  • Excel、紙、口頭で続けている運用

とくに注意したいのが、現場が独自に行う例外処理です。例外処理は在庫差異の原因になりやすいため、丁寧な確認が欠かせません。たとえば、2個セットのうち1個だけが返品されると、管理単位が食い違うことがあります。

また、破損品を隔離しても、システム上の状態を変え忘れるとゴースト在庫が発生します。サンプル品を記録せずに持ち出す運用も典型例です。こうした例外は、As-Isの段階で拾っておかないと、刷新後も差異が残ります。

必須要件と希望要件の切り分け

優先度を決めるには、業務に欠かせない要件と、使いやすさへの希望を分けて考えます。

  • Must:ロット・賞味期限・色サイズなど商材特性に関わる要件
  • Must:ERP・OMSとの在庫連携など、業務停止につながる要件
  • Want:UIの好みや帳票レイアウトの細部

すべてを必須にすると、パッケージで対応できる範囲が狭まり、改修費と納期が膨らみます。また、Mustが曖昧なままだと、標準機能に合わせた結果、根幹業務が回らなくなる恐れがあります。

要件を切り分けるとRFPの精度が上がり、各社の見積もりを同じ条件で比べられます。逆に、曖昧なまま発注すると各社の前提がずれ、価格だけでは適正な比較ができません。

ポイント

Mustかどうか迷う要件は、止まったときに出荷や在庫の数字が合わなくなるかを基準に判断します。判断が分かれたものは、現場の担当者と一緒に業務の流れを確かめてから決めます。

発注先(外注先)の種類と選び方

SaaS、パッケージ、スクラッチ、AI駆動開発の特徴を4枚のパネルで示した図。
標準機能への適合から個別開発まで、選択肢の幅が見渡せます。

発注先は主に4タイプです。得意領域と費用の仕組みを、自社の要件に照らして選びます。

AI駆動開発の登場で、従来の選択肢の前提も変わりつつあります。

SaaS・パッケージ・スクラッチ/AI駆動開発の特徴

導入の手軽さ、業務への適合度、費用や期間は、選択肢によって差が出ます。その差は、以下に挙げる各タイプの特徴に表れています。

  • SaaS:初期費用を抑え、数ヶ月で稼働しやすい
  • パッケージ:業種特化機能があり、一定範囲をカスタマイズできる
  • スクラッチ:業務に合わせられるが、従来は半年〜1年以上かかる
  • AI駆動開発:設計・実装を効率化し、工期とコストを圧縮できる場合がある

SaaSは、標準機能に業務を合わせるFit to Standardが前提です。さらに、従量課金が積み上がると、中長期では割高になる傾向があります。

パッケージは、改修の範囲が広がるほど費用が膨らみます。一方、スクラッチは自社の業務に100%合わせられますが、従来は高額な費用も課題でした。

AI駆動開発を用いた場合、スクラッチ開発の工期とコストを30〜70%圧縮できた事例があります。その結果、パッケージ並みの予算で自社に100%合うシステムを作る選択肢が、現実味を帯びています。

開発形態は、業務の特殊性と許容できるコストを合わせて判断するのが基本です。

物流ノウハウと開発力の見抜き方

提案書や実績数だけでは、物流現場の実務をどこまで理解しているかは判断しにくい面があります。そこで、現場の業務に即した質問を投げかけ、受け答えの具体性から見極めます。

  • 現場知識:在庫の時点整合性、フリーロケーション、フォークの旋回半径
  • 運用対応:繁忙期と閑散期の切替に対する具体策
  • 連携実績:ERP・OMS・TMSやWCS・WES、マテハン機器との接続
  • 移行・撤退支援:データ移行や撤退時のデータ引き上げへの対応

同種の物流案件で連携まで完遂した実績があるかは、契約前に確認します。障害時の責任分界は曖昧になりやすく、複数社が関わると原因の切り分けに時間がかかります。そのため、質問で確かめた答えは、契約前に文書で残しておきます。

ポイント

標準機能で足りない業務が多いなら個別開発を、少ないならSaaSやパッケージを候補にするのが目安です。候補を絞ったら、業務の特殊性と許容できるコストで最終的に判断します。

RFP(提案依頼書)の書き方と丸投げの回避

RFPに記載する目的・範囲、現状・要件、連携・規模、提案条件を4枚のチェックカードで示した図。
4つの観点をそろえると、各社の提案を同じ前提で見比べられます。

RFP(提案依頼書)は、丸投げを防ぎ、各社を同じ条件で比べるための最も重要な書類です。

内容が不十分だと、各社が前提を独自に解釈してしまい、後から追加費用につながります。完璧な仕様書でなくても構いません。ただし、判断に必要な情報は漏れなく盛り込みます。

RFPに盛り込むべき項目

見積もりの前提を揃えるため、RFPには次の情報を記載します。

  • 目的・範囲:プロジェクトの目的、解決したい課題、対象業務
  • 現状・要件:現行構成と課題、Must/Want別の機能要件
  • 連携・規模:連携先と方式、品目数や出荷件数
  • 提案条件:希望日程と予算、提案してほしい形式

出荷件数や拠点数は見積もりを大きく左右するため、繁忙期のピーク値も具体的に示します。さらに、データ移行の対象や並行稼働、稼働後の保守運用についても、希望する条件を書き込みます。評価基準と日程を示しておくと、各社の提案内容と熱意を公平に比べられます。

自社特有の例外処理要件の伝え方

RFPの差は、自社独自の例外処理をどこまで具体化できるかに表れます。

  • 返品:セット品の一部だけを返品する運用
  • 在庫状態:不良品の状態変更やサンプル品の持ち出し
  • 緊急出荷:現場で行うイレギュラーな対応

その内容は、文章とフロー図を使って具体的に伝えます。「現行通り」とだけ書くと、ベンダーは運用を再現できず、刷新後に在庫差異が再発します。

例外処理は件数が少なくても在庫精度や顧客クレームに直結するため、頻度と業務への影響も併せて伝えます。

情報が揃えば、標準機能で対応するかカスタマイズするかを、ベンダーが判断できます。そのうえで、丸投げを避けるには、例外の領域を自社の言葉で説明し切ることが欠かせません。

ポイント

ベンダーからの質問が前提の確認ばかりになったら、RFPの記載が不足している合図です。例外処理と出荷件数の記載から補うと、見積もりの前提がそろいやすくなります。

契約・撤退時に確認すべき条項

旧DBアクセス権、データ引き上げ費用、旧端末の保持、解約条件でシステム移行を支える図。
データ、端末、解約条件の確認箇所が移行前に整理できます。

契約時には機能だけでなく、旧システムからの撤退条件も確認しておきます。出口を軽視すると、移行時に高額な費用がかかったり、データを取り出せなくなったりします。

旧DBアクセス権とデータ引き上げ費用

旧データベースに自社で直接アクセスできない契約は、移行の落とし穴になります。旧ベンダーだけがアクセス権を持つ場合、データを抽出するたびに費用がかかることがあります。

  • 抽出費用:テストやリハーサルで1回あたり数十万円の例がある
  • 旧契約:解約条件、DBアクセス権、データ返却方法と費用を確認する
  • 新契約:将来の乗り換えに備え、データの可搬性を担保する

移行は何度もリハーサルを重ねるため、費用が積み重なると無視できません。そのため、旧契約の条件は選定の段階で見直しておく必要があります。

また、Exit戦略は新ベンダーに任せきれず、発注企業が主体となって進める必要があります。

解約条件と切り戻し・端末保持

切替後のトラブルに備え、旧システムと旧端末を保持する期間を契約時に決めます。

  • 切り戻し:新システム稼働後も旧端末とライセンスを最低3ヶ月保持
  • 倉庫移転費:倉庫移転を同時に進める場合、諸費用が月額保管料の3〜6ヶ月分に達することもある
  • 移転計画:解約予告期間と違約金を確認し、段階移転とバックオーダー消化を計画

旧端末を早く捨てると、再接続できず業務が止まる事態を招きます。移転の費用には、出庫作業費と早期解約違約金が含まれます。割増保管料や棚卸費も、あらかじめ見込んでおきます。事前に移転の計画を立てておくと、想定外の出費を抑えられます。

ポイント

解約予告期間と違約金の条件は、切替日から逆算して確認すると、移転計画の抜けを減らせます。切り戻し用の旧端末を残す期間も、同じ日程表に書き込んでおきます。

外注先との役割分担と費用の考え方

外注では、発注企業とベンダーの役割を分けて進めることが前提になります。役割が曖昧だと責任の空白が生まれ、トラブル時に押し付け合いになります。特に、データ移行、テスト、稼働判断には発注企業の関与が欠かせません。

データ移行・UAT・ロールバックの責任分界

移行の失敗は約7割がデータに起因するといわれます。そのため、分担は次のとおりに決めておきます。

  1. 発注企業が業務を知る立場から、マスタのクレンジングと名寄せを主導する。
  2. 過去12ヶ月に入出荷実績のないマスタや休止ロケーションを捨てる基準を決め、ベンダーには移行ツールの提供と検証を依頼する。
  3. UAT(受け入れテスト)では発注企業が正常系と例外シナリオを用意し、現場が実操作で検証する。
  4. 切替時はエラー率や棚卸差異率などのロールバック基準と判断者を決める。
  5. 並行稼働では出荷指示書やピッキングリストを新システムのみから出し、誤出荷を防ぐ。

隠れコストと5年TCOの確認

初期費用だけでなく、5〜7年のTCO(総保有コスト)で比較します。月額料金や導入形態による5年費用の差は、次の例で確認できます。

  • SaaS:初期費用0円、月額20万円なら5年で1,200万円
  • オンプレ型:初期費用100万円、月額10万円なら5年で700万円
  • 従量課金:単価と利用量に応じた増え方を確認する
  • 端末・保守:端末は1台5万〜30万円、保守費は初期構築費の15〜20%
  • 移行・移転:旧ベンダーの抽出費用と倉庫移動手数料も含める

この例では、初期費用が0円のSaaSのほうが、5年の総額では割高になります。ハンディ端末は人数分の台数が必要になります。また、オンプレやスクラッチでは、保守費が毎年発生します。

TCOで比べておけば、発注後に想定外の費用が出る事態を避けられます。

ポイント

業務の正しさを判断する部分は発注企業が、移行ツールや技術の検証はベンダーが受け持つと、責任の線を引きやすくなります。

まとめ

外注の成否は、発注前に社内の業務をどこまで整理できたかで大きく変わります。例外処理を含む現状業務を洗い出し、Must/Wantを分けてRFPに盛り込めば、見積もりの精度が上がります。

発注先は、SaaS・パッケージ・スクラッチに加えてAI駆動開発も候補にしたうえで、物流ノウハウと連携実績をもとに選びます。旧DBへのアクセス権やデータ引き上げ費用、端末保持といった撤退条件は、契約時に確かめておきます。

移行、UAT、ロールバックの役割を決め、隠れコストを含めた5年TCOで比べることが、現場を止めない刷新につながります。

発注の各論を知りたい方は、進め方・費用相場・おすすめ会社の各記事もご覧ください。

▼全体ガイドの記事
・入出庫管理システム刷新の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。