EC改修の見積もりが比較できないときの要件定義｜変更依頼票・影響範囲・受入基準を1枚にする

EC改修の見積もりを比較できない原因は、制作会社やカートベンダーの単価差だけとは限りません。依頼側が「商品詳細のボタンを直したい」と伝え、依頼先ごとに「テーマだけを直す」「計測も確認する」「アプリとの干渉を調べる」と別々の前提で見積もると、金額と工期を横並びにしても判断できません。

そこで改修依頼は、画面キャプチャや要望文とは別に、見積もりと公開判定に使う変更依頼票として残します。重要なのは、文書を増やすことではありません。見積もり時の前提、公開後に確認する合格条件、問題時に戻す方法を同じ1枚で管理することです。

以下は、ページ修正、テーマ改修、設定変更、外部サービス連携の変更に共通して使える設計です。料金や作業時間を一律に決めるためのものではなく、依頼先から見積もり条件を引き出し、社内で承認できる状態にするために使います。

見積もりの前に「何を変えるか」ではなく「何を成立させるか」を決める

改修要望は、次の3層に分けると比較しやすくなります。

1. 目的：なぜ変更するのか
2. 変更内容：どのページ、設定、コード、連携を変えるのか
3. 成立条件：公開後に何ができれば完了なのか

たとえば「商品詳細ページの購入ボタンを目立たせたい」という依頼だけでは、作業範囲が確定しません。ボタンの文言・色・配置だけを変えるのか、在庫切れ時の表示も対象か、スマートフォン表示も含むか、カート投入イベントの計測確認まで含むかで、必要な確認は変わります。

目的は、抽象的なスローガンではなく、判断に使える形にします。

• 悪い例：購入しやすくしたい
• 改善例：商品詳細ページで、通常在庫の商品を選択し、数量を指定してカートに追加できる状態を維持したまま、購入ボタン周辺の案内を変更する

後者であれば、少なくとも商品バリエーション、在庫条件、数量選択、カート追加という確認対象が見えます。「売上を上げる」といった事業目標を置くこと自体は有用ですが、それだけを受入基準にすると、改修の合否を公開時点で判定できません。事業KPIとリリース判定を分けて記載します。

1枚で回す変更依頼票のテンプレート

変更依頼票は、スプレッドシートの1行、チケット、社内Wikiの定型ページなど、運用中の場所に置けます。小規模な修正でも、次の項目は省略せず、該当しない場合は「対象外」と明記します。

依頼票の役割は、依頼先に実装方法を指定することではありません。たとえば「このファイルを修正する」と決め切れない場合は、変更対象を「商品詳細ページの購入フォーム」と書き、対象ファイルの特定、既存実装との競合調査、対応案の提示を見積もり項目に含めるよう依頼します。

影響範囲は購入導線から逆順に確認する

改修対象が1ページでも、ECでは表示変更が購入・受注・計測・運用にまたがることがあります。すべてを毎回詳細テストするのではなく、変更内容に応じて確認対象を選びます。

購入と受注の確認

最初に、顧客が購入を完了でき、注文が運用側で処理できるかを確認します。対象とする商品条件は依頼票に固定します。

• 商品詳細で商品・バリエーション・数量を選べるか
• 在庫あり、在庫なし、販売条件が異なる商品に表示崩れがないか
• カートへの追加、カート内の数量変更・削除ができるか
• 購入フローを完了できるか
• 注文が管理画面や受注処理の対象として確認できるか

決済、配送、会員、予約販売などを変更しない場合でも、改修箇所がそれらの導線に接するなら、対象外と断定せず確認の要否を依頼先に問います。反対に、対象外の機能を網羅的に保証する契約になっていないかも、見積書の範囲で確認します。

通知・計測・外部連携の確認

次に、注文後の情報が必要な場所に届くかを確認します。ここは画面キャプチャだけでは判定できません。

• 顧客向け・店舗向けの通知メールに必要な情報が載るか
• 広告・アクセス解析のイベントやパラメータが改修対象にあるか
• 在庫、受注、CRM、配送、レビューなどの外部サービスに影響する接点があるか
• 埋め込みタグ、アプリ、独自スクリプトの読み込み順が変わるか

ただし、実注文や外部連携先へのデータ送信を本番で試せない場合があります。その場合は「未実施」と曖昧に終わらせず、代替確認の方法、残るリスク、公開後の監視担当を依頼票に記録します。

運用・権限・保守の確認

公開後に誰が商品や表示を更新するかも影響範囲です。管理画面で変更できていた項目をコードに固定すると、同じ表示を維持するための運用は重くなります。

確認する項目は次のとおりです。

• 日常運用者が変更する箇所と、その手順は変わるか
• 新しいアプリ、アカウント、API設定、タグ管理の権限が必要か
• 改修後のコードや設定の保守担当は誰か
• 素材・文言の差し替えに開発作業が必要になるか

見積額が低くても、運用者が扱えない実装で保守依頼が継続するなら、導入時だけの比較では不足します。見積もりには初回改修だけでなく、引き渡すもの、更新手順、保守対象外を記載してもらいます。

比較できる見積書にする質問のしかた

相見積もりでは、同じ依頼票を渡し、同じ回答形式を求めます。金額だけを尋ねるより、次の項目を分けて回答してもらうと差分を説明できます。

• 実装費、調査費、テスト費、公開作業費はそれぞれ含まれるか
• 対象環境と対象テーマ・テンプレートは何か
• 既存アプリや独自コードとの競合調査は含まれるか
• 依頼側が用意する素材、権限、テストデータは何か
• 修正回数、対応時間、承認待ちが工期に与える条件は何か
• 追加費用になる条件と、判断前に連絡する手順は何か
• 納品物は何か。変更箇所一覧、コード、設定値、操作手順を含むか
• 受入テストと公開立ち会いを誰が担当するか

比較表には「最安」「最短」ではなく、前提差分の列を作ります。たとえばA社は計測確認を含み、B社は含まないなら、B社が不当に高い・安いとは判定できません。依頼票の受入基準と見積書の作業範囲を照合し、基準を満たさない項目を追加見積もりとして可視化します。

自主調査には、カートベンダーへの不満として回答の曖昧さや見積もり根拠への不満を挙げた回答が示されています。しかし、調査主体・対象・方法に限りがあるため、これをEC事業者全体の傾向とは扱えません。個別の見積もりで根拠を確認する必要性を考える材料の一つとして参照するに留めるのが適切です。

受入基準は「操作・期待結果・証跡」で書く

「デザインを確認する」「問題がないこと」は、受入基準として不足します。確認者によって判定が変わるためです。各基準を、次の3点に分解します。

• 操作：誰が、どの条件で、何をするか
• 期待結果：画面、データ、通知がどうなれば合格か
• 証跡：スクリーンショット、注文番号、確認日時、確認者をどこに残すか

例として、商品詳細の購入ボタン改修なら以下のように書けます。

デザインの受入では、参照するデザインデータのURLまたは版数、対象デバイス、許容できない差分を決めます。「完全一致」のような解釈が広い言葉ではなく、変更が必要な要素を列挙します。

また、受入テストで見つかった差分を、瑕疵修正と仕様追加に分ける基準も必要です。依頼票と承認済みの画面案・仕様にある内容が満たされない場合は修正対象です。一方、承認後に新たな表示パターンや連携要件を追加する場合は、影響調査と再見積もりが必要になり得ます。どちらに当たるかを担当者の印象だけで決めず、依頼票の記録に戻って判断します。

Shopifyテーマ改修ではバックアップ・公開・権限を票に記載する

Shopifyのテーマコードを変更する改修では、見た目と受入基準に加え、テーマの状態を依頼票に残します。Shopify ヘルプセンターは、コード編集前にテーマを複製してバックアップを作成することを案内しています。また、コードの変更履歴から復元できる場合がある一方、復元はファイル単位であり、履歴には限りがあります。コード履歴だけを切り戻し策にせず、作業前のテーマ複製を公開計画に含めます。仕様の確認時点は2026年9月8日です。

依頼票には、少なくとも次を記載します。

• 現在公開中のテーマ名と、作業用に複製したテーマ名
• 変更予定のテンプレート、セクション、スニペット、設定、アプリ埋め込み
• 下書きテーマで確認する受入基準と確認担当者
• 公開するテーマ、公開日時、公開実行者、最終承認者
• 切り戻し時に再公開するテーマと、切り戻し判断者

Shopifyでは下書きテーマを公開でき、新しいテーマを公開すると、それまで公開されていたテーマは下書きテーマになります。この仕組みは公開テーマを戻す選択肢になりますが、公開後に行った設定変更や外部サービス側の変更まで自動的に元へ戻ることを意味しません。テーマ以外の変更がある場合は、テーマの再公開とは別に、戻す設定・担当者・順序を定義します。

権限についても、作業者に恒久的に広い権限を渡すのではなく、必要な作業を分けて検討します。Shopifyのストア権限では、テーマの表示・変更・公開に関する権限と、コードエディタから直接変更する権限が区別されています。実際の権限名や付与可否は、ストアのユーザー管理画面と契約・役割設定で確認してください。仕様の確認時点は2026年9月8日です。

公開作業を外部に委ねる場合も、公開承認者を社内に置くのか、作業者に公開まで委任するのかを票に明記します。緊急時に誰が旧テーマを再公開するのかまで決めておくと、連絡待ちで切り戻しが遅れる事態を避けやすくなります。

公開承認は未決事項を閉じてから行う

公開の直前に見るべきものは、完成画面だけではありません。承認者は次の順で確認します。

1. 依頼票の未決事項に、決定者と結論が記録されているか
2. 見積もりの対象範囲と、実際の変更範囲が一致しているか
3. 必須の受入基準に証跡があり、未実施項目の扱いが承認されているか
4. 公開担当、監視担当、問い合わせ窓口が決まっているか
5. 切り戻し対象と判断条件を、担当者が実行できる状態か

公開後は、事前に決めた時間帯または件数を目安に、購入導線、注文確認先、重要な計測・連携を監視します。ここでいう監視は、すべての改修に24時間の体制を求めるものではありません。変更の影響度と営業体制に合わせ、誰がどこを確認するかを決める作業です。

変更依頼票を残すもう一つの利点は、次回改修の見積もりを速くすることです。実際に変更した範囲、発生した追加作業、使った受入基準、切り戻しの有無を追記すれば、次回は「前回と同じ前提か」「何が違うか」から検討できます。改修を単発の発注ではなく、判断可能な変更履歴として扱えます。

参考情報

• EC担当の77.8％がカート業者の「運用開始後に対応品質が下がった」を実感〖自主調査〗
• Shopify ヘルプセンター：テーマコードの編集
• Shopify ヘルプセンター：テーマの公開
• Shopify ヘルプセンター：ストアの許可