SKU管理システム開発の発注/外注/依頼/委託方法について

SKU管理システムの発注・外注は、SaaSやパッケージを選ぶだけでなく、SKUマスタの責任者と在庫確定のルールを定義し、業務に合う範囲を段階的に委託することが成功の近道です。

「SKU管理システムを開発会社へ依頼したいが、何を伝えればよいか分からない」「SaaSとスクラッチ開発のどちらが自社に合うか判断できない」という悩みは少なくありません。本記事では、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積書の比較方法まで、発注前に整理すべき実務を順番に解説します。

▼全体ガイドの記事
・SKU管理システム開発の完全ガイド

SKU管理システムの発注・外注を始める前に知るべき全体像

SKU（Stock Keeping Unit）は、色・サイズ・容量・仕様などを区別した最小の在庫管理単位です。同じ商品名のTシャツでも、白のMサイズと黒のLサイズは通常別SKUとなり、それぞれに在庫数、価格、発注点、バーコードなどを持たせます。発注・外注で重要なのは、商品名を一覧にすることではなく、SKUの親子関係と在庫の変動履歴を業務全体でつなぐことです。

発注前に、商品を登録・変更・廃止する部署と、SKUコードやJANコードを確定する担当者を決めます。ECモール、POS、倉庫、会計システムがそれぞれ商品コードを持っている場合、どのシステムを正本にするかを決めないまま連携すると、同一商品の二重登録や在庫の不一致が起きやすくなります。RFPには、親商品、SKU、JAN・バーコード、単位、価格・原価、仕入先、拠点、棚番、ロット・期限をどの単位で管理するかを明記します。

SKU管理では、画面やAPIを作ることより、既存データの整理と現場運用の切り替えに時間がかかる場合があります。Excelに重複SKU、表記ゆれ、単位違い、廃番データが混在しているなら、データクレンジング、移行用CSVの作成、移行リハーサル、棚卸の突合まで委託範囲に含めます。さらに、操作マニュアル、現場研修、稼働後の問い合わせ窓口、障害時の連絡手順も見積書の対象にすると、納品後に別料金が発生するリスクを抑えられます。

SKU管理システムはどの発注形態を選ぶべきですか？

結論からいえば、標準的な入出庫や棚卸が中心ならSaaSまたはパッケージ、独自の引当・商品構成・連携が競争力に直結するなら追加開発またはスクラッチが適しています。最初から全社機能を作り込むのではなく、標準機能を使いながら独自要件をAPIやアドオンで切り出すハイブリッド方式も現実的です。

SaaSは、入出庫、棚卸、発注点、拠点管理、権限管理などを短期間で始めたい企業に向きます。公開料金の一例として、らくらく在庫は初期費用無料で、500SKUのプランが月額3,000円×店舗数、5,000SKUのプランが月額5,000円×店舗数、30,000SKUのメガプランが月額55,000円×店舗数です（税別、出典: グリニッジ株式会社「らくらく在庫」料金、2026年確認）。セット販売やFBAマルチチャネル連携などは別料金となるため、基本料金だけで判断しないことが大切です。

zaicoも2026年6月1日からスターター、ベーシック、プロフェッショナルの3プランへ刷新し、棚卸、コードスキャン、ロット・期限、発注点、拠点管理、外部連携などを提供しています。SaaSを選ぶときは、SKU数だけでなく、利用者数、拠点数、API利用、データ移行支援、解約時のデータ返却、標準機能で扱えない例外処理の有無を確認します。

受託開発は、複雑なセット品や構成品、独自の引当順、製造・卸・ECをまたぐ業務など、既製品の設定だけでは運用できない場合に検討します。自社の競争力に関係しない入出庫・棚卸・権限・ログまで独自実装すると、初期費用と保守負担が膨らみます。標準化できる部分と差別化すべき部分を分け、業務のどこをSaaSに任せ、どこを独自システムに残すかをRFPの段階で整理します。

ハイブリッド方式では、コア在庫をSaaSやパッケージで管理し、独自のSKUマスタ、販売チャネル連携、発注提案、分析画面などをAPIで接続します。1拠点・代表的な100〜500SKUで入荷、引当、出荷、返品、棚卸を通しで試し、問題がなければ他拠点へ広げる進め方です。発注先には、APIの再送、重複受信、通信断、部分出荷、キャンセル、在庫マイナスを実データで検証するPoCを依頼します。

SKU管理システムの発注・外注を進める5ステップ

発注では、候補会社を先に決めてから要件を考えるのではなく、現状の業務とデータを整理し、その内容を同じ条件で複数社へ提示します。以下の5ステップで進めると、価格だけでなく提案の品質やリスクも比較しやすくなります。

まず、商品・SKU・JAN・在庫・受注・発注・返品・倉庫ロケーションの台帳を集めます。SKU数は登録件数だけでなく、稼働中、予約、廃番、セット品、構成品に分け、拠点数、販路数、月間受注件数、月間出荷件数、同時利用者数も数えます。ExcelとECモールでコードが違う場合は対応表を作り、在庫の正本と更新タイミングを仮決めします。

現状と希望をまとめたRFP（提案依頼書）には、背景、目的、対象業務、対象データ、連携先、非機能要件、希望納期、予算の考え方、提案書の提出形式を記載します。「在庫をリアルタイムにしたい」だけでは解釈が分かれるため、受注確定、引当、出荷確定、返品受付、棚卸差異の承認など、在庫が変わるイベントを業務シナリオで示します。候補会社には、標準対応、設定対応、追加開発、対象外を分類して回答してもらいます。

デモでは、きれいなサンプル商品だけでなく、カラー・サイズ違い、セット品、返品、部分出荷、欠品、ロット・期限、拠点間移動を使います。既存データを少量移行し、入荷から出荷、返品、棚卸までの数量が各履歴に残るか確認します。CSVの文字コード、空欄、重複受信、APIエラー時の再送、通信断からの復旧も確認し、受入テストの合格条件として文書化します。

本番稼働は、全拠点を一度に切り替えるより、1拠点または1ブランドから始める方が安全です。在庫差異率、欠品率、売り越し件数、棚卸時間、出荷リードタイムを稼働前後で比較し、効果と残課題を確認します。発注先には、操作研修、問い合わせ対応、障害時の一次切り分け、月次レビュー、追加拠点の展開支援をいつまで提供するか確認します。

RFP・要件整理で発注先に伝えるべき項目

RFPの目的は、発注先に仕様を一方的に押し付けることではなく、各社が同じ前提で提案し、見積条件の差を見えるようにすることです。特にSKU管理では、機能の有無よりデータの粒度と例外処理の定義が見積額を左右します。

商品（親商品）とSKU（子商品）の関係、SKUコードとJAN・型番の違い、単位換算、セット品と構成品、仕入先、価格・原価、拠点、棚番を定義します。在庫も実在庫だけでなく、有効在庫、確保在庫、受注残、入荷予定、安全在庫、発注点に分けます。ロット番号、賞味期限・使用期限、先入先出、トレーサビリティが必要なら、後付けではなく初期要件として明示します。

連携先ごとに、送受信する項目、連携方向、実行タイミング、エラー時の再送、重複防止、手動補正の責任者を表にします。ECの受注を取り込み、在庫を引き当て、出荷確定を戻す場合、どの時点を在庫減算とするかが曖昧だと売り越しにつながります。LOGILESSの公式機能説明でも、商品マスタ、リアルタイム在庫、ロット、賞味期限、ロケーション、在庫操作ログ、庫内デバイスが分けて説明されています（出典: 株式会社ロジレス「在庫管理機能」、2026年確認）。この粒度で自社の連携要件を整理します。

担当者ごとの最小権限、MFA、IP制限、通信・保存データの暗号化、変更履歴、在庫調整理由、バックアップ、復旧目標（RTO・RPO）、障害通知、APIキー管理、脆弱性対応、データのエクスポートをRFPに書きます。顧客や配送先の情報を扱う場合、個人情報保護委員会は、委託先の安全管理措置を事前に確認し、契約内容の実施状況を監査するなどして把握することが望ましいと示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、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数、拠点数、連携数、ハンディ端末、ロット・期限、既存データの状態によって大きく変わる推定レンジです。

リサーチノートの業務システム相場では、PMが1人月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倍に膨らむ可能性があるため、安い提案ほど作業範囲と前提条件を確認します。

ランニングコストには、クラウド利用料、ユーザー追加、拠点追加、API回数、連携オプション、ハンディ端末、バーコード機器、保守、監視、バックアップ、データ保管、問い合わせ対応が含まれます。SaaSでは、利用量やオプションで月額が変わるため、SKU数・店舗数・ユーザー数が増えた場合の料金表を確認します。受託開発では、保守費を初期費用の年15〜25%程度とする提案もありますが、対応時間、対象範囲、バージョンアップ、障害対応を含めて個別に確認します。

SKU管理システムの委託先選定と見積比較のポイント

委託先は、知名度や最安値だけでなく、自社と近いSKU数・拠点数・販路数の経験、データ移行の責任範囲、現場端末への理解、連携障害への対応力で選びます。見積書を横並びにする際は、各社の「含む・含まない」を一つの表にまとめ、初期費用だけでなく3年総額と稼働後の変更費まで比べます。

候補会社には、同業の導入社数だけでなく、近いSKU数、拠点数、月間出荷量、ロット・期限の有無、EC・POS・WMS・ERPの連携実績を尋ねます。デモでは、代表的な商品マスタを使い、入荷、受注引当、部分出荷、返品、棚卸差異の承認まで再現します。現場の担当者が操作して、バーコードの読み取り、通信断時の対応、修正履歴の確認を行うことが重要です。

見積比較では、要件定義、設計、開発、テスト、移行、教育、保守を分け、各工程の工数と単価を確認します。特に、データクレンジング、SKUコードの変換、初期在庫の登録、APIの接続試験、受入テストの支援が含まれているかを見ます。提案書に「連携対応」とだけ書かれている場合は、項目数、方向、頻度、認証方式、エラー再送、監視、再処理の方法まで質問します。

候補3社程度に同一RFPを配布し、価格、納期、体制、標準機能と追加開発の境界、3年総額、リスク、発注者側の作業を比較します。価格差が大きい場合は、品質の差と決めつけず、対象外となった機能、移行件数、テストケース、保守時間、第三者サービス費を確認します。初期費用が安くても、拠点やSKUが増えたときの追加料金が高い場合は、将来費用まで含めると評価が逆転することがあります。

よくある失敗は、Excelとの二重管理、SKUコードの重複、連携タイミングの不一致、ロット管理の後付け、例外処理の未テスト、現場教育不足です。対策として、SKUマスタの正本、変更権限、在庫調整の承認、データ移行の検収、障害時の代替手順、受入テストの合格条件を文書化します。納品後の不具合修正、脆弱性対応、バックアップ復元テスト、データ返却も契約に含めます。

顧客や配送先の個人情報を委託先が扱うなら、アクセスできる情報とシステムの範囲、再委託の事前報告・承認、監査・報告、事故時の連絡期限を決めます。個人情報保護委員会のガイドラインでも、委託先の安全管理措置の確認と、再委託先を含む取扱状況の把握が示されています。発注者が丸投げするのではなく、業務責任者、IT責任者、現場責任者を社内に置くことが、納品後の運用リスクを下げます。

SKU管理システムの発注・外注でよくある質問

最後に、発注前に多く寄せられる疑問へ回答します。自社の条件に置き換え、RFPや候補会社への質問事項として活用してください。

あります。SKU数が少なくても、販路が複数ある、返品やセット品が多い、在庫差異の確認に時間がかかる場合は、標準的なSaaSを短期間で導入する効果が見込めます。一方、単一拠点で入出庫が少なく、既存の表計算で正確に運用できているなら、まず無料トライアルや小規模プランで業務適合性を検証し、いきなりスクラッチ開発を発注しない判断も適切です。

形式を変換すれば移行できる場合がありますが、そのままの移行は避けます。重複SKU、空欄、単位違い、旧コード、廃番、商品名の表記ゆれを整理し、移行前後の件数と在庫数量を突合します。少量の代表データで移行リハーサルを行い、初期在庫、ロット・期限、拠点、棚番、セット品が正しく登録されることを確認してから全件移行します。

相談できます。発注前の現状調査や要件定義を準委任で支援してもらい、その成果をRFPと要件定義書にまとめてから開発契約へ進む方法があります。相談時には、現在の台帳、業務フロー、困っている在庫差異、SKU数、拠点数、連携先、希望時期を準備すると、初回打ち合わせで具体的な論点を整理しやすくなります。

まず、機能の価格ではなく、前提条件と対象範囲を確認します。要件定義、データクレンジング、移行、連携試験、教育、保守、端末、追加拠点の費用が含まれているかをそろえ、同じSKU数・拠点数・連携数で3年総額を比較します。安い提案に対象外や発注者側作業が多い場合は、その作業を社内で担えるかまで含めて判断します。

まとめ

SKU管理システムの発注・外注では、最初にSKUマスタの責任者、在庫の正本、在庫が変わるタイミングを決めます。そのうえで、SaaS・パッケージ・受託開発・ハイブリッドのどれが業務に合うかを比較し、標準機能と独自開発の境界を明確にします。

RFPには、SKU・商品・在庫・ロット・期限・セット品のデータ要件、EC・POS・WMS・ERPとの連携、権限・ログ・バックアップ、移行と教育の範囲を記載します。代表的なSKUで入荷、引当、出荷、返品、棚卸を通しで検証し、受入条件と稼働後のKPIまで発注先と共有します。

請負と準委任を要件の確定度に応じて使い分け、成果物、検収、知的財産、再委託、保守、データ返却を契約で確認します。初期費用だけでなく、移行費、連携費、端末、月額、追加SKU・拠点、保守、障害対応を含む総額で見積もりを比べると、自社に合う委託先を選びやすくなります。

▼全体ガイドの記事
・SKU管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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