ECサイトの要件定義でつまずくのは、機能を並べる作業そのものではありません。「どこまで書けば漏れがないか」の基準が手元にないことと、法令やカード業界のガイドラインが実装を先に縛っている部分を後から発見することの2つです。この記事では、デジタル庁の標準ガイドラインが定める記載事項の型を骨組みに使い、EC特有の必須要件を一次資料から確認していきます。
まとめ：ECサイトの要件定義で最初に固める4点
ECサイトの要件定義では、次の4点を先に固めると大きな手戻りを避けられます。
- 記載事項の型を先に決める。デジタル庁のデジタル・ガバメント推進標準ガイドライン（DS-100）は、要件定義書に業務要件・機能要件・非機能要件・情報システムの実現案を記載すると定め、機能要件を5事項、非機能要件を18事項に分解しています。政府情報システムの整備・管理に関するルールなので民間案件に適用義務はありませんが、記載事項のひな型としては案件に合わせて調整しながら使えます。
- 法令由来の要件を機能要件に先に入れる。特定商取引法は、通信販売の広告に表示する事項と、最終確認画面に表示する事項を条文で列挙しています。これらは画面仕様の前提であり、あとから足せる装飾ではありません。
- カード決済の方式を要件定義の段階で決める。クレジットカード・セキュリティガイドライン【6.1版】は、EC加盟店に非保持化またはPCI DSS準拠と脆弱性対策、さらにEMV 3-Dセキュアの導入と不正ログイン対策を求めています。決済方式の選択はシステム構成そのものを変えます。
- 非機能要件は数値で書く。DS-100は性能について「応答時間、バッチ処理時間等を記載する」と定めています。「速いこと」では検収できません。
なお、ECサイトの種類や構築方法そのものの比較はECサイトとは？種類・構築方法・費用相場と「既製で足りる／開発すべき」の判断軸を解説で、企画から公開までの工程はECサイトの構築・作り方を解説｜5つの方法の選び方と要件定義から公開までの手順で扱っています。この記事は要件定義書の中身に絞ります。
ECサイトの要件定義と構築方法の選定の違い
ECの案件では、要件定義の前に「SaaSかパッケージかフルスクラッチか」の議論が始まることがよくあります。しかし構築方法の選定は手段の選択であり、要件定義は「何を満たせば業務が回るか」の定義です。順序を逆にすると、選んだ製品でできることが要件になってしまい、業務側の必須条件が落ちます。
DS-100の第3編第5章は、要件定義書に記載する内容として業務要件の定義、機能要件の定義、非機能要件の定義、そして情報システムの実現案の4つを挙げています。注目すべきは、実現案が要件と分けて最後に置かれている点です。同ガイドラインは、システム方式を先に定めてから各要件を検討する進め方も認めたうえで、「システム方式を詳細に指定しすぎると事業者からより良い提案を受けられなくなるおそれもあるため、記載の粒度について配慮すること」と注意しています。製品を先に決める進め方が禁止されているわけではなく、決め打ちの粒度に注意せよ、という整理です。
もうひとつ、DS-100は要件の決定主体についても踏み込んでいます。機能要件・非機能要件・実現案は「情報システム部門のみで決定するものではなく、制度所管部門、業務実施部門を含めた」プロジェクト管理体制の全体で決定することが不可欠だとしています。ECに置き換えれば、商品部・物流部・カスタマーサポート・経理までを要件定義の当事者に含めるということです。
要件定義と後続工程の線引きが曖昧なときは基本設計とは？システム開発での位置づけと成果物、要件定義・詳細設計との違いを、業務要件の書き方は業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説を参照してください。
機能要件の洗い出しで定義する5つの事項
DS-100は機能要件を、機能・画面・帳票・データ・外部インタフェースの5つの事項で定義すると規定しています。ECサイトの機能一覧は担当部門ごとに書き足されて長くなりがちですが、この5分類に振り分けると、どの区分が薄いかが見えます。
| DS-100の事項 | ECサイトでの主な中身 |
|---|---|
| 機能に関する事項 | 商品登録、在庫引当、カート、受注、出荷指示、返品・キャンセル、会員、ポイント |
| 画面に関する事項 | 商品一覧・詳細、カート、最終確認画面、注文完了、マイページ、管理画面 |
| 帳票に関する事項 | 納品書、領収書、請求書、出荷指示書、売上日計表 |
| データに関する事項 | 商品マスタ、在庫、会員、受注、配送、ポイント残高。保持期間 |
| 外部インタフェースに関する事項 | 決済代行、配送会社、基幹システム、会計ソフト、モール、メール配信 |
この5つのうち、ECで条件を詰めきれずに残りやすいのが外部インタフェースです。DS-100は外部インタフェース一覧として「相手先の情報システム、送受信データ名、送受信タイミング、送受信の条件の基本的な考え方等を記載する」と求めています。ECでは在庫連携の頻度（リアルタイムか日次バッチか）と、受注データを基幹へ渡すタイミングが、そのまま欠品クレームの発生率と経理の締め作業に直結します。ここを「連携する」の一言で済ませると、設計工程で送受信の単位・失敗時のリトライ・重複データの扱いを改めて決め直すことになります。
同ガイドラインは外部インタフェースについて「オープンなＡＰＩとしての活用が行われることも想定して整備するよう留意すること」とも述べています。将来のモール出店やアプリ展開を視野に入れるなら、要件定義の段階でAPI化の余地を残す判断が必要です。
帳票については「業務のデジタル化を前提に、帳票は最小限にすることが望ましい」との規定があります。ECでも、同梱する紙の帳票を減らせるかどうかは梱包コストに直結する論点です。
機能要件と非機能要件の切り分け自体に迷う場合は機能要件とは？非機能要件・業務要件との違いと定義する5つの事項で整理しています。画面遷移図やER図の描き分けは要件定義と設計で作る7つの図｜画面遷移図・ER図とデザイナーの担当範囲を参照してください。
交渉の余地がない法令由来の必須要件
ECサイトの要件には、発注者と受注者の合意では動かせない部分があります。ここを要件定義の後半に回すと、画面仕様とデータ項目の両方をやり直すことになります。
特定商取引法が定める広告の表示事項
通信販売として特定商取引法の規制を受ける場合、同法第11条は広告について次の事項の表示を義務づけています。条文の列挙は第1号から第6号までです。なお同条ただし書により、請求があれば遅滞なくこれらを記載した書面または電磁的記録を提供する旨を表示する場合は、省令の定めるところにより一部を表示しないことができます。
- 商品若しくは権利の販売価格又は役務の対価（販売価格に商品の送料が含まれない場合には、販売価格及び商品の送料）
- 代金又は対価の支払の時期及び方法
- 商品の引渡時期若しくは権利の移転時期又は役務の提供時期
- 申込みの期間に関する定めがあるときは、その旨及びその内容
- 申込みの撤回又は解除に関する事項
- 前各号に掲げるもののほか、主務省令で定める事項
第6号の省令事項は、同法施行規則第23条に10号まで列挙されています。第1号が「販売業者又は役務提供事業者の氏名又は名称、住所及び電話番号」、第2号が、法人が電子情報処理組織を使用する方法（インターネット等）により広告する場合の「代表者又は通信販売に関する業務の責任者の氏名」です。ほかにも、販売価格と送料以外に購入者が負担すべき金銭があるときはその内容と額（第4号）、契約不適合責任の定めがあるときはその内容（第5号）、定期購入のように二回以上継続して契約する必要があるときの金額と契約期間（第7号）、販売数量の制限その他の特別な条件（第8号）が含まれます。いわゆる特定商取引法に基づく表記のページは、この条文と省令をそのまま項目に落としたものです。7類型それぞれの規制と表示義務の全体像は特定商取引法とは？7類型の規制と通信販売の表示義務をEC実装要件で解説で扱っています。
最終確認画面に表示する6項目
見落とされやすいのが第12条の6です。同条は、事業者が定める様式の書面や、画面に表示する手続に従って顧客が行う申込みを「特定申込み」と定義し、その画面に次を表示しなければならないと定めています。
- 販売する商品若しくは特定権利、又は提供する役務の分量
- 第11条第1号から第5号までに掲げる事項（販売価格と送料、支払時期と方法、引渡時期、申込期間の定め、撤回・解除に関する事項）
つまり、カートの最終確認画面には分量を含む6項目がそろっている必要があります。さらに同条第2項は、その画面で「当該手続に従つた情報の送信が…申込みとなることにつき、人を誤認させるような表示」と、第1項各号の事項について「人を誤認させるような表示」を禁止しています。購入ボタンの文言、定期購入の回数表示、送料の表示位置までが法令の射程に入るということです。要件定義書では、この6項目を最終確認画面の必須表示項目として明記しておきます。
カード決済に関するガイドラインの指針対策
クレジットカード決済を扱うなら、クレジット取引セキュリティ対策協議会（事務局は日本クレジット協会）の「クレジットカード・セキュリティガイドライン」を確認します。現行は2026年3月11日改訂の【6.1版】です。同ガイドラインは、掲げる措置または同等以上の措置を適切に講じている場合に、割賦販売法に規定する「必要かつ適切な措置」が講じられているとみなされる位置づけにあります。ただし同ガイドライン自身が、割賦販売法では指針対策が実務指針となっている措置に限らず「実施するべき措置が義務付けられていることに留意する」と注記しており、ガイドラインを満たせば法令対応が完了するわけではありません。
EC加盟店に対する指針対策は2本です。カード情報保護対策は「カード情報を保持しない非保持化、又はカード情報を保持する場合はPCI DSSに準拠する。さらに、EC加盟店のシステム及びWebサイトの『脆弱性対策』を講じる」。不正利用対策は「不正利用防止策として、オーソリゼーション処理の体制整備、加盟店契約上の善良なる管理者の注意義務の履行、EMV 3-Dセキュアの導入及び適切な不正ログイン対策を実施する」。脆弱性対策・不正ログイン対策・EMV 3-Dセキュアの導入は、2025年3月公表の【6.0版】で指針対策に追加された項目です。
| 指針対策の要素 | 要件定義書に落とす項目 |
|---|---|
| 非保持化 | リダイレクト型かJavaScript型かの選択。自社で保存・処理・通過させない構成の確認 |
| PCI DSS準拠 | 保持する場合のみ。準拠範囲と評価方法（対象はv4.0.1） |
| 脆弱性対策 | 5分類すべてを実施（非保持化でも必要） |
| EMV 3-Dセキュア | 認証のタイミング（決済の都度か登録時か）と、渡すデバイス情報等の項目 |
| 不正ログイン対策 | 会員登録時・会員ログイン時・属性情報変更時のリスクを踏まえた対策を1つ以上 |
脆弱性対策は「ウイルス対策をする」といった抽象的な要件ではありません。6.1版は導入する脆弱性対策として次の5つを挙げ、「下記のすべての対策を講じる」としています。具体的な対策内容は附属文書の「セキュリティ対策導入ガイド」に委ねられています。
- システム管理画面のアクセス制限と管理者のID/パスワード管理（IPアドレス制限、制限できない場合はベーシック認証等、2段階認証または多要素認証、ログイン失敗10回以下でのアカウントロック）
- データディレクトリの露見に伴う設定不備への対策（公開ディレクトリに重要ファイルを置かない、アップロード可能な拡張子の制限）
- Webアプリケーションの脆弱性対策（脆弱性診断またはペネトレーションテストの定期実施、プラグインとソフトウェアの更新、セキュアコーディングの確認）
- マルウェア対策としてのウイルス対策ソフトの導入、運用
- 悪質な有効性確認、クレジットマスターへの対策
この5つは、そのまま非機能要件の情報セキュリティの節に転記できます。管理画面のIP制限や多要素認証は後付けが難しいため、要件定義の段階で決めておく項目です。
とくに注意したいのが、非保持化の判定です。同ガイドラインは、非保持化を「自社で保有する機器・ネットワークにおいて『カード情報』を『保存』『処理』『通過』のいずれも行わないこと」と定義したうえで、自社の決済システムが通過型か非通過型かを認識しないまま漏えい事故で初めて通過型だと判明する事例があると指摘し、通過型を導入している場合は非通過型への移行か、カード情報を保持する必要がある場合はPCI DSSに準拠しなければならないとしています。既存ECのリプレースでは、現行が通過型かどうかの確認を要件定義の入力情報にしておきます。
EMV 3-Dセキュアについては、導入期限が先にありました。ガイドライン4.0版（2023年3月策定）が「原則、全てのEC加盟店は2025年3月末までにEMV 3-Dセキュアの導入を計画的に進める」ことを求め、クレジット取引セキュリティ対策協議会が2023年11月に公開した導入推進ロードマップも「2025年3月末までに、原則、全てのEC加盟店にEMV 3-Dセキュアの導入を求める」と明記しています。この期限はすでに過ぎているため、要件定義では導入を既定として組み立てたうえで、自社の取引が別途定められた未導入可能取引に当たるかどうかを、契約するカード会社または決済代行事業者に確認する形になります。仕組み自体の解説は3Dセキュアとは？EMV 3-Dセキュア2.0の仕組み・認証フローとEC決済への実装を開発視点で解説にまとめています。
ただし、運用面には幅が残されています。6.1版は「EC加盟店は、EMV 3-Dセキュアを導入した上で、原則としては決済の都度、EMV 3-Dセキュアによる認証を行うことが求められる」としたうえで、他の不正利用対策の内容や抑止効果に応じて、カード番号の登録時に認証する運用や、加盟店のリスク判断で認証する運用も認められるとしています。要件定義では「導入する」で止めず、どのタイミングで認証を挟むかまで決めておくと、カゴ落ちへの影響を見積もれます。
なお、カード会社が把握する不正利用金額が「3ヵ月連続50万円超」に該当する加盟店は不正顕在化加盟店とされ、追加の対策導入が求められます。要件定義では、不正が増えたときに対策を追加できる拡張余地を残しておくことが実務的な備えになります。
電子帳簿保存法が求める受注データの保存要件
もうひとつ、要件定義の段階でデータ項目と保持期間に影響するのが電子帳簿保存法です。国税庁の電子帳簿保存法一問一答【電子取引関係】（令和8年7月）の問2は、電子取引を「インターネット上にサイトを設け、当該サイトを通じて取引情報を授受する取引等」と説明しており、ECサイトで授受する注文情報はこれに該当します。保存対象は自社システムの内部データ全般ではなく、注文書、契約書、送り状、領収書、見積書等に通常記載される取引情報です。
同一問一答の問18は、電子取引データの保存に「真実性や可視性を確保するための要件を満たす必要があります」としています。真実性は、タイムスタンプが付された後の授受、速やかに（または業務の処理に係る通常の期間を経過した後、速やかに）タイムスタンプを付すこと、訂正削除の記録が残るか訂正削除ができないシステムでの授受と保存、訂正削除の防止に関する事務処理規程の備付けと運用、のいずれかの措置で確保します。2つ目の括弧書きは、授受からタイムスタンプ付与までの事務処理に関する規程を定めている場合に限られます。可視性は、電子計算機処理システムの概要を記載した書類の備付け（自社開発のプログラムを使用する場合に限ります）、見読可能装置の備付け等、検索機能の確保が要件です。検索機能については、基準期間の売上高が5,000万円以下でダウンロードの求めに応じられる場合など、一定の条件で不要となる特例があります。要件定義書では、受注データの保持期間、検索条件（取引年月日・取引金額・取引先）、訂正削除の履歴をどう残すかを明記しておきます。
なお、令和4年1月1日から令和5年12月31日までの電子取引を対象とした宥恕措置は期限の到来をもって廃止されており、現在は所定の要件を満たす場合に保存時の要件を不要とする猶予措置に置き換わっています。猶予措置でも電子データ自体の保存は必要です。真実性の要件を事務処理規程で満たす方法は事務処理規程とは？電子帳簿保存法の真実性要件を満たす作成方法と国税庁サンプル【2026年版】で解説しています。
非機能要件を数値で書くための18の観点
非機能要件は「落ちないこと」「速いこと」と書かれがちですが、それでは検収も見積もりもできません。DS-100は非機能要件を、a)からr)までの18の事項で定義すると規定しています。
| 区分 | 事項 |
|---|---|
| a から f | ユーザビリティ及びアクセシビリティ／システム方式／規模／性能／信頼性／拡張性 |
| g から l | 上位互換性／中立性／継続性／情報セキュリティ／情報システム稼働環境／データマネジメント |
| m から r | テスト／移行／引継ぎ／教育／運用／保守 |
ECサイトで重くなるのは、この中の規模・性能・信頼性・拡張性・情報セキュリティです。DS-100は規模について「機器数、設置場所、データ量、処理件数、利用者数等を記載する」とし、データ量は「ライフサイクル期間における将来の見込みも記載すること」と求めています。ECなら、商品点数、月間受注件数、会員数、画像の総容量を、現在値と数年後の見込みの両方で書くということです。
性能については「応答時間、バッチ処理時間等を記載する」と定める一方で、「性能が過度にならないよう適切な要件とすること」という歯止めも置かれています。ECの性能要件で難しいのは、平常時ではなくセールやテレビ放映時のピークをどう扱うかです。自社のアクセスログから実測したピーク値を出発点にし、その何倍まで耐える設計にするかを発注者側が決めて要件に書くのが筋です。「想定される最大アクセスに耐えること」という書き方では、受注側は見積もれません。ピーク対応のアーキテクチャ選択はアクセス集中に対応するスケーラブルなクラウドアーキテクチャ設計の基本で扱っています。
信頼性を表す代表的な指標のひとつが稼働率です。ただし稼働率の数字だけを決めても、計画停止を含むか、障害の起点をどこから数えるかが曖昧だと合意になりません。この整理はSLA（サービスレベル合意）とは？定義・SLOとの違い・要件と稼働率保証を解説が詳しいです。
非機能要件の項目をより細かく詰めるときは、IPAが公開している非機能要求グレードが実務でよく使われます。現在IPAが掲載しているのは「非機能要求グレード2018」で、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6領域に分類されています。DS-100の18事項と対応づけると、どちらの枠組みで書いても抜けを相互にチェックできます。概要は【非機能要求グレードとは何か？】IPAが提唱するフレームワークの概要と非機能要求定義の目的を詳しく解説するで、品質特性の分類から攻める場合はISO/IEC 25010とは？品質特性の一覧と2023年改訂（安全性の追加）まで解説を参照してください。
要件の品質を確認する7つの観点と未確定要件の扱い
要件を書き終えたあとの確認基準も、DS-100が示しています。定義した内容について「その必要性、網羅性、具体性、定量性、整合性、中立性及び役割分担の明確性の観点」から、さらに情報セキュリティ等の観点から実現可能性があることを確認する、という規定です。この7つはレビューのチェックリストにそのまま使えます。
| 観点 | ECサイトのレビューでの問い |
|---|---|
| 必要性 | その機能を落とすと、どの業務が止まるのか |
| 網羅性 | 返品・一部出荷・再送などの異常系が抜けていないか |
| 具体性 | 「使いやすいこと」で終わっていないか |
| 定量性 | 応答時間、処理件数、保持期間に数値が入っているか |
| 整合性 | 在庫引当のタイミングが受注要件と物流要件で食い違わないか |
| 中立性 | 特定製品でしか実現できない書き方になっていないか |
| 役割分担の明確性 | マスタ登録や画像加工を発注側と受注側のどちらが担うか |
そして、要件が固まりきらないまま次工程へ引き継ぐ場面で効いてくるのが、未確定要件の扱いに関する規定です。DS-100は「定義の時点において、未確定な要件については、それがプロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにするものとする」と定めています。すべてを確定させてから要件定義を終えるのではなく、未確定であること自体を書き残すのが正しい進め方だ、という立場です。
ECの案件では、キャンペーンの仕様、モール連携の対象、越境対応の有無などが要件定義の時点で固まらないことがよくあります。これらを空欄のまま次工程へ送るのではなく、「未確定」「いつまでに誰が決める」「決まらない場合の既定値」の3点を書いておけば、変更管理の対象として扱えます。
要件定義書への落とし込みとレビュー体制
ここまでの内容を文書にする段になったら、章立てとレビュー観点は要件定義書の書き方：章立てサンプル・記載項目・レビュー観点を作業手順で解説に沿って進めるのが早いです。EC固有の追加としては、特定商取引法の表示事項と最終確認画面の6項目、カード決済方式の選択、外部インタフェース一覧の4つを独立した章として立てておくと、後工程で参照しやすくなります。
外部ベンダーへ発注する場合は、要件定義書をそのまま提案依頼の材料にできます。DS-100も、非機能要件については日本産業規格等のほか「ＲＦＩ等を通じて、広く情報を取得し、実現性等の検証を行う」としています。情報提供依頼と提案依頼の使い分けはRFI・RFP・RFQの違いとは？意味・使い分けと発行の流れを実務目線で整理で整理しています。
市場環境の面でも、要件を絞る判断は以前より重要になっています。経済産業省の令和6年度電子商取引に関する市場調査（2025年8月26日公表）によれば、2024年の国内BtoC-EC市場規模は26.1兆円で前年比5.1%増、物販系分野は15兆2,194億円でEC化率は9.78%でした。物販のEC化率が1割に届いていないということは、多くの事業者にとって売上の大半が依然としてEC以外の経路にあるということです。実店舗や既存の受注チャネルを併せ持つ事業者であれば、店舗在庫の見せ方、実店舗での返品受付、会員IDの統合を要件定義の段階で決めておくと、後からの接続工事を避けられます。
よくある質問
ECサイトの要件定義は誰が主導すべきですか？
情報システム部門だけで決めるものではありません。DS-100は、機能要件・非機能要件・実現案について「情報システム部門のみで決定するものではなく、制度所管部門、業務実施部門を含めた」体制全体で決定することが不可欠だとしています。ECでは商品部、物流、カスタマーサポート、経理を当事者に含め、それぞれの業務が止まらない条件を出してもらう形が現実的です。
要件定義の時点で決まらない項目はどう書けばよいですか？
空欄にせず、未確定であること自体を書きます。DS-100は、未確定な要件は「プロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにする」と定めています。あわせて、いつまでに誰が決めるか、決まらない場合の既定値を併記しておくと、変更管理の対象として追跡できます。
カートの最終確認画面には何を表示する必要がありますか？
特定商取引法第12条の6により、商品や役務の分量と、同法第11条第1号から第5号までの事項（販売価格と送料、支払時期と方法、引渡時期、申込期間の定めがあるときはその旨と内容、申込みの撤回又は解除に関する事項）の表示が必要です。同条第2項は、申込みになることを誤認させる表示と、これらの事項を誤認させる表示を禁止しています。
EMV 3-Dセキュアは必ず導入しなければなりませんか？
クレジットカード・セキュリティガイドライン【6.1版】は、EC加盟店の不正利用対策の指針対策として「EMV 3-Dセキュアの導入及び適切な不正ログイン対策を実施する」と明記しています。4.0版の時点で2025年3月末までの導入が求められ、その期限はすでに過ぎているため、実務上は導入を前提に要件を組み立てることになります。ただし認証のタイミングには幅があり、6.1版は原則として決済の都度としつつ、他の不正利用対策の内容や抑止効果に応じてカード番号の登録時に認証する運用なども認めています。具体的な適用範囲や設定は、契約するカード会社または決済代行事業者との確認が必要です。
非機能要件はどこまで細かく書けばよいですか？
検収できる粒度が目安です。DS-100は性能について「応答時間、バッチ処理時間等を記載する」と定める一方、「性能が過度にならないよう適切な要件とすること」とも述べています。必要以上に厳しい数値はコストに跳ね返るため、自社の実測値を出発点に、ピーク時に何倍まで耐えるかを発注側が決めて書くのが現実的です。
SaaSを使う場合でも要件定義は必要ですか？
必要です。DS-100も、導入するクラウドサービスやパッケージ製品をシステム方式として先に定めたうえで業務要件・機能要件・非機能要件を検討する進め方を認めており、要件の定義自体を省いてよいとはしていません。SaaSを選ぶ場合、要件定義の役割は「作るものを決める」ことに加えて「その製品で満たせない要件を特定する」ことになります。外部インタフェース、帳票、データの保持期間、法令由来の表示項目を先に定義しておけば、製品の標準機能で足りるか、追加開発や運用でのカバーが要るかを比較できます。
