ピッキングシステムのRFP/要件定義書/提案依頼書について

ピッキングシステムを開発・導入するうえで、プロジェクトの成否をもっとも大きく左右するのが要件定義です。とくにピッキングは、倉庫レイアウトや商品特性、出荷の波動、既存のWMSやマテハン機器との関係が複雑に絡むため、これをいかに正確に要件として整理し、RFP（提案依頼書）や要件定義書に落とし込めるかが、現場に定着するシステムになるか、使われず形骸化するかの分かれ目になります。現場ヒアリングを怠ってベンダーに丸投げした結果、高額なシステムが現場の作業実態と噛み合わず、誰も使わないまま廃止に至るケースは珍しくありません。

本記事は、ピッキングシステムのRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。現場ヒアリングとAsIs/ToBeモデルの描き方、ピッキング方式・物量・倉庫レイアウトを要件に落とす方法、WMS/WCS/WESの責任分界の定義、従量課金のコスト上限条項、データ移行と現場操作性の評価軸まで、倉庫の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、ピッキングシステムの全体像をまだ把握していない方は、まずピッキングシステムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・ピッキングシステムの完全ガイド

現場ヒアリングとToBeモデルから始める進め方

ピッキングシステムの要件定義は、機能の一覧を書き出すことから始めるのではなく、現場が今どうピッキングしているかを徹底的に観察・ヒアリングすることから始めるべきです。ピッキングは現場の暗黙知の塊であり、ベテランが無意識に行っている工夫や、例外的なオペレーションを拾い切れるかが、使われるシステムになるかどうかを決めます。

まず行うべきは、現状（AsIs）のピッキング作業を可視化することです。作業者が出荷指示を受け取ってから、棚を回り、検品し、梱包に渡すまでの動線を実際にたどり、どこで歩行が無駄に発生しているか、どこでミスが起きやすいか、どこで作業が滞るかを記録します。倉庫管理者の頭の中にある「だいたいこうなっている」では不十分で、実測した行数・時間・歩行距離まで押さえることが、後で導入効果を定量化する土台になります。

とくに重要なのが、例外処理の洗い出しです。在庫が指示数に足りなかったとき、ロケーションに商品がなかったとき、急ぎ便の割り込みが入ったとき、現場は今どう対応しているのか。こうした例外こそがシステム化で漏れやすく、後述する失敗の多くはここに起因します。要件定義の段階で例外パターンを網羅的にリストアップし、それぞれをシステムでどう扱うかを決めておくことが、リリース後の「これでは現場が回らない」を防ぎます。AsIsの可視化を省くと、理想論だけのシステムができあがり、現場は従来の紙に戻ってしまいます。

AsIsを可視化したら、次にあるべき姿（ToBe）を描きます。ピッキング方式をどう変えるか、どのデバイスで指示するか、検品をどこまで自動化するか、といった理想の作業フローを設計し、それによって何をどれだけ改善するかという効果指標（KPI）を明確にします。たとえば「ピッキング1人あたりの処理行数を1.5倍にする」「誤出荷率を現状の何分の一にする」「繁忙期の新人立ち上げ日数を半減する」といった具体的な目標です。

この効果指標は、RFPでベンダーに提示する判断軸になると同時に、導入後のROI評価の基準にもなります。クラウド型なら5年TCO180〜1,800万円、回収期間1〜3年が目安ですが、この投資を正当化できるかは、ToBeで定めた効果が現実に出るかにかかっています。riplaのようなフルスクラッチ受託の立場では、この「現場の作業実態から逆算してToBeを描き、効果指標で投資を裏付ける」進め方を一貫して重視します。要件定義書の冒頭には、必ずこのToBeと効果指標を明記し、開発の目的を関係者全員で共有しておくことが大切です。

物量・方式・倉庫レイアウトを要件化する

ピッキングシステムの要件で核心になるのが、自社の物量と商品特性を数値で表現し、それに合った方式を要件化することです。ベンダーは物量の前提がなければ適切な提案も見積もりもできません。曖昧な物量で進めると、過剰な機能を盛り込んで高額になるか、逆にピークに耐えられないシステムになります。

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（倉庫実行システム）はその中間で作業全体をリアルタイムに最適化する役割を担います。ピッキングシステムはこの中でどこに位置づくのかを要件で明確にしないと、たとえば「最適ルートはWMSが決めるのか、WESが決めるのか」が曖昧になり、開発後に機能の重複や空白が判明します。

この役割の違いを体系的に解説した情報は意外と少なく、多くの企業が混同したまま発注してしまいます。RFPでは、自社のシステム全体像の中でピッキングシステムが担う範囲を図で示し、上位のWMSや受注管理から何を受け取り、下位のWCSや機器へ何を渡すのかというインターフェースを明記しましょう。とくにマテハン機器を導入する場合は、機器ベンダーとシステムベンダーの責任分界点を契約書レベルで定義しておくことが、後の「動かない」「誰の責任か」というトラブルを防ぎます。

責任分界と並んで、連携インターフェースの仕様とデータ移行も要件として明記が必要です。受注管理（OMS）やECからどんなフォーマットで出荷指示を受け取るか、出荷実績をどう返すか、リアルタイムAPIかバッチCSVか、といった連携方式を定義します。連携費用は基幹で100〜500万円、ECモール1モール20〜100万円が目安で、独自システムとの連携は50〜500万円以上と高額になりやすいため、連携範囲を要件で絞ることがコスト管理につながります。

データ移行も見落とせない要件です。既存の商品マスタ、ロケーションマスタ、在庫データをどう移行するか、移行時のデータクレンジングを誰が担うかを決めておかないと、リリース直前に大量の手作業が発生し、稼働が遅れます。ハンディ端末や周辺機器の調達、現場研修も含めた「隠れコスト」を要件とスケジュールに織り込んでおくことが、見積もりの妥当性を判断する前提になります。RFPには、こうした連携・移行・教育の範囲をどちらが担うかを明記し、提案の比較軸として揃えておきましょう。

RFPに盛り込む評価軸とコスト条項

要件を整理したら、それをRFP（提案依頼書）にまとめ、ベンダーから提案と見積もりを引き出します。ここで、何を評価軸にし、どんなコスト条項を盛り込むかが、後悔しないベンダー選定とコスト管理を左右します。価格だけで選ぶのではなく、現場操作性とコストの透明性を評価軸に据えることが肝心です。

ピッキングシステムは現場の作業者が毎日使うものだからこそ、操作性の評価軸を必ずRFPに含めるべきです。機能一覧の充足度だけでなく、実際にデモ環境で未経験のスタッフが操作してみて、説明なしでどこまで作業できるかを評価します。繁忙期に臨時スタッフを大量投入する現場では、この「すぐ使えるか」が品質と教育コストを直接左右します。直感的なUIは、新人が短期間で戦力化する分、教育担当の負担も減らします。

評価軸には、操作性に加えて、ベンダーの導入支援体制やSLA（サービス品質保証）、保守の範囲も含めます。改正物流効率化法など制度対応への姿勢、トラブル時の対応スピード、運用支援の手厚さは、長く使うシステムでは価格以上に重要です。RFPで複数ベンダーから提案を取る際は、これらの評価軸を点数化し、価格・機能・操作性・支援体制を総合的に比較できるようにしておくと、稟議でも説明しやすくなります。安さだけで選んだ結果、現場に定着せず作り直しになれば、かえって高くつきます。

クラウド型ピッキングシステムで要件に必ず含めたいのが、従量課金のコスト上限に関する条項です。月額は基本料に加え、ユーザー1人あたり0.5〜3万円、出荷1,000件あたり1〜5万円、オプション1〜5万円といった従量部分が積み上がります。繁忙期に出荷が数倍に跳ね上がると、この従量課金が想定を超えて膨らむ「コスト爆発」が起こり得ます。RFPの段階で、ピーク時の課金シミュレーションを提示させ、上限額や段階課金の条件を確認しておくことが重要です。

あわせて、初期費用の内訳とTCO（総保有コスト）を3〜5年スパンで提示させましょう。クラウド型は5年TCO180〜1,800万円、パッケージ・オンプレは800〜6,000万円、フルスクラッチは5,000万円以上が目安で、構築形態によって桁が変わります。カスタマイズが全体の70%を超えるならスクラッチの方が費用効率的になる、といった判断軸も持っておくとよいでしょう。RFPでは、初期・月額・従量・保守・連携・教育まで含めた総額を、複数ベンダーで同じ前提で比較できる形で求めることが、コストの妥当性を見極める決め手になります。要件定義の精度が、そのまま見積もりの精度を決めるのです。

機能要件やコスト条項に加えて、見落とされがちなのが非機能要件です。ピッキングシステムは出荷が止まれば現場が完全に停止するため、可用性（止まりにくさ）、ピーク時のレスポンス性能、障害時の復旧時間、データのバックアップといった非機能要件をRFPに明記しておく必要があります。たとえば「繁忙期のピーク出荷時にも操作レスポンスが何秒以内」「障害発生時に何時間以内に復旧」といった水準を、SLA（サービス品質保証）として求めておくことが、稼働後の安心につながります。

あわせて、保守の範囲とサポート体制も要件として確認しましょう。クラウド型は自動アップデートで保守が含まれることが多い一方、オンプレやスクラッチは年間保守費が開発費の8〜10%程度発生するのが一般的です。トラブル時の連絡窓口、対応時間帯、改正物流効率化法など制度変更への追従、といった運用支援の内容を、提案に含めるよう求めます。機能だけを比較して保守やSLAを軽視すると、稼働後に「障害時に誰も助けてくれない」「制度改正に対応してもらえない」といった事態に陥ります。非機能要件と保守範囲は、長く使うシステムの安定稼働を左右する重要な要件です。

まとめ

ピッキングシステムの要件定義・RFP作成を振り返ると、成否は「現場のAsIsと例外処理を可視化し、ToBeと効果指標で投資目的を定め、物量・方式・レイアウト・デバイスを数値と方針で要件化し、WMS/WCS/WESの責任分界と連携・移行を明記し、操作性とコスト上限を評価軸に据える」という一連の精度にかかっています。とくに例外処理の洗い出し、波動の数値化、責任分界の明確化、従量課金のコスト上限条項は、見落とすと後で大きな手戻りを招く要件です。要件定義の質が、そのまま見積もりとシステムの質を決めます。

RFPを作るときに大切なのは、機能を網羅することではなく、自社の現場が本当に何に困っていて、どんな効果を出したいのかを起点に要件を組み立てることです。複数ベンダーから同じ前提で提案を取り、価格・機能・操作性・支援体制・TCOを総合的に比較してください。riplaはフルスクラッチ受託と国内開発の立場から、現場の出荷業務から逆算した要件整理と、RFP作成から定着までの伴走を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。