EC要件定義書の書き方｜テンプレ項目・サンプル・チェックリストを徹底解説

はじめに

「ECサイトの要件定義書を作ることになったが、社内にフォーマットがなくゼロから書き起こす自信がない」
「他社の要件定義書を見たことがなく、どの粒度で書けばベンダーに伝わるのか分からない」
「機能要件と業務要件と仕様書の違いが整理できず、章立てから迷っている」

EC構築・リプレイスの一次担当として要件定義書の作成を任された方から、よく聞かれる悩みです。

要件定義書はECサイト構築プロジェクトの設計図にあたるドキュメントで、その後の見積もり・設計・開発・テスト・受け入れ判定の基準書になります。

ところが要件定義書は、社内に過去のサンプルが残っていないケースが多く、書き手によって粒度がバラつきがちな文書でもあります。

「業務要件」と書きながら機能仕様を書いている、「非機能要件」が一行で済まされている、画面イメージが文字説明だけ、想定取引量の前提が抜けている。
こうした漏れがあると、ベンダーは要件を読み解くために何度も追加質問することになり、見積もり精度が落ち、後工程で「想定と違う」が頻発します。

逆に、要件定義書が章立て・粒度・サンプル文のレベルで整っていれば、ベンダー提案の質も実装の品質も大きく変わります。

本記事では、EC要件定義書のテンプレ項目（業務要件・機能要件・非機能要件・画面要件・連携要件・データ要件・運用要件）、章ごとの記述例とサンプル文、Shopify構築時に特に押さえたい項目、要件定義書と仕様書の違い、よくある書き方の落とし穴、レビュー時のチェックリストまで解説します。

これから要件定義書を書き起こす担当者、ベンダーに提示する直前のレビュー段階の担当者、社内テンプレートを整備したいPMの方の判断材料としてお使いください。

目次

1. EC要件定義書とは｜仕様書・RFPとの違い

2. EC要件定義書の標準的な章立てとテンプレ全体像

3. 表紙・改訂履歴・前提条件の書き方

4. 業務要件の書き方とサンプル

5. 機能要件の書き方とサンプル

6. 非機能要件の書き方とサンプル

7. 画面要件・UI要件の書き方

8. データ要件・外部連携要件の書き方

9. 運用要件・保守要件の書き方

10. Shopify構築時に押さえたい要件定義書の追加項目

11. 要件定義書でよくある書き方の落とし穴

12. レビューチェックリストと承認プロセス

13. まとめ

---

【無料相談】EC要件定義書の整備をご支援します 要件定義書の章立て、書きぶり、Shopify構築時の必須項目の整理について、Shopifyの専門家が無料でご相談に乗ります。社内テンプレートの叩き台、ベンダー提示前のレビュー、いずれの段階でも対応可能です。
 [無料で相談する]　[資料をダウンロード]

---

1. EC要件定義書とは｜仕様書・RFPとの違い

EC要件定義書は、構築するECサイトが満たすべき「要件」を文書化したドキュメントです。事業部・情シス・ベンダーが共通の基準書として参照し、見積もり・設計・開発・テスト・受け入れ判定のすべての工程で土台になります。

実務では「要件定義書」「仕様書」「RFP（提案依頼書）」がしばしば混在して語られますが、それぞれ目的と粒度が異なります。最初に整理しておきます。

1-1. 要件定義書・仕様書・RFPの違い

3つのドキュメントの違いを整理した一覧です。

RFPは「ベンダー候補に投げる」段階で、選定前に作る資料です。

要件定義書は「ベンダー選定後にベンダーと合意する」段階で完成させる資料で、業務要件・機能要件・非機能要件を体系的に整理します。

仕様書は要件定義の後工程として、ベンダー側が要件を実装に落とすための設計資料です。

つまり実務の流れは、RFP（要件のたたき台）→ 要件定義書（要件の合意）→ 仕様書（実装設計）と段階的に粒度が深まっていきます。

1-2. 要件定義書が果たす3つの役割

要件定義書がプロジェクト内で果たす役割は、大きく次の3つに整理できます。

1. 見積もり・契約の基準書：開発スコープを文書として固定し、追加見積もり・契約変更の判断材料にする

2. 設計・開発・テストの基準書：基本設計・詳細設計・テスト設計の参照元として使われる

3. 受け入れ判定の基準書：リリース前の受け入れテストで、要件を満たしているかを判定する物差しになる

この3役を一つの文書で担うため、要件定義書の精度はプロジェクト全体の品質を左右します。

1-3. 要件定義書と仕様書をどう書き分けるか

「要件定義書」と「仕様書」の境界に迷う担当者は多いです。実務的な線引きの目安は次のとおりです。

• 要件定義書：「何を実現させたいか」「どんな条件を満たさせたいか」のWhat

• 仕様書：「どうやって実現するか」のHow

たとえば「会員ランク別にポイント還元率を変えたい」は要件定義書側の記述です。

「会員ランクテーブルにrank_idカラムを持たせ、ポイント計算サービスがrank_idを参照してパーセントを切り替える」は仕様書側の記述になります。

要件定義書のなかに実装レベルの記述が混ざると、ベンダー裁量で改善できる範囲を狭め、見積もりが過剰に膨らむ要因にもなります。Whatに留める意識が重要です。

2. EC要件定義書の標準的な章立てとテンプレ全体像

EC要件定義書の章立ては、業界として明確な標準は定まっていませんが、IPA『非機能要求グレード』や各種ガイドラインを参考に、実務で使われている共通形が見えてきています。ここでは中規模〜大手EC事業者の要件定義書で頻出する標準的な章立てを示します。

2-1. 標準的な章立て（テンプレ全体像）

要件定義書の標準的な章立ては、おおむね次のとおりです。

すべての章を均等な分量で書く必要はなく、事業特性に応じて軽重をつけます。

たとえばB2B-EC色が強いプロジェクトでは「業務要件」「外部連携要件」が厚くなり、D2C寄りのプロジェクトでは「画面要件」「データ要件」が厚くなる傾向です。

2-2. 章ごとの想定ページ数の目安

中規模ECの新規構築・リプレイス案件で、要件定義書のページ数の目安は次のとおりです。

合計で80〜250ページ程度のレンジになることが多いですが、ページ数自体が目的ではありません。「読む側が判断・実装できる粒度になっているか」を基準に調整します。

2-3. ドキュメント体裁の指定（書式・記号・採番）

要件定義書を複数人で書くと、書式や記号がバラつきがちです。冒頭のテンプレ整備段階で次を統一しておくと、後工程のレビューが楽になります。

• 採番ルール：章「1.」、節「1.1.」、項「1.1.1.」、機能要件は「FR-001」など接頭辞付き

• 要件記述の語尾：「〜できること」「〜すること」「〜であること」のいずれかに統一

• 必須／希望の区別：「【必須】」「【希望】」「【任意】」を要件文の冒頭または末尾に付ける

• 画面項目の表記：太字で項目名、括弧書きでデータ型・桁数（例：商品名（VARCHAR、200桁）)

• 図表の引用ルール：図表番号を採番し、本文から参照（例：図4-1、表5-3）

これらは些細なルールに見えますが、後でテストケースや変更管理で要件を一つひとつ参照する際に大きな差を生みます。

3. 表紙・改訂履歴・前提条件の書き方

要件定義書の最初の3章は分量こそ少ないものの、ドキュメント全体の精度を左右する重要なパートです。

3-1. 表紙に書くべき項目

表紙には次の情報を漏れなく載せます。

• プロジェクト名（正式名称）

• ドキュメント名（例：「○○ECサイト構築 要件定義書」）

• 発行日

• 版数（v1.0、v1.1、v2.0など）

• 発行元（事業部名・部署名）

• 機密区分（社外秘／関係者外秘など）

複数版が運用されると、どれが最新か分からなくなりがちです。

版数とファイル名のルールはプロジェクト開始時に決め、ファイル名に版数を含めることを推奨します。

3-2. 改訂履歴の書き方

改訂履歴は、要件定義書が更新されたタイミングと変更内容を追跡するための一覧です。

改訂履歴を残しておくと、ベンダーや経営層から「いつ何が変わったのか」を聞かれた際に即答できます。

3-3. プロジェクト概要に含める要素

プロジェクト概要には、次の要素を簡潔に記載します。

• プロジェクトの背景（なぜこのプロジェクトを実施するのか）

• プロジェクトの目的（何を達成するのか）

• KPI・成功基準（定量的なゴール）

• スコープ（対象範囲、対象外範囲）

• 体制図（事業部・情シス・ベンダーの役割分担）

• 全体スケジュール（要件定義〜リリースまでの大枠）

特に「対象外範囲（スコープ外）」を明記することが重要です。
スコープ外を文書として残しておかないと、開発フェーズで「これも含まれていると思っていた」という認識違いが頻発します。

3-4. 前提条件・制約条件の書き方

前提条件・制約条件は、要件全体の解釈に影響する制約を明記する章です。

• 予算制約：投資上限、初期費用と運用費用の配分

• スケジュール制約：リリース希望日、関係する社内イベント（決算、繁忙期など）

• 技術制約：採用予定のプラットフォーム、既存システムとの整合性、社内ITポリシー

• 組織制約：プロジェクト参画可能な人数、外部支援の範囲

• 法規制・コンプライアンス：個人情報保護法、特定商取引法、景品表示法、業界ガイドライン

要件定義書の中盤を読んだベンダーから「なぜここまでの要件にしたのか」と聞かれたとき、この章で前提を示せていれば判断の背景を共有できます。

4. 業務要件の書き方とサンプル

業務要件は「誰が、何を、どのように行うのか」を整理する章です。
EC事業の業務フロー全体を視覚化し、後続の機能要件・データ要件の根拠になります。

4-1. 業務要件で書くべき要素

業務要件章で押さえるべき要素は次のとおりです。

• 業務一覧：対象とする業務の全体像（受注処理、出荷指示、在庫管理、返品処理、顧客対応など）

• 関係者・ロール：業務に関与する登場人物（顧客、EC運営者、CS、物流、経理、ベンダーなど）

• 業務フロー図：As-Is（現状）とTo-Be（構築後）のフロー

• 業務ルール：判定条件・例外処理（与信限度、ポイント計算、キャンセル可能条件など）

• 業務量・処理ボリューム：月間処理件数、ピーク時の集中度

このうち業務フロー図は、テキストだけで書こうとすると伝わりません。
BPMN（Business Process Model and Notation）やシンプルなフローチャート形式で、図として埋め込みます。

4-2. 業務フロー記述のサンプル

サンプルとして、EC受注処理の業務フロー記述例を示します。

業務名：通常受注処理

この粒度で業務フローを書いておくと、機能要件側で「どの機能がどの業務ステップを担うのか」が紐付きやすくなります。

4-3. 業務ルールの記述サンプル

業務ルール（ビジネスルール）は、システムが判定すべき条件を明文化する箇所です。

サンプル：会員ランク別のポイント還元率

サンプル：キャンセル可能条件

• 出荷指示前：顧客・運営の双方からキャンセル可能

• 出荷指示後、出荷前：運営判断でキャンセル可能、顧客からは不可

• 出荷後：返品処理に切り替え

業務ルールは要件定義書のなかで最も実装に近い記述になります。
ルールに抜けや矛盾があると、開発後半でテストデータを作成する段階で問題が露見し、手戻りが発生します。

4-4. 業務要件記述の落とし穴

業務要件章でよく見る落とし穴は次の3つです。

1. 現状フローのまま貼り付け：As-Isばかりが厚く、To-Beが書かれていない

2. 登場人物の役割が曖昧：「運営担当」とだけ書かれ、誰が何の権限を持つのか不明

3. 例外処理が抜けている：正常系だけで例外系（決済エラー、在庫切れ、不正注文）の記述がない

例外処理は、業務要件章の段階で網羅しておかないと、機能要件・テストケースの設計時に大きな抜けを生みます。

5. 機能要件の書き方とサンプル

機能要件は、システムが提供すべき機能の一覧と詳細を定義する章で、要件定義書のなかで最もボリュームが大きくなる部分です。

5-1. 機能要件で書くべき要素

機能要件章では次の要素を整理します。

• 機能一覧表：機能名、機能ID、優先度（必須／希望／任意）、概要

• 機能詳細：機能ごとの入力／処理／出力、画面遷移、例外処理

• 画面遷移図：主要フローの画面遷移を図示

• 権限・ロール定義：誰がどの機能を使えるかの一覧

機能要件はベンダーが見積もりを出す際の最重要参照箇所です。粒度がバラつくと見積もりが安定しません。

5-2. 機能一覧表のサンプル

機能一覧は、機能IDで採番し、優先度を付けて整理します。

優先度は実装スコープを決めるうえで重要な情報です。
「必須」「希望」「任意」の3段階くらいに絞り、定義もテンプレ冒頭で明記しておきます。

5-3. 機能詳細の記述サンプル

機能詳細は、機能一覧の各機能を1ページ程度で展開します。サンプルを示します。

FR-001：商品登録

• 目的：商品情報をECサイトに掲載するための登録機能

• 入力項目：商品コード、商品名、カテゴリ、価格、税区分、在庫数、画像、商品説明、SEO情報

• 処理：必須項目チェック、重複コードチェック、画像リサイズ、データベース登録、検索インデックス更新

• 出力：登録完了画面（商品ID表示）、エラー時はエラー一覧

• 権限：商品管理権限を持つユーザーのみ実行可

• 例外処理：必須項目不備、画像形式エラー、容量超過、重複コード時のエラー処理

FR-005：注文一覧表示

• 目的：管理画面で受注状況を確認する機能

• 入力項目：検索条件（期間、ステータス、商品、顧客、決済方法）

• 処理：条件に該当する注文の抽出、ソート、ページング

• 出力：注文一覧、件数表示、CSV出力

• 権限：受注管理権限を持つユーザー

• 例外処理：検索結果0件時の表示、抽出件数上限超過時の警告

この粒度で全機能を網羅すると、機能要件章だけで30〜80ページに達することが多いです。

5-4. 画面遷移図と画面要件への接続

機能要件章では、主要業務フローの画面遷移図を図として埋め込みます。
受注、会員登録、商品検索など、複数画面をまたぐフローは特に重要です。

画面ごとの詳細は7章「画面要件・UI要件」で別途展開し、機能要件章では「どんな順番で画面が遷移するか」「どの画面でどの機能が呼び出されるか」を中心に解説します。

5-5. 機能要件記述の落とし穴

機能要件章でよく見る落とし穴は次のとおりです。

1. 粒度がバラつく：同じ章の中に1行で済む機能と数ページの機能が混在

2. 優先度の定義が曖昧：「必須」「希望」の境界が定まらず、ベンダーが判断に迷う

3. 画面と機能の対応が不明：機能一覧と画面一覧が紐付かず、実装範囲が読み取れない

4. 権限定義が後付け：機能ごとの権限が章末にまとめられ、機能要件と一貫性が取れない

特に1の粒度問題は、複数人で書いた要件定義書で頻発します。テンプレ冒頭で「機能詳細は1機能あたり1ページを目安」のような目安を共有しておくと一定の均質化が図れます。

---

【要件定義書テンプレ・チェックリストの無料提供】 EC構築・リプレイスに使える要件定義書テンプレートとレビューチェックリストを、無料でお渡ししています。社内テンプレ整備の叩き台、ベンダー提示前の最終チェックにご活用ください。
 [無料で相談する]　[資料をダウンロード]

---

6. 非機能要件の書き方とサンプル

非機能要件は、性能・可用性・セキュリティ・運用などシステムが満たすべき条件を定義する章です。

6-1. 非機能要件の6カテゴリ

非機能要件の整理にあたっては、IPA『非機能要求グレード』の6カテゴリが実務上の標準として参照されることが多いです（出典：IPA『非機能要求グレード 2018』）。

ECサイトでは特に「可用性」「性能・拡張性」「セキュリティ」の3カテゴリが事業継続性に直結します。

6-2. 性能要件の記述サンプル

性能要件は数値で記述するのが原則です。サンプルを示します。

数値の根拠（過去実績、想定成長率、ピーク時集中度）も併記すると、ベンダーが性能設計の妥当性を判断しやすくなります。

なお、Googleの調査によると、モバイルページの表示速度が1秒から3秒に遅れるだけでユーザーの直帰確率は32%上昇し、3秒以上かかると53%の訪問者が離脱すると報告されています。
性能要件の閾値設定は、こうした業界知見も踏まえて決めるとよいでしょう。

6-3. 可用性要件の記述サンプル

可用性は稼働率と計画停止時間で表現します。

稼働率の数値は、提示する数字によってインフラ構成・冗長化要件・運用体制が大きく変わります。事業上どこまで必要か（99.5%／99.9%／99.99%）を経営側と合意しておきます。

6-4. セキュリティ要件の記述サンプル

セキュリティ要件は、ECサイトでは特に厚く書く章です。

• 認証：管理画面アクセスはIP制限＋多要素認証

• 暗号化通信：全ページHTTPS、TLS1.2以上

• 個人情報：氏名・住所・電話番号は暗号化保存

• 決済情報：自社で保持しない（決済代行に集約）

• アクセスログ：管理操作ログを2年以上保管

• 脆弱性診断：年1回以上の外部診断、CVSS7.0以上の脆弱性は速やかに対応

• WAF（Web Application Firewall）：常時稼働

• PCI DSS準拠：決済代行経由のため、SAQ Aレベルの対応

決済情報の保持有無は、PCI DSSの対応範囲を大きく左右します。
EC事業者の多くは決済情報を自社で保持しない構成（決済代行への集約）を選択しますが、この前提を明文化しておく必要があります。

6-5. 運用要件の記述サンプル

運用要件は、リリース後の運用業務をどう設計するかの定義です。

運用要件が薄いと、リリース後に「監視範囲が分からない」「障害発生時の責任分担が曖昧」といった問題が表面化します。
最低限、監視範囲・障害対応SLA・バックアップ方針は明文化しておきます。

7. 画面要件・UI要件の書き方

画面要件は、デザイン・UIに関する要件をまとめる章です。
デザインの仕上げはベンダー側のクリエイティブ業務になりますが、要件として最低限定義しておくべき項目があります。

7-1. 画面要件で書くべき要素

画面要件章では次の要素を解説します。

• 画面一覧：トップ、商品一覧、商品詳細、カート、決済、マイページなど

• 画面ごとの主要要素：表示項目、操作項目、画面遷移先

• ワイヤーフレーム：主要画面のレイアウトを図示

• デザイン方針：トーン、ブランドガイドライン、参考サイト

• レスポンシブ要件：PC／タブレット／スマートフォン対応の範囲

• アクセシビリティ要件：JIS X 8341-3準拠など、必要な基準

7-2. 画面一覧のサンプル

画面一覧は、画面IDで採番して整理します。

画面IDを使って機能要件と画面要件の対応を明示すると、見積もり時の確認漏れが減ります。

7-3. ワイヤーフレームの粒度

要件定義書段階のワイヤーフレームは、デザイン詳細ではなく「レイアウトと配置要素」レベルで十分です。

• 主要画面（トップ、商品詳細、カート、決済、マイページ）はワイヤーで定義

• それ以外の画面は要素一覧で代替可能

• ワイヤーは別ファイル（PDF、PPT、Figma）として参照を付ける

要件定義書本文にすべての画面イメージを埋め込むと、文書の見通しが悪化します。主要画面のみ本文に、それ以外は付録もしくは別ファイル参照とするのが現実的です。

7-4. レスポンシブ要件・アクセシビリティ要件

レスポンシブ要件は、対応デバイスとブレークポイントを明示します。

• PC：1280px以上

• タブレット：768〜1279px

• スマートフォン：767px以下

総務省『令和5年通信利用動向調査』では、スマートフォンからのインターネット利用率はパソコンを上回り、ECにおいてもモバイル経由のセッションが過半を占める事業者が多くなっています。
スマートフォン体験の優先度を要件として明文化しておきます。

アクセシビリティについては、JIS X 8341-3（高齢者・障害者等配慮設計指針）への準拠レベル（A／AA／AAA）を必要に応じて指定します。

8. データ要件・外部連携要件の書き方

データ要件と外部連携要件は、EC事業の業務継続性に直結する章です。
データ移行の漏れや連携の認識違いは、リリース直後に大きな事故に発展しやすい部分です。

8-1. データ要件で書くべき要素

データ要件章では次の要素を整理します。

• データ移行範囲：既存システムから新ECへ移行するデータの一覧

• データ構造：主要エンティティ（商品、顧客、注文、ポイント、在庫など）

• データ保持期間：エンティティごとの保持期間、削除ポリシー

• データクレンジング：移行前のデータ整理範囲

データ移行範囲のサンプル

移行件数の見立ては、ベンダーの移行スクリプト設計・移行リハーサルの工数見積もりに直結します。可能な限り早い段階で把握しておきます。

8-2. 外部連携要件で書くべき要素

外部連携要件章では、ECサイトと連携する外部システムを整理します。

連携要件では、特に「連携方式」「連携頻度」「データ項目」「エラー時の処理」を明示することが重要です。

8-3. 連携データ項目の粒度

主要連携については、データ項目レベルでの整理を要件定義書に含めます。

サンプル：基幹システム ⇔ EC 商品同期データ項目

この粒度まで要件定義書段階で詰めるのが理想ですが、実務的にはベンダー選定後の設計フェーズで詰めるケースも多いです。プロジェクトの規模・期間に応じて、要件定義書段階か設計フェーズかを判断します。

9. 運用要件・保守要件の書き方

運用要件・保守要件は、リリース後にプロジェクトを安定運用するための章で、リリース後に「想定外」を減らすための重要なパートです。

9-1. 運用要件の主要項目

運用要件章では次の項目を整理します。

• 運用体制：事業部・情シス・ベンダーの役割分担

• 運用業務一覧：商品登録、受注管理、顧客対応、キャンペーン設定など

• 運用時間・SLA：対応時間帯、応答時間、復旧時間

• 障害対応フロー：監視・検知から復旧・報告までのフロー

• 変更管理プロセス：機能追加・改修依頼の受付・優先順位付け・実施フロー

• 定例運営：月次・四半期のレビュー会議、改善提案

運用体制と役割分担のサンプル

役割分担を明文化しておかないと、リリース後に「障害対応はベンダー任せだと思っていた」「機能改修依頼の窓口が分からない」といった問題が起きやすくなります。

9-2. 保守要件の主要項目

保守要件章では、リリース後の機能改修・追加開発をどう運用するかを整理します。

• 保守契約の範囲：定額保守の対象範囲、追加開発の単価・スピード

• 改修要望の受付フロー：要望提出から実施判断・実装・リリースまでのフロー

• 緊急改修対応：障害起因の緊急修正の対応時間・体制

• バージョンアップ対応：プラットフォームのバージョンアップ時の対応範囲

• 法改正対応：個人情報保護法、消費税、特商法等の法改正への追従

特にバージョンアップ対応は、Shopify等のSaaS型プラットフォームを採用する場合に重要な論点です。プラットフォーム側のアップデートは自動的に降ってきますが、自社カスタマイズ部分の追従はベンダー保守側の責任範囲になります。

9-3. 受け入れテスト要件

リリース前の受け入れテストについても、要件定義書段階で方針を整理しておきます。

• テスト方針：機能網羅、シナリオ、性能、セキュリティ、ユーザビリティ

• 受け入れ基準：機能要件のすべてが動作、性能要件を満たす、致命的バグ0件

• テスト体制：事業部・情シス・ベンダーの役割

• テスト期間：受け入れテスト期間、不具合修正期間

• 不具合の対応優先度：致命・重大・中・軽の定義

受け入れテスト要件が薄いと、リリース直前に「合格条件が定まっていない」という事態に陥ります。
事業部・情シス・ベンダーの三者で、要件定義段階で基準を合意しておきます。

10. Shopify構築時に押さえたい要件定義書の追加項目

ECプラットフォームとしてShopifyを採用する場合、要件定義書に追加で押さえておくべき項目があります。
SaaS型ならではの構造を理解したうえで、要件の粒度を調整することがポイントです。

10-1. Shopify構築の要件定義書で特に重要な項目

Shopifyを採用するプロジェクトでは、次の項目を要件定義書に追加します。

• Shopifyプラン：Basic、Shopify、Advanced、Plusのいずれを採用するか

• テーマ採用方針：標準テーマ（Dawn等）、有料テーマ、フルカスタムテーマのいずれか

• Apps（アプリ）の採用一覧：必須機能を実現するアプリの選定と要件

• カスタマイズ範囲：Liquid、JavaScript、Hydrogenによるカスタマイズ範囲

• API利用範囲：Admin API、Storefront APIの利用範囲

• Shopify Functions の利用：チェックアウトカスタマイズの範囲

• Shopify Flow の利用：自動化ワークフローの範囲

• 多言語・多通貨：Shopify Markets での対応範囲

• ヘッドレス構成の検討：Hydrogen + Oxygen 等のヘッドレス採用判断

SaaS型のため、フルスクラッチに比べてカスタマイズ範囲は構造的に限定されます。逆に、標準機能・Apps・APIを組み合わせる発想で要件を整理することで、開発工数と運用コストを大幅に圧縮できる点が魅力です。

10-2. Apps採用に関する要件記述のサンプル

Shopify構築では、機能の多くをAppsで実現するため、Apps選定の要件も明文化します。

Appsは複数組み合わせると月額コストが積み上がるため、必要なAppsの月額合計を運用コスト試算に組み込んでおくことが重要です。

10-3. Shopify Plus 採用時の追加項目

中堅〜大手ECでShopify Plusを採用する場合、次の項目も要件定義書に追加します。

• マルチストア構成：ストア分割の単位（地域別、ブランド別、B2B別）

• Wholesale機能：B2B（卸売）チャネルの要件

• Shopify Functions のチェックアウトカスタマイズ：割引・配送・支払い方法の制御

• POS連携：実店舗連携の範囲

• 専任サポート（Merchant Success Manager）：活用範囲

Shopify Plusの価格や個別契約条件は公開されていないため、要件定義書段階では「ご相談ベースでの確認」として記載しておきます。

10-4. SaaS型プラットフォームを採用する際の要件記述の考え方

Shopifyに限らず、SaaS型プラットフォームを採用する要件定義書では、フルスクラッチ前提の書き方を引きずらないことが重要です。

• 「標準機能で実現できる範囲」を最初に整理する

• 標準で実現できない部分のみカスタマイズ要件として書く

• 「将来的に標準機能で対応されそうな要件」は実装を一旦見送る選択肢を持つ

• プラットフォーム側のロードマップを定期的に確認する前提を運用要件に含める

この発想を持たずにフルスクラッチ用の要件定義書をそのままSaaS型に当てはめると、不必要なカスタマイズが積み上がり、SaaS採用のメリットが薄れてしまいます。

11. 要件定義書でよくある書き方の落とし穴

要件定義書の作成現場で繰り返し起きる失敗パターンを整理します。レビュー時のチェック観点としても使えます。

11-1. 抽象的すぎる要件記述

「使いやすい管理画面」「分かりやすい商品一覧」「快適な検索体験」のような抽象表現は要件として機能しません。

抽象的な要件は、ベンダーが解釈に迷い、結果として実装後に「想定と違う」が発生します。要件は次のように具体化します。

11-2. 業務要件抜きの機能要件

業務要件章を省略し、機能要件章だけが充実している要件定義書もよく見かけます。

業務要件がないと、機能要件は「実装側の都合」で書かれた要件になりやすく、現場業務との整合性が取れません。
業務上、誰が何のために使う機能なのかを業務要件で押さえてから機能要件に入る順番が、品質を担保する基本です。

11-3. 非機能要件が一行で済まされている

非機能要件が「セキュリティ：適切に対応する」「性能：問題ないこと」のような一行で済まされているケースもあります。

非機能要件はインフラ構成・運用体制・コストを大きく左右するため、数値で記述するのが原則です。性能・可用性・セキュリティは閾値や基準値を明示します。

11-4. 例外処理・データ量前提が抜けている

正常系のフローばかりが書かれ、例外処理（決済エラー、在庫切れ、配送不可、不正注文、システム障害時の挙動など）が抜けている要件定義書は多いです。
EC事業のオペレーションでは、例外処理がカスタマー体験と運用負荷に直結します。

合わせて、想定データ量・トランザクション量（月間PV、月間注文件数、ピーク時集中度、商品点数、会員数、注文履歴総量）の前提も抜けがちなポイントです。
前提がないとベンダーは概算で見積もらざるを得ず、リリース後に性能問題が表面化します。

11-5. 連携要件の認識違いとスコープ外の明記漏れ

外部連携要件では、連携方式（API／CSV、リアルタイム／日次バッチ）、データ項目（必須・任意・型・桁数）、エラー処理（リトライ、通知、手動補正）の3点で認識違いが頻発します。
連携先システムの担当者をレビューに巻き込み、合意形成しておきます。

また「対象範囲（スコープ）」は書かれているのに「スコープ外」が書かれていない要件定義書も多くあります。
取り扱わない商材、連携しない既存システム、対応しないデバイス・ブラウザ、別フェーズに送る機能などは、理由とセットでスコープ外として明文化しておきます。

12. レビューチェックリストと承認プロセス

要件定義書を仕上げる最終段階では、レビューチェックリストに沿った確認と、承認プロセスの整備が重要です。

12-1. レビューチェックリスト

要件定義書を提出する前のセルフチェックとして、次の観点で確認します。

12-2. 承認プロセスの設計

要件定義書の承認プロセスは、ステークホルダーの数が多いプロジェクトほど重要になります。

承認後の要件変更は「変更管理プロセス」を経るルールにしておかないと、開発フェーズで要件が崩れます。

12-3. 要件凍結のタイミング

要件定義書を「凍結（ベースライン化）」するタイミングは、設計フェーズ入りの直前です。

• 凍結前：要件のすり合わせ、修正、追加が自由にできる期間

• 凍結後：原則として要件追加・変更は変更管理プロセスを経る

凍結タイミングを明示しないと、開発が始まっても要件が動き続け、スコープクリープ（要件膨張）が起きます。

凍結のタイミング・基準・変更管理ルールも、要件定義書または別途プロジェクト計画書に明記しておきます。

まとめ

EC要件定義書は、ECサイト構築・リプレイスの設計図です。
章立てを標準化し、業務要件・機能要件・非機能要件を体系的に整理することで、後工程の品質と効率が大きく変わります。

EC要件定義書を仕上げる7つのポイント

1. 要件定義書・仕様書・RFPの違いを整理し、WhatとHowを書き分ける

2. 業務要件を先に固めてから機能要件に入る

3. 非機能要件は性能・可用性・セキュリティを数値で記述する

4. 画面要件と機能要件を画面IDで紐付ける

5. データ要件・連携要件は方式・頻度・項目の3点をセットで明示する

6. SaaS型プラットフォーム採用時は「標準機能ベース」で要件を整理する

7. スコープ外と凍結タイミングを明文化する

最初の一歩を踏み出そう

完璧な要件定義書をいきなり書き起こすのは難しく、社内テンプレートが整っていない段階では尚更です。
まずは標準的な章立てに沿って骨子を作り、業務要件・機能要件の主要項目から書き起こしていく進め方が現実的です。

ベンダー提示前のレビュー、社内テンプレ整備、Shopify構築時の要件粒度の調整など、要件定義書まわりでお困りの点があれば、いつでもご相談ください。

---

【無料相談】EC要件定義書のレビュー・テンプレ整備をご支援します EC構築・リプレイスの要件定義書について、ベンダー提示前のレビュー、社内テンプレートの整備、Shopify採用時の要件粒度の調整など、Shopifyの専門家が無料でご相談に乗ります。
 [無料で相談する]　[資料をダウンロード]

---

参考文献

1. 経済産業省『令和5年度 電子商取引に関する市場調査』2024年

2. IPA（情報処理推進機構）『非機能要求グレード 2018』

3. Google『The Need for Mobile Speed』2018年

4. 総務省『令和5年通信利用動向調査』2024年

5. 経済産業省『DXレポート』各年版