受注生産の EC で、仕様の選択から価格の算出、見積もり、生産指示までをどうつなぐか

オーダーメイドや受注生産の商品を EC で売ろうとすると、最初に目が行くのは「お客様が仕様を選べる画面」です。色、サイズ、材質、オプションを選ぶと、画像が変わる。見た目としては分かりやすく、画面としては実現しやすくなっています。ところが、画面ができても、受注のあとに工場や事務の担当者が注文内容を読み解いて、生産指示書を作り直すことがあります。選んだ内容が、そのまま生産の指示にならないからです。

この記事では、受注生産の EC で、仕様の選択から価格の算出、見積もり、受注確定、生産指示までを一本のデータの流れとして設計するときに、発注前に決めておきたい論点を整理します。

1. 仕様の選択は、画面ではなくルールとして持つ

オーダーメイド EC システム「GB Custom」を紹介する、ECのミカタの記事では、首輪とリードが 8,000 万通り以上の組み合わせに対応し、選んだカスタム内容が商品画像に即時反映されると説明されています（出典）。

設計の側で問題になるのは、その組み合わせのうち「作れないもの」をどう扱うかです。たとえば次のような制約があります。

• 材質 A には、この大きさは選べない
• オプション X とオプション Y は同時に付けられない
• 特定の色は、特定の部品でしか使えない
• 大きさが一定を超えると、納期が変わる

こうした制約を、画面の入力チェックのコードの中に埋め込んでしまうと、商品が増えるたびに画面を作り直すことになります。また、工場側の担当者が持っている「作れる・作れない」の知識と、EC の画面の判定がずれていきます。

私たちは、先に決めたいのは、制約をデータとして持つかどうかだと考えます。仕様の項目、選択肢、選択肢どうしの禁止や必須の関係を、画面とは別の「商品の仕様ルール」として管理できれば、画面、見積もり、生産指示のすべてが同じルールを見ます。誰が、どの画面で、そのルールを更新するのかも合わせて決めます。

2. 価格の算出は、仕様のどの項目が価格に効くかだけを分ける

先ほどの記事では、大きさや材質によって価格を変動させられると紹介されています。

仕様の項目を「価格に効くもの」と「効かないもの」に分け、効くものについては、加算なのか、掛け算なのか、数量などの段階で変わるのか、取引先ごとに変わるのかを区別しておきます。取引先ごとの価格を含める場合は、仕様による変動と取引先の掛け率のどちらを先に適用するかの順序も決めます。順序が決まっていないと、画面に出る金額と、事務が手で計算する金額が一致しません。

もう一つ、決めておきたいのは「画面に出す金額は確定額か目安か」です。私たちは、確定額として出すなら、その金額で受注しても利益が出ることを算出のルールが保証している必要があり、目安として出すなら、確定までに誰がどの時点で金額を直すのかを仕組みの上に置く必要があると考えます。

3. 見積もりは、EC の「寄り道」ではなく状態として設計する

受注生産の商品には、画面だけでは価格を確定できないものがあります。特殊な寸法、図面の持ち込み、数量が大きい注文などです。これらを「問い合わせフォームに流す」だけにすると、その後の見積もりが EC の外で進み、注文のデータが分断されます。

見積もりを EC の中に持つ場合は、注文に至るまでの状態を決めておくとよいと私たちは考えます。たとえば次のとおりです。

• 仕様を選んだ状態（まだ価格は目安）
• 見積もりを依頼した状態
• 社内で確認中の状態
• 見積もりを提示した状態（有効期限つき）
• お客様が承認して受注が確定した状態
• 期限が切れた状態

ここで見落としやすいのは、見積もりの有効期限と、見積もり後に仕様が変わった場合の扱いです。提示した見積もりの仕様をお客様が変えたとき、価格を再計算して見積もりを作り直すのか、差分だけ見積もるのか。提示済みの見積もりの内容は、あとから変えられない記録として残すのか。これらが決まっていないと、受注後に「見積もりのときと内容が違う」という行き違いが起きます。

4. 受注が確定した時点で、仕様を固定して記録する

私たちは、受注が確定した瞬間に、その注文の仕様と価格を、商品のマスタとは切り離して固定するのがよいと考えます。あとから仕様ルールや単価表が更新されても、すでに受けた注文の内容は変わらないようにするためです。

固定して持っておきたいのは、次のような情報です。

• お客様が選んだ仕様の全項目と、その時点の選択肢の名前
• 価格の内訳（基本価格、追加料金、割引、取引先の掛け率）
• 適用した仕様ルールと単価表の版
• 見積もりを経た場合は、その見積もりの番号と有効期限

価格の内訳を持っていると、受注後に「なぜこの金額になったのか」を説明でき、返品や変更の相談にも対応しやすくなります。

5. 生産指示は、受注データから自動で作れる形にする

ここが、画面から工場までをつなぐ最後の部分です。BtoB 向け EC システムの提供元である日立ソリューションズの製品ページは、EC システムで入力された注文データを基幹システムへ連携することで、基幹への入力作業を減らせると説明しています（出典）。受注生産では、注文データの連携にとどまらず、受注した仕様から生産指示の内容を作ることまでを視野に入れるとよいと考えます。

そのためには、お客様向けの言葉と、工場向けの言葉の対応を先に決める必要があります。お客様の画面では「オーク調」と表示している材質が、生産側では特定の材料コードで管理されていることがあります。選択肢ごとに、生産側のコード、部品表（どの部品をいくつ使うか）、加工の指示を対応づけておけば、受注データから生産指示書を組み立てられます。

あわせて決めておくのは、連携の方向と、止まったときの扱いです。

• 受注データは、どのタイミングで基幹システムに渡すか（受注確定の直後か、入金の確認後か）
• 生産側で「この仕様は作れない」と分かったとき、EC の注文にどう戻すか
• 受注後の仕様変更を、いつまで受け付けるか（生産に着手したあとは変えられない、など）
• 納期の目安を、画面にどう出すか。基幹システムの生産計画から取るのか、固定の日数で出すのか

受注後の変更の扱いは、特に重要です。商品によっては、着手後は取り消せないことがあり、変更を受け付けられる期限を、状態として持つ必要があります。

6. 発注前に、次の 6 つを書き出す

ここまでの論点を、要件定義の前に次のようなメモにしておくと、開発会社との話が具体的になります。

1. 仕様の項目と選択肢、選択肢どうしの禁止や必須の関係
2. 価格を決める項目と、適用する順序（取引先別の価格を含めるか）
3. 画面で価格を確定できないケースと、見積もりの流れ
4. 受注確定の時点で固定して持つ情報
5. 生産側のコードや部品表と、画面の選択肢の対応
6. 受注後に仕様を変えられる期限と、生産側から差し戻すときの流れ

すべてに答えが出ていなくても構いません。答えが出ていない項目が分かれば、そこが要件定義で最初に話し合うところです。

まとめ

受注生産の EC は、仕様を選ぶ画面だけでは完成しません。仕様のルール、価格の算出、見積もりの状態、受注時の固定、生産指示への変換までが一本の流れでつながっていてはじめて、受注後の手作業を減らせます。画面の見た目より先に、この流れの設計を決めておくことをおすすめします。

私たちは、予約・受注生産、BtoB、基幹システム連携など、既存の EC サービスでは実現しにくい仕組みを持つ EC を、要件定義から設計・開発する「ECサイト構築」を提供しています。受注生産の EC の設計でお悩みの場合は、お気軽にご相談ください。