DAY67では、農業・漁業・畜産・食品加工には、自然・旬・生産量・品質などの変動があることを学びました。DAY68では、食品を継続してEC販売するために、賞味期限・消費期限・温度管理・製造ロット・最低発注量・衛生管理を整理しました。では、商品を一番よく知っている生産者・メーカーに、EC運用も全部お願いすれば、効率がよいのでしょうか？

例えば、農家へこうお願いしたとします。「野菜を作ってください」「写真も撮ってください」「商品ページも作ってください」「毎日在庫を更新してください」「注文が来たら確認してください」「箱詰めしてください」「送り状を出してください」「発送してください」「購入者から質問が来たら答えてください」「返品・配送事故にも対応してください」「レビューにも返信してください」。一見すると「産地直送だから、全部生産者がやった方が早そう」に見えます。

しかし、朝、畑へ行き、収穫。選別。出荷。農作業。機械整備。資材確認。天候確認。取引先対応。その途中で、EC管理画面を開き、注文確認。写真撮影。文章作成。在庫更新。問い合わせ返信。という状態になれば、本来の商品づくりに使う時間が削られていきます。さらにEC側も「生産者へ任せたので大丈夫」となると、注文を見落としていない？在庫は合っている？期限は大丈夫？発送した？問い合わせは返した？という全体管理ができなくなります。つまり問題は、生産者がECを使えるか使えないかではありません。役割設計です。

DAY68との違い

DAY68は「食品を継続販売するために、何を管理する？」、DAY69は「その管理を、誰が担当する？」です。つまり、DAY68で作った期限・Lot・在庫・温度などの仕組みを、「全部、生産者が更新してください」としてはいけません。DAY69では、生産者側・EC側・物流側の役割を分けます。そして次回DAY70では、農業・漁業とはまた違う、職人・伝統工芸・メーカーの商品特性を整理します。

先に結論｜生産者には「EC業務」ではなく「生産情報」をお願いする

生産者へお願いしたいのは、生産数量、出荷可能数量、品質、規格、収穫予定、製造予定、商品仕様、原材料、保存方法、期限、Lot、発送可能日などです。EC側で持つのは、商品ページ、販売価格、EC在庫、注文管理、顧客対応、キャンセル、返品、追跡、販促、分析などです。つまり、生産者は「商品を作る＋商品について正しい情報を出す」、EC側は「その情報を、売れる形・運用できる形へ変換する」。生産者を、ECオペレーターにしない。これが基本です。

なぜEC運用は破綻するのか

生産者は、商品について非常に詳しいです。例えば桃農家なら、品種、栽培方法、収穫時期、味、品質、保存方法、今年の出来について、EC担当者より詳しいでしょう。しかしEC運営には別の知識があります。商品登録、在庫管理、受注、配送設定、キャンセル、返金、問い合わせ、広告、アクセス解析など、違う仕事です。

繁忙期は、生産作業量とEC注文・対応量が同時にピークを迎える可能性があります。例えば、朝5時から収穫のピーク、同時に1日80件の注文と20件の問い合わせ。これが重なると、本来の商品づくりに使う時間が削られ、発送漏れや更新忘れが必然的に発生します。

写真と商品説明の役割分担

ECでは商品写真が必要なため、生産者へ「写真を送ってください」とお願いすることがあります。これは問題ありません。問題になるのは、毎商品・毎回「EC用に、背景を整えて、横1200pxで、明るさを調整して、5カット撮ってください」までお願いすることです。生産者は写真家ではありません。

「商品を一番知っているから、説明文も書いてください」も一見合理的ですが、文章作成が得意とは限りません。役割は、Producer：Information Owner、EC：Content Ownerという考え方です。

生産者からもらう写真とEC側の加工

生産者からもらいたいのは、畑、漁船、工房、作業風景、収穫、原料、商品などの素材写真です。EC側は、トリミング、明るさ調整、サイズ変更、商品ページ用加工を行います。Producer：素材写真、EC：販売用写真、という考え方です。毎回「いい感じでお願いします」ではなく、縦横両方・商品全体・商品アップ・生産風景・人物が映る場合は掲載可否確認・明るい場所、といった簡単な撮影ルールを作ります。難しい撮影技術は要求しません。ブランド商品・ギフト・高単価商品などは、専門撮影をEC側で手配する方法もあります。

商品説明のヒアリング

生産者へ聞くのは、商品名、品種、特徴、産地、作り方、こだわり、味、食べ方、保存方法、注意点、数量、サイズなどです。Producer：事実・経験・ストーリー、EC：商品説明・FAQ・見出し・注意事項へ整理、と分けます。「500文字書いてください」をやめ、「この商品の一番の特徴は？」「一般品との違いは？」「おすすめの食べ方は？」「保存方法は？」「購入者へ伝えたいことは？」というフォーム形式にすれば答えやすくなります。ただし、EC側で文章を整える際、全部を広告会社の言葉に変えると生産者らしさがなくなるため、生産者の言葉を消しすぎません。EC側が作った説明文は、最後に生産者へ「この説明で間違っていない？」と事実確認をしてもらいます。

在庫更新の役割分担

「今日の収穫数を確認して、Shop管理画面を開いて、在庫数を変更してください」を毎日行うのは、繁忙期には大きな負担になります。農業では収穫・選別・梱包・出荷など時間が決まった作業があり、その中でEC管理画面操作を要求すると本来業務と競合します。漁業も、海へ出る時間・水揚げ・選別・市場・処理があり、常にスマートフォンで注文を見るとは限りません。食品工場も、製造中にEC注文画面を開くことが本来業務ではありません。

生産者から必要なのは「EC在庫数」ではなく、例えば「本日出荷可能：50、明日：40見込、今週：200程度」です。Producer Available：50、既存受注：20、安全在庫：10なら、EC Available：20という計算をEC側が行います。生産者へ「安全在庫」まで考えさせません。生産者：供給情報、EC：販売制御、です。Forecast（来週100見込）、Committed（確実にECへ出せる60）、EC Allocation（ECへ割当50）は、DAY67で学んだ数字をEC側が管理します。

リアルタイム更新が本当に必要かは商品によります。工場在庫はリアルタイム連携、農作物は朝1回更新、週次供給は週1更新など、更新頻度（Realtime／Daily／Weekly／Event Based）を決めます。「数量が大きく変わったらフォームで知らせる」だけでも運用でき、入力項目は「今日出せる数量」「次回予定」「リスク（LOW／MEDIUM／HIGH）」「コメント」程度に絞ります。20項目入力より3項目です。システムを使わせることが目的ではなく、正しい供給情報をECへ届けることが目的です。

受注確認と自動処理

注文1件ごとに「発送できますか？」と生産者へ確認していると、ECの意味が薄れます。事前にToday Allocation：50のように販売可能数量を決めておけば、50までEC側で受注できます。大量注文、特殊配送、ギフト、法人注文など例外だけ確認し、通常注文はOrder→Payment→Inventory Allocation→Shipment Instructionと自動処理します。生産者への注文通知が必要なら、1件ずつメールを飛ばさず、毎日15時に「明日発送：20件」のようにまとめて通知します。注文100件・メール100通では確認しにくくなるためです。

Order、Product、Quantity、Delivery Date、Gift、Noteを一覧化した出荷指示書を用意します。例えば「13時までなら翌日発送、それ以降は翌々日」という受注締切ルールを、午前：収穫、午後：梱包、16時：Carrier集荷という生産側スケジュールと合わせて逆算します。EC都合だけで翌日配送を約束せず、生産工程を見て納期設定します。

梱包・配送ラベルと「産地直送か、EC倉庫発送か」

生産者直送なら梱包が必要ですが、商品を箱へ入れるだけではありません。商品、緩衝材、保冷材、同梱物、納品書、配送ラベル、ギフトなど必要なものがあり、生産者ごとに新聞紙・緩衝材とバラバラでは品質差が出るため、箱サイズ・数量・緩衝材・保冷剤・シール位置・送り状位置などの梱包仕様書を作ります。文章20ページより写真5枚でマニュアル化する方が伝わりやすいでしょう。資材を生産者が毎回買うのも負担のため、EC側が資材を一括手配し生産者へ送る方法があります。商品はあるのに箱がなければ発送できないため、梱包資材（Box、Ice Pack、Label等）も在庫として管理し、夏は保冷・冬は通常など季節で資材を変えます。送料契約・集荷条件・配送事故などの配送会社との交渉も、EC側でまとめる方法があります。

生産者直送は、鮮度・中間物流削減・産地直送感がメリットですが、梱包・ラベル貼付・発送作業が生産現場の負担になります。生鮮食品、鮮度最優先の商品に向いています。EC倉庫発送は、生産者がまとめて納品するだけで個別出荷負担ゼロがメリットですが、保管費・温度管理コスト・鮮度リスクがデメリットです。常温加工食品などに向いています。どちらが正解かは商品によります。生鮮はProducer Direct、加工品はWarehouse、のように混在させる方法もあります。

配送ラベルの役割分担

送り状作成は、住所・電話・郵便番号・配送希望・商品名・代引などの入力があり、意外と負担です。件数が少なければ手書きも可能ですが、100件では負担になります。注文情報→配送データ→ラベルまで、できるだけEC側でデータ作成を自動化し、生産者は印刷・貼付という役割分担もできます。プリンターがない場合はそもそも現場環境を確認します。PC、プリンター、Wi-Fi、スマホ、作業スペースがあるとは限らないため、「これぐらいできますよね」を避け、EC設計者は実際にどう作って、どう箱詰めして、どこから発送するか現場を見ます。

問い合わせとクレーム対応

購入者から「いつ届きますか？」と聞かれても、生産者には分かりません。Carrierの配送状況だからです。送料、配送日、注文状況、決済、キャンセル、返品、Trackingなど、EC側で答えられる質問は多くあります。今年の作柄、品種、生産方法、具体的な商品仕様など、生産者にしか答えにくい質問だけを、Customer→EC CS→必要な場合だけProducerという一次対応・二次対応の流れで振り分けます。「お問い合わせが来ました。返事お願いします」を毎回やらず、よく聞かれる質問（桃なら「冷蔵庫へ入れる？」「硬いけど大丈夫？」「食べ頃は？」「傷がある？」等）は事前に生産者へ確認し、正しい回答をEC側のFAQへ回答テンプレートとして用意します。すると生産者は同じ質問に毎回答えなくてよくなり、未知の質問・商品固有・専門回答だけを確認すればよくなります。「5分以内に回答」のような即応は生産現場に合わない可能性があるため、EC一次回答は当日、Producer確認は1〜2営業日など回答期限を決め、「生産者へ確認しております」とEC側で購入者へ一次案内します。

クレームは整理してから生産者へ

購入者の「傷んでいました」というクレームを、生産者へ直接ぶつけません。EC側が、注文、Lot、配送、写真、到着日を整理してから、Producerへ確認します。箱が潰れているならCarrier（配送事故）候補、商品だけ異常なら製造・品質候補というように、原因をCustomer、Carrier、EC Warehouse、Producerのどこかに切り分けます。Order、Lot、Delivery、Photo、Issueを整理してから生産者へ渡すことが、EC側の仕事です。問題を解く前に、問題を整理します。

需要と供給の双方向フィードバック

EC運用を引き取れば終わりではなく、EC側にも仕事があります。売上、注文、売れ筋をProducerへ返します。来週注文が増えそうなら事前共有します。「明日から広告を10倍」を生産者へ知らせないのは危険で、Campaign→Expected Orders→Supply Check→Launchという順で広告と供給をつなぎます。テレビ・SNS紹介は急増リスクがあり、供給500・予想注文2,000なら、売り切れ表示・予約・購入上限を使います。広告側の失敗を生産者へ「何とかしてください」と転嫁せず、無理な増産を要求しません。

ECにはレビュー、問い合わせ、検索キーワードがあります。「小さいサイズが欲しい」「ギフト需要が多い」「食べ方が分からない」などをProduct Feedback→Producer→Product Improvementという形で生産者へ共有します。ECは販売窓口だけではなく、市場から得た情報を生産現場へ返す役割があります。

理想的な役割分担表

生産者へ渡す業務を決める基準

その仕事は生産者にしかできない？（YESなら生産者、NOなら切り出し候補）、毎日何回発生する？（頻度が高いならEC側・自動化候補）、繁忙期に増える？（増えるなら特に切り出す）、専門知識が必要？（商品専門知識ならProducer、EC操作ならEC側）、ミスすると顧客へ影響する？（影響大ならチェック工程を作る）、自動化できる？（Order List、Label、Notification、Stock Alert等）、まとめて処理できる？（1件ずつではなくBatch）、誰でもできるよう標準化できる？（YESなら生産者本人から外せる可能性）という基準で判断します。

やってみよう｜役割設計 自己診断ツール

自社の運用ができているものをタップしてください。3つのカテゴリーごとに、未対応の項目数から改善の方向性が分かります。

実際のケースで考えてみよう

Producer：A農園、Product：桃6個セット、産地直送とします。最初の案は、農家が商品登録・写真・在庫・注文・梱包・発送・問い合わせを全部担当。しかし収穫ピークは朝5時〜、1日80件の注文と20件の問い合わせが重なり、夜になってやっと注文画面を確認、翌朝には発送漏れが発生しました。「農家さん、ちゃんと確認してください」では解決しません。

Producer：生産・品質・供給、EC：販売・顧客・データ、になりました。これが役割分担です。加工食品メーカーのケースでも同様で、「毎日在庫を更新してください」と管理画面を渡した結果、製造兼任の担当者が更新を漏らし、EC在庫20・実際0で欠品キャンセルが発生しました。改善として、週次在庫報告＋EC側での安全在庫設定、在庫が少なくなったらAlert、次回製造日が分かれば予約販売へ切替、という設計にすれば、「リアルタイム更新できない」を「運用ミス」にせず、システム設計で補えます。

役割分担チェックリスト

該当する項目をタップしてチェックしてください。

チェック済み：0 / 6

アウトプットワーク｜生産者・EC役割分担シート

実際に、農家・漁業者・食品メーカーなどの商品をEC販売すると仮定してください。入力内容はこのブラウザにのみ保存され、外部へは送信されません。

理解度チェッククイズ

よくある質問

今回のまとめ

DAY69では、生産者にEC運用を任せすぎてはいけない理由を整理しました。今回覚えてほしいポイントは、次の5つです。

1. 商品に詳しい人とEC運営担当は同じでなくてよい
2. 生産者からは「EC在庫」より「供給情報」をもらう
3. 商品説明は情報提供と文章作成を分ける
4. 問い合わせはEC一次対応・生産者二次対応にする
5. 需要情報と供給情報を双方向で共有する

最も重要なのは、「生産者の負担を減らす」だけではありません。生産者：生産・品質・商品知識・供給情報。EC：販売・注文・顧客・在庫制御・データ。Logistics：保管・梱包・配送。それぞれの強みをつなぐことです。桃農家に「毎日EC在庫を更新してください」ではなく「今日、ECへ何箱出せますか？」と聞き、Producer：50箱、EC：安全在庫10、EC Available：40とする方が役割が明確です。商品説明も「500文字書いてください」ではなく「今年の桃の特徴は？」「おすすめの食べ方は？」「保存方法は？」と聞き、Producer：事実、EC：文章、と分けます。問い合わせも、Customer→Producerではなく、Customer→EC→必要な場合だけProducerです。

そしてEC側からも、売れた商品、売れなかった商品、レビュー、購入者の要望、次月の需要予測を生産者へ返します。つまり、Producer→Supply Information→EC→Demand Information→Producerという循環です。生産者へECを丸投げしない。EC側も商品づくりを生産者へ丸投げしない。お互いがそれぞれの得意分野を持ち、情報でつながる。これが、継続できるEC運用です。

獲得バッジ

文：横田和也／解決ドットコム編集部