入出庫管理システムの更改を検討し始めると、多くの担当者がまず悩むのが「どこに、どう発注すればよいのか」という点です。製品カタログや機能比較の情報は数多く見つかりますが、実際に外注・委託を進める段階になると、要件のまとめ方や契約条項の確認、旧ベンダーからのデータ引き上げといった泥臭い実務でつまずくケースが後を絶ちません。発注の進め方を誤ると、稼働後に在庫差異が多発したり、見積もりに含まれない費用が次々と発生したりと、当初の想定を大きく超えるコストとリスクを抱え込むことになります。
本記事では、入出庫管理システム更改を外注・委託する際の発注の進め方を、発注先の選び方から要件整理、RFP(提案依頼書)の書き方、契約条項の確認、役割分担の握り方まで体系的に解説します。特に競合記事では触れられにくい「旧システムからの撤退コスト」「データ移行の責任分界」「並行稼働の終わらせ方」といった移行実務の勘所を、具体的な数字とともにお伝えします。これから発注準備を進める情シス担当者や物流部門の責任者の方が、ベンダー任せにせず主導権を握って進めるための実践的な指針として活用いただけます。
▼全体ガイドの記事
・入出庫管理システム更改の完全ガイド
入出庫管理システム更改の発注形態と外注先の種類
入出庫管理システムの更改を外部に委託する場合、発注先は大きく分けて四つのタイプに分類されます。それぞれ得意領域や費用感、カスタマイズの自由度が異なるため、自社の業務特性と要件に合った発注先を選ぶことが、更改プロジェクトの成否を左右します。まずは発注先の種類を正しく理解し、自社がどのタイプに発注すべきかを見極めることから始めましょう。
発注先の主な種類とそれぞれの特徴
発注先の一つ目は、クラウド型(SaaS)のWMSを提供するベンダーです。月額数万円から利用でき、初期費用を抑えて短期間で導入できる反面、自社業務に合わせた細かなカスタマイズには制約があります。二つ目はパッケージ型(オンプレミス)のベンダーで、初期費用は数百万円以上かかるものの、買い切り型で中長期のコストを抑えやすく、ある程度の業務適合も可能です。
三つ目は、複数のパッケージや周辺システムを組み合わせて構築するSIer(システムインテグレーター)です。ERPやTMSとの連携、自動倉庫やマテハン機器との接続など、複雑な要件をまとめて担えるのが強みとなります。四つ目はフルスクラッチ開発を手がける開発会社で、自社の例外処理や独自オペレーションに100%適合させたい場合に選択肢となります。
近年はAI駆動開発の普及により、スクラッチ開発の工期とコストが30〜70%圧縮できるようになりました。これにより「パッケージか、スクラッチか」という従来の二項対立が崩れ、パッケージ並みの予算で自社業務に完全フィットしたシステムを構築するという新しい選択肢が現実味を帯びています。発注先を検討する際は、この最新の開発潮流も視野に入れておくとよいでしょう。
内製と外注の使い分けの判断基準
すべてを外注するのではなく、自社で担う範囲と外部に委託する範囲を切り分けることも重要です。たとえば要件定義や業務設計は現場を最もよく知る自社が主導し、開発・移行・連携の実装部分を外注するという役割分担が現実的です。マスターデータのクレンジングや検収テストを自社が担うことで、ベンダー任せによる要件の抜け漏れを防げます。
一方で、社内に物流システムに精通した人材がいない場合は、上流の要件整理から伴走してくれるベンダーやコンサルを選ぶべきです。判断基準としては、自社の業務がどれだけ特殊か、社内に維持運用できる体制があるか、更改後の改修頻度がどの程度見込まれるかという三点で考えると整理しやすくなります。内製にこだわりすぎると属人化を再生産し、丸投げすぎると現場に合わないシステムができあがるため、バランスが肝心です。
外注・委託する前に整理しておくべきこと
発注の成否は、ベンダーに声をかける前の社内準備でほぼ決まると言っても過言ではありません。現状業務の課題を曖昧にしたまま発注すると、ベンダーは標準機能を提案するしかなく、結果として現場に合わないシステムが納品されてしまいます。発注前に自社で何を整理しておくべきかを押さえておきましょう。
現状業務(As-Is)の棚卸しと課題の言語化
まず取り組むべきは、現状の入出庫業務を一つひとつ可視化する作業です。入荷検品、格納、ピッキング、出荷検品、返品処理といった一連の流れを工程ごとに書き出し、どこで時間がかかっているか、どこで属人化が進んでいるかを洗い出します。特に注意したいのが「例外処理」で、2個1セットの商品を1個だけ返品する処理や、破損品を物理的に隔離したものの論理ステータスを変更し忘れるといった現場の運用が、在庫差異の温床になっています。
こうした例外処理を発注前に棚卸ししておかないと、新システムでも同じ在庫差異が再発します。在庫が合わない真因の多くは、システムの性能ではなく現場の「良かれと思った例外運用」にあります。サンプル品の無記録持ち出しや、セット品とバラ品の単位の食い違いといった細かな運用まで含めて言語化し、ベンダーに正確に伝えられる状態にしておくことが重要です。
必須要件(Must)と希望要件(Want)の切り分け
洗い出した要件は、絶対に外せない必須要件(Must)と、できれば実現したい希望要件(Want)に切り分けます。この切り分けがないと、すべてが「必須」として扱われ、カスタマイズ費用が際限なく膨らんでいきます。たとえば賞味期限管理やロット管理は食品物流では必須ですが、業種によっては不要なため、自社にとっての優先順位を明確にすることが費用最適化の第一歩となります。
切り分けの際は「標準機能で実現できることは標準に合わせる(Fit to Standard)」という発想を持つと、開発コストを大きく抑えられます。現場の慣れだけを理由にしたカスタマイズ要望は、本当に業務上必要かを問い直しましょう。一方で、自社の競争力の源泉となっている独自オペレーションは妥協せず必須要件として明示することで、発注後の追加開発や手戻りを防げます。
発注を成功させるRFP(提案依頼書)の書き方
RFP(提案依頼書)は、ベンダーから精度の高い提案と見積もりを引き出すための設計図です。RFPの完成度が低いと、各社の提案がバラバラの前提で作られ、横並びの比較ができなくなります。逆に丸投げのRFPでは、ベンダーが安全側に見積もりを膨らませるか、後から追加費用を請求する余地を残すため、発注側が損をします。RFPに何を書くべきかを具体的に押さえておきましょう。
RFPに必ず盛り込むべき項目
RFPには、プロジェクトの目的とゴール、対象業務の範囲、現状の課題、必須要件と希望要件、想定する予算とスケジュール、評価基準を明記します。特に重要なのが、現在の出荷件数や取扱SKU数、拠点数、ピーク時の処理量といった定量データを示すことです。これらの数字があってはじめて、ベンダーは必要なサーバー構成や端末台数、ライセンス数を正確に見積もれます。
あわせて、ERPやOMS、TMSといった周辺システムとの連携要件も具体的に記載します。連携方式がAPIなのかCSVなのか、リアルタイム連携が必要なのかバッチでよいのかによって、開発工数は大きく変わります。自動倉庫やAGV・AMRといったマテハン機器との連携がある場合は、500万円から3,000万円規模の追加開発が発生することもあるため、RFPの段階で明示し、責任分界点を確認できるようにしておきましょう。
自社特有の例外処理・連携要件の伝え方
RFPで最も伝え忘れやすいのが、現場の例外処理です。通常フローは標準機能で対応できても、イレギュラーな運用がシステムに反映されないと、稼働後に在庫差異やオペレーション停滞が起こります。返品時の単位変換、破損品のステータス管理、緊急出荷の優先順位付けなど、現場で実際に行われている例外処理を業務シナリオとして文章化し、RFPに添付すると効果的です。
例外処理を伝える際は「こういう場面で、誰が、どう操作し、在庫がどう変動するか」という粒度まで落とし込むと、ベンダーが対応可否と工数を正確に判断できます。曖昧な要望は曖昧な見積もりを生むため、できる限り具体的な事例で示すことが大切です。こうした下準備が、後の追加費用や認識齟齬を防ぐ最大の保険になります。
丸投げを避けるための工夫
丸投げを避けるには、発注側がプロジェクトの判断軸を持っておくことが欠かせません。RFPに評価基準を明記し、提案内容を点数化して比較する仕組みを用意すると、各社の提案を客観的に評価できます。価格だけでなく、物流業務への理解度、移行支援の手厚さ、稼働後のサポート体制といった定性的な観点も評価項目に含めましょう。
また、提案を受ける際にはデモやプロトタイプの提示を求め、実際の操作感を現場メンバーに確認してもらうことをおすすめします。提案書はどれも良く見えるものですが、実際に触ってみると現場との相性が見えてきます。発注側が主体的に関与する姿勢を見せることで、ベンダー側も緊張感を持って提案に臨み、結果として提案の質が高まります。
契約・委託時に確認すべき条項とリスク
発注先が決まったら契約に進みますが、ここで見落としがちなのが「旧システムからの撤退」に関する条項です。新システムの導入条件にばかり目が向き、現在使っているシステムから抜けるための条件を確認していないと、移行段階で予期せぬ高額費用に直面します。契約時に必ず確認すべきリスクと条項を押さえておきましょう。
旧ベンダーからのデータ引き上げ(撤退)条件
多くの企業が見落とすのが、旧システムのデータベースへの直接アクセス権が自社にないというケースです。この場合、移行テストやリハーサルでデータを抽出するたびに、旧ベンダーへ1回あたり数十万円のスポット費用を支払うことになります。移行作業は何度もリハーサルを重ねるため、抽出費用だけで数百万円に達することも珍しくありません。
こうした事態を防ぐには、新システムを発注する前に、現行契約の解約条件とデータの引き渡し条件を確認しておくことが不可欠です。データの抽出形式、提供範囲、費用、納期を契約書で明確にし、可能であればデータベースへの読み取りアクセス権を確保しておきましょう。撤退の出口戦略を発注前に描いておくことが、移行コストを大きく左右します。
検収条件・瑕疵対応・保守範囲の確認
契約書では、何をもって納品完了とするかという検収条件を明確に定めることが重要です。検収基準が曖昧だと、現場で不具合が出ても「仕様通り」と押し切られたり、逆に支払いをめぐってトラブルになったりします。出荷エラー率や処理速度といった定量的な合格基準を契約に盛り込むことで、双方の認識を揃えられます。
あわせて、稼働後の瑕疵対応期間と保守の範囲も確認しておきましょう。オンプレミスやスクラッチ開発の場合、年間保守費は初期構築費の15〜20%が固定的に発生するのが一般的です。保守に含まれる作業範囲と、追加費用が発生する範囲の線引きを契約段階で明確にしておかないと、稼働後の運用コストが想定を超えてしまいます。
外注先と握っておくべき役割分担と費用
発注後のプロジェクトを円滑に進めるには、発注側とベンダーの役割分担を事前に明確に握っておくことが欠かせません。役割が曖昧なまま進めると、データ移行やテストの責任の所在が不明確になり、トラブル発生時にお互いが責任を押し付け合う事態に陥ります。どの作業を誰が担うかを、プロジェクト開始前に文書で確認しておきましょう。
データ移行・UAT・並行稼働の責任分界
更改プロジェクトの失敗の約7割はデータに起因すると言われており、データ移行の責任分担は特に重要です。マスターデータのクレンジングは現場を知る自社が主導し、抽出から新システムへの投入はベンダーが担うといった分担を明確にします。クレンジングの基準としては、過去12ヶ月入出荷実績のないマスターや休止ロケーションは思い切って捨てるといった「12ヶ月ルール」を設けると、ゴミデータの持ち込みを防げます。
UAT(ユーザー受け入れテスト)は発注側の責任で実施し、通常フローだけでなくイレギュラーな例外処理のシナリオまで網羅することが重要です。並行稼働の期間中は、出荷指示書やピッキングリストを必ず新システムのみから出力する「指示系統の一本化」を徹底します。新旧両方から指示書が出ると重複ピッキングや誤出荷が連発するため、ここはベンダーと運用ルールを明確に握っておく必要があります。
見積もりに出にくい隠れコストの確認
発注時の見積もりには現れにくい隠れコストを、事前に把握しておくことも重要です。ハンディ端末は1台あたり5万円から30万円程度で、利用人数分の調達が必要になります。クラウド型は初期費用が抑えられる反面、従量課金が積み上がり、5年から7年のTCO(総保有コスト)で見るとオンプレミスより割高になる「コスト逆転」が起こり得ます。
たとえば初期費用0円で月額20万円のSaaSは5年で1,200万円、初期費用100万円で月額10万円のパッケージは5年で700万円となり、長期では後者が有利になります。さらにWMS刷新と倉庫移転を同時に行う場合は、旧倉庫からの出庫作業費や早期解約違約金、割増保管料などで月額の3〜6ヶ月分の移動手数料が発生します。こうした隠れコストを役割分担とあわせて確認し、TCOで総合的に判断することが大切です。
発注・外注でよくある失敗と回避策
入出庫管理システムの更改では、毎回似たような失敗が繰り返されています。これらは事前に知っておけば十分に回避できるものばかりです。代表的な失敗パターンと、その回避策を具体的に押さえておきましょう。
ベンダー丸投げによる要件抜け漏れ
最も多い失敗が、要件定義をベンダーに丸投げしてしまうケースです。現場を知らないベンダーは標準的な業務フローを前提に設計するため、自社特有の例外処理が抜け落ち、稼働後に在庫差異やオペレーション停滞が発生します。物理的に隔離した破損品のステータスを変更し忘れると、引当対象に残ったゴースト在庫が欠品クレームを引き起こすといった事故も起こります。
回避策は、要件定義に現場メンバーを必ず参加させ、例外処理を含めた業務を発注側が主導して言語化することです。ベンダーはあくまで実現手段の専門家であり、業務の専門家は自社である、という役割認識を持つことが大切です。定例ミーティングで進捗と認識を継続的にすり合わせる体制を組むことで、要件の抜け漏れを早期に発見できます。
現場教育不足と並行稼働の崩壊
もう一つの典型的な失敗が、現場教育の不足と並行稼働の崩壊です。新システムの操作研修が不十分なまま本番を迎えると、現場が混乱し、入力ミスや作業遅延が多発します。さらに並行稼働中は新旧両方への二重入力が必要となり、現場の工数は通常の1.5〜2倍に膨れ上がるため、繁忙期に切り替えを行うと現場が崩壊します。
回避策として、並行稼働や本番切り替えは必ず出荷量の少ない閑散期に設定します。並行稼働には「出荷エラー率0.5%未満」「API連携が4週間安定稼働」といった明確な終了条件(Exit Criteria)を定め、達成できたら速やかに旧システムを停止します。また、旧システムや旧ハンディ端末は稼働後も最低3ヶ月は保持し、万一のロールバックに備えることで、業務停止のリスクを最小化できます。
まとめ
入出庫管理システム更改の発注・外注を成功させる鍵は、ベンダーに声をかける前の社内準備と、移行実務・撤退戦略まで見据えた契約・役割分担にあります。発注先の種類を理解したうえで自社に合うタイプを選び、現状業務と例外処理を棚卸しして必須要件と希望要件を切り分け、精度の高いRFPで横並びの比較ができる状態を作ることが出発点です。
契約段階では、旧ベンダーからのデータ引き上げ条件や検収基準、保守範囲を必ず確認し、データ移行やUAT、並行稼働の責任分界を文書で握っておきましょう。ハンディ端末や年間保守、倉庫移転の手数料といった隠れコストも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を創業。