WMSのリアーキテクチャの発注/外注/依頼/委託方法について

WMSのリアーキテクチャを外注する流れは、まず発注前に現状と目指す姿を整理し、次にRFP(提案依頼書)で要件を共有し、最後に契約と役割分担を明確にする順です。この順に進めると、段階移行を安全に進められます。

全体像は、WMSのリアーキテクチャの完全ガイドもご覧ください。

▼全体ガイドの記事
・WMSのリアーキテクチャの完全ガイド

WMSのリアーキテクチャ外注前の整理事項

発注前に現状とゴールを固めておかないと、提案がかみ合わず、契約後に範囲の認識違いが起きやすくなります。既存システムと業務が動いたまま作り替えるため、現状把握は欠かせません。さらに、自社の状況を言語化できるほど、RFPの精度と見積もりの妥当性が高まります。

リアーキテクチャの目的と対象範囲の明確化

外注の前に、リアーキテクチャで何を実現したいのか、どこまで作り替えるのかを決めておきます。

  • 現状の課題:レスポンス遅延や、属人化・ブラックボックス化した過度なカスタマイズの解消。
  • 将来への対応:EOL/EOSL、EC化、多品種少量化への備え。
  • 対象範囲:入出庫、在庫引当、ピッキング、出荷のうち、負債のある機能から選ぶ。

目的が曖昧なままだと、ベンダーから全面再構築の提案が出て、見積もりが膨らむおそれがあります。一方で、在庫引当だけが複雑化しているなら、その領域をサービスとして切り出せることもあります。全面刷新よりも、効果の高い領域から段階的に手を入れるほうが、投資対効果は高まります。

現場の例外処理と暗黙仕様の洗い出し

旧システムの暗黙仕様を取りこぼさないために、現場の例外処理を洗い出しておきます。

  • セット品:2個1セットの商品を1個だけ返品するケース。
  • 破損品:物理的に隔離しても、論理ステータスの変更が漏れるケース。
  • サンプル:記録を残さない持ち出し。

画面やソースコードからは、例外が旧システムでどう吸収されていたかが見えません。そのため、例外の扱いを洗い出さずに新構造へ移すと「ゴースト在庫」が生まれ、欠品クレームにつながります。そこで、自社のベテラン担当者に聞き取り、正規フロー外の作業と、画面に出てこない必須処理を記録しておきます。

洗い出しを怠ると、要件定義で聞き漏れが生じ、稼働後に在庫差異が出るおそれがあります。一方で、例外を伝えておけば、RFPの質も高まります。

ポイント

社内で目的と対象範囲を言葉にでき、現場の例外処理も挙げられた段階が、発注に進む一つの目安になります。ここが曖昧なまま見積もりを取ると、各社の提案を比べにくくなります。

発注先の種類とリアーキテクチャに強いパートナーの選び方

パートナーの物流理解、段階移行、機能分割とデータ分離、外部連携を示す4つの観点
提案内容に加えて、移行と連携の経験も見比べられます。

外注先のタイプによって、初期費用、自由度、運用後のコスト構造が変わります。見積もり額だけで比べると、中長期で割高になったり技術的負債が残ったりすることがあります。そのため、目的に合わせて選ぶ必要があります。

SaaS移行・パッケージ・スクラッチ・AI駆動開発の選択肢

方式によって、初期費用、運用費、業務への適合度が異なります。

  • SaaS:初期費用を抑えやすく、数ヶ月での稼働が見込めます。
  • パッケージ:オンプレ型なら、一定のカスタマイズが可能です。
  • フルスクラッチ:自社業務に合わせて自由に構築できます。
  • AI駆動開発:工期とコストを従来比30〜70%圧縮するケースがあります。

SaaSは、標準機能に業務を合わせられる企業に適しています。一方で、出荷件数の多い大規模倉庫では、従量課金による中長期のコストに注意が必要です。

パッケージの年間保守費は初期構築費の15〜20%で、固定費になります。さらに、カスタマイズが積み重なると、パッケージでも再び負債化するリスクがあります。

フルスクラッチは業務に100%合わせられますが、従来は開発に半年から1年以上かかり、費用も高額でした。これに対し、AI駆動開発は、パッケージ並みの予算で自社に100%合うシステムを作る選択肢として注目されています。

モノリスを段階的に分解するには、柔軟な開発手法に対応できるかどうかも評価の軸になります。

物流ノウハウとアーキテクチャ設計力の見抜き方

発注側は、候補先の物流理解と設計力を提案書と合わせて確かめます。

  • 物流理解:こちらが聞く前に、例外処理や在庫の時点整合性を質問してくるかどうか。
  • 移行実績:稼働中のシステムを止めずに段階移行した経験の有無。
  • 設計経験:モノリスを機能単位で切り出し、データ層を分離した実績。
  • 連携実績:ERP、OMS、TMSとのAPI・EDI連携の経験の有無。

移行実績を重視するのは、旧システムを動かしたまま置き換える段階的移行(ストラングラーパターン)が現実的だからです。

機能の説明だけで終わる会社は、稼働後の運用で苦労する可能性があります。そこで、導入企業へのヒアリングや稼働中画面のデモを依頼すると、実力を確かめやすくなります。

比較基準をさらに詳しく見たい場合は、おすすめの開発会社をまとめた記事も参考になります。

ポイント

候補を絞るときは、段階移行と連携の実績があるかを先に見ておくと、比べる軸がそろいます。見積額の大小は、5年TCOと合わせて判断します。

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

背景と目的、現状と要件、KPIと連携、条件と評価の4項目を並べたRFP構成図
4つの情報群をそろえると、提案の前提を合わせやすくなります。

RFP(提案依頼書)は、要件を伝えて、各社から比べられる提案を得るための文書です。前提がそろっていないと見積もりを比べられず、ベンダー任せになりがちです。

そこで、現状と目指す姿、評価軸を示すと、提案と見積もりの精度が上がります。特に、リアーキテクチャでは、現行システムの構造をどこまで開示できるかが提案を左右します。

丸投げを避けるRFPの構成

比較できる提案を得るために、RFPには次の4つの情報をそろえます。

  • 背景と目的:プロジェクトの理由と目指す姿。
  • 現状と要件:As-Is業務とシステム構成、目指す姿(To-Be)、必須・希望要件。
  • KPIと連携:達成目標と連携対象システム。
  • 条件と評価:想定スケジュール、予算レンジ、評価基準。

また、現行DBの構成、カスタマイズ箇所、処理性能も、開示できる範囲で整理しておきます。内部情報を示すほど、ベンダーが作り替えの難易度を見積もる材料がそろいます。

KPIは、「ピッキング指示の応答時間を3秒以内」「夜間バッチを4時間以内に短縮」のように数字で示します。要望だけを並べるより、必要な背景を伝えたほうが、段階移行や代替案の提案を引き出せます。

評価基準を事前に示しておけば、判断がぶれにくくなり、社内での合意形成にもつながります。さらに、ベンダーからの質問を受けて、RFPも継続的に見直しながら運用します。

自社特有要件と連携・段階移行要件の伝え方

自社の例外処理、外部連携、段階移行の条件を具体的にしたうえで、RFPに記載します。

  • 例外処理:バラ返品の月件数と破損品の扱い。
  • ERP連携:リアルタイムAPIかCSVバッチかの方式。
  • 機器連携:WCS/WESの追加開発費の見積もり。
  • 段階移行:切り出す機能と、旧新間のデータ同期。

たとえば、「在庫管理を正確にしたい」と書くと解釈が分かれ、追加開発の原因になります。

また、自動倉庫やAGV・AMRがある場合は、WCS/WESとの連携が500万〜3,000万円規模の追加開発になることもあります。連携方式によって工数や障害時のリスクが変わるため、契約前に各社の連携・移行実績を確かめておくことが、稼働後のトラブルの防止につながります。

ポイント

KPIを数字で示せない項目があれば、社内で目標がまだ決まっていないサインと考えます。その項目はRFPを出す前に詰めておくと、各社の提案を同じ前提で比べられます。

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

次の刷新やベンダーの変更時に、データを出せずに高額な費用が生じる例があります。そのため、発注時には契約の条項に加えて、「撤退(Exit)」の条項も確認しておきます。

また、技術的負債を解消しても新たなロックインを抱えないよう、撤退の条件を定めておくことが大切です。

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

移行や将来の撤退に備えて、旧DBへのアクセス権やデータ引き上げの条件を契約で確かめておきます。

  • 旧DBアクセス:自社に権限がない場合の、旧ベンダーへの抽出依頼。
  • 抽出費用:1回数十万円で、反復すると百万円単位になることもある。
  • 返却条件:CSVやDBダンプの形式、マスタ・トランザクション・履歴の提供範囲、費用上限。
  • 権利帰属:新ベンダーのデータ返却、ソースコード、設計書の扱い。

段階移行では、テストやリハーサルのたびに抽出を繰り返すことになります。そのため、条件を決めておくと、次の刷新で同じ苦労を避けられます。

解約条件と保守・SLAの取り決め

費用と稼働の継続への影響を見ながら、契約時に次の条件を確かめます。

  • SaaS:最低契約期間と中途解約時の違約金。
  • オンプレ・スクラッチ:保守更新条件と解約予告期間。
  • 保守費・TCO:初期構築費の年15〜20%を含めた、5年・7年での試算。
  • SLA:復旧目標、サポート時間、初動応答、繁忙期の体制。

WMSが止まると、出荷と売上に直結します。そのため、繁忙期の対応体制も契約前に確かめておく必要があります。

費用の内訳や相場については、見積相場をまとめた記事も判断材料になります。

ポイント

契約書に撤退時のデータ返却の形式や費用上限が書かれていなければ、その時点で締結を急がず、条件を詰め直すのが目安になります。

外注先と握るべき役割分担

自社とベンダーの役割を比較し、自社のマスタ整備と受け入れテスト、ベンダーの移行ツール開発と投入を示す図
移行作業と受け入れ確認の担当を分けて整理できます。

リアーキテクチャでは、外注先に任せる作業と自社が担う作業が混在します。分担が曖昧だと、作業の押し付け合いが起きて、プロジェクトが停滞しかねません。そこで、契約時に作業分担表(RACIなど)を作り、責任の所在を文書にしておきます。

データ移行とUATシナリオの責任の切り分け

WMSの作り替えでは、失敗の約7割がデータに起因すると言われます。また、移行は抽出、クレンジング、投入の工程に分かれます。

  • 役割分担:一般に自社はマスタのクレンジングと名寄せ、ベンダーは移行ツールの開発と投入を担う形が現実的。
  • 移行基準:過去12ヶ月の実績がないマスタや休止ロケーションは移行対象外。
  • 時点整合性:抽出から投入までに生じる在庫差分の担当者。
  • UAT:例外業務を含む受け入れテストシナリオを、自社が作成すること。

ベンダーのテストは正常系が中心になりやすいため、現場の例外が漏れることがあります。そこで、セット品のバラ返品、破損品処理、緊急出荷が新構造で正しく流れるかを、自社の目で検証しておきます。

並行稼働とロールバック責任の明確化

並行稼働と切り戻しに備えて、運用ルール、終了条件、判断権限を決めておきます。

  • 二重入力:並行稼働で工数は1.5〜2倍。出荷指示書は新システムに一本化する。
  • Exit Criteria(終了条件):例としてエラー率0.5%未満、API連携が4週間安定稼働。
  • 切り戻し:棚卸差異率などの判断基準と実行権限。
  • 旧環境の保持:旧端末とライセンスを最低3ヶ月維持すること。

新旧両方から指示書を出すと、誤出荷につながります。機能単位で移行する場合は、個別に戻せる設計にしておきます。また、旧端末を早期に処分しないことで、切り戻せなくなる事態も防ぎます。

棚卸差異率の基準がないと、出荷停止が続くおそれがあります。全体の進め方は、プロジェクト手順をまとめた記事も参考になります。

ポイント

作業分担表の中で、UATのシナリオ作成や切り戻しの判断者が決まっていない項目は、役割分担が未完成だと考えるのが目安です。

WMSのリアーキテクチャ外注でよくある失敗と回避策

よくある失敗を知っておくと、同じ問題を避けやすくなります。主な原因は、発注側の準備不足、連絡設計の甘さ、作り替えへの過度な期待です。

ベンダー丸投げと隠れコストの罠

丸投げによる要件の漏れや、見積もりに出にくい費用は、発注前に洗い出しておきます。

  • 要件漏れ:自社固有の運用や暗黙仕様をRFPに記載すること。
  • SaaS費用:初期0円と月20万円なら5年で1,200万円、初期100万円と月10万円なら700万円。
  • 周辺費用:端末は1台5万〜30万円。Wi-Fi整備や導入支援費も見込む。
  • 倉庫移転:月額の3〜6ヶ月分の移動手数料が生じることもある。

現場の運用を知っているのは自社です。そのため、要件の整理を怠ると、在庫差異や業務の混乱につながります。

初期費用が無料でも、従量課金のため割高になる場合があります。そこで、本体価格と周辺費用を含めた5年TCOで判断します。

現場教育不足と切替タイミングの誤り

教育と切替時期を計画しておき、移転を伴う場合は出荷停止中の対応も決めておきます。

  • 現場教育:UATからキーパーソンを巻き込んで、操作に慣れてもらうこと。
  • 切替時期:二重入力と出荷ピークが重ならない閑散期。
  • 倉庫移転:出庫費、解約違約金、割増保管料、棚卸費の見込み。
  • 出荷停止:段階移転とバックオーダー消化を、外注先と調整すること。

新しいシステムに納得できないと、旧来の方法に戻ってしまい、入力が崩れて在庫精度が落ちます。そのため、研修は稼働直前に詰め込むより、UATの段階から操作に慣れておくほうが定着につながります。

まとめ

外注は、目的と対象範囲、現場の例外の整理から始めます。その後は、RFP、契約、役割分担へと進めていきます。旧DBのアクセス権やデータ引き上げ費、並行稼働時の指示と切り戻し条件も、あわせて確かめておきます。

WMSは在庫と出荷を支えるため、作り替えの成否は現場の混乱や追加費用に直結します。だからこそ、本体価格に加えて5年TCOや隠れコスト、撤退時の自由度を見て発注先を選ぶことが大切です。

自社が担う領域を決めたうえで、段階移行を安全に進められるパートナーに委託します。また、AI駆動開発も選択肢に入れ、技術的負債を残さない発注方法を検討します。

▼全体ガイドの記事
・WMSのリアーキテクチャの完全ガイド

会社紹介

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

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

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

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

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

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