倉庫業界のシステム発注は、現場業務の可視化、要件と責任範囲の合意、外部連携・移行・保守の整理の順に進めると、手戻りを抑えた導入につながります。
RFPや要件定義書に書く内容を、発注企業の視点で順に見ていきます。全体像は倉庫業界のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・倉庫業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングと業務標準化を起点とした進め方
要件定義は、DXの流行に合わせて始めるよりも、現場の業務プロセスを把握することから始めます。目的が曖昧なまま高機能なシステムを導入すると、現場と合わず使われないおそれがあります。
入庫から棚卸までの各工程を、作業者へのヒアリングで可視化することが土台になります。WMS導入は失敗率が60%を超えるとも指摘されており、その一因として、業務を曖昧にしたまま発注することが挙げられています。
AsIs可視化とToBe設計の進め方
発注側は現場と協力して、現状業務（AsIs）を可視化し、あるべき姿（ToBe）を設計します。関係者への聞き取りでは、実際の作業を確かめるとともに、無駄や手戻り、二重入力の有無も確認します。
長年の慣行には、ベテランにしかできない手順や不要な工程が紛れていることがあります。これをそのまま要件にすると、複雑で使いにくいシステムになります。
- 現状を図にする：入庫担当、ピッカー、出荷検品、在庫管理、配車の業務フローを、担当ごとに図で整理します。
- 業務を標準化する：不要な工程や属人的な手順を見直し、シンプルにしてからシステム化します。
- ToBeを共有する：描いた業務フローをRFPに添付し、目指す姿をベンダーに示します。
現状の棚卸しを省くと、暗黙のルールや例外処理が要件から抜け落ち、開発後に現場が回らなくなります。そこで、業務標準化（AX）を経てからRFPに記載することが、定着につながります。
導入目的とスコープの明文化
RFPには、導入目的とスコープ（対象範囲）を明記します。目的を測定できる形にしておくと、ベンダーの提案と評価軸が明確になります。
- 誤出荷率：現状からどの水準へ下げるかを示します。
- 棚卸差異：差異をゼロに近づける目的を掲げます。
- 出荷処理時間：何割短縮するかの目標。
「何%から何%へ」といった目標値は、元の業務実績に基づいて定めます。目的が曖昧だと、多機能な提案によって費用や複雑さが増すことがあります。
対象範囲は、たとえばWMSの入出庫・在庫管理までを対象とし、TMS連携や基幹連携は次フェーズとするといった形で線引きします。スモールスタートの場合は、初期実装と将来拡張を分けて記載します。目的とスコープの明文化は、後の要件凍結と費用管理を支えるRFPの中心です。
例外処理と繁忙期運用の聞き漏れ防止
通常の入出庫は整理しやすい一方で、例外にシステムが対応できないと現場が止まります。そこで、例外フローを掘り起こす質問を要件定義のヒアリングに組み込みます。
- 例外処理：返品、緊急出荷、ロット違いの差し替えを確認します。
- 繁忙期の取扱量：通常時の数倍になるピーク負荷を確かめます。
- 繁忙期の運用：応援人員や臨時の出荷形態の扱い。
繁忙期には、通常時の数倍の負荷で処理が遅れることも珍しくありません。そのため、ピーク時の条件を要件定義書に記載し、負荷耐性を確認しておくと、稼働遅延や現場の不満を防ぎやすくなります。
協力義務を踏まえた要件凍結のルール
発注側のユーザー企業にも、開発に協力する責任があります。開発が失敗した場合、ベンダーのプロジェクトマネジメント（PM）義務が語られます。一方で、判例ではユーザー側の協力不足も問われています。
RFPと要件定義書を整えることは、協力義務を果たす具体的な行動にあたります。要件が曖昧なまま開発を始め、後から追加要望を重ねると、発注側にも責任が及ぶことがあります。
協力義務違反が問われた判例の教訓
旭川医大病院とNTT東日本の事件では、発注側の協力義務違反が認定されました。この件の控訴審は札幌高裁で、判決日は平成29年8月31日です。
要件の確定後に、発注側が169項目の追加・変更を求めました。このうち124項目は、当初の対象外と判断されています。その結果、発注側のみに約14億1,500万円の支払いが命じられました。
この判例が示すのは、要件を後から際限なく膨らませると、重大な法的リスクを伴うということです。要件定義にとっての教訓は明確です。
- 対象範囲を合意する：RFPと要件定義書に記載し、合意後は安易に変えない運用にします。
- 追加要望を確認する：無制限に開発へ入れると、納期遅延、費用膨張、法的リスクを招きます。
- 要件定義書を整える：ベンダーへの指示書であると同時に、発注側の責任範囲を定める契約上の基礎です。
- 繁忙期の要望を扱う：追加要望は、範囲と影響を確かめてから判断します。
要件凍結と変更管理プロセスの定義
判例の教訓を実務に反映するには、発注側が要件凍結（フィックス）と変更管理のプロセスを定義します。
要件定義が完了した時点で凍結しておかないと、途中の要望がそのまま開発に入り込んでしまいます。そこで、凍結の前後で何をどう扱うかを、あらかじめ決めておきます。
- 対象を確定する：開発する範囲を文書にし、双方で合意します。
- 変更手順を決める：変更の判断者と正式な申請方法を定めます。
- 影響を評価する：費用と納期への影響を見てから判断する手順です。
変更はどうしても起きるため、一切認めない運用は現実的ではありません。RFPの段階でベンダーに手順を示し、正式な手続きと追加費用を共有しておけば、無用な摩擦を抑えられます。
riplaは、フルスクラッチ受託と国内開発の立場から、要件凍結と変更管理を含む要件整理を重視しています。発注側が協力義務を果たしながら進めることが、導入を成功に導く鍵だと考えています。
発注側のプロジェクト体制と参加者
要件定義はベンダー任せにせず、発注側の現場・管理・経営が担う共同作業として進めます。そのうえで、意思決定、現場知識の提供、最終承認の担当をそれぞれ明確にします。
- 意思決定者：プロジェクトの判断に責任を負う立場です。
- 現場担当者：業務知識を提供し、ヒアリングや確認に加わります。
- 承認者：要件や成果物を最終確認します。
現場に詳しい担当者は、専任で割り当てるのが望ましいです。通常業務と兼務すると確認の時間が足りず、要件の精度が落ちることがあります。
旭川医大事件が示すように、発注側の関与が足りないと、法的責任にもつながります。RFPの段階で体制を整えておくことは、遅延や要件の揺れを防ぐ基礎になります。体制づくりは、技術の検討より前に固める要件定義の出発点です。
外部EDI連携の事前協議の要件化
倉庫システムは、荷主・小売・運送会社などの取引先とデータをやり取りします。そのため、自社だけで要件を固めても、取引先のEDI仕様に合わなければ連携は成り立ちません。
要件定義の早い段階で、主要取引先の電子データ交換の仕様を確認します。外部関係者との事前協議も計画に入れておくと、後の手戻りを防げます。
仕様変更の3ヶ月前協議を前提とした設計
物流EDIの仕様変更には、リードタイムを見込んだ事前協議が欠かせません。実務上の目安は、取引先の変更を最低3ヶ月前から協議することです。
仕様確定とテスト日程は、全体の予定に組み込んでおきます。協議が遅れると、完成後にテストができず、稼働が遅れることがあります。
さらに、農協（JA）系統物流と商系物流など、複数の仕様が併存しています。そのため、各取引先の仕様と対応日程を整理し、連携要件を要件定義書に記すことが大切です。これは、競合が見落としがちな実務上の要点です。
連携対象と責任分界点の明記
連携要件をそろえるには、対象システムと責任分界点をRFPに記しておきます。変換処理やエラー対応の担当が曖昧だと、障害が起きたときに責任の押し付け合いになりかねません。
- 連携方式：EDI、API、ファイル連携のどれにするかを整理します。
- データ項目：連携する情報の範囲を記載します。
- 頻度と責任：連携頻度と、自社・取引先それぞれの担当範囲を示します。
連携の範囲を具体的にすると、見積もりの精度も高まります。連携先が多いほど開発工数と見積もりの幅が広がるため、対象と責任分界点を具体化し、各社が同じ前提で比べられるようにします。
外部連携は倉庫システムの費用と難度を左右します。だからこそ、要件定義で正確に押さえておくことが、後の予算超過を防ぐ要になります。
データ移行・クレンジングとSLAの要件化
データ移行とマスター整備（クレンジング）は、失敗の原因になりやすい工程です。機能が優れていても、汚れたデータを移せば、誤った情報を処理するだけになってしまいます。
商品や取引先のマスターが不正確なままでは、優れた機能も活かせません。だからこそ、移行とクレンジングは要件定義書に独立した項目として明記します。
3在庫の一致とマスター整備の要件化
本番稼働の前に、基幹システム、WMS、実物の三つの在庫を突き合わせます。誰が、いつ、どのように一致させるかを、計画に含めておきます。
在庫がずれると、システムの数字が信頼されなくなり、現場が数え直す二度手間に戻るおそれがあります。三在庫をそろえておくことが、稼働後の混乱を防ぎます。
- 商品コード：コードを統一し、廃番商品を整理します。
- 取引先情報：最新の状態に更新します。
- 移行データ：種類と件数、現状の品質を整理し、責任分担も決めます。
クレンジングは時間がかかるため、後半に押し込まれがちです。要件定義の段階で工数と担当を確保し、RFPにも必要な事項を記載しておきます。データの正確さは、システム機能と同じくらい稼働の成否を左右します。
SLAと保守範囲の明確化
RFPでは、SLA（サービス品質保証）と保守範囲を定義します。倉庫には24時間稼働の現場もあるため、停止が出荷や得意先への納品に影響します。
- 障害連絡：発生時の連絡体制を確認します。
- 復旧目標：障害からの復旧にかける目標時間を定めます。
- 対応時間：サポートを受けられる時間帯を明記します。
各ベンダーの保守体制を比べ、導入後の支援が現場の定着を支えられるかを確かめます。
また、保守費は開発費の15〜20%を目安にするとよいでしょう。たとえば、開発費が3,000万円なら、年間の保守費はおよそ450〜600万円になります。
初期費用だけでなく、保守費を含む総保有コスト（TCO）を見据えておくことが大切です。SLAと保守範囲、その費用を要件として明確にすると、安定して使い続けられるシステムを選ぶ前提が整います。
riplaは移行・保守も含む要件整理を一貫して支援しています。
提案評価軸と運用サポート体制の確認
RFPに評価軸を示しておくと、各社の提案を同じ観点で比べられます。機能、費用、納期に加えて、業界の現場理解や導入後の支援も確認します。
- 現場理解：業界特有の現場感やノウハウを持っているかを見ます。
- 問い合わせ対応：ヘルプデスクの有無。
- 定着支援：伴走型サポートの範囲を確認します。
トラブル時の対応者や、現場を理解した担当者がいるかどうか、定着までの支援範囲を具体的に問います。価格や機能だけで選ぶと、稼働後に支援が手薄になるリスクがあります。
RFPでサポート体制を明確に問うことは、導入の成否を左右する現場定着への準備になります。評価軸を事前に定めておけば、発注側の判断もぶれにくくなります。
まとめ
倉庫業界のシステム導入は、失敗率60%超とも指摘される難しい取り組みです。成功の鍵は、現場ヒアリングと業務標準化（AX）からToBeを描くことにあります。
協力義務を踏まえて要件を凍結し、外部EDI連携の事前協議、データ移行・クレンジング、SLAまでを漏れなく要件に含めます。
旭川医大病院とNTT東日本の判例では、169項目の追加要望のうち124項目が対象外とされ、発注側に約14億1,500万円の支払いが命じられました。
要件定義では、現場業務から逆算し、機能の一覧よりも先に、目的とスコープ、責任分界点、移行と保守を文書で確定します。
EDI仕様の変更は3ヶ月前から協議し、保守費は開発費の15〜20%が目安です。ベンダーが同じ前提で提案できるよう、RFPを整えます。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングから要件凍結、移行・保守まで見据えた要件整理を支援しています。全体像は完全ガイドをご覧ください。
▼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を創業。