技術記事

「ECサイトをシステム会社に発注したい。でも何を伝えればいいか分からない」——このような状態で開発会社に問い合わせると、必ずと言っていいほど見積もりがズレます。

後になって追加費用が発生したり、欲しかった機能が含まれていなかったり。

その原因のほとんどは、発注前の要件整理が不十分だったことにあります。

この記事では、ECサイトをシステム会社に発注する際に整理すべき要件を全項目リスト化します。最近はAIとチャットしながら要件定義を進める方も増えています。そのままAIへの入力として使える構造にしていますので、ぜひ一項目ずつ自社の状況を当てはめながら読んでください。

発注前に整理すべき10の領域

ECサイトの要件は、大きく以下の10領域に分かれます。全てに答えられなくても構いませんが、ここで曖昧なものが多いほど、見積もりの誤差と開発後の手戻りが大きくなります。

1. ビジネス基本情報（何を・誰に・どのスケールで売るか）

2. 商品・カタログ管理

3. 決済・課金

4. 配送・物流

5. 会員・アカウント管理

6. 販促・マーケティング機能

7. 管理画面・オペレーション

8. 外部システム連携

9. セキュリティ・法令対応

10. 将来の拡張計画

1. ビジネス基本情報（誰に何をどのスケールで売るか）

最初に伝えるべきは「ビジネスの全体像」です。これが曖昧なままでは、開発会社側がどのアーキテクチャ・技術スタックを選ぶべきか判断できません。

確認すべき項目

• 販売形態：BtoC（一般消費者向け）/ BtoB（企業間取引）/ 両方

• 商品の種類：物販（有形商品）/ デジタルコンテンツ（PDF・動画・ソフトウェア）/ サービス販売

• SKU数の規模感：初期登録予定の商品数（例：10点・100点・10,000点以上）

• 想定注文数：1日あたりの想定注文件数（例：月100件〜・繁忙期ピーク時）

• ターゲットのデバイス：スマートフォンメイン / PCメイン / 両方同等

• 既存サイトの有無：新規構築 / 既存サイトからのリプレイス（データ移行が必要か）

• 多言語・多通貨対応：日本語のみ / 英語対応 / 海外販売を含む

AIとの会話例：「BtoCの物販ECで、商品数は初期100点から始めて1年後に500点に拡張予定。スマートフォンがメインチャネルで、海外配送は今のところ考えていない」のように具体的に伝えるとスムーズです。

2. 商品・カタログ管理の要件

商品データの構造がシステムの複雑さを大きく左右します。特に「バリエーション（色・サイズ）があるか」「在庫管理が必要か」は初期から明確にしてください。

確認すべき項目

• バリエーション管理：単品（SKU固定）/ 色・サイズ・素材などのバリエーションあり

• 在庫管理：リアルタイム在庫管理が必要か / 受注生産（在庫を持たない）か

• 在庫の置き場所：自社倉庫 / 外部倉庫（3PL）/ ドロップシッピング（仕入れ先から直送）

• 商品画像：1商品あたりの画像枚数（例：メイン1枚＋サブ4枚）

• 商品属性：素材・産地・アレルゲン情報など商品固有の項目があるか

• 定期購入・頒布会：毎月自動で同じ商品を届ける仕組みが必要か

• セット販売・バンドル：複数商品をセットで販売する機能が必要か

• デジタルコンテンツ：購入後にダウンロードURLを発行する仕組みが必要か

3. 決済・課金の要件

決済は「何の決済代行を使うか」だけでなく、「どの支払い手段を受け付けるか」を全て洗い出す必要があります。後から追加すると手数料体系や実装コストが変わります。

確認すべき項目

• クレジットカード：Stripe / Square / PAY.JP / GMOペイメントゲートウェイなど

• コンビニ払い・銀行振込：入金確認後に発送するフローが必要か

• 代金引換（代引き）：配送会社との連携が必要

• キャリア決済：ドコモ払い・auかんたん決済・ソフトバンクまとめて支払い

• 後払い（BNPL）：NP後払い・Paidy・ペイディなど

• QRコード決済：PayPay / LINE Pay など（主にBtoC向け）

• サブスクリプション：月額/年額の定期課金が必要か

• 分割払い：独自の分割支払い対応が必要か

• BtoB向け請求書払い：月次まとめ請求・与信管理が必要か

決済手段が増えるほど実装コストと月額手数料が上がります。「初期はカードのみ、半年後にコンビニ払いを追加」という段階的な計画でも開発会社に伝えておくと設計に反映できます。

4. 配送・物流の要件

配送要件は「送料の計算ロジック」が最も複雑化しやすい部分です。シンプルなルールに見えても、例外ケースを全て洗い出すと想定外の工数が発生することがあります。

確認すべき項目

• 配送業者：ヤマト運輸 / 佐川急便 / 日本郵便 / 複数業者を使い分け

• 送料の計算ルール：全国一律 / 地域別 / 重量別 / 購入金額で無料になる条件

• お届け日時指定：希望日・時間帯の選択が必要か

• 追跡番号の連携：配送業者の追跡URLを注文メールに自動挿入するか

• 複数倉庫からの発送：倉庫が複数あり、商品ごとに発送元が変わるか

• 冷蔵・冷凍対応：温度管理が必要な商品があるか

• 海外配送：対応国・関税・通関書類の扱い

• WMS連携：倉庫管理システムとのAPI連携が必要か

5. 会員・アカウント管理の要件

「会員登録を必須にするか」だけでも開発の方向性が変わります。ゲスト購入を認めると購入完了率が上がる一方で、リピート率の管理が難しくなります。

確認すべき項目

• 会員登録の要否：登録必須 / ゲスト購入可 / 購入後に会員化を促す

• ソーシャルログイン：Google / LINE / Apple でのログインに対応するか

• 会員ランク制度：ゴールド会員・シルバー会員など購買額で区分するか

• ポイント・スタンプ：購入額に応じてポイントを付与するか / 失効ルール

• お気に入り・ウィッシュリスト：商品を保存しておく機能が必要か

• 購入履歴：過去の注文を会員ページで確認できるか

• BtoB向け企業アカウント：複数担当者が1つの企業アカウントを共有するか

• 本人確認（KYC）：年齢確認・免許証確認などが法的に必要か

6. 販促・マーケティング機能の要件

販促機能は後から追加できるものも多いですが、初期設計に組み込んでおく方がコスト効率が高い機能もあります。特にクーポンとメールの設計は初期から決めておくことを推奨します。

確認すべき項目

• クーポン・割引コード：コードで割引適用 / 初回購入割引 / 期間限定セール

• タイムセール：開始・終了日時を設定した自動価格変更が必要か

• 送料無料キャンペーン：条件付き送料無料の期間設定

• メールマガジン：会員向けのメール配信（自前 / Mailchimp / Sendgridなど）

• カート放棄メール：カートに商品を入れたまま離脱した顧客へのリマインド

• レビュー・口コミ機能：商品レビューの投稿・表示・管理が必要か

• アフィリエイト：紹介リンクによる成果報酬の管理

• ギフト・プレゼント機能：のし・ラッピング・メッセージカードの対応

• SNSシェアボタン：Instagram / X（Twitter）/ LINE への商品シェア

7. 管理画面・オペレーションの要件

「誰が」「何を」「どれくらいの頻度で」管理するかによって、管理画面の設計が大きく変わります。管理スタッフの人数と権限設計は必ず確認してください。

確認すべき項目

• 管理者の人数と役割：1人で全て管理 / 複数スタッフで役割分担（商品担当・出荷担当など）

• 権限管理：スタッフによって見られる情報・操作できる機能を制限するか

• 注文管理フロー：受注→入金確認→ピッキング→出荷→完了の各ステータス管理

• CSV/Excelエクスポート：注文データ・商品データ・顧客データの書き出し

• CSVインポート：商品の一括登録・更新をCSVで行うか

• 売上レポート：日次・月次の売上・客単価・商品別売上の確認

• 在庫アラート：残数が一定以下になったら通知する機能

• 問い合わせ管理：注文に紐づいたカスタマーサポート機能が必要か

8. 外部システム連携の要件

ECサイトは単体で完結するシステムではなく、既存のツール・サービスとつなぐことで初めて業務フローが完成します。連携先が多いほど開発工数は増えます。

確認すべき項目

• 会計ソフト：freee / 弥生会計 / MFクラウド会計への売上データ自動連携

• 物流・WMS：倉庫管理システム（例：ロジクラ・ZAICO）とのAPI連携

• CRM / MA：Salesforce / HubSpot / Klaviyo などとの顧客データ連携

• 基幹システム（ERP）：既存の受発注・在庫・顧客管理システムとの連携

• 分析ツール：Google Analytics 4 / Meta Pixel / TikTok Pixelの設置

• チャットサポート：Zendesk / Intercom / LINE公式アカウントの組み込み

• モール在庫連携：楽天・Amazon・Yahoo!ショッピングと在庫を一元管理するか

9. セキュリティ・法令対応の要件

ECサイトは個人情報と決済情報を扱うため、セキュリティ要件は「非機能要件」ではなく「必須要件」です。法令対応の不備は事業リスクに直結します。

確認すべき項目

• SSL/TLS：全ページのHTTPS化（現代では必須）

• カード情報の非保持化：PCI DSS準拠。カード番号を自社サーバーに保存しない設計

• 個人情報保護法対応：プライバシーポリシーの整備・同意取得・開示請求対応

• Cookie同意（GDPR対応）：EU向け販売を行う場合は必須

• 特定商取引法ページ：販売者情報・返品ポリシー・配送条件の法定記載

• 不正注文対策：不正利用検知（3Dセキュア / 住所とIPの不一致検知など）

• ログイン保護：多要素認証（MFA）の対応可否

• 定期バックアップ：データの自動バックアップ頻度と保存期間

10. 将来の拡張計画

「今すぐ必要ではないが、1〜2年後には欲しい機能」を初期から開発会社に伝えることで、後から追加しやすいアーキテクチャを選択してもらえます。これを伝えないと、後の追加開発コストが数倍になることがあります。

伝えておくべき将来計画の例

• スマートフォンアプリ（iOS / Android）への展開予定

• BtoBとBtoCの両チャネル展開

• 海外対応（多言語 / 多通貨 / 海外配送）

• 出品者が複数いるマーケットプレイス形式への転換

• サブスクリプション・定期便の追加

• AI推薦機能（「この商品を買った人は〇〇も買っています」）

• オフライン（実店舗）とのPOS連携・在庫統合

見落としがちな「非機能要件」

機能の話ばかりに集中すると非機能要件を忘れがちです。しかしこれが開発コストと運用コストの差を生みます。

• 表示速度：GoogleのCore Web Vitalsを意識したパフォーマンス基準（特に商品一覧・画像の多いページ）

• 同時アクセス耐性：セール・テレビ放映などでアクセスが集中したときのスパイク対応

• 可用性（稼働率）：99.9%（月8時間のダウン許容）か 99.99%（月4分）か

• SEO：商品ページのURL設計・構造化データ（JSON-LD）・サイトマップ自動生成

• 障害対応SLA：障害発生時に何時間以内に対応してもらえるか

• ソースコードの所有権：開発会社からソースコードの納品を受けるか / ブラックボックスのSaaSか

AIとチャットしながら要件定義を進めるときの伝え方

ChatGPTやClaudeなどのAIに要件定義を手伝ってもらうとき、最初に「自社のビジネス概要」を一段落で説明してから、上記の10領域を一つずつ質問形式で確認していくと整理が早く進みます。

AIへの最初の入力テンプレート

以下をコピーして自社情報を埋め、AIに貼り付けてください。

私は[業種]の[BtoC/BtoB]向けECサイトを[新規構築/リプレイス]したいと考えています。
商品数は初期[　]点で、1日あたりの想定注文数は[　]件程度です。
メインのデバイスは[スマートフォン/PC]で、[海外配送あり/日本国内のみ]です。
現在使っている決済手段は[　]です。
外部システムで連携が必要なものは[　]です。
これからECサイトの要件をまとめたいので、上記10領域を一つずつ確認する質問をしてください。

このように業種・規模感・現状・優先テーマをセットで伝えると、AIも具体的な質問を返しやすくなります。上記の各セクションをチェックリストとして使いながら、「自社はこの項目をどうするか」を一つずつ決定していくと、開発会社に渡せる要件書の骨格が完成します。

まとめ：要件が揃うと見積もりの精度が上がり、コストも下がる

「何を作るか」が明確なほど、開発会社は正確な見積もりを出せます。曖昧な状態で発注すると、不確実性のバッファとして見積もりが膨らむか、後から追加費用が発生するかのどちらかです。

上記の10領域を全て埋める必要はありません。「今は分からない」「後で決める」という項目があれば、そのまま開発会社に伝えてください。重要なのは、不明点を隠さず共有することです。不明点が多い場合は、まず要件定義フェーズ（要件整理のみを行うスモールな発注）を先行させる方法もあります。

micomiaでは要件定義の段階から相談に乗っています。「まだ何も決まっていない」という状態でも、上記のチェックリストを持ってご連絡いただければ、優先順位の整理から一緒に進められます。