化粧品・日用品業界のシステム開発は、商品から会計までのデータをつなぐ前提で、既存サービスと個別開発を使い分けて発注します。発注は、発注形態を決めたうえでRFPと要件を整え、工程に合う契約を選び、費用と委託先を比べて、段階的に稼働させるまでの流れで進みます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
化粧品・日用品業界のシステム開発を発注する前に知るべき全体像
化粧品・日用品向けのシステムは、在庫管理だけを担う単独のツールとは異なります。商品情報を起点に、受注、在庫引当、出荷、顧客、売上、会計までのデータがつながる仕組みです。データがつながって初めて、業務全体の効率化と販売機会の拡大につながります。
事業の共通言語としてのSKU・商品マスタ
販売単位、入荷単位、保管単位など、管理する粒度を決めておきます。原価や販売価格、販促対象、チャネル別の掲載可否も、あわせて定義します。
- 化粧品：ブランド、シリーズ、色、香り、容量、セット、限定版の単位で管理します。
- 日用品：詰め替え用、セット品、販促品、ケース入数、JANコードを扱います。
粒度が曖昧なまま外注すると、ECの表示と倉庫の在庫が一致しない原因になります。
OMOと定期通販をそろえた業務設計
OMOと定期通販は、顧客と現場の双方が扱いやすい形に設計します。たとえば、店舗で接客した顧客が後日ECで購入した場合、そのスタッフの貢献を評価に反映する設計も検討できます。
- OMO：店舗とECで顧客、ポイント、購入履歴、在庫を共通化し、どのシステムを正とするかを定めます。
- 定期通販：スキップ、次回配送日の変更、商品変更、解約、同梱サンプルやチラシの差し替えまでを対象に含めます。
化粧品・日用品業界のシステムに適した発注形態
既存サービスで業務を吸収できる範囲は、パッケージやSaaSを活用し、差別化につながる業務だけを個別開発する形態が現実的です。
フルスクラッチは自由度が高い一方、費用や納期、保守の負担が大きくなります。
SaaS・パッケージを中心とした委託形態
在庫や受注、WMS、定期通販など、標準機能が成熟した領域では、SaaSやパッケージを候補にします。導入会社には、初期設定やデータ移行、POSやECとのAPI連携、現場教育を依頼します。
たとえば、OMSとWMSを連携させ、一定間隔で出荷指示を自動で連携できれば、注文が急増したときの転記作業を減らせます。
選定時は、機能数だけでなく、自社の例外処理に対応できるかを確認します。例外処理の対象は、同梱物や返品、欠品です。ロットや複数倉庫も含まれます。
個別開発・フルスクラッチの形態
既存製品では合わせにくい業務は、個別開発の候補になります。独自の会員ランクや商品提案、AI肌診断との連携などが該当します。また、店舗スタッフへの売上還元も含まれます。
独自性のない機能まで作り込むと、投資の回収が難しくなります。そのため、MUSTは商品・在庫・受注・出荷・会計の正確性、WANTは高度なレコメンドやARなどに分けて考えます。まず基礎業務を安定させ、そのあとで拡張する構成が安全です。
発注前にRFPと要件を整理する進め方
RFPは、開発会社へ機能を丸投げする資料ではなく、自社の目的や業務、制約、評価基準をそろえて示す資料です。発注側が業務判断を先送りすると、会社ごとに前提の違う見積もりが届きます。そのため、価格を比べられなくなります。
業務フローとデータの正の決め方
業務の抜け漏れを防ぐため、商品登録から会計までの流れを一枚にまとめ、通常処理と現場で起きる例外の両方を確認します。例外は通常の流れから外れるぶん見落とされやすいので、現場への聞き取りで洗い出しておきます。次の4点を、流れと例外の両面から整理します。
- 業務フロー：商品登録と発注から会計まで、入荷と検品、保管、受注と引当、出荷、返品と返金を含めてつなぎます。
- データの正：商品マスタは基幹、在庫はWMS、顧客はCRMといったように、情報ごとに参照元のシステムを決めます。
- 店舗在庫：ECへ開放する場合は、更新時期や引当期限、店頭取り置き、欠品時の代替案を記載しておきます。
- 例外処理：限定品の予約やセット商品の分解、破損や返品、棚卸差異を、現場に聞き取ります。
薬機法・ロット・使用期限の機能要件への落とし込み
厚生労働省は、通常の流通下で品質を保証できる化粧品について、使用期限を合理的に設定する趣旨を示しています（出典：厚生労働省「薬事法の一部を改正する法律の施行について」）。
- 商品変更：成分変更前後の商品を同一商品とみなすか、別SKUとして分けるかを定めます。
- ロット追跡：ロット番号や入荷日、使用期限、製造元、出荷先の履歴を残し、問題が起きたときに対象商品と出荷先をたどれるようにします。
- 期限管理：期限表示だけでなく、期限が近い商品の出荷制限や在庫引当、廃棄、履歴確認も要件に含めます。
テスター・サンプルの原価管理
店舗ごとの配布数や使用数、廃棄数、補充依頼を記録できれば、販促費の実態と商品別の採算が見えてきます。
- 仕入原価：売上にならなくても、テスター、サンプル、店頭配布品には原価がかかります。
- 定期便：顧客セグメントと注文条件に応じて、サンプルやお礼状を出荷指示に自動で反映できれば、個別の指示を減らせます。
- RFP：「サンプル管理」と書くだけでなく、担当者、時期、画面、連携する会計科目まで記載します。
化粧品・日用品業界のシステム発注から稼働までの進め方
外注プロジェクトは、発注書を出したあとも、稼働まで段階を追って進みます。企画から要件定義、設計までを最初の区切りとし、その後は開発やテスト、移行、教育を経て稼働後の改善へ進みます。各段階の成果物と承認者は、あらかじめ明確にしておきます。
企画・要件定義でのMUSTとWANTの分け方
初回リリースで業務を止めないために、要件の優先順位を決めておきます。優先順位があれば、ベンダーの提案を機能数ではなく業務成果で比べられます。
- MUST：商品マスタ、在庫、受注、出荷、顧客情報など、止まると業務に支障が出る機能です。
- WANT：AI肌診断、ARメイク、ライブコマースの高度な分析は、目的と効果を検証する別フェーズに回します。
- 要件：目的や利用者、入力と処理、出力、例外、受入条件をセットで示します。
設計・開発での連携仕様と変更管理
複数のシステムをつなぐ連携と、開発中に起こる変更をどう管理するかを、あらかじめ整理しておきます。
- API連携：EC、POSなど連携先ごとの項目と更新頻度を設計し、再送や重複防止、個人情報の扱いも決めます。
- 注文急増：ライブコマースやインフルエンサー施策の際に、アクセス数、在庫引当の競合、受付遅延の表示、キャンセル処理を確かめます。
- 変更管理：口頭では済ませず、影響範囲、追加工数、費用、納期、承認者を変更管理票に残します。
テスト・移行・リリースでの現場シナリオの再現
テストでは画面の動きだけでなく、色違い商品の誤出荷、期限切れロットの引当、定期便のスキップ、店舗受取、返品返金まで確かめます。
同梱物の分岐や通信障害からの復旧も試します。移行では、商品コードの重複、旧システムにない項目、顧客の同意情報、ポイント残高、未出荷注文を洗い出します。
全店舗へ一斉に広げず、まずは1倉庫・1店舗・1チャネルでパイロット運用します。そのうえで、現場の修正をシステムに反映し、段階的に展開すると安全です。
請負と準委任の使い分け
契約形態は、プロジェクト全体で一つにそろえる必要はなく、工程ごとに選んでもかまいません。要件が未確定の工程と、成果物や受入条件を確定できる工程を分けると、責任範囲と変更リスクを整理できます。
請負契約の成果物と受入基準
請負契約では、ベンダーが合意した成果物を完成させ、発注者が検収する形が基本です。
- 成果物と受入基準：画面やAPI、バッチ、移行データ、テスト仕様書、操作マニュアルについて、内容を明確にします。
- 要件の確定：要件が未確定のまま機能を固定すると、追加費用や納期の延長が起きやすくなります。
IPAの開発モデルでも、要件定義は準委任、設計・プログラミング・テストは請負を基本としています。工程ごとの責任分担の考え方も示されています（出典：IPA「システム開発の健全化に向けて」）。
協働しながら要件を固める場合の準委任契約
準委任契約は、ベンダーが専門的な業務を遂行する契約です。発注側が判断を重ねながら進める工程に向いており、契約の組み立て方は次の4点で押さえます。
- 適する工程：企画、現状分析、要件定義、導入支援、アジャイル開発などが該当します。
- 発注側の判断：工程が進むなかで、要件の確定や変更の受け入れを発注側が判断します。
- 契約内容：完成保証がないため、月次作業や稼働人数、会議体、成果物、評価方法、終了条件を記載しておきます。
- IPAのモデル：基本契約と機能単位の個別契約を組み合わせる形です。
IPAは、要件が未確定のアジャイル型開発で、この契約モデルを示しています（出典：IPA「エンタプライズ系事業／非ウォーターフォール型開発」）。
化粧品・日用品業界のシステム開発費用相場と内訳
開発費は、SKU数や店舗数、倉庫数、ECチャネル数で変わります。加えて、既存システムのAPI有無、データ移行量、法規制・ロット管理の厳密さも影響します。金額に加えて、初期費用に含まれる範囲と、運用費や追加開発になる範囲も確認します。
規模別の初期費用の幅
本記事での初期予算の目安は、規模や機能範囲によって異なります。
- 小規模：在庫・受注管理や限定EC連携で300万〜700万円程度。
- 中規模：POS連携・会員管理・基本EC連携で700万〜1,800万円程度。
- 大規模：多店舗・高度な会員販促・EC統合で1,800万〜4,000万円以上。
これは要件整理のための概算レンジで、公的な定価ではありません。
2024年の国内BtoC-EC市場は26.1兆円、EC化率は9.8％まで拡大しています（出典：経済産業省「令和6年度電子商取引に関する市場調査」）。ECを後から付け足すのではなく、将来のチャネル連携を初期設計に含める企業が増えています。そのため、連携費用も見積もりに入れておきます。
開発費以外も含めた見積もりの分解
比べやすい見積もりにするため、費用項目を工程や運用内容ごとに分けて記載してもらいます。
- 開発工程：企画・要件定義、UI設計、アプリ開発、API連携、インフラ構築。
- 導入作業：データ移行、テスト、教育、プロジェクト管理。
- 運用費：保守運用、クラウド、監視、脆弱性対応、OSやミドルウェアの更新。
SaaSの場合は、初期設定費や月額利用料、ユーザー数や注文数に応じた従量課金、外部サービスの利用料も確認します。
運用を始めたあとも、問い合わせ対応や改善開発は発生します。そのため、初期費用だけで比べると、3年間の総額で逆転することがあります。
委託先の選定と見積比較のポイント
委託先は、知名度だけでなく、化粧品・日用品の業務と例外処理を理解しているかで見ます。提案書の見た目より、現場の業務シナリオを具体的に質問してくる会社かどうかも確認します。
D2C・定期通販・OMO・物流の実績
業務領域ごとの経験と、例外処理への対応を確認します。ARやAI肌診断では、顧客データの同意、利用目的、保存期間、API連携、個人情報保護について、どこまでを誰が受け持つかも質問します。
- 受注・定期便：「ECサイトを作った」だけでなく、出荷までの自動化や、継続購入の変更・解約を経験しているかを見ます。
- 連携・物流：同梱物の出し分け、店舗とECの在庫共有、POSや会員、ポイントとの接続。
- 業務理解：可能であれば、匿名化された画面や業務フローを見せてもらい、ロット追跡、返品、棚卸、欠品への回答を確かめます。
見積もりの前提・成果物・除外範囲の比較
各社を同じ条件で比べるには、対象機能、連携本数、店舗数、SKU数、移行対象データをそろえておきます。
テスト範囲、教育回数、保守時間も合わせておきます。安い見積もりでも、移行や休日対応、セキュリティ診断、マニュアル、旧システムとの並行稼働が含まれない場合があります。
「別途」の発生条件と上限金額を確認します。開発会社の想定リスクと、発注者が負担する作業も、説明会で言葉にしてもらいます。
現場定着と店舗スタッフの評価までの提案力
OMOでは、ECの売上だけでなく、店舗側の納得も考慮した提案かを確認します。
- 評価・インセンティブ：スタッフが接客した顧客のEC購入を識別し、報酬の算定に反映するルールを設計すると、チャネル間の対立を減らしやすくなります。
- 運用支援：権限、教育、KPI、問い合わせ窓口、稼働後の改善会議まで提案できるかを確認します。
- 改善体制：利用率や入力漏れを計測し、現場の声を次の見直しにつなぐ体制が、長期的な成果を左右します。
発注後のプロジェクトで失敗しない体制づくり
発注者側に業務判断をできる責任者がいないと、判断がベンダーに集中し、現場ごとに異なる要望が増えます。そこで、経営、事業部、物流、店舗から代表者を出し、EC、情報システム、経理も加えます。決定事項は一か所で管理します。
発注者側の意思決定者と業務オーナー
発注者側で判断が止まらないよう、役割を分けて責任者を決めておきます。担当する範囲と進め方は、次の4点です。
- プロジェクト責任者：予算、優先順位、納期、リスクの判断を担います。
- 業務オーナー：商品マスタ、物流、定期通販、店舗、会計などの業務ルールと受入条件を受け持ちます。
- 週次会議：進捗率、未決事項、変更、障害、次の意思決定を扱います。
- 未決事項：放置すると後工程で高額な作り直しが起きるため、回答期限とエスカレーション先を定めます。
個人情報・障害対応・保守の責任分界
顧客の肌悩みや購入履歴、会員情報や決済情報を扱う場合は、守り方の設計が欠かせません。たとえば、アクセス権限やログ、暗号化やバックアップを設計します。また、委託先の管理や、退職者のアカウント無効化も必要です。
障害が起きたときは、注文受付を止めるか、在庫を一時保留するか、手作業に切り替えるかを決めておきます。
保守契約には、受付時間や一次回答、復旧目標を明記します。そのうえで、軽微な修正の範囲と追加開発との境界、脆弱性対応、データ返却方法も定めます。
よくある質問
化粧品・日用品業界のシステム発注では、費用のほかに、法規制や物流、EC、店舗運用の責任分担について質問が集まりやすいです。代表的な疑問に、順に答えます。
化粧品・日用品業界のシステム開発費用はいくらですか？
初期予算は小規模なら300万〜700万円程度、中規模なら700万〜1,800万円程度、大規模なら1,800万〜4,000万円以上が目安です。
店舗数やSKU数、外部連携やデータ移行、ロット管理の精度で変わります。同じ機能名であっても、金額が一致するとは限りません。
3年間のSaaS利用料や保守、追加開発を含めて比較します。
RFPには何を書けばよいですか？
会社概要や希望納期に加えて、現状業務や課題を記載します。商品・SKU・ロット、店舗・EC・倉庫の構成も書いておきます。
外部システムやデータ移行、セキュリティに加えて、予算と評価基準も書きます。通常処理と例外処理、MUSTとWANT、発注者とベンダーの役割を分けておくと、同じ前提で提案を受けやすくなります。
請負契約と準委任契約はどちらを選べばよいですか？
未確定の要件を調査し、合意を形成する段階では準委任を検討します。成果物と受入条件を固定できる設計、開発、テストは、請負が基本です。
工程ごとに契約を分ける方法もあります。ただし、完成責任と変更管理、検収、作業範囲を明確にしてから契約します。
パッケージとフルスクラッチはどちらがよいですか？
標準化しやすい在庫や受注、WMSは、パッケージやSaaSを優先します。一方、独自の顧客体験や評価制度など、差別化につながる領域は、個別開発を組み合わせるのが現実的です。
既存製品の制約やAPI、データ所有権を比べます。あわせて、将来のアップデートと運用担当者の負担も見ます。そのうえで、自社の強みに投資できる方法を選びます。
まとめ
化粧品・日用品業界のシステム発注では、商品やSKU、ロット、使用期限を整理します。そのうえで、店舗やEC、物流のデータの流れに加え、CRMや会計との関係も明確にします。
RFPでは、課題や例外処理、MUSTとWANTを示します。移行範囲と受入条件も書き、複数社から同じ前提の見積もりを取ります。
費用は小規模300万〜700万円程度、中規模700万〜1,800万円程度、大規模1,800万〜4,000万円以上が目安です。初期費用だけで判断しません。
要件定義は準委任、成果物を確定できる開発は請負など、工程に合う契約を選びます。発注者側にも意思決定者と業務オーナーを置きます。
まず商品・在庫・受注・出荷の基盤を安定させます。その後、定期通販やOMOを段階的に加えます。AI肌診断やライブコマースも、段階を踏んで加えると、予算と現場定着を両立しやすくなります。
発注前の業務・費用・契約の最終確認
業務フローと例外処理がRFPにあるか、見積もりの前提と除外範囲が明確かを確認します。工程ごとの契約と責任分担にも無理がないか見直します。
自社の強みにつながる機能に投資し、標準化できる業務は既存サービスを活用します。そうすると、継続的に改善できるシステムにつながります。
参考にした公的情報
参照した公的資料は、厚生労働省「薬事法の一部を改正する法律の施行について」と経済産業省「令和6年度電子商取引に関する市場調査」です。
IPA「システム開発の健全化に向けて」と「エンタプライズ系事業／非ウォーターフォール型開発」を参照しました。
リンクは資料名の順に並べています。
- https://www.mhlw.go.jp/web/t_doc?dataId=00ta6826&dataType=1
- https://www.meti.go.jp/english/press/2025/0826_003.html
- https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/20250424-kouen.pdf
- https://www.ipa.go.jp/archive/digital/iot-en-ci/process/ent02-c.html
▼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を創業。