卸売・商社向け在庫管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

卸売・商社向け在庫管理システムの開発は、倉庫の数量を見える化するだけでなく、受注・発注・入荷・出荷・売上・請求と、在庫を持たない直送や売買同時計上まで一つの流れで設計することが成功のポイントです。

現物とExcelと基幹システムの数字が合わない、受注残や発注残が見えず欠品と過剰在庫が同時に起きる、拠点ごとに運用が違って集計できないといった課題を解決するために、要件整理から選定、設計開発、テスト、稼働、定着までの進め方を解説します。費用相場、見積もりで確認すべき項目、現場で使われるチェックリストも紹介します。

▼全体ガイドの記事
・卸売・商社向け在庫管理システム開発の完全ガイド

卸売・商社向け在庫管理システムの全体像

卸売・商社向けの在庫管理システムは、商品を保管する会社の在庫だけを管理する道具ではありません。商品・取引先・仕入先・倉庫・ロケーションを共通マスタで管理し、注文を起点に在庫、調達、物流、売上、請求までの状態をつなぐ業務基盤です。開発の最初に業態の違いを整理しないと、倉庫作業は効率化できても、営業が確認する納期や購買担当が見る発注残が改善されないため注意が必要です。

卸売業では、仕入れた商品を自社倉庫や外部倉庫に保管し、販売先からの注文に応じて引き当て、出荷する流れが中心です。そのため、現在庫だけでなく、受注済みでまだ出荷していない数量、発注済みで未入荷の数量、拠点間移動中の数量を分けて管理する必要があります。単純な在庫数を表示するだけでは、画面上は在庫があるのに別の受注へ引き当て済みという事態が起こります。受注残と発注残を加味した「予定フリー在庫」を表示できるかが、選定時の重要な確認項目です。

食品卸であれば賞味期限や許容日、医療機器卸であればロット、預託在庫、短期貸出、金属・電子部品卸であれば多品種、長期滞留、重量や荷姿の換算が要件になります。NECソリューションイノベータの食品卸向け事例では、2拠点、約13,000品目、月35万出荷明細を扱い、期限管理と無線ハンディを組み合わせています（出典: NECソリューションイノベータ「食品卸ULTRAFIX/WMS導入事例」）。このように商品点数や出荷明細が増えるほど、画面機能だけでなく、スキャン、検品、通信障害時の運用まで確認する必要があります。

商社では、自社が商品を保管しない直送、受注と発注が同時に発生する取引、輸出入や外為をともなう取引が少なくありません。倉庫の在庫だけを管理対象にすると、契約は成立しているのに入荷予定や納期回答が見えない、販売単価と仕入単価を比較できず案件別の粗利が分からない、といった問題が残ります。受注・発注・仕入・売上を一つの案件番号や伝票番号で追跡できるように設計します。

SCSKは2025年、商社・卸売業向けのPROACTIVEテンプレートについて、受発注同時や売買同時計上、輸出入・外為、EDI・EC・WMS・物流会社APIとの連携などを発表しました（出典: SCSK株式会社「商社・卸売業向けテンプレート」2025年）。これは、業界向けシステムを選ぶときに「在庫画面があるか」だけでなく、取引の発生形態と会計・物流への連携まで評価する必要があることを示しています。

導入目的を「最新システムにする」と置くと、機能が増えても成果を判断できません。開始前に、棚卸に何時間かかっているか、在庫差異が何件あるか、欠品や誤出荷がどれくらい発生しているか、受注入力や納期確認に何分かかっているかを測定します。導入後は、在庫差異率、棚卸時間、欠品率、誤出荷率、在庫回転率、滞留在庫金額、受注入力時間を月次で比較します。

たとえば「在庫を見える化する」ではなく、「営業が電話で倉庫へ確認する時間を減らす」「月末棚卸を一日で終える」「受注残と発注残を同じ画面で確認する」のように、利用者の行動まで言い換えます。指標の定義、集計対象、基準期間、目標値、責任者を要件定義書に入れておくと、稼働後の改善が進めやすくなります。

卸売・商社向け在庫管理システムの進め方は？

進め方は、(1)要件整理、(2)製品・開発会社の選定、(3)設計・開発、(4)テスト、(5)稼働、(6)定着の6フェーズに分けると判断しやすくなります。結論から言うと、最初に画面を作り始めるのではなく、現物・データ・取引の流れを整理し、標準化する業務と残す業務を決めてから方式を選びます。各フェーズの完了条件を決めることが、手戻りを抑える近道です。

最初に、営業、購買、倉庫、物流、経理、情報システム、管理職からヒアリングします。部門別に「注文を受ける」「在庫を引き当てる」「仕入先へ発注する」「入荷を検品する」「出荷を確定する」「売上・仕入・請求を計上する」業務を時系列で並べ、担当者、入力項目、判断条件、例外処理、利用中のExcelや紙帳票を記録します。通常処理だけでなく、分納、返品、欠品、直送、預託、無償サンプル、キャンセル、拠点間移動も同じ図に書きます。

次に、商品コード、商品名、規格、単位、荷姿、JAN・バーコード、ロット、期限、仕入先、販売先、倉庫、ロケーション、単価、税区分を棚卸します。特に「1箱24個」「1ケース10箱」のような単位換算と、同じ商品に複数コードが存在する状態は、在庫差異と誤出荷の原因になります。現物、Excel、旧システムからサンプルデータを抽出し、重複、未使用コード、表記ゆれ、欠損値を確認することが重要です。

要件はMust、Should、Couldに分けます。Mustには受注・発注・入出荷・棚卸・権限など業務継続に必要な機能、Shouldには予定フリー在庫・EDI・ハンディなど効果が大きい機能、Couldには高度な需要予測や特殊帳票など後から追加できる機能を置きます。要件整理の完了条件は、業務フロー、データ項目一覧、例外処理一覧、非機能要件、優先順位、受入条件が関係者に承認されている状態です。

方式は、クラウドSaaS、業界パッケージ、セミオーダー・ERP、フルスクラッチの順に標準機能を確認し、合わない部分だけを追加する考え方が基本です。SaaSは短期導入や拠点共有に向き、業界パッケージは卸売の販売・購買・在庫をまとめやすく、セミオーダーは複数拠点・会社・会計連携を調整しやすい特徴があります。スクラッチは自由度が高い一方で、要件定義、テスト、保守、人材確保まで発注者の責任が広がります。

候補を比較するときは、商品・単位・ロット・期限、受注・引当・分納・返品、発注・入荷予定・仕入、直送・預託、輸出入・外為、拠点間移動、ハンディ、EDI・API、会計・請求連携を同じシナリオでデモしてもらいます。資料の「対応可能」だけでは判断せず、自社の実データを使ったPoCで、受注から出荷までの操作数、入力ミスの防止、通信断時の処理、履歴の追跡を確認します。

契約前には、月額料金や開発費だけでなく、初期設定、商品マスタのクレンジング、過去在庫と受注履歴の移行、外部連携、ハンディ端末、帳票、教育、並行稼働、保守、追加改修を含めた5年総額を比較します。データの所有者、API利用条件、エクスポート方法、障害時の復旧目標、解約時のデータ返却、設計書とソースコードの帰属も確認しておくと、将来のロックインを抑えられます。

設計では、要件を画面、帳票、データ、権限、連携、バッチ、ログに落とし込みます。受注入力画面を作るときも、販売先ごとの価格、納品条件、与信、在庫引当、分納、直送、納期回答、キャンセルの扱いまで決めます。倉庫側は入荷予定との照合、数量差異、破損、ロット・期限、ロケーション移動、ピッキング、検品、出荷確定、返品を一つの業務シナリオとして設計します。

商社型では、受注と発注を別伝票にするのか、案件番号で結び付けるのか、在庫を持たない取引をどのタイミングで売上・仕入計上するのかを明文化します。輸出入では、通貨、為替、船積み、入荷予定、関税、費用配賦、粗利の確定時点を経理と確認します。機能が豊富でも、取引の状態遷移が曖昧だと、納期や採算の数字が部門ごとに異なるためです。

開発中は、毎週の進捗会議で課題、決定事項、未決事項、変更要求を管理します。現場の代表者には、画面レビューだけでなく、実際のコードスキャン、入荷検品、棚卸、返品処理を体験してもらいます。標準機能に合わせて業務を変える場合は、変更理由と現場メリットを説明し、カスタマイズする場合は将来の保守費とバージョンアップへの影響を記録します。

テストは、プログラム単体の確認だけでは不十分です。単体テスト、機能間の結合テスト、実業務を通す総合テスト、利用者が受入条件を確認する受入テストの順で進めます。卸売・商社では、受注→在庫引当→発注→入荷→検品→出荷→売上・仕入→請求という正常系に加えて、欠品、分納、返品、直送、受注取消、仕入先の納期遅延、単位換算、ロット期限切れを必ず試します。

テストデータは、実際によく売れる商品だけでなく、類似品、セット品、単位が複数ある商品、休眠商品、価格改定品、期限の近い商品を含めます。マスタ移行では件数だけを照合せず、商品コード、名称、単位、在庫数量、評価単価、取引先、受注残、発注残の合計を旧システムと比較します。移行リハーサルを少なくとも一度行い、差異が出た場合の修正責任者と締切を決めます。

非機能テストでは、月間出荷明細や同時利用者数を前提にした性能、バックアップからの復元、障害時の連絡、権限の逸脱、操作ログ、APIエラー、ハンディの通信断を確認します。受入テストの合格条件は「担当者が触れた」ではなく、「受注残と発注残が所定の条件で表示される」「棚卸差異を承認できる」「取引履歴を追跡できる」のように判定可能な文にします。

全拠点を一斉切り替えするか、代表拠点や特定の商品群から段階導入するかを、取引量と業務の複雑さで決めます。初回は受注・発注・入出荷・棚卸に絞り、販売管理や会計、EDI、外部倉庫との連携を後続にする方法もあります。逆に、月末締めや法定帳票に関わる部分を後回しにすると、二重入力が長期化するため、締め処理の境界は先に決めます。

稼働前には、本番マスタの凍結日、最終棚卸、未処理受注、発注残、入荷予定、返品、請求締め、旧システムの参照期間を決めます。切り替え当日に不具合が起きても業務を止めないよう、紙の出荷指示、緊急連絡先、手入力用の様式、復旧判断者を準備します。旧システムをすぐに消去せず、一定期間は参照専用にすることで、過去取引の確認にも対応できます。

稼働直後は、問い合わせ窓口を一本化し、問い合わせ内容を操作ミス、マスタ不備、仕様差異、システム障害に分類します。日次で在庫差異、受注残、出荷遅延、連携エラーを確認し、週次で改善課題の優先順位を更新します。稼働判定を「システムが動く」ではなく、「業務が旧手順へ戻らず、必要なKPIを計測できる」と置くことが大切です。

定着の成否は、操作マニュアルを配るだけでは決まりません。営業には在庫・納期・受注残の確認方法、購買には発注点と納期回答、倉庫にはスキャン・検品・棚卸、経理には売上・仕入・請求の連携を、役割別の短い教材で教えます。新入社員や応援要員が後から使えるよう、画面の説明だけでなく、例外処理と問い合わせ先も残します。

1か月目は操作とデータの誤りを減らし、3か月目は在庫差異と入力時間、6か月目は欠品率、在庫回転率、滞留在庫金額など経営指標を見直します。利用率が低い部門があれば、利用者を責めるのではなく、入力項目が多すぎる、現場の通信が不安定、マスタ登録の責任者が不明、旧Excelの方が早いといった原因を分解します。

AI需要予測やAI-OCRは、商品コード、取引日、数量、単位がそろってから段階的に導入します。入力ルールが統一されていない状態でAIを追加しても、誤った予測や読取結果の確認作業が増える可能性があります。まずバーコード、マスタ、権限、履歴、棚卸を安定させ、その後に予測や自動化へ進む順番が現実的です。

卸売・商社向け在庫管理システムの費用相場とコスト内訳

費用は、利用者数だけでなく、商品点数、拠点数、月間明細、ロット・期限、ハンディ台数、EDI・API本数、会計連携、データ移行、教育、非機能要件で大きく変わります。以下は在庫・購買・受発注システムの一般的な目安を卸売・商社向けに読み替えたレンジであり、公的な平均価格や個別案件の確定額ではありません。見積もりでは、方式ごとの初期費用と運用費を分けて確認します。

クラウドSaaSは、設定と初期データ移行を含めて初期費用0〜50万円程度から始められるケースがあります。公開料金の一例として、ZAICOは2026年6月以降の料金表で、スターター月額8,980円、ベーシック月額49,800円、プロフェッショナル月額15万円以上を税別で示しています（出典: 株式会社ZAICO「在庫管理システム zaico 機能一覧」2026年）。ただし、これはライセンスの実例であり、卸売向けの受発注、会計、EDI、ハンディ、移行、教育まで含む導入総額ではありません。

業界パッケージは、初期費用100万〜1,000万円程度、導入期間3〜6か月程度が一つの目安です。標準機能の適合度が高ければ費用と期間を抑えられますが、特殊な単位換算、取引先別帳票、直送、複数会社、EDIを追加すると上振れします。セミオーダーやERPは500万〜8,000万円程度、期間6か月〜2年程度、フルスクラッチは1,000万〜数億円で、中〜大規模では5,000万〜3億円以上になる目安もあります。これらは要件・工数・連携数からの推定レンジであり、特定金額を保証するものではありません。

大規模な開発では、複数拠点や既存基幹の刷新、外部倉庫・物流会社との連携、厳格な性能・監査要件が費用を押し上げます。反対に、1拠点で標準的な入出庫と棚卸から始め、会計や受発注の連携を後から追加するなら、初期範囲を絞れる可能性があります。相場を見るときは、金額の大小だけでなく、どこまでが初期範囲に含まれるかを確認します。

開発費の内訳は、要件定義、設計、開発・単体テスト、結合・総合テスト、移行・導入に分けて提示してもらいます。類似する業務システムの目安では、要件定義10〜15%、設計25〜35%、開発・単体テスト30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%程度という構造で整理されることがあります。ただし、既存データが汚れている企業や連携が多い企業では、移行・テストの比率が高くなるため、割合を固定的に使わないことが大切です。

別途費用になりやすい項目は、商品マスタのクレンジング、過去在庫・受注履歴の移行、EDIやAPIの接続、外部倉庫との調整、ハンディやラベルプリンター、帳票追加、現場教育、操作マニュアル、休日の切り替え支援、並行稼働、バックアップ環境です。見積書に「一式」と書かれている項目は、数量、単価、成果物、回数、前提条件を質問します。

運用費には、SaaSの月額利用料、サーバー・クラウド基盤、ユーザーや拠点の追加、ハンディ端末、通信、バックアップ、監視、問い合わせ、障害対応、法改正対応、追加改修が含まれます。パッケージやセミオーダーでは、初期費用の年10〜20%程度を保守の目安として置く場合がありますが、契約時間、対象範囲、バージョンアップ、休日対応、訪問支援の有無によって変動します。

EDIやAPIは、接続先の仕様変更、通信量、監視、再送、エラー時の手動処理まで費用に影響します。会計連携では締め処理や税区分、請求書連携では取引データの保存や検索、改ざん防止の運用も確認します。国税庁はEDI、インターネット、電子メールの添付ファイルなどを電子取引に含め、電子取引データを一定の要件で保存する必要があると案内しています（出典: 国税庁「電子帳簿保存法の概要」）。

卸売・商社向け在庫管理システムの見積もりを取る際のポイント

相見積もりを取る目的は、最も安い会社を決めることではなく、同じ業務条件で費用・期間・責任分界を比較することです。候補会社へ渡す情報が曖昧だと、A社は移行を含み、B社は開発だけ、C社は連携を別料金として見積もるため、金額を並べても判断できません。簡易なRFPを作り、要件と前提条件をそろえます。

RFPには、会社・事業所・倉庫・外部倉庫の数、利用者と権限、商品点数、年間・月間の受注件数、出荷明細、仕入先・販売先の数、バーコードやラベルの種類、ロット・期限の有無、受注残・発注残の件数を記載します。システムの規模は「中小企業」「大量取引」といった言葉ではなく、データ量とピーク時間で伝えることが大切です。

業務要件には、通常処理と例外処理を分けて書きます。通常処理は受注から出荷、発注から入荷、棚卸から差異承認までを示し、例外処理は分納、返品、直送、預託、欠品、代替品、仕入先変更、輸出入、受注取消、在庫を持たない売買同時計上を示します。各業務について、入力者、承認者、確定タイミング、取消方法、履歴の残し方、帳票、連携先を整理します。

非機能要件には、稼働時間、同時利用者数、応答時間、バックアップ頻度、復旧目標、認証、MFA、IP制限、ログ保存期間、権限、API、CSV出力、障害時の手作業を含めます。電子取引データを扱う場合は、取引年月日、金額、取引先などで検索できるか、訂正・削除の履歴や事務処理規程をどう整えるかを、経理と情報システムの両方で確認します。

候補会社には、同じ業務シナリオでデモを依頼します。たとえば「受注した商品が自社倉庫にないため仕入先へ発注し、直送または入荷後出荷を選び、分納が発生し、売上・仕入・請求を確認する」という流れです。卸売型なら期限の近い商品を先に出す、ハンディで検品する、棚卸差異を承認するシナリオを加えます。商社型なら在庫を持たない取引、外貨、案件別粗利、受発注同時登録を加えます。

確認する質問は、同業・類似規模の導入実績、標準機能とカスタマイズの境界、導入責任者、現場教育の方法、移行作業の担当、連携障害時の一次対応、保守時間、追加改修の単価、データ返却、契約終了時の移行支援です。導入事例は「効率化した」という表現だけでなく、商品点数、拠点数、出荷明細、利用端末、対象業務が自社に近いかを見ます。

カスタマイズのリスクは、業務を変えずに旧帳票やExcelをそのまま再現しようとすることで増えます。追加する前に、標準機能で代替できないか、手順を変えられないか、将来のバージョンアップで壊れないかを確認します。特に、少数の担当者しか使わない特殊帳票や、判断の根拠が曖昧な承認は、まず運用ルールを整理してから要否を決めます。

移行のリスクは、旧システムのデータをそのまま取り込めると考えることです。商品コードの重複、廃番品、単位の違い、取引先名の表記ゆれ、在庫評価単価の欠損、受注残の定義違いを事前に洗い出します。移行対象を「現行在庫だけ」「未完了の受注・発注」「過去の検索用履歴」に分け、必要な保持期間と検索方法を決めます。

定着のリスクは、導入後の責任者と改善予算が決まっていないことです。業務部門のオーナー、マスタ管理者、システム管理者、ベンダー窓口を明確にし、月次のKPI会議を予定に入れます。商品追加、価格改定、倉庫追加、取引先のEDI変更など、日常的な変更を誰が申請し、誰が承認し、いつ反映するかも運用設計に含めます。

よくある質問（FAQ）

卸売・商社の導入では、期間、WMSとの違い、Excelからの移行、AIの必要性について質問が多くあります。自社の規模や業態で答えは変わりますが、最初に判断するときの基準を整理します。

標準機能中心のクラウドSaaSであれば、設定・データ移行を含めて1〜3か月程度、業界パッケージで3〜6か月程度が一つの目安です。複数拠点、EDI・API、会計連携、商社固有の外為や売買同時計上、全面的な基幹刷新がある場合は、6か月から2年程度、またはそれ以上になる可能性があります。期間は機能数よりも、意思決定の速さ、マスタ整備、テストデータの準備、現場の参加度で変わります。

倉庫内の入荷、ロケーション、ピッキング、検品、出荷精度が主課題ならWMSが有力ですが、受注・発注・売上・仕入・請求や拠点間の在庫を統合したい場合は、販売・購買・在庫を含む基幹側の設計が先になります。どちらか一方に決めるのではなく、在庫の正本をどのシステムに置き、受注や発注の状態をどの連携で同期するかを決めます。食品卸のように期限・ハンディ・大量出荷が重要ならWMSとの連携を要件に含めます。

Excelをそのまま取り込むのではなく、商品コード、単位、取引先、倉庫、在庫数量、受注残、発注残の正しい定義を決め、重複・表記ゆれ・廃番・欠損を整理します。現場ごとに別ファイルを使っている場合は、どのファイルが正しいかを責任者が決め、移行前の棚卸で現物とデータを突き合わせます。過去履歴はすべて移行するのではなく、日常検索に必要な期間と、監査・請求確認に必要な保存方法を分けると、費用と期間を抑えやすくなります。

最初から必須ではありません。商品マスタ、販売実績、季節性、発注・入荷実績、単位が統一され、欠品や過剰在庫の原因を説明できる状態になってから、発注点や安全在庫の補助として導入する方が効果を検証しやすくなります。導入する場合も、AIの予測値を自動発注へ直結させず、担当者が根拠を確認して承認する運用から始めます。

まとめ

卸売・商社向け在庫管理システムの開発は、在庫数量を表示する画面を作ることから始めません。卸売型では受注残・発注残・入荷予定・期限・多拠点をつなぎ、商社型では直送、売買同時計上、輸出入、案件別採算まで含めて、取引全体を追跡できる状態を目指します。

進め方は、要件整理で現状とデータをそろえ、選定で標準機能・連携・5年総額を比べ、設計開発で例外処理を形にし、テストで実データと異常系を検証します。その後、段階導入や並行運用で稼働リスクを抑え、教育とKPI改善で定着させます。各段階に承認者、成果物、完了条件を置けば、曖昧な追加要望や手戻りを早く発見できます。

まずは商品マスタと拠点一覧を作り、現物在庫、Excel在庫、基幹システム在庫を同じ商品コードと単位で突合します。次に、受注から出荷、発注から入荷、返品や直送までの業務フローを描き、現場が困っている場面を優先順位付けします。そこからRFPやPoCを準備し、自社に合う方式と開発パートナーを比較することが、費用と導入後の定着を見通す第一歩になります。

▼全体ガイドの記事
・卸売・商社向け在庫管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。