見積もりと「できる／できない」の提案
スコープ・前提条件・リスクを明記した見積もりと、代替案つきの提案ができる
最終確認: 2026-09
解説
受託の現場でなぜ必要か： この回では、スコープ・前提条件・リスクを明記した見積もりと、代替案つきの提案ができるようになります。
受託では、見積もりは金額を出すためではなく、「何をやって、何をやらないか」を合意するための書類です。
見積もりとは、スコープと前提を合意する書類
見積もりは、「何をやって、何をやらないか」をクライアントと合意するために作ります。
スコープ（作業の範囲）は、設定作業・テーマ実装・アプリ選定と設定・データ投入・テスト・引き渡しに分けます。
設定作業には、決済・配送・税・ポリシーが入ります。
テーマ実装は、セクション単位で数えます。
前提条件とリスク項目を書く
前提条件には、プラン、使用テーマ、アプリの月額は別途、原稿と画像はクライアント支給、修正回数を書きます。
リスク項目には、チェックアウト要件（Plus依存）、外部連携、移行データの品質、アプリの相性を挙げます。
リスクは「調査費」として見積もりに切り出します。
前提とリスクを書いた見積もりは、追加要望のたびに自分を守ってくれます。
「できない」はどう伝えるか
「できません」は、必ず「代わりに〜できます（費用差 ±）」とセットで伝えます。
判断表（テーマ／アプリ／Functions／外部のどれで実現するかを並べた表）を添えると、クライアントが自分で選べます。
変更管理はどうするか
追加要望は、別見積もりにします。
テーマエディタでクライアントが変えられる範囲を先に共有すると、要望が減ります。
自分で変えられると分かれば、開発者に頼む必要がなくなるからです。
※ ShopifyはShopify Inc.の商標です。本サイトは個人が制作した非公式の学習教材であり、同社の承認・提携・後援を受けていません。記載内容は2026-09時点のものです。料金・上限値・管理画面のラベルは変わるため、作業の前に公式ドキュメントで確認してください。