大阪の制作会社がEC構築を外注するとき｜カート設定と検収の分担を決める

大阪の制作会社がEC構築を外注する前に、画面実装、カート設定、商品登録、注文テストの分担を決める方法。販売事業者・元請・構築パートナーの決定、作業、検収を一枚の表で整理します。

デザインは社内で作り、カートの構築だけを外部へ頼みたい。大阪の制作会社やデザイナーがEC案件を受けたとき、見た目の画面は決まっていても、送料や決済、商品登録、注文後の通知を誰が決めるかは残っていることがあります。「デザインを渡せば構築できる」と考えて進めると、実装途中に販売条件の確認が始まり、検収の基準も曖昧になります。

外注相談の前に必要なのは、使うカートの名前だけではありません。EC画面、カート設定、商品情報、運用確認を分け、顧客である販売事業者、元請の制作会社、構築パートナーのうち、誰が条件を決め、誰が作業し、誰が結果を確認するかを一枚にします。この記事は元請担当者が、受注したEC案件の依頼範囲と引渡し条件を整理するためのものです。

以下の分担表は架空案件の編集例です。特定のカートや決済方法の対応可否、価格、販売条件を保証するものではありません。実際の仕様は、採用するサービスの現行資料と販売事業者の決定事項を照合し、契約する制作範囲へ反映してください。

「構築」を画面と設定へ分けて相談する

元請が「デザイン完成、構築を依頼」と伝えても、外注先には足りない情報があります。商品一覧、商品詳細、カート、注文手続き、完了画面のどこまでをデザインしたか。標準の画面を使うのか、表示や導線を調整するのか。注文時の条件を誰が決め、管理画面へ入力するのか。これらが分からないと、作業量だけでなく、実装可能な範囲も判断しにくくなります。

まず、画面ごとに「デザイン確定」「標準表示を使用」「要確認」を付けます。商品ページの色や写真の並びが確定していても、選択肢、在庫、販売期間、配送方法などの動作条件は別です。逆に、機能だけ決めても、在庫切れや入力エラーの表示がデザイン案にないことがあります。静止画の一場面を、購入の全状態が決まった仕様書として扱いません。

画面一覧には、通常表示だけでなく、スマートフォン、入力エラー、在庫切れ、販売前後、注文完了の状態を付けます。すべてを一からデザインするかはカートの標準機能と予算次第ですが、状態が存在することは見積り前に共有します。デザイン案から読み取れない動作をパートナーが独自に決めた場合、元請の承認をどの時点で取るかも決めておきます。

たとえばfutureshopの商品登録マニュアルには、商品価格、在庫、販売期間、配送に関わる項目などが並びます。サービスの現在の画面にどんな設定項目があるかを確かめる資料です。記事中の表はfutureshopの設定手順を教えるものではなく、「見た目のデザイン」と「販売事業者が決める値」と「構築者が入力する作業」を切り分けるために参照します。別のカートなら、その公式仕様で照合し直します。

元請は顧客との約束を一本化する立場として、未決定項目の一覧と質問の窓口を持ちます。パートナーが直接顧客へ確認する契約なら、誰が回答を記録し、元請のデザインや見積りへ戻すかを決めます。窓口が複数あると、担当者ごとに違う「確定版」を見て構築することがあります。質問票の版と回答した人を残すだけでも、手戻りの理由を追いやすくなります。

EC画面・カート設定・運用確認を一枚にする

販売条件を決める人、画面と設定を作る人、注文結果を確かめる人の三段階の分担図 — 販売条件の決定、元請とパートナーの作業、三者による検収を分ける架空の分担図。実際の役割は案件ごとに合意します。

分担表は「元請／外注」の二列だけでは足りません。販売条件の持ち主は顧客です。実装者が値を入力できても、送料、返品条件、在庫、商品説明を勝手に決めることはできません。一方、販売事業者が内容を確定しても、その値が購入画面に正しく出るかは実装と検証の問題です。そこで、各行に「決定」「作業」「検収」の三つの役割を置きます。

表は左右にスクロールして確認できます。

確認する領域	販売事業者が決めること	元請と構築パートナーの作業分担例	検収で見るもの
商品一覧・詳細画面	商品名、説明、画像、販売条件の確定版	元請が画面と原稿を整理し、パートナーがカートへ実装	代表商品と例外商品で表示・選択肢を確認
カート・注文画面	配送先、送料、決済、注文受付の条件	元請が条件を集約し、パートナーが設定と表示を確認	条件を変えた注文テストと表示の記録
商品登録・在庫	登録対象、価格、公開時期、運用担当	元請がデータ形式を整え、登録作業の担当を決定	件数、代表商品、在庫・公開状態の照合
通知・注文後の運用	誰が注文を受け、発送・変更へ対応するか	パートナーが通知設定を実装し、元請が案内文を照合	通知先、送信内容、管理画面の状態を確認
公開と引渡し	公開判断、販売開始、日々の更新責任	切替担当と手順を三者で合意	設定一覧、未解決項目、運用連絡先を受領

これは役割を決めるための例で、販売事業者、元請、パートナーのどれかにすべてを固定する表ではありません。元請が商品登録まで担う案件も、顧客が自社で登録する案件もあります。大切なのは、各行の担当が空欄のまま「構築一式」と呼ばないことです。作業だけでなく、その結果をどの資料と突き合わせるかまで決めます。

「確認済み」と書く欄には証拠を対応させます。デザインなら承認済み画面、商品情報なら確定した登録データ、送料なら販売事業者の条件表、テストなら操作と結果の記録です。承認者が口頭で「よさそう」と述べたことと、商品全件の条件を確認したことは同じではありません。検収に使うサンプル、全件確認する項目、未解決の例外を分けて残します。

検収範囲は、登録件数が増えるほど曖昧になりやすいものです。商品名や価格など全件照合する欄と、レイアウトや選択操作を代表商品で確かめる欄を分けます。例外商品があるなら、通常商品と同じ標本に含めず別に確認します。誰がどこまで見るかを先に決めれば、納品時に「登録した」と「内容を承認した」が混ざりません。

商品情報と運用条件は顧客への質問経路を決める

商品登録を外注に含めるなら、誰が元データを用意し、どの形式で渡し、途中の修正をどこへ戻すかを決めます。画像の加工とアップロードは制作側が担えても、商品名、素材、サイズ、価格、在庫、発送条件の正しさを販売事業者の確認なしで完成扱いにはできません。元請が受け取った表の列が不足している場合は、構築パートナーが推測で埋めるのではなく、質問として戻します。

最初に、代表商品を一つ選び、商品詳細、選択肢、カート、注文確認まで通してみます。その商品だけでは扱えない条件も一覧にします。色やサイズの選択がある商品、予約販売、配送方法が異なる商品など、今回の商材に実在する例だけを対象にします。架空の例外を増やして見積りを膨らませず、実在する販売条件を顧客から確認します。

送料と配送についても、デザイン上の「送料無料」表示とカートの計算が一致するかが重要です。futureshopの配送・送料設定マニュアルには、複数商品、配送サービス、リードタイムなどに関わる設定が示されています。どの条件を使うかは顧客と採用カートによって変わります。制作側は公式資料を見て質問の抜けを探し、販売事業者に決定してもらった値を作業仕様へ落とします。

顧客への質問を「商品情報をください」一行で終わらせません。いつまでに何を確定するか、未決定のまま作れる画面はどこか、販売開始までに必要な条件は何かを並べます。回答者が営業、倉庫、経理、法務などに分かれるなら、元請側で統合する人を決めます。決済・税・表示義務に関する判断が必要なときは、販売事業者の責任者と適切な専門担当へ確認し、制作会社が適用を断定しません。

商品データに変更が入ったときの扱いも決めます。商品名の誤字修正と、価格・送料・販売期間の変更は影響が違います。後者は画面だけでなく注文テストをやり直す必要があるかもしれません。変更受付の窓口、反映期限、再確認する画面を案件ごとに定め、古い表を再取込しない版管理を用意します。

テスト注文と公開後の担当を検収条件にする

商品ページが表示され、カートボタンが押せても、構築の確認は終わりません。送料が条件どおり出るか、決済の結果をどう扱うか、注文通知がどこへ届くか、在庫がどう変わるかを一連で見る必要があります。Shopifyのテスト注文の公式案内は、チェックアウト、注文処理、在庫、発送、メール通知、税に関する設定をテスト注文で確認できると説明しています。これはShopifyを採用すべきという推薦ではありません。どのカートでも、採用するサービスの公式なテスト方法を確認する出発点として扱います。

検収の前に、テスト環境と実際の決済を取り違えないよう確認します。サービスや決済方法によって、テストモードの条件、注文データの残り方、実際の請求が発生する場合の扱いは異なります。futureshopのコマースクリエイター移行ガイドも、特定の決済テストで売上処理を確定すると実際の引落しが起こり得ると注意しています。元請とパートナーは、採用環境の公式手順を読んで実施者と承認者を決め、記事を操作手順の代わりにしません。

テストは一件の成功だけで終えません。今回の販売条件に合わせて、通常商品、在庫がない商品、送料条件が変わる組合せ、エラーや注文取消しなど、必要な場面を選びます。すべてを機械的に試すのではなく、販売事業者が実際に扱う条件から優先します。元請はデザインと案内文、パートナーは設定と注文の動作、販売事業者は価格・送料・受注後の運用を確認する形が一例です。最終承認者と未解決項目を明記します。

検収票には、テスト日時、環境、使った商品と条件、期待した表示、実際の表示、注文通知、管理画面の状態、確認した人を残します。スクリーンショットだけでは、どの設定値と組み合わせた結果か分かりません。逆に「テスト済み」とだけ書いても、顧客が引渡し後に再確認できません。個人情報や決済情報を共有資料へ残さない方法も、使うサービスの運用に合わせて決めます。

不具合が見つかった場合は、表示の修正、設定値の修正、販売条件の再決定を分けます。前二者は制作側の作業になっても、条件自体の変更には販売事業者の確認が要ります。修正後にどのテストをやり直すか、元請が顧客へどの結果を返すかまで記録すると、検収の完了条件が明確になります。

公開の担当も、検収とは別に決めます。パスワード解除、ドメイン切替、決済の本番化、商品公開、初回注文の監視を誰が行うか。公開時刻を設定しても、元請が全作業を自動的に担当するわけではありません。引渡しには、設定した項目の一覧、管理者権限の所在、残る課題、商品更新と注文対応の連絡先を含めます。公開後の保守や追加機能は、依頼範囲に入るか別途相談かを示します。

制作パートナーへ渡す前に一案件で確かめる

まず、顧客から受けたEC案件の一つを選び、画面一覧と販売条件の表を並べます。画面ごとにデザインの確定状態、カート設定の決定者、商品データの提供者、テストの実施者と承認者を書き込みます。空欄が見つかったら、外注先の見積りで勝手に埋めず、顧客か元請の担当者へ戻す質問にします。

次に、代表商品一件の登録から注文、通知、管理画面、引渡しまでを仮にたどります。どの画面と設定をパートナーに任せるか、どの判断を元請と販売事業者に残すかが見えれば、EC構築の相談は「カート一式」より具体的になります。実装の可否と工数は採用するカートと要件を確認したうえで決め、検収は合意した条件と結果を照らして行います。