ピッキングシステムの要件定義は、現場の把握、物量の整理、連携と評価軸の検討、RFPへのまとめの順に進めると、現場定着につながります。
本記事は発注企業向けに要件定義へ特化し、現場、倉庫、連携と評価軸の順に解説します。全体像は完全ガイドもご覧ください。
▼全体ガイドの記事
・ピッキングシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングとToBeモデルから始める進め方
要件定義は、機能一覧を作るより先に、現場のピッキングを観察して聞き取ることから始めます。ピッキングには暗黙知が多くあります。そのため、ベテランの工夫や例外的な作業を拾い切れるかどうかが、システムが使われるかを左右します。
AsIsの作業動線と例外処理の可視化
まず、現状（AsIs）のピッキング作業を実際にたどり、流れを把握します。出荷指示から棚回り、検品、梱包への引き渡しまで、一通り追います。
導入後の効果を後から数字で確かめられるよう、作業の実態を次の観点で記録し、実測値を押さえておきます。
- 動線と停滞：無駄な歩行や、作業が滞る場所の記録
- 作業実績：行数、時間、歩行距離の実測
- 例外処理：指示数の不足、ロケーションの不在、急ぎ便の割り込みへの対応
例外は漏れやすく、導入の失敗の多くがこの扱いに起因します。そこで、例外を網羅的に洗い出して扱いを決めておくと、稼働後の混乱を防げます。反対に、実態を調べずに理想だけで設計すると、作業者が従来の紙に戻るおそれがあります。
ToBeモデルと達成すべき効果指標の定義
AsIsの次に、あるべき姿であるToBeを描きます。作業フローと、改善効果を測るKPIを具体化します。
- 作業フロー：方式、指示デバイス、検品の自動化範囲の設計
- 処理行数：ピッキング担当者1人あたりの処理行数を1.5倍に上げる目標
- 誤出荷率：現状からどの程度減らすかの設定
- 新人育成：繁忙期の立ち上げ日数を半分にする目標
効果指標は、RFPでベンダーに示す判断軸になるとともに、導入後のROI評価にも使います。
投資に見合うかどうかは、ToBeで定めた効果が実際に出るかで決まります。費用の目安は、クラウド型の5年TCOが180〜1,800万円、回収期間が1〜3年です。
riplaは現場の作業実態からToBeを描き、効果指標で投資を裏付ける進め方を重視します。また、要件定義書の冒頭にToBeと効果指標を書いておくと、開発目的を関係者全員で共有できます。
物量・方式・倉庫レイアウトの要件
自社の物量と商品特性を数値で示し、それに合う方式を要件としてまとめます。前提が曖昧だと、ベンダーは適切な提案も見積もりも出せません。さらに、物量が曖昧なままだと、機能過多で高額になる場合や、ピークに耐えられないシステムになる場合があります。
SKU数・出荷行数・波動の数値による提示
RFPには、物量の分布と変動を示す数値を記載します。その数値が、方式や性能要件、費用の提案に影響します。
- 商品と注文：SKU数、1注文あたりの平均行数
- 出荷量：1日あたりの出荷件数・出荷行数
- 物量の変動：繁忙期と平常時の物量比
少量多品種か少品種多量かで、方式と構成が変わります。同じ商品が複数の注文に分散するならトータルピッキング、注文ごとに品目が異なるならシングルピッキングが候補です。
また、繁忙期に平常時の何倍まで増えるかを示さないと、ピーク性能は見積もれません。費用面では、クラウド型は出荷1,000件あたり1〜5万円の従量課金が一般的で、波動が大きいと繁忙期の費用が跳ね上がることがあります。
RFPには平常時とピーク時の物量を記し、ピーク性能と費用の見込みも提案に含めるよう求めます。
倉庫レイアウトとデバイス方式の要件
物量に加えて、レイアウト、ロケーションの運用、指示デバイスを書き出し、運用方針と方式の選択肢を整理します。
- ロケーション：固定・フリー・ハイブリッドのどれで運用するか
- ゾーン：倉庫内をどう分け、どう運用するか
- デバイス：ハンディ・DPS・ボイスの採用やエリア別併用
デバイスは、作業環境に合わせて選びます。たとえば、重量物で両手を使う現場や冷凍倉庫ではボイス、習熟の早さを重視するならDPSが候補です。
また、SKUが多く入れ替わりが激しい現場では、ハンディが候補になります。専用ハンディを多数そろえると初期費用がかさむため、ロジクラのようにiPhoneを使う選択肢もあります。
レイアウトとデバイスが曖昧なままだと、現場の動線に合わない指示設計になり、歩行が増えるおそれがあります。
将来の物量拡大とマテハン拡張への備え
現在の物量だけでなく、将来の拡大も要件に含めます。成長シナリオごとに、システムがどこまで対応できるかを確認します。
- 出荷量：事業成長で倍増した場合の対応
- SKU数：商品数が大幅に増えた場合の対応
- 拠点：新しい倉庫を開設した場合の対応
- 機器：将来のマテハン拡張と連携方法
要件定義は、現在だけでなく数年先の自社を見据えて行います。導入時の物量に合わせきってしまうと、数年で性能が頭打ちになり、再構築が必要になる場合があります。
人手のハンディピッキングから始めても、出荷が増えた後にAGVや自動倉庫を導入する可能性があります。そのため、拡張のしやすさを要件に明記しておきます。
マテハン連携の費用は、バーコード接続で50〜500万円、自動倉庫制御で500〜1,000万円です。さらに、ロボット・AGVは1,000〜3,000万円以上かかります。
後付けで連携できる設計かどうかが、将来の投資効率を左右します。RFPには成長シナリオと拡張要件を記し、数年先を見据えた提案を求めます。
WMS/WCS/WESの責任分界と連携要件
要件定義では、WMS・WCS・WESなど隣接システムとの責任分界を明らかにします。連携の境界を要件の中で決めておくことが、トラブルを避ける鍵になります。ベンダー同士が担当範囲を押し付け合わないよう、要件に境界を明記します。
WMS・WCS・WESの役割の切り分けと記述
RFPには、各システムの役割と、ピッキングシステムが担う範囲を図で示します。役割を解説した情報は少なく、混同したまま発注しないよう、次のように切り分けます。
- WMS：在庫、ロケーション、入出荷を管理する上位システム
- WCS：コンベアや自動倉庫などの機器を直接制御する仕組み
- WES：作業全体をリアルタイムに最適化する中間システム
たとえば、最適ルートをWMSとWESのどちらが決めるかを明確にしないと、開発後に重複や空白が見つかります。
RFPには、上位のWMSや受注管理から受け取る情報と、下位のWCSや機器へ渡す情報を、インターフェースとして書きます。
マテハン機器を導入する場合は、機器ベンダーとシステムベンダーの責任分界点を、契約書レベルで定めます。
連携インターフェースとデータ移行の要件
システム間の連携仕様とデータ移行も要件に含めます。連携先と方式、移行時の担当を、あらかじめ揃えておきます。
- 連携内容：OMSやECからの出荷指示と出荷実績の返却
- 連携方式：リアルタイムAPIかバッチCSVか
- 移行対象：商品・ロケーションのマスタ、在庫データ
- 移行作業：データクレンジングを誰が担当するか
連携費用は、基幹で100〜500万円、ECモールは1モールあたり20〜100万円が目安です。一方で、独自システムとの連携は50〜500万円以上と高額になりやすく、範囲を絞ることが費用管理につながります。
移行の方法や担当を決めておかないと、リリース直前に手作業が増え、稼働が遅れるおそれがあります。
さらに、端末や周辺機器の調達、現場研修も「隠れコスト」として要件と予定に含めます。これらを含めて、見積もりの妥当性を判断します。
連携、移行、教育の担当範囲を明記すると、各社の提案を同じ条件で比べられます。
RFPに盛り込む評価軸とコスト条項
要件をRFPにまとめ、ベンダーから提案と見積もりを集めます。そのうえで、評価軸とコスト条項が選定と費用管理を左右します。価格だけでなく、現場操作性と費用の透明性も評価軸にします。
デモによる現場操作性の評価軸
毎日使うシステムだからこそ、実機の操作性をRFPの評価軸に入れます。機能一覧を見るだけでなく、デモ環境で次の点を確かめます。
- 操作の分かりやすさ：未経験者が説明なしでどこまで使えるか
- 支援体制：導入支援、SLA、保守の範囲
- 制度対応：改正物流効率化法などへの対応姿勢
- 障害対応：トラブル時の対応スピードと運用支援
未経験スタッフの操作性は、繁忙期に臨時スタッフを多く入れる現場で、品質と教育コストを左右します。また、直感的なUIは、新人の戦力化を早め、教育担当の負担も減らします。
複数ベンダーを比べるときは、価格・機能・操作性・支援体制を点数化します。安さだけで選び、定着しないまま作り直すと、かえって費用がかかります。
従量課金のコスト上限条項
クラウド型では、従量課金が膨らむ場合に備えて、ピーク時の試算と上限条件を確認します。料金の構成要素も分けて提示してもらいます。
- ユーザー従量分：1人あたり月額0.5〜3万円
- 出荷従量分：1,000件あたり1〜5万円
- オプション：月額1〜5万円
基本料にこれらが加わるうえ、繁忙期に出荷が数倍になると、従量分が想定を超えることがあります。RFPでは、ピーク時の課金試算と上限額、段階課金の条件を求めます。
初期費用の内訳とTCO（総保有コスト）は、3〜5年の期間で提示してもらいます。形態ごとの5年TCOの目安は、クラウド型が180〜1,800万円です。一方、パッケージ・オンプレは800〜6,000万円、フルスクラッチは5,000万円以上が目安です。
カスタマイズが全体の70%を超えるなら、スクラッチの方が費用効率的になる、という判断軸もあります。
初期費用、月額、従量、保守、連携、教育を含めた総額を、同じ前提で複数社に求めます。要件定義の精度が、見積もりの精度を左右します。
非機能要件とSLA・保守範囲の明記
機能が動いていても、出荷が止まれば現場全体に影響が及びます。見落とされがちな非機能要件も、RFPに条件として記します。確認する稼働条件は、次の4点で整理してもらいます。
- 可用性：システムの止まりにくさ
- 性能：ピーク時のレスポンス
- 復旧：障害時の復旧時間
- データ保護：バックアップの方法
繁忙期の操作応答を何秒以内にするか、障害時に何時間以内で復旧するかなど、SLA（サービス品質保証）の水準を求めます。
保守範囲とサポート体制も確かめておきます。クラウド型は、自動アップデートを含めて保守込みの場合が多いです。一方、オンプレやスクラッチは、年間保守費が開発費の8〜10%程度になるのが一般的です。
トラブル時の連絡窓口や対応時間帯、改正物流効率化法などの制度変更への追従も、提案に含めてもらいます。
保守やSLAを軽く見ると、障害時の支援や制度改正への対応を受けられないおそれがあります。非機能要件と保守範囲は、長く使うシステムの安定稼働を左右します。
まとめ
要件定義では、AsIsと例外処理を洗い出し、ToBeと効果指標で投資の目的を定めます。物量、方式、レイアウト、デバイスも、数値や方針として要件にまとめます。
WMS/WCS/WESの責任分界や連携・移行を明記し、操作性とコスト上限を評価します。例外、波動、責任分界、従量課金の上限を見落とすと、手戻りにつながります。
要件定義の質が、見積もりとシステムの質を左右します。RFPでは、現場の困りごとと実現したい効果を起点に、要件を組み立てます。
複数ベンダーから同じ前提で提案を集め、価格・機能・操作性・支援体制・TCOを総合的に比べます。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を創業。