ECサイトの構築では、販売する商品や必要な機能、運用方法などによって、適切な構築方法や制作範囲が変わります。
例えば、一般的な商品を販売するECサイトと、定期購入や法人向けの販売、実店舗との在庫連携が必要なECサイトでは、求められる仕組みが異なります。
こうした条件を十分に確認しないまま制作を進めると、後から必要な機能が判明し、設計の変更や追加開発につながることがあります。
この記事では、ECサイトの構想や要望がある程度具体的になっている事業者から相談を受けたWeb制作会社に向けて、要件定義で確認すべき項目と、その理由を具体例を交えて解説します。
なお、まだECサイトの構想が明確になっていない場合は、関連記事「ECサイト制作の相談を受けたら?最初に確認したいヒアリング項目」を参考に、基本的な事項から整理してみてください。
要件定義では何を明確にするのか
ECサイトの要件定義では、事業者の希望を具体的な機能や業務条件へ落とし込み、構築方法や制作範囲を検討できる状態にすることが重要です。
例えば、「衣類を30種類販売したい」という情報だけでは、商品ページの仕様や商品登録の作業量を十分に判断できません。
色やサイズの組み合わせ、価格や在庫の管理方法、商品画像の準備状況なども確認する必要があります。
また、「実店舗とネットショップで在庫を共有したい」という要望がある場合は、現在利用しているシステムや在庫を更新する方法によって、必要な対応が変わります。
このように、同じECサイト構築でも、事業者の要望によって必要な作業や費用は異なります。
ヒアリングでは、希望する機能だけでなく、その機能をどのように利用したいのかまで確認しましょう。
必要に応じて技術的な実現方法を調査し、構築範囲や見積もりの前提条件を整理していきます。
ECサイト構築で確認したいヒアリング項目
商品情報・商品構造
まず確認したいのは、販売する商品の情報と管理方法です。
主な確認事項は次のとおりです。
- 商品数と、色・サイズなどのバリエーション数
- 商品ごとの価格、在庫、商品コード(SKU)
- 商品カテゴリーや分類方法
- 商品名、説明文、画像などのデータの準備状況
ここで注意したいのは、商品数と登録・管理するデータ数が必ずしも一致しないことです。
例えば、1つの商品に5色・4サイズがあり、すべての組み合わせを販売する場合、20種類のバリエーションが発生します。
それぞれで価格や在庫を管理する必要があれば、商品データの構造や登録方法にも影響します。
また、商品データがExcelなどで整理されているのか、画像や説明文を新たに準備する必要があるのかによっても作業量は変わります。
商品情報の構造とデータの準備状況を確認しておくことで、商品登録や商品ページの実装に必要な作業を把握しやすくなります。
販売方法・購入条件
次に、どのような条件で商品を購入できるようにするのかを確認します。
- 通常購入、定期購入、予約購入などの販売方法
- セット販売やまとめ買いの条件
- クーポン、割引、送料無料キャンペーン
- 会員登録の要否や会員向けの特典
- 法人向け販売、顧客別価格などの条件
例えば、定期購入を導入する場合は、配送頻度、購入回数、解約条件などを整理する必要があります。
通常購入と定期購入を同じ商品ページで提供したい場合は、購入方法を選択する画面の設計にも関わります。
また、法人向けの販売では、取引先ごとに価格を変える、特定の顧客だけが商品を購入できるようにするなど、一般消費者向けとは異なる要件が考えられます。
販売方法は、利用するカートシステムの対応可否や追加機能の必要性に関わるため、具体的な条件まで確認しておくことが重要です。
注文・決済
注文・決済については、希望する購入方法や、標準機能以外に必要な仕組みがあるか確認します。
主な確認事項は次のとおりです。
- 希望する決済方法
- 会員登録なしで購入できるようにするか
- 注文完了メールなどに独自の通知機能が必要か
- 外部の受注管理システムとの連携が必要か
特に決済方法は、利用するカートシステムの選定に影響する場合があります。
例えば、代金引換を利用したい場合、BASEでは対応していませんが、Shopifyでは手動決済として設定できます。
このように、事業者が希望する決済方法によっては、カートシステムの標準機能では対応できないことがあります。
そのため、一般的な購入手続きで問題ないのか、特別な機能を希望しているのかを確認しておきましょう。
配送・在庫管理
配送と在庫管理については、事業者が想定している販売・発送の方法に合わせて、具体的な条件を確認します。
主な確認事項は次のとおりです。
- 配送対象地域と配送方法
- 送料の設定条件
- 商品によって異なる配送条件の有無
- 商品の発送拠点・外部倉庫の利用状況
- 在庫の管理場所と管理方法
- 在庫切れ時の販売や注文の扱い
送料の設定には、さまざまなパターンがあります。
全国一律で送料を設定する方法のほか、配送先の地域、購入金額、商品の重量や個数などによって送料を変更する方法などがあります。
例えば、下記のようなパターンです(あくまで例です)。
表が画面に収まらない場合は、左右にスクロールできます。
| 送料の設定方法 | 具体例 |
|---|---|
| 全国一律 | 全国どこでも送料700円 |
| 地域別 | 本州700円、北海道1,200円、沖縄1,500円 |
| 購入金額別 | 5,000円以上の購入で送料無料 |
| 重量・個数別 | 3点までは700円、4点以上は1,000円(梱包サイズが変わる場合) |
| 商品・配送方法別 | 通常商品は宅配便、冷凍商品はクール便で発送 |
商品をまとめて発送できる場合は、購入点数が増えても送料を据え置くことがあります。一方、重量や梱包サイズが一定の条件を超える場合は、送料が高くなることもあります。
また、購入金額に応じた送料無料など、販売促進を目的とした条件を設けるケースもあります。
特に注意したいのは、複数の条件が重なる場合です。
例えば、常温商品と冷凍商品を同時に購入した場合、送料を合算するのか、別々に計算するのかによって、必要な仕組みが変わります。
こうした送料設定の対応範囲は、利用するカートシステムの標準機能や追加アプリによって異なるため、希望する条件を整理したうえで実現可能か確認する必要があります。
在庫管理については、在庫をどこで管理し、どこから発送するのかが重要です。
例えばShopifyでは、店舗や倉庫をロケーションとして登録し、それぞれの拠点で在庫を管理できます。
また、注文ルーティング機能によって、在庫状況や設定したルールに応じて発送拠点を割り当てることも可能です。
実店舗とECサイトで在庫を共有したい場合は、Shopify POSを利用する方法や、外部POSとの連携アプリなどを利用する方法が考えられます。
このように、在庫をECサイト内で管理するのか、既存システムと連携するのかによって、必要な設定や開発内容が変わります。
外部システムとの連携
事業者がすでに業務システムを利用している場合は、ECサイトとの連携が必要か確認します。
- POSレジや店舗管理システム
- 在庫管理・受注管理システム
- 倉庫・物流システム
- 会計システムや基幹システム
- その他、利用中の外部サービス
外部システムとの連携では、どのサービスと、どのような情報を連携したいのかを具体的に確認することが重要です。
例えば、Shopifyの場合は次のような連携が考えられます。
表が画面に収まらない場合は、左右にスクロールできます。
| 連携する情報 | 実現方法の例 |
|---|---|
| 在庫情報 | APIや連携アプリを使って在庫数を同期する |
| 商品情報 | APIを使って商品名・価格・バリエーションなどを登録・更新する |
| 受注情報 | Webhookなどを利用して注文情報を外部システムへ送信する |
例えば、外部の基幹システムで商品情報を一元管理している場合、その情報をShopifyへ連携する仕組みを構築できます。
また、Shopifyで注文が発生した際に、外部の受注管理システムへ注文情報を送ることも可能です。
ただし、APIが提供されているからといって、必ず簡単に連携できるわけではありません。
外部システム側の対応状況やデータ形式、情報を更新するタイミングなどによって、必要な設定や開発範囲は異なります。
既存の連携アプリで対応できる場合もあれば、個別開発が必要になる場合もあるため、利用中のサービス名と連携したい情報を確認したうえで、実現方法を検討しましょう。
デザイン・ページ構成・機能
デザインについては、事業者の希望をもとに、具体的なページ構成や必要な機能を整理していきます。
一般的なECサイトでは、次のようなページが考えられます。
表が画面に収まらない場合は、左右にスクロールできます。
| ページ | 主な役割 |
|---|---|
| トップページ | ブランドやおすすめ商品、キャンペーンの紹介 |
| 商品一覧ページ | カテゴリーごとに商品を探す |
| 商品詳細ページ | 商品情報の確認、種類・数量の選択、カートへの追加 |
| カート・購入手続き | 注文内容の確認、配送先・支払い方法の入力 |
| お問い合わせ | 購入前後の問い合わせ受付 |
| ご利用ガイド | 送料、配送、支払い、返品などの案内 |
| 会社概要・各種ポリシー | 事業者情報や特定商取引法に基づく表示など |
このほか、ブランド紹介、FAQ、ブログ、会員向けページなどを設ける場合もあります。
ただし、これらをすべて個別に制作するとは限りません。カートシステムや既存テンプレートに標準で用意されているページもあるため、既存機能をどこまで利用できるか確認することが重要です。
デザインや機能に関する要望は、制作費用に大きく影響する部分です。
例えば、次のような構築方法が考えられます。
- 既存テンプレートを利用し、色・画像・テキストなどを調整する
- 既存テンプレートをベースに、独自のレイアウトやデザインを追加する
- オリジナルデザインで各ページを制作する
- 商品検索や商品選択画面などに独自の機能を実装する
参考サイトがある場合は、見た目だけを再現したいのか、機能や動きも同じようにしたいのかを具体的に確認しましょう。
データ移行・公開準備
既存ECサイトのリニューアルや別のカートシステムへの移行では、現在のデータや機能をどこまで引き継ぐか確認する必要があります。
一方、新規構築の場合も、公開に必要な素材や各種サービスの準備が必要です。
主な確認事項は次のとおりです。
- 商品・顧客・注文履歴などの移行対象(既存サイトがある場合)
- 既存サイトの機能やデザインの引き継ぎ
- ドメインやURLの取り扱い
- 商品画像、原稿、各種ページの準備状況
- 決済サービスの契約・申請状況
- 特定商取引法に基づく表示や各種ポリシーの準備
- 公開前のテストと確認範囲
既存ECサイトからの移行で確認したいこと
既存ECサイトを別のカートシステムへ移行する場合は、何を引き継ぎたいのかによって必要な作業が異なります。
例えば、BASEからShopifyへの移行では、次のような対応が考えられます。
表が画面に収まらない場合は、左右にスクロールできます。
| 顧客の要望 | BASEからShopifyへの移行時の対応・制約 |
|---|---|
| 商品を引き継ぎたい | 移行可能。 BASEの商品データをCSVで出力し、Shopify用に変換して取り込む。商品画像やバリエーションの確認も必要。 |
| 既存顧客に引き続き利用してほしい | 条件付きで移行可能。 既存の会員情報をそのまま移行することは出来ないが、BASEの注文データなどから取得できる顧客情報を整理し、Shopifyへ登録するのは可能。 |
| 過去の注文履歴を残したい | 追加対応により移行可能。 Shopifyの標準CSV機能では注文履歴を取り込めないため、移行アプリやAPIなどを利用する。 |
| 現在のデザインや機能を維持したい | そのままの移行はできない。 Shopifyの仕組みに合わせた再構築が必要で、同等の機能を再現できるか個別に確認する。 |
| 今までのURLを使いたい | 条件付きで対応可能。 独自ドメインは継続利用できるが、BASE提供のURLは引き継げない。個別ページのURL変更にも対応が必要。 |
※一般的なBASEからShopifyへの移行を想定した例です。実際の対応可否は、データの状態や利用中の機能によって異なります。
このように、データを移行できる場合でも、形式の変換や再設定、追加開発などの作業が発生することがあります。
具体的な移行方法は、移行元のシステムやデータの状態によって異なるため、個別に調査する必要があります。
新規構築・移行案件のいずれでも、商品画像や原稿の準備、各種サービスの契約、公開前の確認など、必要な作業と担当範囲を整理しておきましょう。
予算・スケジュール
予算とスケジュールは、構築方法や制作範囲を検討するうえで重要な確認事項です。
主な確認事項は次のとおりです。
- 制作予算と上限金額
- 月額利用料や追加アプリなど、継続的に発生する費用の想定
- 公開希望日と、その日程を変更できるかどうか
- 商品データや画像、原稿などの準備状況
- デザインや仕様の確認・承認に必要な期間
例えば、同じ機能を希望していても、予算によって既存テンプレートを活用するのか、独自のカスタマイズを行うのかといった選択が変わります。
また、公開希望日については、単なる目標なのか、新商品の発売やキャンペーンに合わせた変更できない期限なのかを確認することが重要です。
ECサイトの構築では、制作作業だけでなく、商品データの準備、決済サービスの審査、公開前のテストなどにも時間がかかる場合があります。
そのため、希望する予算・納期と必要な機能を照らし合わせ、実現可能な制作範囲やスケジュールを検討しましょう。
ヒアリング内容を要件として整理する
ヒアリングで確認した内容は、そのまま制作仕様として確定するのではなく、整理と確認を行う必要があります。
特に、次の3点が重要です。
必須の要件と希望する要件を区別する
例えば、「定期購入は公開時から必要だが、会員ランク機能は将来的に導入したい」という場合、両者を同じ優先順位で扱う必要はありません。
公開時点で必要な機能と、将来的な追加を想定している機能を分けておくことで、制作範囲を考えやすくなります。
未確定事項と調査事項を明確にする
顧客側で販売条件が決まっていない場合もあれば、制作会社側で技術的な調査が必要な場合もあります。
例えば、希望する送料条件が標準機能で実現できるか、既存の在庫管理システムと連携できるか、といった内容です。
これらを曖昧なまま進めず、何が未確定なのか、誰が確認するのかを整理します。
制作範囲と担当者を明確にする
例えば、商品登録100件を制作会社が担当するのか、事業者が登録するのかによって、必要な作業量が異なります。
また、アプリの導入・設定、データ移行、公開前のテスト、公開後の保守など、どこまでを制作会社側が行うのか確認が必要です。
ここで重要なのは、事業会社内部の細かな業務分担ではなく、制作会社と事業者の間で、誰がどの作業を受け持つかを明確にすることです。
要件と担当範囲を整理することで、見積もりの前提条件を明確にしやすくなります。
まとめ|要件定義では、希望を具体的な仕様へ落とし込む
ECサイトの要件定義では、商品や販売方法だけでなく、決済、配送、在庫管理、外部システム連携、デザイン、データ移行、予算・スケジュールなど、さまざまな事項を確認する必要があります。
重要なのは、項目を一通り聞くことだけではありません。
なぜその確認が必要なのかを理解し、事業者の希望がサイトの仕様や制作範囲にどのように関わるのかを整理することです。
すべての要件を一度に確定させる必要はありませんが、未確定事項や技術的な調査が必要な部分を明確にしておけば、構築方法の検討や見積もりを進めやすくなります。
事業者と制作会社の認識を合わせながら、実現したいことを具体的な要件に落とし込んでいきましょう。
「顧客の要望を実現できるか技術的に確認したい」「ECサイトの実装を任せられるパートナーを探している」そのようなWeb制作会社様は、トドケルへご相談ください。
トドケルでは、Shopifyを中心としたECサイトの構築・カスタマイズに対応しています。制作会社様の実装面での協業についても、お問い合わせフォームからお気軽にご相談ください。
