卸売・商社向け在庫管理システムの発注は、業務を整理し、要件定義を固め、提案を比べる順に進めると、取引全体を見える化できます。
全体像は、卸売・商社向け在庫管理システム開発の完全ガイドにまとめています。
▼全体ガイドの記事
・卸売・商社向け在庫管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
卸売・商社向け在庫管理システムを外注する全体像
卸売企業では、入荷・保管・出荷に加えて、受注残と発注残を同じデータで確認できる設計が必要です。一方、商社では直送、受発注同時の取引、輸出入・外為、案件別採算まで扱うため、在庫画面だけでは経営判断に必要な情報がそろいません。
在庫管理と取引管理の一つの流れ
商品とSKUは、マスタとして先に整理しておきます。そのほか、次の項目もマスタとして整えます。
- 単位・荷姿・ロット・期限
- 取引先・仕入先
- 倉庫・ロケーション
取引の流れは、販売側と仕入側に分けて連携させます。
- 販売側：受注・引当から出荷指示、ピッキング、納品、売上、返品までを連携させます。
- 仕入側：発注、入荷予定、検品、仕入、支払を連携し、発注残を追える形にします。
受注残と入荷予定を反映した予定フリー在庫があれば、営業と購買が同じ数字を使えます。さらに、納期の回答と発注量の判断にも役立ちます。
卸売型と商社型の業務差分の切り分け
卸売型と商社型では、優先する要件が異なります。そのため、発注側は業務の差分をRFPに記し、倉庫管理だけの提案を避けます。
- 卸売型：多品種、賞味期限やロット、複数拠点と外部倉庫、ハンディターミナル、誤出荷防止を重視します。
- 商社型：直送、預託、売買同時計上、輸出入・外為、販売先別の価格と納品条件、案件別粗利を優先して扱います。
SCSKが2025年に発表したPROACTIVEの商社・卸売業向けテンプレートは、受発注同時や売買同時計上を扱います。加えて、EDI、EC、WMS、物流会社APIとの連携も示されています（出典: SCSK「PROACTIVE」商社・卸売業向けテンプレート発表、2025年）。
発注形態の選び方
選定では、業務を標準化できる範囲と既存システムとの連携を確かめます。あわせて、将来の変更量や5年程度の総保有コストも比べます。最初からフルスクラッチに決めず、標準機能で扱える業務と、競争力に関わる個別開発を分けて考えます。
標準業務を早く整える場合のクラウドSaaS
クラウドSaaSは、サーバーの調達や大規模な保守体制を自社で持たずに始められます。加えて、拠点間で同じ在庫を見やすい点も強みです。
- 標準化を優先：棚卸、入出庫、発注、期限管理を短期間で整えたい企業に適しています。
- 個別要件を確認：売買同時計上や複雑な外為、独自価格計算、基幹会計連携を、APIや追加機能の範囲で扱えるかを確かめます。
発注前に対応範囲を確かめると、標準機能との差を把握できます。
業界パッケージの適合度と変更範囲
業界パッケージは、標準機能への適合度と、変更後の条件を見極めて選びます。
- 標準機能：販売・購買・在庫を備え、卸売業に共通する業務を導入しやすい方法です。
- 変更条件：製品に業務を合わせられるかと、改修後のバージョンアップの条件を確かめます。
一例として、日立システムズのFutureStage事例では、くぎ・工具など一万点を超える品目の在庫把握が紹介されています。また、産業用機構部品卸売業の不良在庫・滞留在庫の把握事例もあります（出典: 株式会社日立システムズのFutureStage導入事例）。
セミオーダーとフルスクラッチの適用範囲
セミオーダーは、標準の受発注・在庫・会計機能に個別の機能を加える方法です。たとえば、直送、預託、輸出入、採算、承認、EDIなどを追加できます。
フルスクラッチは自由度が高い一方で、要件定義やテスト、障害対応、設計書の維持、人材確保を発注者が長く負担します。独自性が商品・取引・粗利の競争力に直結し、既存パッケージに業務を合わせられない場合は、フルスクラッチが候補となります。
RFPと要件整理に書く範囲
RFPは、各社の提案を同じ条件で比べるための文書です。「便利なものを提案してください」と依頼する文書ではありません。
RFPには、対象業務と現状の問題、必要なデータや制約を記します。優先順位と納期、予算の考え方、見積項目も含めます。完璧な仕様書を目指すより、業務の事実と判断事項を分けて書くことが大切です。
現状業務とデータの流れの整理
受注から棚卸までを、業務フローとして一本の流れに描きます。まず、受注から引当、発注、入荷までを並べ、続いて検品、保管、出荷を書きます。さらに、売上、請求、入金、返品、棚卸も同じ流れに入れます。
- 工程ごとの情報：担当者と入力媒体、承認者、データ、受け渡し、例外処理を記録します。
- 情報の所在：Excelや紙、電話・FAX・メール、Web-EDI、既存基幹、外部倉庫など、どこに情報があるかを示します。
データの所在が分かると、二重入力とシステム連携の対象を見つけられます。
Must・Should・Couldによる要件の優先順位付け
稼働初日から必要な機能はMust、早期に効果を出したい機能はShould、将来検討する機能はCouldに分けます。商品単位と荷姿単位の換算や、ロット・期限、受注残・発注残は、Mustになりやすい項目です。さらに、棚卸差異、権限、操作ログもMustになりやすい項目です。
需要予測やAI-OCRは、商品マスタと入力ルールが整ってから効果を検証するCouldに回せます。そうすると、初期費用と導入リスクを抑えやすくなります。
RFPに入れる数量・連携・移行・運用条件
提案依頼書には、見積もりの前提になる数量や運用条件を記します。
- 規模：商品点数や取引先数、倉庫・拠点数、月間の受注明細と出荷明細の量を記載します。
- 機器・連携：ハンディ台数やEDI・API本数、帳票数、稼働時間、同時利用者数を示します。
- 業種固有の条件：食品では賞味期限と許容日、医療機器では預託と貸出を明記します。
- 履歴と取引：移行件数、金属・部品の単位・荷姿と滞留、商社の直送・外為・案件採算を書き添えます。
また、商社の条件には売買同時計上も含めます。見積では、商品マスタのクレンジングや移行リハーサル、教育、並行稼働、稼働後支援を、別項目にしてもらいます。
発注・外注の進め方と順序
外注は、相談と現状調査から始め、要件定義、提案・見積比較、契約を経て、設計・開発、テスト、移行、教育に進み、稼働後の支援で終わります。
要件が固まる前に開発費だけで比べると、追加費用が増えやすくなります。そこで、要件定義と本開発を分けて発注する方法も有効です。
要件定義と小さな検証の先行発注
まず、現物とExcel、既存基幹の在庫を突き合わせ、マスタの重複や単位の揺れを確かめます。
- 実データを使い、受注から引当、出荷までの流れをPoCで検証します。
- 発注から入荷検品、在庫反映までを確かめます。
- 棚卸差異と返品の処理を検証します。
営業、購買、倉庫、経理の代表者に操作してもらい、画面だけでなく例外処理が現場で回るかを見ます。
開発工程に含める移行リハーサルと教育
移行の対象には、マスタに加えて、未出荷の受注残や未入荷の発注残、ロット・期限、棚卸差異も含まれ得ます。過去の在庫評価や、案件・採算に必要な取引履歴も対象の候補になります。そのうえで、整形担当、データ承認者、障害時に旧運用へ戻す担当を、契約前に決めておきます。
また、操作教育は本番直前だけに行わず、業務別の手順書やテスト用データ、問い合わせ窓口、現場リーダーを事前に準備します。
段階導入と並行稼働による業務停止の防止
全拠点を一度に切り替えず、商品群や一拠点を選んで稼働させます。結果は、在庫・出荷と、業務・採算の二つの面から確かめます。
- 在庫・出荷：在庫差異率、欠品率、誤出荷率、棚卸時間を追います。
- 業務・採算：在庫回転率、滞留在庫金額、受注入力時間を比べます。
並行稼働では、どちらを正とするか、二重入力を止める時期、差異の判定者を決めておきます。あわせて、物流や会計の締め日を避けて切り替える準備も必要です。
請負・準委任・SaaS利用の使い分け
契約形態は、成果物と仕様が固まっているか、発注者と開発会社がどこまで協働するかで選びます。
契約名称だけでは判断せず、条項で中身を確かめることが必要です。確認するのは、仕様変更や検収、知的財産、障害対応です。さらに、データ返却、再委託、終了時の移行も対象です。
請負契約の成果物と受入条件
請負契約は、合意した仕様に基づいてシステムやドキュメントを完成させ、検収する開発に適しています。
機能一覧だけでなく、画面や帳票、連携、性能を含めた完了条件を明記します。権限やログ、移行、テストにも、完了の条件を定めておきます。
受入テストには、受注・発注・入荷・出荷・返品の代表的なシナリオを含めます。また、不具合の無償修正期間と追加要望を分けておくと、紛争を避けやすくなります。
準委任契約の使いどころ：要件定義と伴走支援
準委任契約は、専門家の知識や作業時間の提供を受ける形の契約です。
- 向く業務：現状調査、要件定義、PMO、運用設計、PoCなど、成果の範囲を事前に固定しにくい業務です。
- 契約時に決める項目：作業時間の報告に加え、会議体と担当者、成果物を決めます。意思決定事項と課題管理、次工程へ移る条件も含みます。
- 契約の組み合わせ：要件定義を準委任に、本開発を請負か段階契約にすると、初期の不確実性を抑えられます。
SaaS利用の利用条件と終了時の返却
SaaSは、月額または年額で機能を利用する契約です。料金のほか、ユーザー数や拠点数、データ容量を押さえます。さらに、APIや帳票、サポートの条件も見ます。
バックアップや障害時の連絡、サービスレベルを確かめます。あわせて、料金改定や解約時のデータ出力形式、保存期間も見ておきます。
業務データの所有権や、個人情報を含む場合の委託先管理を見ます。再委託先と国外保管の有無も押さえておきます。
卸売・商社向け在庫管理システムの費用相場
費用は、方式や拠点数、商品・取引先・履歴の量によって変わります。さらに、ハンディ端末やEDI・API連携の有無でも費用は動きます。そのほか、次の項目でも変わります。
- 帳票
- 移行
- 教育
- 保守
次に示すのは、業務システムの一般的な目安です。卸売・商社専用の公的な平均額ではありません。
判断する際は、初期費用に加えて、5年程度の利用料や保守、追加改修、移行、連携、教育を含む総額で比べます（出典: NotebookLMリサーチノート「卸売・商社向け在庫管理システム」、2026年整理）。
方式別の初期費用の幅
方式別の初期費用は、次の幅が目安になります。
- クラウドSaaS：設定と初期データ移行を除き、0万〜50万円程度です。
- 業界パッケージ：100万〜1,000万円程度です。
- セミオーダー・ERP：500万〜8,000万円程度とされます。
- フルスクラッチ：1,000万円から数億円までが、一つの目安です。
大規模な基幹刷新では、5,000万〜3億円以上になる場合もあります。これは案件規模による参考の幅で、特定企業の確定額ではありません。
zaicoの資料には、2026年6月以降の料金が掲載されています（出典: 株式会社ZAICO「zaico機能一覧」、2026年4月更新）。料金は、スターター月額8,980円、ベーシック月額49,800円、プロフェッショナル月額150,000円からです（税別）。
これは在庫管理SaaSのライセンス料金の例です。受発注や会計、EDI、初期インポート、ハンディ導入、教育までを含んだ開発総額ではありません。
料金表では、追加ユーザーや拠点、API、帳票、サポートの条件も確かめます。
工程ごとの見積内訳
見積もりは、工程ごとに分けてもらいます。比率が大きいのは、基本設計・詳細設計と開発・単体テストです。
一般的なコスト構造の比率は、次のとおりです（出典: NotebookLMリサーチノート、類似業務システムの一般的な目安）。
- 要件定義：10〜15%程度です。
- 設計：25〜35%程度です。
- 開発・単体テスト：30〜40%程度です。
- 結合・総合テスト：15〜20%程度です。
- 移行・導入：5〜10%程度です。
比率は案件によって変わるため、予算へそのまま当てはめず、工程の抜け漏れを見つける目安として使います。
ランニングコストと追加費用
月額利用料や保守料のほかにも、追加費用が発生する場合があります。
- 利用・連携：クラウド基盤、ユーザーや拠点の追加、API、EDI接続、データ保管が対象です。
- 機器・運用：ハンディ端末とラベル、帳票の変更、監視・診断、教育、問い合わせ対応が対象です。
- 導入作業：商品マスタの重複を直すクレンジングや、過去在庫・受注履歴の移行、並行稼働、休日切替、現場訪問が該当します。
保守費が初期費用の20%を大幅に超える場合は、その中身を尋ねます。24時間対応や改修枠、ライセンス、インフラ、問い合わせの内訳が、確認の対象です。
委託先の選定と見積比較で見るべきポイント
委託先は、知名度や見積総額の安さだけで決めず、卸売・商社の業務理解と、現場の例外を要件に落とし込む力で見ます。
提案書では、業務課題への回答や導入手順、リスクを読みます。加えて、発注者側の作業、移行・連携・教育の体制、稼働後支援も確かめます。
業種実績の確認：製品名より業務条件
実績の適合度は、卸売・商社という業種名だけでは判断できません。そのため、自社と似た業務条件の事例を尋ねます。
- 食品：期限・許容日、無線ハンディ、外部倉庫の条件を確かめます。
- 部品：一万点超のSKU、単位換算、滞留在庫の実績を見ます。
- 商社：直送、売買同時計上、輸出入、案件採算の経験を聞きます。
一例として、NECソリューションイノベータの食品卸事例では、2拠点、約13,000品目、月35万出荷明細、期限管理、無線ハンディが紹介されています（出典: NECソリューションイノベータ「食品卸ULTRAFIX/WMS導入事例」）。数字が近い事例を基にすると、性能や運用に関する質問を具体化しやすくなります。
同じ前提と内訳による相見積もりの比較
同じRFPを2〜4社程度へ渡し、質問への回答も全社に共有します。比較表では、開発範囲、導入作業、契約・納品の三つを並べて見ます。
- 開発範囲：標準機能・個別開発、要件定義、画面・帳票・連携本数。
- 導入作業：移行件数、テスト担当、教育時間、稼働後支援。
- 契約・納品：保守・追加改修単価、納品ドキュメント。
最安値の見積でも、移行や教育が含まれていないため、安く見える場合があります。見積の除外項目を確かめます。
契約前に確認する責任分界とベンダーロックイン
発注者は、マスタ準備と取引先調整、現場テストの担当を明確にします。データ承認や端末設置、教育についても、誰が担うかを決めておきます。
開発会社が用意する範囲も確かめます。設計書やソースコード、API仕様のほか、テスト結果、操作手順書、障害対応記録も対象です。
契約が終わるときは、標準形式でのデータ出力や他社への移行支援、再委託先と連絡体制を押さえます。こうしておくと、将来のベンダーロックインを抑えられます。
外注時のセキュリティ・法令・運用リスク
卸売・商社のシステムは、取引先情報や価格、仕入条件を扱います。注文書や請求書、入金情報、担当者情報も含まれます。
- アクセスと記録：権限やMFA、IP制限、暗号化、操作・変更ログを、RFPに含めます。
- 継続運用：バックアップや復元テスト、脆弱性対応、障害時の手作業を決めておきます。
そして、委託する範囲と自社が承認する範囲を分けておきます。
EDI・メールの注文書や請求書の保存条件
国税庁は、EDI、インターネット、メール添付で授受したものを電子取引に含めています。注文書や契約書、送り状、領収書、見積書などが、その対象です（出典: 国税庁「電子帳簿保存法の概要」）。
受注・発注・請求データの保存先を決め、取引年月日や金額、取引先で検索できるようにします。あわせて、訂正・削除を防ぐ方法も設計の段階で確かめます。
紙に印刷しておけば済むとは限りません。そのため、経理担当者と委託先を交えて運用を決めます。
商品・取引先・在庫データの責任者
商品コードや単位、荷姿、価格の定義が部門ごとに異なると、システム上の数字が一致しなくなります。取引先名や倉庫、ロケーションの定義でも、同じことが起きます。
デジタル庁は、2025年6月に「データガバナンス・ガイドライン」を公開しました。企業データの活用に向けた経営者向けの要点を示しています（出典: デジタル庁「データガバナンス・ガイドライン」、2025年）。
商品マスタの登録者と承認者、変更ルールを決めます。重複チェックや廃番処理、品質KPIも定めておきます。そのうえで、システム会社任せにしない体制を組みます。
よくある質問（FAQ）
発注・外注の検討で出やすい疑問に、順に答えます。
最適解は、自社の規模や取引形態によって変わります。回答は、製品選びへそのまま使うより、RFPの確認項目へ置き換えて活用すると役立ちます。
在庫管理システムの外注費用はどのくらいですか？
標準SaaSの設定から大規模な基幹刷新まで幅があるため、初期費用を一つの金額で言い切ることはできません。
SaaSは設定と移行を除いて0万〜50万円程度、業界パッケージは100万〜1,000万円程度です。セミオーダーやERPは、500万〜8,000万円程度とされます。
費用は、拠点や連携、移行、教育の範囲によって変わります。そこで、複数社へ同じ条件で依頼し、5年総額と内訳を比べます。
最初からフルスクラッチで開発するべきですか？
多くの企業は、まず標準機能で業務を整えます。そのうえで、直送や売買同時計上、外為、独自採算など、競争力に直結する部分を追加する方法から検討します。
フルスクラッチは自由度が高い反面、要件定義やテスト、保守、人材確保の負担が長期にわたります。
既存製品との適合度、変更できない業務、5年総額、終了時の移行性を比べて判断します。
RFPを作る前にシステム会社へ相談してもよいですか？
相談できます。その際は、業務フローや拠点数、商品点数、月間明細、連携先、困りごとを整理しておくと、提案の精度が上がります。
要件が不明なまま本開発を急がず、現状調査や要件定義、PoCを先に発注します。あわせて、成果物と次の判断条件も合意しておきます。
データ移行は発注者と開発会社のどちらが担当しますか？
開発会社が移行ツールの設計や取り込みを担当する場合でも、元データの意味を確かめ、商品・取引先・在庫の正しさを承認するのは発注者です。
対象データや整形ルール、移行件数、リハーサル回数を、見積と契約の両方に書いておきます。加えて、エラー時の再実行や未移行データの保管、稼働後の照合方法も含めます。
移行を曖昧なまま無償作業にしてしまうと、稼働直前に大きな負担が生じます。
まとめ
発注では、在庫数だけでなく、受注残や発注残、入荷予定を見ます。直送、売買同時計上、輸出入、採算も、業務フローに整理します。
方式は、標準化の範囲と連携、5年総額で比べます。さらに、現場の使いやすさや将来の移行性も見ておきます。機能の多さだけで決めないことが肝心です。
RFPに書くべき項目の整理
まず、業務フローと商品・取引先・在庫データ、拠点数、月間明細を整理します。そのうえで、連携先と例外処理、Must・Should・Couldを書き加えます。さらに、移行対象や教育、稼働後支援も、RFPに入れておきます。
同じ条件のRFPを渡し、標準機能と個別開発、初期費用とランニング費用を分けて見積もってもらいます。発注者と開発会社の責任も、あわせて整理しておきます。
小さな検証から本開発への進め方
候補会社には、実データを使ったPoCや要件定義、移行リハーサル、現場教育を提案してもらいます。価格だけでなく、業務理解と定着支援も確かめます。
発注形態と契約は段階を踏んで選び、稼働後のKPIを決めたうえで改善を続けます。そうすると、在庫差異と欠品を減らし、取引全体を見える化する近道になります。
▼全体ガイドの記事
・卸売・商社向け在庫管理システム開発の完全ガイド
▼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を創業。