入出庫管理システムの要件定義とRFP作成は、現場業務の可視化、システムの責任分界、費用と移行条件の明文化の順に進めます。こうした準備が、現場に合った提案と妥当な見積りにつながります。発注企業の視点から、要件定義書とRFPの作り方を実務に沿って解説します。
▼全体ガイドの記事
・入出庫管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
AsISの入出庫フローの可視化とToBeを描く要件定義
要件定義は、現状（AsIS）の入出庫業務を可視化するところから始めます。入荷→検品→棚入れ→保管→ピッキング→出荷検品→出荷の流れに沿って、担当者と作業内容を書き出します。
現場の作業を書き出さないと、例外処理や暗黙のルールが要件から漏れます。そのため、稼働後に現場の運用と合わず、手戻りが生じるおそれがあります。
現場ヒアリングによる例外処理の洗い出し
AsISの可視化の精度は、現場ヒアリングをどこまで深く行うかで決まります。ヒアリングでは、作業の担い手と、標準手順から外れる場面を聞き取ります。
- 担当者：入荷、ピッキング、出荷、在庫管理の各担当者
- 作業と負担：実際の作業内容と、手間取る場面
- 例外処理：返品、不良品の隔離、部分出荷、分納、キャンセル、ロット指定出荷
- 暗黙のルール：得意先ごとの梱包資材や、賞味期限の近い商品の出荷順
例外を要件に含めないと、システムは標準フローしか扱えず、手作業やExcelとの二重運用になりかねません。さらに、在庫差異が残れば、導入効果も半減します。
年に数回しか起きなくても、起きると大変な処理まで聞き取ります。そのうえで、要件に明記するか手運用に残すかを決めます。例外の線引きを要件定義で明確にしておくと、後のトラブルを防げます。
ヒアリングでは、現場で当たり前になっていて言語化されていない慣行も引き出します。また、ベテランの判断についても、システムで扱うか運用ルールに残すかを決めます。
暗黙知を拾わないと、稼働後に従来できていた作業ができず、現場の不満につながります。そこで、AsISでは作業手順だけでなく、現場の判断や慣行も洗い出します。
ToBeモデルによるあるべき入出庫の姿の設計
あるべき業務の姿（ToBe）は、導入後の業務像を具体化して設計します。業務像を先に描き、そこから必要な機能を決めます。
- 自動化する工程：FAXの入荷予定を、仕入先データ連携で自動的に取り込む
- なくす無駄：AsISとToBeの差分から、システムで実現する要件を定める
- 実現の優先度：要件を必須・優先・将来に分け、初期構築の範囲を決める
理想を追いすぎず、現場が運用できる範囲に収めます。機能を詰め込みすぎると、現場は使いこなせず手作業に戻るおそれがあります。現場業務から逆算してToBeを描き、段階的に実現する進め方が成否を分けます。
WMS・OMS・WCS・WESの責任分界の要件化
多くの企業は、どのシステムがどこまでを担うのかが曖昧なところでつまずきます。そのままでは、機能の重複や抜け漏れが生じるうえ、ベンダー間の責任問題も招きます。
WMS（倉庫管理）、OMS（受注管理）、WCS（倉庫制御）、WES（倉庫実行）の責任分界は、要件定義のなかでも専門性が問われる部分です。
WMSとOMSの境界と在庫連携の要件化
WMSは倉庫内の「モノ」を、OMSは受注や注文の「情報」を管理します。境界が曖昧だと、在庫数の正や出荷指示の発行元が定まらず、連携に不整合が生じます。
- 在庫マスタ：WMSが持ち、OMSは引当可能在庫を参照する
- 同期条件：在庫の同期方法と頻度を明文化する
- 連携方式：一体型（WMS＋OMS）か、API連携で別々につなぐかを選ぶ
在庫連携では、タイムラグに特に注意します。同期が遅れると、出荷済み在庫への過剰受注や、在庫があるのに欠品と表示する機会損失が起きます。
リアルタイムで連携する在庫と、バッチで許容する範囲は、自社の欠品リスクと出荷頻度に応じて定めます。
WCS・WESとマテハン連携の責任分界の要件化
機器と人の作業を連動させる倉庫では、WMS・WCS・WESの三層で、制御と実行の責任範囲を分けます。
- WMS：倉庫の業務指示を出す
- WCS：自動倉庫やコンベアなどの機器を直接制御する
- WES：複数の機器や人の作業を横断して、全体を最適化する
要件定義では、ロケーション決定などの判断をどの層が担うかを、境界線として明示します。境界が曖昧だと、判断が重複したり抜けたりして、現場が混乱しかねません。
マテハン連携では、ベンダー間の責任分界点を特に要件として明記します。各社や機器メーカーが異なると、障害時に責任の所在が決まらないおそれがあります。
古い自動倉庫との接続相性も確認します。連携費用は、自動倉庫制御で500〜1,000万円、ピッキングロボットやAGVでは1,000〜3,000万円以上かかります。そのため、RFPには各社の責任範囲と連携部分の動作保証を明記し、提案間で境界が整合するかを確かめます。
従量課金のコスト上限とデータ移行の要件化
クラウド型では、出荷件数やユーザー数に応じた従量課金が一般的です。そのため、繁忙期に出荷が急増すると、費用が想定外に膨らむことがあります。
機能だけでなく、運用後のコスト構造とデータ移行のリスクも要件に含めます。移行の段取りを見落とすと、稼働開始の時点で在庫差異を持ち込むことになります。
従量課金のコスト上限条項
クラウド型の従量課金は、利用人数と出荷量の両方で増えるため、単価の単位を分けて確認します。
- ユーザー料金：1人あたり0.5〜3万円
- 出荷料金：1,000件あたり1〜5万円
平常時の物量だけで見積もると、月額が跳ね上がる場合があります。たとえば、セール期や年末には出荷が数倍になります。そこで、繁忙期のピーク物量で試算し、費用が許容範囲かを確かめます。
RFPでは、単価体系に加えて、ピーク時の上限額と、一定件数を超えた場合の割引条項を求めます。こうした条項があれば、想定外のコスト増を契約の段階で抑えられます。
固定料金型と従量課金型のどちらが物量の変動に合うかも、要件化の過程で判断できます。出荷が安定していれば固定型、繁閑差が大きければ上限付きの従量型を候補にし、選んだ理由を要件に記します。
データ移行と現場操作性の評価軸の要件化
既存システムやExcelから移行するデータは、範囲と精度を決めておきます。移行の範囲は、次の4つの情報について、どこまで移すかを確かめます。
- 商品マスタ
- 在庫数
- ロケーション情報
- 取引先情報
データに誤りがあると、稼働初日から在庫差異を抱えることになり、新システムへの信頼も揺らぎます。そのため、誰がデータを整備し、どう検証し、いつ移行するかまで段取りを明確にします。
現場の操作性も評価の対象です。繁忙期には臨時スタッフも使うため、ハンディ端末のUI/UXと、新人が習熟するために必要な教育時間をRFPに記載します。
提案ベンダーにはデモを求め、機能の豊富さだけでなく、迷わず操作できるかを要件として明示します。データ移行と操作性をRFPに含めることが、導入後の定着を左右します。
RFPに盛り込む項目と見積りの妥当性の判断
RFP（提案依頼書）は、要件をベンダーが提案しやすく、公平に比較できる形にまとめたものです。完成度が高いほど提案は具体的になり、見積りの精度も上がります。
要件が曖昧だと、ベンダーはリスクを見込んで高めに見積もるか、追加費用の余地を残す場合があります。
RFPに必ず盛り込むべき項目
RFPには、プロジェクトの背景や業務範囲、機能・非機能要件を記載します。具体的には、次の情報を盛り込みます。
- 目的と範囲：プロジェクトの目的・背景と対象業務
- 機能・非機能：機能要件の優先度、性能・可用性・セキュリティ
- 連携と移行：外部システム・マテハンとの連携、データ移行範囲
- 物量と計画：平常時・ピーク時の出荷件数、希望スケジュール、予算感
- 運用保守：対応範囲とSLA（サービス品質保証）
機能要件は、必須・優先・将来に分けて示します。想定物量は、システム規模や従量課金の見積もりに使われるため、平常時とピーク時の両方を数値で示します。
非機能要件では、繁忙期の性能、倉庫の稼働中の可用性、在庫や取引先情報の保護を定めます。これらをRFPに含めると、各ベンダーの提案がどこまで現実的かを見極めやすくなります。
改正物流効率化法などへの対応が必要な場合は、その要件を明記し、ベンダーに対応方針を提案してもらいます。
運用保守では、障害の受付時間や復旧目標、機能追加や軽微なカスタマイズの依頼方法と費用、繁忙期の支援体制を要件に示します。そのうえで、各社の対応を比べます。
入出庫管理システムは、現場が毎日使う業務基盤です。停止すれば出荷が滞るため、運用保守の要件は欠かせません。
運用の段階で頼れるかどうかが、長期的な満足度を左右します。機能や価格だけでなく、運用まで見据えた要件をRFPに含めることが、後悔のない選定の前提になります。
見積りの妥当性を判断する軸
提案が出揃った段階で、見積りの妥当性を判断します。金額は、構築形態ごとの相場と照らして確かめます。
- クラウド型：初期0〜100万円、月額3〜30万円
- パッケージ／オンプレ型：初期500〜3,000万円
- フルスクラッチ：初期3,000万〜1億円超
相場から大きく外れる見積りは、要件の理解にずれがあるか、見積りが不足または過剰になっていないかを疑います。
連携費用も相場と照らして確かめます。目安は、基幹との連携が100〜500万円、ECモールは1モール20〜100万円です。
隠れコストの有無も、見積りを判断するうえで重要な点です。データ移行、ハンディ端末などの機器、初期研修、年間保守費が明記されているかを見ます。
年間保守費は、開発費の8〜10%が一般的です。また、費用が別途見積りになっていると、総額が膨らむおそれがあります。
カスタマイズ比率が全体の70%を超える場合は、パッケージよりスクラッチのほうが費用効率的だという目安もあります。
同業種・同規模の入出庫管理システムを手がけた実績、保守やトラブル対応のSLA（サービス品質保証）、繁忙期の支援体制も確認します。長く運用するには、こうした点も見積り金額と同じくらい大切です。
相場と隠れコストを精査したうえで、価格・機能・実績・運用体制を総合的に評価します。丁寧な要件定義は多面的な比較の前提となり、自社に合うパートナーを選ぶ助けになります。
まとめ
要件定義では、現場ヒアリングでAsISと例外を可視化し、ToBeとの差分を必須・優先・将来に分けます。そのうえで、システムの責任分界を定め、従量課金の上限、データ移行、現場操作性も要件に含めます。
RFPには想定物量と非機能要件を盛り込みます。提案を受けたら、クラウド初期0〜100万円、スクラッチ初期3,000万円超などの相場と隠れコストを照らして、見積りを判断します。
要件定義では、要望を並べるだけでなく、現場業務から逆算して実現すべき差分を言語化します。現場起点で要件を固めることが、運用に合うシステム選びにつながります。
例外処理とシステムの責任分界を曖昧にしないことが、使われないシステムを避ける近道です。
riplaは、フルスクラッチ受託と国内開発の立場から、現場ヒアリングを起点とした要件整理、相場を踏まえたRFP作成、ベンダー選定を一貫して支援します。全体像の確認には、完全ガイドをご活用ください。
▼全体ガイドの記事
・入出庫管理システムの完全ガイド
▼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を創業。