SKU管理システムの発注・外注は、SKUマスタの責任者と在庫確定のルールを決め、業務に合う範囲を段階的に委託する流れで進めます。
「何を伝えればよいか分からない」「SaaSとスクラッチ開発のどちらが自社に合うか判断できない」という悩みは少なくありません。
▼全体ガイドの記事
・SKU管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SKU管理システムの発注・外注の全体像
SKU（Stock Keeping Unit）は、色・サイズ・容量・仕様などで区別した、在庫を管理する最小の単位です。たとえば、同じ商品名のTシャツでも、白のMサイズと黒のLサイズは通常別のSKUになります。それぞれに在庫数や価格、発注点、バーコードを持たせます。
発注・外注で押さえたいのは、SKUの親子関係と在庫の変動履歴を業務全体でつなぐことです。商品名を一覧にしただけでは、この関係は見えません。
SKUマスタの責任者の決定
商品を登録・変更・廃止する部署と、SKUコードやJANコードを確定する担当者は、発注前に決めておきます。ECモールやPOSのほか、倉庫と会計システムがそれぞれ商品コードを持つ場合は、どのシステムを正本にするかを先に決めます。決めないまま連携すると、同一商品の二重登録や在庫の不一致が起きやすくなります。
RFPには、商品をどの単位で管理するかを明記します。まず、親商品とSKU、JAN・バーコード、単位の関係を書きます。価格・原価や仕入先のほか、拠点、棚番、ロット・期限も、同じ単位で揃えて書きます。
外注範囲に含める移行と定着
SKU管理では、画面やAPIを作ることより、既存データの整理と現場運用の切り替えに時間がかかる場合があります。そのため、移行の範囲は発注時に明示しておく必要があります。
たとえば、Excelに重複SKUや表記ゆれ、単位違い、廃番データが混在しているなら、その整理も委託範囲に含めます。具体的には、データクレンジングや移行用CSVの作成、移行リハーサル、棚卸の突合が対象です。
さらに、操作マニュアルや現場研修、稼働後の問い合わせ窓口、障害時の連絡手順も、見積書の対象にします。こうして含めておくと、納品後に別料金が発生するリスクを抑えられます。
SKU管理システムの発注形態の選び方
標準的な入出庫や棚卸が中心なら、SaaSまたはパッケージが合います。独自の引当や商品構成、連携が競争力に直結するなら、追加開発またはスクラッチが適しています。
- SaaS・パッケージを導入するケース
- 受託開発・スクラッチを選ぶケース
- ハイブリッド方式で段階的に発注するケース
最初から全社の機能を作り込まず、標準機能を使いながら独自の要件をAPIやアドオンで切り出す方式もあります。これがハイブリッド方式で、現実的な選択肢になります。
SaaS・パッケージを導入するケース
SaaSは、入出庫や棚卸、発注点などを短期間で始めたい企業に向いています。拠点管理や権限管理も、同じ仕組みの中で扱えます。SaaSを選ぶときは、SKU数だけで決めず、ほかの条件も比べます。
- 規模：SKU数に加えて、利用者数と拠点数
- 連携と移行：API利用の可否とデータ移行支援
- 解約と例外：解約時のデータ返却、標準機能で扱えない例外処理の有無
公開料金の一例として、らくらく在庫は初期費用が無料です。月額は、500SKUのプランが3,000円×店舗数、5,000SKUのプランが5,000円×店舗数です。30,000SKUのメガプランは55,000円×店舗数です（税別、出典: グリニッジ株式会社「らくらく在庫」料金、2026年確認）。
セット販売やFBAマルチチャネル連携は別途かかるため、基本料金だけで判断すると、その分を見落とすおそれがあります。
zaicoも2026年6月1日から、スターター、ベーシック、プロフェッショナルの3プランに刷新されました。棚卸やコードスキャン、ロット・期限の管理を提供しています。発注点や拠点管理、外部連携なども備えています。
受託開発・スクラッチを選ぶケース
受託開発は、既製品の設定だけでは運用できない場合に検討します。たとえば、複雑なセット品や構成品、独自の引当順、製造・卸・ECをまたぐ業務が当てはまります。
自社の競争力に関係しない入出庫・棚卸・権限・ログまで独自に実装すると、初期費用と保守負担が膨らみます。
自社では、標準化できる部分と差別化すべき部分を分け、業務のどこをSaaSに任せ、どこを独自システムに残すかを、RFPの段階で整理します。
ハイブリッド方式で段階的に発注するケース
ハイブリッド方式では、コア在庫をSaaSやパッケージで管理します。独自のSKUマスタや販売チャネル連携、発注提案、分析画面などは、APIで接続します。
まず、1拠点・代表的な100〜500SKUで、入荷、引当、出荷を通しで試します。返品と棚卸も試し、問題がなければ他拠点へ広げます。
発注先には、実データで検証するPoCを依頼します。APIの再送や重複受信、通信断の扱いを確かめます。部分出荷やキャンセル、在庫マイナスも、確認の対象に含めます。
SKU管理システムの発注・外注を進める流れ
発注では、候補会社を先に絞るより、現状の業務とデータを整理することが先です。その内容を同じ条件で複数社に示すと、提案を比べやすくなります。段階を追って進めると、価格だけでなく提案の質やリスクまで見比べられます。
現状調査によるSKU数・拠点数・販路数の確定
まず、商品・SKU・JAN、在庫、受注の台帳を集めます。発注や返品、倉庫ロケーションの台帳も、対象に含めます。
SKU数は登録件数だけでなく、稼働中・予約・廃番の状態ごとに分けます。セット品と構成品も、別に数えます。拠点数や販路数に加えて、月間の受注件数と出荷件数、同時利用者数も数えます。
ExcelとECモールでコードが違う場合は、対応表を作り、在庫の正本と更新タイミングを仮決めします。
RFPの配布と提案内容のそろえ方
現状と希望をまとめたRFP（提案依頼書）には、背景と目的、対象業務を書きます。対象データや連携先、非機能要件も記載します。希望納期と予算の考え方、提案書の提出形式も、あわせて示します。
「在庫をリアルタイムにしたい」だけでは、解釈が分かれます。そのため、在庫が変わる場面を業務シナリオで示します。
たとえば、受注確定や引当、出荷確定などが対象です。返品受付や棚卸差異の承認も含めます。候補会社には、標準対応と設定対応、追加開発、対象外を分類して回答してもらいます。
PoCと移行リハーサル
デモでは、きれいなサンプル商品だけでなく、業務で起きる場面を含む商品を使います。カラー・サイズ違い、セット品、返品を含めます。さらに、部分出荷や欠品、ロット・期限、拠点間移動も確認します。
自社の既存データを少量移行し、入荷から出荷、返品、棚卸までの数量が各履歴に残るかを確かめます。
CSVの文字コードや空欄を確認します。重複受信やAPIエラー時の再送、通信断からの復旧も見ます。受入テストの合格条件として文書化します。
段階稼働と定着支援の契約範囲
本番稼働は、全拠点を一度に切り替えるより、1拠点または1ブランドから始める方が安全です。稼働前後で、在庫差異率や欠品率、売り越し件数を比べます。棚卸時間や出荷リードタイムも比べ、効果と残課題を確認します。
発注先には、操作研修や問い合わせ対応、障害時の一次切り分けを、いつまで提供するか確認します。月次レビューや追加拠点の展開支援も、期限を決めて確かめます。
RFP・要件整理で発注先に伝えるべき項目
RFPの目的は、発注先に仕様を伝えて、各社が同じ前提で提案し、見積条件の差が見えるようにすることです。特にSKU管理では、機能の有無よりも、データの粒度と例外処理の定義が見積額を左右します。
SKU・在庫・取引データの関係の定義
商品（親商品）とSKU（子商品）の関係、SKUコードとJAN・型番の違いを定義します。単位換算や、セット品と構成品の扱いも決めます。
仕入先や価格・原価は、どの単位で持つかを決めます。拠点と棚番も、定義に含めます。
在庫は、実在庫だけでなく有効在庫や確保在庫に分けます。受注残や入荷予定、安全在庫、発注点も、在庫の種類として整理します。必要な場合は、ロット番号や賞味期限・使用期限、先入先出、トレーサビリティを、初期要件として最初から明示します。
EC・POS・WMS・ERPとの連携境界の決定
連携先ごとに、送受信する項目と連携方向を表にします。実行タイミングやエラー時の再送、重複防止も書き込みます。手動補正の責任者も、表に加えます。
たとえば、ECの受注を取り込み、在庫を引き当て、出荷確定を戻す場合、どの時点を在庫減算とするかが曖昧だと売り越しにつながります。
LOGILESSの公式機能説明でも、商品マスタとリアルタイム在庫、ロット・賞味期限が分けて説明されています（出典: 株式会社ロジレス「在庫管理機能」、2026年確認）。ロケーションや在庫操作ログ、庫内デバイスも、別の機能として並んでいます。この粒度で自社の連携要件を整理します。
非機能要件に入れる権限・ログ・バックアップ
担当者ごとの最小権限、MFA、IP制限を、RFPの非機能要件に書きます。通信や保存データの暗号化、変更履歴、在庫調整の理由も書きます。
バックアップや復旧目標（RTO・RPO）、障害通知も入れます。さらに、APIキー管理、脆弱性対応、データのエクスポートも書きます。
顧客や配送先の情報を扱う場合、個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」（2026年確認）では、委託先の安全管理措置を事前に確認することが示されています。契約内容の実施状況を監査し、取扱状況を把握することも求められます。
SKU管理システムの契約形態の選び方
契約形態は、要件の確定度と、発注者が負う変更リスクの大きさで選びます。契約名だけで決めず、契約書と見積書で中身を確認します。
確認するのは、成果物と検収条件、仕様変更の扱いです。さらに、責任分界や知的財産、再委託を見ます。保守の範囲も、同じ契約書と見積書で確かめます。
請負契約の成果物と検収条件
請負契約は、定義した成果物を完成させ、検収することを重視する契約です。成果物には、画面一覧やAPI仕様、移行データを含めます。テスト結果や操作マニュアルも、成果物として定めます。
検収期限、重大不具合の扱い、修正期限も明記します。要件が固まっていない段階で全工程を固定価格にすると、想定外の例外処理が追加費用や納期延長につながるため、要件定義を先行して契約を分ける方法もあります。
準委任契約の要件整理と伴走支援
準委任契約は、専門家の稼働や業務遂行を依頼する形の契約です。現状調査やRFP作成支援、要件定義に向きます。プロジェクト管理やアジャイル開発、運用改善などにも使えます。
成果物の完成を一律に保証する契約ではないため、担当者の役割や稼働時間を明確にします。定例会や報告内容、意思決定の期限も、決めておきます。
発注者側にも、業務部門の参加やデータ提供、レビュー、受入判断を行う責任があることを合意します。
知的財産・再委託・保守の責任分界
納品範囲には、開発したプログラムだけでなく、設計書やデータモデル、API仕様を含みます。テスト仕様やインフラ設定も、納品範囲として確認します。IaCや運用手順も含めます。
著作権の帰属や利用許諾、第三者ライブラリの条件を決めます。契約終了時のデータ返却や、再委託先の開示と承認、脆弱性修正の期限も、契約に書いておきます。
個人データを扱う場合は、再委託先の選定・契約・監査についても、委託元が把握できる条項を設けます。法的な判断が必要な条項は、弁護士などの専門家にも確認します。
SKU管理システムの費用相場とコストの内訳
SKU専用の開発費は、公的な平均統計が確認しにくいものです。そのため、ここでの数字は、公開料金と、在庫・販売・物流を含む業務システムの人月単価・工数を組み合わせた目安です。
税込と税別の表示や、端末、バーコードプリンターは、会社によって別計上になります。倉庫作業費や既存データのクレンジングも、別計上になります。そのため、特定の金額をそのまま予算化せず、同じ条件のRFPで見積もりを取ります。
導入パターン別の初期費用・期間の目安
小規模SaaSは、初期設定や移行支援を含めて0万〜30万円程度の初期費用で、月額3,000円〜15万円程度、即日〜1か月程度で始められるケースがあります。中堅SaaS・パッケージは、設定や教育、連携を含めて30万〜300万円程度です。月額は1万〜50万円程度、導入期間は1〜4か月程度が目安です。
公開料金では、らくらく在庫の月額3,000円〜55,000円×店舗数という段階制が確認できますが、オプションや店舗数で変わります。独自要件を含むMVPスクラッチは、費用が300万〜1,000万円程度、期間が3〜6か月程度です。EC・WMS・ERP連携型は、費用が1,000万〜3,000万円程度、期間が6〜12か月程度です。
全社基幹・大規模スクラッチは、費用が3,000万〜1億円超、期間が12〜24か月以上となる可能性があります。これらは推定のレンジで、SKU数や拠点数、連携数によって大きく変わります。ハンディ端末やロット・期限、既存データの状態も影響します。
人件費と工数の見方
リサーチノートの業務システム相場では、1人月あたりの単価の目安が示されています。PMは90万〜150万円、SEは65万〜110万円、PGは50万〜90万円です。中小開発会社は80万〜120万円、大手SIerは150万〜200万円程度です。
これはSKU管理システムの確定価格ではなく、体制や地域、契約条件で変わる参考値です。見積書では、要件定義や画面・API設計、実装、連携を分けてもらいます。テストと移行、教育と稼働後支援も、工程ごとに示してもらいます。
総費用に占める人件費は約60〜80%、要件定義は工期の約25%、テストは15〜17%程度という目安があります（出典: NotebookLMリサーチノート「業務システム全般_18」抽出Q&A、2026年）。要件定義を短くしすぎると、後から仕様変更が増え、当初工数の1.3〜1.5倍に膨らむ可能性があります。そのため、安い提案ほど作業範囲と前提条件を確認します。
月額以外のランニングコストと3年総額
ランニングコストには、クラウド利用料、ユーザーや拠点の追加、API回数が含まれます。連携オプションやハンディ端末、バーコード機器も、費用の対象になります。保守や監視、バックアップも、見込みに入れます。
データ保管や問い合わせ対応も、費用として数えます。SaaSでは、利用量やオプションで月額が変わるため、SKU数・店舗数・ユーザー数が増えた場合の料金表を確認します。
受託開発では、保守費を初期費用の年15〜25%程度とする提案もあります。対応時間や対象範囲、バージョンアップ、障害対応も含めて、個別に確認します。
SKU管理システムの委託先選定と見積比較
委託先は、知名度や最安値だけでなく、自社に近いSKU数や拠点数、販路数の経験で選びます。そのほか、データ移行の責任範囲や現場端末への理解、連携障害への対応力も見ます。
見積書を横に並べるときは、各社の「含む・含まない」を一つの表にまとめます。初期費用だけでなく、3年総額と稼働後の変更費まで比べます。
業務適合性で見る実績
候補会社には、同業の導入社数だけでなく、近いSKU数や拠点数を尋ねます。あわせて、月間出荷量やロット・期限の有無も確認します。EC・POS・WMS・ERPとの連携実績も尋ねておきます。
デモでは、代表的な商品マスタを使い、入荷や受注引当、部分出荷を再現します。返品や棚卸差異の承認まで、通しで見せてもらいます。現場の担当者が操作して、バーコードの読み取りや通信断時の対応、修正履歴の確認を行うと、確かめられます。
見積比較の前提条件のそろえ方
見積比較では、要件定義と設計、開発、テストごとに、工数と単価を確認します。移行や教育、保守も、工程として分けて示してもらいます。特に、データクレンジングやAPIの接続試験、受入テストの支援が含まれているかを見ます。
提案書に「連携対応」とだけ書かれている場合は、項目数や方向、頻度を質問します。認証方式やエラー再送、再処理の方法なども、具体的に聞きます。監視も含めて聞いておくと、各社の差が見えてきます。
候補3社程度に同一のRFPを配布し、価格や納期、標準機能と追加開発の境界、3年総額を比べます。価格差が大きい場合は、品質の差と決めつけず、対象外となった機能や発注者側の作業、移行件数、テストケース、保守時間、第三者サービス費を確認します。初期費用が安くても、拠点やSKUが増えたときの追加料金が高い場合は、将来費用まで含めると評価が逆転することがあります。
失敗リスクと契約上の対策
よくある失敗は、Excelとの二重管理、SKUコードの重複、連携タイミングの不一致です。ロット管理の後付けや例外処理の未テスト、現場教育不足も、よく見られる失敗です。対策として、SKUマスタの正本と変更権限、在庫調整の承認を文書にします。
データ移行の検収や障害時の代替手順、受入テストの合格条件も、同じように文書にします。納品後の不具合修正や脆弱性対応、バックアップ復元テストとデータ返却も、契約に含めます。さらに、発注者が丸投げしないよう、業務責任者やIT責任者、現場責任者を社内に置きます。
顧客や配送先の個人情報を委託先が扱うなら、アクセスできる情報の範囲と、再委託の事前報告や承認を決めます。監査や事故時の連絡期限も、あわせて決めます。個人情報保護委員会のガイドラインでも、委託先の安全管理措置の確認と、再委託先を含む取扱状況の把握が示されています。
SKU管理システムの発注・外注でよくある質問
発注前によく寄せられる疑問に、回答の形でまとめます。自社の条件に置き換えて、RFPや候補会社への質問事項として使ってください。
SKU数が少なくてもシステムを外注する意味はありますか？
外注する意味はあります。SKU数が少なくても、販路が複数ある場合や、返品やセット品が多い場合、在庫差異の確認に時間がかかる場合は、標準的なSaaSを短期間で導入する効果が見込めます。
一方で、単一拠点で入出庫が少なく、既存の表計算で正確に運用できているなら、まず無料トライアルや小規模プランで業務適合性を確かめる方法もあります。いきなりスクラッチ開発を発注しない判断も、適切です。
ExcelのSKUデータをそのまま移行できますか？
形式を変換すれば移行できる場合もありますが、そのままの移行は避けます。重複SKUや空欄、単位違いを整理します。旧コードや廃番、商品名の表記ゆれも整えたうえで、移行前後の件数と在庫数量を突合します。
少量の代表データで移行リハーサルを行い、初期在庫やロット・期限が正しく登録されることを確認します。拠点や棚番、セット品も確認したうえで、全件を移行します。
RFPを作る知識がなくても開発会社へ相談できますか？
相談できます。発注前の現状調査や要件定義を準委任で支援してもらい、その成果をRFPと要件定義書にまとめてから、開発契約へ進む方法があります。
相談時には、現在の台帳や業務フロー、困っている在庫差異を準備します。SKU数と拠点数、連携先、希望時期も伝えると、初回の打ち合わせで論点を整理しやすくなります。
見積もりが会社ごとに大きく違うときは何を見ればよいですか？
まず、機能ごとの価格よりも、前提条件と対象範囲を確認します。
要件定義やデータクレンジング、移行の費用が含まれているかをそろえます。連携試験や教育、保守の費用も、同じ条件で確認します。端末や追加拠点の費用も含め、同じSKU数・拠点数・連携数で3年総額を比べます。
安い提案に対象外や発注者側作業が多い場合は、その作業を社内で担えるかまで含めて判断します。
まとめ
SKU管理システムの発注・外注では、最初にSKUマスタの責任者と在庫の正本、在庫が変わるタイミングを決めます。
発注側は、SaaSやパッケージ、受託開発、ハイブリッドのどれが業務に合うかを比べ、標準機能と独自開発の境界を明確にします。
発注前のRFPと業務シナリオ
RFPには、SKU・商品・在庫・ロット・期限・セット品のデータ要件を書きます。EC・POS・WMS・ERPとの連携や、権限・ログ・バックアップも記載します。移行と教育の範囲も、含めておきます。
代表的なSKUで入荷、引当、出荷を通しで検証します。返品と棚卸も、同じ流れで確かめます。受入条件と稼働後のKPIまで、発注先と共有します。
3年の運用を見通した契約と費用の比較
請負と準委任は、要件の確定度に応じて使い分けます。成果物や検収、知的財産を契約で確認します。再委託や保守、データ返却も、同じ契約で確かめます。
初期費用だけでなく、移行費や連携費、月額まで含めた総額で比べます。追加SKUや拠点、保守、障害対応も見ておくと、自社に合う委託先を選びやすくなります。
▼全体ガイドの記事
・SKU管理システム開発の完全ガイド
▼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を創業。