Shopify制作の見積もりを3社から取ったら、金額が3倍違った——この現象の原因は、制作会社の良し悪しではありません。発注側が「何を作るか」を確定させないまま見積もりを依頼したため、各社が別々の前提で計算しただけです。要件定義書は、この前提を揃えるための唯一の道具です。本記事では、Shopify制作の要件定義書に必ず入れるべき12項目、見積もりが跳ね上がる5つの分岐点、そしてそのまま使えるテンプレート構成を、発注側の視点で解説します。
Shopify制作の要件定義書とは何か
この定義の核心は最後の一文にあります。要件定義書の価値は、書いてあることよりも「書いていないこと＝まだ決まっていないこと」が明示される点にあります。決まっていない項目が10個あると分かっていれば、見積もりに幅を持たせられます。決まっていないことに気づかないまま発注すると、その10個は制作の途中で一つずつ表面化し、そのたびに追加費用と納期遅延を生みます。
要件定義書・RFP・仕様書の違い
この3つは混同されがちですが、目的も作成者も異なります。
| 文書 | 誰が作るか | 目的 | 作るタイミング |
|---|---|---|---|
| RFP（提案依頼書） | 発注側 | 複数社に同条件で提案・見積もりを依頼する。課題と目的が中心で、解決手段は各社に委ねる。 | 制作会社を選ぶ前 |
| 要件定義書 | 発注側と制作会社が共同 | 実現する内容と範囲を確定させ、双方の認識を一致させる。契約の実質的な土台。 | 制作会社決定後、着手前 |
| 仕様書（設計書） | 制作会社 | 要件を技術的にどう実装するかを記述する。開発者向けの文書。 | 要件定義の後、実装前 |
実務上、中小規模のEC事業者がRFPを完璧に作るのは負担が大きすぎます。現実的には、本記事で示㡙12項目を埋めた簡易版の要件定義書を作り、それを持って複数社に相談するのが最も費用対効果の高いやり方です。それだけで見積もりのブレは大幅に縮小します。
用語解説
| 用語 | 意味 |
|---|---|
| スコープ | 今回の制作でやると決めた作業の範囲。スコープ外を明記しないと、際限なく作業が膨らむ（スコープクリープ）。 |
| 受入基準 | 「これが満たされていれば完成」と発注側が判断する条件。これがないと検収が終わらない。 |
| 非機能要件 | 機能そのものではない品質条件。表示速度、対応ブラウザ、同時アクセス数、セキュリティなど。見落とされやすい。 |
| テーマ | Shopifyのデザインテンプレート。無料・有料・オリジナル制作の3択があり、この選択が費用構造を決定づける。 |
| アプリ | Shopifyの機能拡張プログラム。多くは月額課金で、導入数がランニングコストに直結する。 |
| メタフィールド | Shopify標準項目にない独自データを持たせる拡張領域。商品情報が複雑な事業者には必須の検討項目。 |
| Shopify Plus | 大規模事業者向けの上位プラン。チェックアウト画面のカスタマイズなど、通常プランでは不可能な要件が実現できる。 |
なぜEC制作で要件定義が抜け落ちるのか
「要件定義が大事」は誰もが知っています。それでも省略される。ここには構造的な理由があります。
理由①：要件定義に費用を払う文化がない
「まだ何も作っていないのに費用が発生するのか」という心理が働きます。結果、制作会社は要件定義を無料のヒアリングとして圧縮せざるを得ず、精度の低い前提のまま見積もりが出ることになります。
理由②：発注側が要件を言語化できない
「今のサイトの不満」は語れても「実現したい状態」は語りにくいものです。ここを制作会社任せにすると、制作会社の得意分野に引きずられた要件が出来上がります。
理由③：早く公開したいという圧力
「来月のセールに間に合わせたい」という時間的制約が、最初に削られる工程を要件定義にします。しかしここを削った分は、後工程で21〜3倍の時間になって返ってきます。
理由④：見積もり合戦の構造
相見積もりでは、要件を丁寧に詰めて正直な金額を出した会社ほど高く見え、前提を曖昧にしたまま安い金額を出した会社が選ばれやすい。この逆選択が業界全体の要件定義の質を下げています。
つまり、要件定義が抜けるのは誰かの怠慢ではなく、発注構造そのものが要件定義を省略させる方向に働いているということです。だからこそ、発注側が意図的に要件定義書を用意することが、そのまま競争優位になります。
Shopify制作の要件定義書に必ず入れる12項目
以下の12項目を埋めるだけで、見積もりの精度は劇的に上がります。順番にも意味があります。上から順に、事業目的 → 制約 → 具体仕様 の流れです。
- 事業目的とKGI／KPI「なぜ作るのか」を数値で書きます。「月商◯円」「CVR◯%」「リピート率◯%」など。ここが曖昧だと、以降のすべての判断基準が失われます。デザインの好き嫌いで揉めるプロジェクトは、例外なくこの項目が空欄です。
- ターゲットと購買シナリオ誰が、どういう経路で訪れ、何を見て、どう迷い、何で決めるのか。ペルソナの年齢や職業よりも、「購入までの意思決定プロセス」を書くほうが実務では役立ちます。
- 取扱商品の構造商品点数、バリエーションの軸数（色・サイズ・容量など）と各軸の選択肢数、セット商品の有無、定期購入の有無。この項目が費用に最も直結します。「Tシャツ50型 × 色5 × サイズ4 = 1,000SKU」のように計算式で書いてください。
- サイト構成（サイトマップ）必要なページを階層で列挙します。トップ、商品一覧、商品詳細、カート、会員マイページ、特集ページ、ブログ、会社案内、FAQ、特商法表記など。ページ数は見積もりの基本単位です。
- 必要な機能一覧と優先度機能を列挙し、それぞれに「必須／あると良い／今回は対象外」の3段階を付けます。この優先度付けこそが要件定義の実体です。全部「必須」と書く要件定義書は、要件定義をしていないのと同じです。
- デザイン方針とテーマ選択既存テーマをそのまま使うのか、カスタマイズするのか、オリジナル制作するのか。参考サイトを3つ挙げ、それぞれ「どこが良いのか」を言語化します。「おしゃれな感じ」は要件ではありません。
- 決済・配送・税の要件使用する決済手段、送料の計算ルール（地域別、重量別、金額別、クール便）、配送日時指定、ギフト対応、軽減税率、海外発送と多通貨の有無。送料計算ルールは、想像以上に複雑になりやすい要注意項目です。
- 外部システム連携在庫管理、受注管理、会計、CRM、MA、POS、3PL倉庫。それぞれ「連携方向（どちらからどちらへ）」「頻度（リアルタイム／1日1回）」「対象データ」の3点を書きます。ここが曖昧だと、後で最大級の追加費用が発生します。
- データ移行の範囲既存サイトがある場合、何を移すのか。商品、顧客、注文、レビュー、ブログ記事。移行元のデータ形式とレコード件数も明記します。
- 非機能要件対応ブラウザとバージョン、スマートフォン対応の基準、表示速度の目標、セール時の同時アクセス想定、アクセシビリティ、セキュリティ要件。忘れられやすいが、後から追加すると最も高くつく領域です。
- 公開後の運用体制と保守範囲誰が商品を登録し、誰がページを更新し、誰が障害に対応するのか。保守契約に含まれる範囲と含まれない範囲、対応時間帯、緊急時の連絡フロー。ここを決めずに公開すると、公開翻日から揉めます。
- スケジュールと受入基準公開希望日から逆算したマイルストーンと、各段階での確認者・確認内容。そして「何をもって完成とするか」の受入基準。これがないと検収がいつまでも終わりません。
⚠️ 最も忘れられ、最も高くつく3項目
実務上、後から発覚して追加費用と揉め事の原因になるのは、圧倒的に⑦送料計算ルール、⑧外部システム連携、⑩非機能要件の3つです。この3つは目に見えないため、デザインや商品ページの議論に埋もれて最後まで放置されがちです。
逆に言えば、初回の打ち合わせでこの3つを具体的に質問してくる制作会社は、実務経験が豊富だと判断できます。デザインの話から入り、この3つに触れないまま見積もりを出す会社は、後から必ず追加が発生します。
見積もりが3倍変わる5つの分岐点
同じ「Shopify制作」でも、次の5つの分岐によって金額は数倍変わります。相見積もりを比較する前に、自社がどちら側なのかを確定させてください。
| 分岐点 | 低コスト側 | 高コスト側 | なぜ差が出るのか |
|---|---|---|---|
| ① テーマ | 既存テーマをそのまま利用、設定変更のみ | オリジナルデザインをフルスクラッチ実装 | 実装工数が数倍。加えて将来のShopifyアップデート追従コストも変わる。 |
| ② 商品構造 | バリエーション2軸以内、商品数が数十点 | 3軸超、セット商品、数千SKU | Shopifyのオプション上限を超えると構造の作り替えが必要。データ整形工数も点数に比例。 |
| ③ 定期購入 | なし（都度購入のみ） | あり（頻度変更・スキップ・同梱対応） | アプリ選定、決済設計、会員マイページ改修、既存顧客の移行対応がすべて追加になる。 |
| ④ 外部連携 | なし、または既製アプリで完結 | 基幹システムとAPIでリアルタイム連携 | 個別開発が発生し、相手側システムの仕様調査・テスト工数が読みにくい。最も見積もりが割れる項目。 |
| ⑤ 移行データ | 新規構築、または整形済みCSVあり | データが未整備（表記ゆれ・画像欠損・HTML崩れ） | データクレンジングは手作業になりやすく、点数×項目数で工数が膨らむ。事前に見えにくい。 |
この表を持って制作会社に「うちは①が低コスト側、③が高コスト側です」と伝えられれば、見積もりの精度は格段に上がります。逆に、この5つが不明なまま出てきた見積もりは、金額ではなく「その会社が置いた前提」を比較しているだけです。
そのまま使える要件定義書のテンプレート構成
実際の文書構成です。A4で10〜20ページ、初回は各項目3行ずつでも構いません。完璧さより、空欄が可視化されることに価値があります。
📄 Shopify制作 要件定義書｜目次構成
- プロジェクト概要／背景、事業目的、KGI・KPI、公開希望日、想定予算レンジ
- 体制と役割分担／発注側の決裁者・実務担当者・確認者、制作側の窓口、連絡手段と定例頻度
- ターゲットと購買シナリオ／主要顧客像、流入経路、意思決定プロセス、離脱しやすい箇所
- 商品情報の構造／商品点数、バリエーション軸と選択肢数、SKU総数、セット商品、定期購入の有無
- サイトマップ／必要ページの階層一覧、各ページの目的とテンプレート種別
- 機能要件一覧／機能名／目的／優先度（必須・希望・対象外）／実現手段（標準機能・アプリ・個別開発）の4列表
- デザイン要件／方針、テーマ選択、参考サイト3件と評価理由、ブランドカラー・フォント指定、禁止事項
- 決済・配送・税／決済手段、送料ルールの計算表、配送オプション、税区分、海外対応
- 外部システム連携／システム名／連携方向／頻度／対象データ／連携方式（API・CSV・手動）の5列表
- データ移行／移行対象、移行元と件数、移行しないもの、データ整備の責任範囲
- 非機能要件／対応ブラウザ、表示速度目標、同時アクセス想定、セキュリティ、アクセシビリティ
- 運用・保守／公開後の更新担当、保守範囲と対象外、対応時間、障害時フロー、月額費用
- スケジュール／マイルストーン、各段階の成果物と確認者、確認にかける営業日数
- 受入基準／完成と判断する条件、検収方法、検収期間
- スコープ外の明記／今回やらないことの列挙（最重要）
- 未決事項リスト／現時点で決まっていない項目と、いつまでに誰が決めるか
⚠️ 15章「スコープ外の明記」と16章「未決事項リスト」を必ず入れてください
この2章がある要件定義書と、ない要件定義書では、プロジェクトの揉め率がまったく違います。「やること」を書くのは誰でもできます。「やらないこと」と「まだ決まっていないこと」を明文化できるかが、要件定義書の質そのものです。
特に16章は、着手時点では空欄が10個あって構いません。重要なのは「決まっていないという事実が、双方に見えている」ことです。見えていれば、それは管理できるリスクになります。見えていなければ、それは事故になります。
【独自視点】要件定義書は「作る指示書」ではなく「決めたことの記録」である
ここが、多くの発注者が誤解している最大のポイントです。
要件定義書を「制作会社に渡す指示書」だと捉えると、発注側は「できるだけ詳しく、できるだけ多く書かなければ」というプレッシャーを感じます。そして書ききれずに挫折し、結局「いい感じにお願いします」になります。これが要件定義が形骸化する典型的な経路です。
発想を逆転させる
私たちは、要件定義書を「意思決定のログ」として位置づけ直すことを提案しています。指示書ではなく、記録です。
指示書として捉えると
「網羅しなければ」という圧力が生まれ、完成しない。書けない項目は放置され、曖昧なまま着手される。結果、制作の途中で発注側が判断を迫られ続ける。
意思決定のログとして捉えると
「今日決まったことを書き足す」だけでよい。空欄は「まだ決めていない」という有効な情報になる。結果、決めるべきことのリストが可視化され、順番に潰せる。
この転換がもたらす実務上の効果は3つあります。
第一に、要件定義が着手前に完成する必要がなくなります。「決まったことから書く」なら、初回打ち合わせの直後から書き始められます。プロジェクトの進行と並行して要件定義書が育っていく形になり、着手前に完璧を目指して停滞することがなくなります。
第二に、判断の履歴が残ります。「なぜこの仕様にしたのか」が3か月後に分からなくなるのは、EC制作で最もよくある事故です。決定の理由を1行添えて記録しておくと、後の仕様変更の議論が驚くほど速く終わります。
第三に、担当者が変わっても引き継げます。これは特に、社内でECを担当する人が少ない中小事業者にとって決定的です。要件定義書が意思決定のログになっていれば、それはそのまま業務マニュアルの土台になります。
「ECは戦術ではなく設計で決まる」
ボトルシップが一貫して掲げている考え方です。要件定義書は、この「設計」を目に見える形にした唯一の成果物です。
どのアプリを入れるか、どのテーマを買うか、バナーをどう作るか——これらはすべて戦術です。戦術は変更できますし、失敗しても取り返せます。しかし「何を扱い、誰に、どういう順路で買ってもらい、誰がそれを運用するのか」という設計は、一度決めると後から変えるコストが桁違いに大きい。要件定義とは、この取り返しのつかない部分だけを、着手前に丁寧に決める作業のことです。
逆に言えば、要件定義書に書くべきは「取り返しがつかないこと」だけで十分です。ボタンの色は要件定義書に要りません。商品の構造、連携の方式、運用の担い手——この3つが書いてあれば、要件定義書は8割方その役目を果たしています。
関連する支援メニュー
- ECサイト構築支援｜要件定義から実装、公開後の改善までを一貫して担当します。
- ECコンサルティング｜発注前の要件整理、相見積もりの評価、社内合意形成を支援します。
- EC運用代行｜公開後の商品登録・受注対応・広告運用の実務を巻き取ります。
- 物流支援｜送料設計、在庫連携、3PL選定など物流側の要件を整理します。
要件定義書を持って制作会社に相談する手順
要件定義書ができたら、次は制作会社選定です。ここでも順序を間違えると、せっかくの要件定義書が活きません。実務上は次の4ステップで進めます。
3〜4社に絞り込み、同じ要件定義書を渡す
10社に声をかける必要はありません。比較検討の労力が分散し、かえって判断精度が下がります。重要なのは全社にまったく同じ資料を渡すこと。口頭で補足した内容が会社ごとに違うと、比較の前提が崩れます。補足事項が出たら、要件定義書に追記して全社に再送してください。
質問の内容と量で、実務経験を測る
要件定義書を渡した後に返ってくる質問は、その会社の実力を映す最良の指標です。送料の例外条件、在庫連携の頻度、公開後の更新担当者——こうした地味な部分を突いてくる会社は、実装後の運用まで想像できています。逆に「承知しました、では見積もりを出します」で終わる会社は、前提を自社に都合よく置いている可能性があります。
見積もりは総額ではなく内訳の構成で比較する
要件定義、デザイン、実装、データ移行、テスト、公開後の監視。この6区分がそれぞれ独立して計上されているかを確認します。「サイト制作一式」とだけ書かれた見積もりは、比較のしようがありません。内訳を出せない会社には、出してもらってください。断る理由がないはずの依頼です。
未決事項の扱いを契約前に合意する
要件定義書の16章に残った未決事項を、いつまでに誰が決め、決まらなかった場合はどうするのかを契約前に握ります。ここを曖昧にすると、未決事項がそのまま追加費用の温床になります。「未決事項が確定した時点で、影響範囲と費用を書面で再合意する」という一文を契約書に入れておくだけで、後の交渉が大幅に楽になります。
この4ステップで進めると、制作会社側から見ても「この発注者は要件が固まっている＝手戻りが少ない」と判断され、見積もりのリスクバッファが小さくなります。要件定義書を用意することは、発注側の理解のためだけでなく、実質的な値引き交渉としても機能するということです。
よくある誤解
誤解①「要件定義は制作会社が作るもの」
仕様書は制作会社が作りますが、要件定義は共同作業です。事業目的、商品構造、運用体制は発注側にしか分かりません。丸投げすると、制作会社の得意分野に最適化された要件が出来上がります。
誤解②「詳しく書くほど良い要件定義書」
分量ではなく優先度と範囲が明確かどうかです。100ページあっても全機能が「必須」と書かれていれば、それは要件定義をしていません。むしろ「対象外」の記述量が質を示します。
誤解③「決まってから書き始める」
逆です。書きながら決めるのが正しい順序です。空欄が「決めるべきこと」を教えてくれます。完璧に決まるのを待っていると、いつまでも着手できません。
誤解④「要件定義に費用を払うのは無駄」
要件定義に投じた費用は、実装フェーズの手戻り削減で回収されます。要件定義を省いたプロジェクトは、平均して総費用が膨らみます。安く見える見積もりの多くは、この工程が抜けています。
誤解⑤「一度決めたら変更できない」
変更は前提です。重要なのは変更を記録し、影響範囲と追加費用を合意すること。要件定義書がないと、変更が変更として認識されず、なし崩しに作業が増えます。
誤解⑥「Shopifyは簡単だから要件定義は不要」
立ち上げが簡単なのと、事業要件を満たすのは別問題です。むしろ自由度が高いぶん、決めるべきことは増えます。簡単さを理由に要件定義を省くと、アプリだらけで運用不能なサイトが出来上がります。
発注前チェックリスト
制作会社に見積もりを依頼する前に、次の項目に答えられるか確認してください。7つすべてに答えられれば、見積もりのブレはほぼなくなります。
- このサイトで達成したい数値目標を1つ挙げられるか「売上を上げたい」ではなく「月商をいくらにしたいか」「CVRを何%にしたいか」。
- SKU総数を計算式で説明できるか「型数 × 色 × サイズ = 総SKU数」。バリエーションの軸数が3を超えるかどうかは必ず確認。
- 必要な機能を「必須／希望／対象外」に仕分けられるか全部必須と答えるなら、まだ仕分けができていません。
- 外部システムとの連携の有無と方式を説明できるか在庫・受注・会計・倉庫。連携方向と頻度まで言えるか。
- 送料の計算ルールを表で書けるか地域別、重量別、金額別、クール便、離島。例外条件も含めて。
- 公開後、誰が何を更新するのか決まっているか商品登録、ページ更新、受注対応、障害連絡。担当者名まで。
- 「今回やらないこと」を3つ挙げられるかこれが一番重要です。挙げられないなら、スコープが定義できていません。
よくある質問（FAQ）
Q1. 要件定義書は何ページくらいが適切ですか？
ページ数に正解はありませんが、中小規模のEC事業者ならA4で10〜20ページが実務的な目安です。重要なのは分量ではなく、本記事の12項目それぞれに「決まっていること」か「未決である」ことが書かれているかどうかです。初回は各項目3行ずつでも構いません。空欄が可視化されることに価値があります。
Q2. 要件定義だけを制作会社に依頼することはできますか？
可能です。要件定義フェーズを独立した契約として切り出す進め方は実務上よくあります。この方式の利点は、要件定義の成果物を持って複数社に同条件で見積もりを依頼できる点です。要件定義を担当した会社にそのまま実装を依頼する義務はありません。ただし、要件定義を無料で行う会社は実装契約を前提としている場合が多いため、成果物の権利がどちらに帰属するかは事前に確認してください。
Q3. 途中で要件を変更したくなったらどうすればいいですか？
変更自体は問題ありません。重要なのは、変更を口頭で伝えて終わりにせず、変更内容・影響を受ける他の要件・追加費用・納期への影響の4点を書面で合意することです。この手順を最初に決めておくと、変更のたびに交渉が発生する事態を避けられます。要件定義書に「変更管理の手順」の章を設けておくのが理想的です。
Q4. 相見積もりの金額差はどう評価すればいいですか？
金額の総額ではなく、内訳の項目構成を比較してください。要件定義、データ移行、リダイレクト設計、公開後の監視といった工程が独立項目として計上されているかを見ます。これらが計上されていない見積もりは安く見えますが、その工程を行わないか、後から追加請求されるかのどちらかです。同じ要件定義書を全社に渡した上で、なお金額が2倍以上開く場合は、各社にその理由を直接質問するのが最も確実です。
Q5. 社内にEC担当者が1人しかいません。それでも要件定義できますか？
できますが、優先順位を絞る必要があります。1人体制なら、本記事の12項目のうち③商品構造、⑧外部システム連携、⑪運用体制の3つに集中してください。この3つは発注側にしか分からず、後から変更するコストが最も高い項目です。デザインや細かな機能は制作会社の提案をベースに調整できますが、この3つを曖昧にしたまま進めると、公開後に運用が破綻します。
まとめ
この記事の要点
- 要件定義書とは、「何を実現するか」「どこまでが範囲か」「何をもって完成とするか」を発注側と制作会社が同じ解釈で読める状態にした合意文書である。本質は決めたことと決めていないことを区別する文書。
- RFP・要件定義書・仕様書は別物。中小EC事業者は、12項目を埋めた簡易版の要件定義書を持って複数社に相談するのが最も費用対効果が高い。
- 必ず入れる12項目のうち、後から最も高くつくのは⑦送料計算ルール、⑧外部システム連携、⑩非機能要件の3つ。この3つを初回に質問してくる制作会社は経験が豊富。
- 見積もりが数倍変わる分岐点は5つ——テーマ、商品構造、定期購入、外部連携、移行データの整備状況。自社がどちら側かを確定させてから相見積もりを取る。
- 「スコープ外の明記」と「未決事項リスト」が要件定義書の質を決める。やらないことと、まだ決まっていないことを書けているかがすべて。
- 要件定義書は指示書ではなく意思決定のログ。書きながら決める。空欄は「決めるべきこと」を教えてくれる有効な情報。
- 書くべきは取り返しのつかないことだけ。商品の構造、連携の方式、運用の担い手——この3つが書けていれば8割は達成できている。
100文字要約：Shopify制作の要件定義書とは、実現内容・範囲・完成条件を発注側と制作会社が同じ解釈で読める合意文書。12項目を埋め、スコープ外と未決事項を明記することで見積もりのブレと手戻りが激減する。
