スコープ
プロジェクトにおける「作業範囲」のことです。「何を作って、何を作らないか」「誰が何をやるか」の明確な線引きを指します。
Web 制作では、ページ数・機能・修正回数・SEO対策の有無などが代表的な軸になり、RFP(制作会社への提案依頼書)や契約書で明文化します。
契約時に明示すべき 4 つの項目
- 含まれるもの：対象となるページ数、機能、デザインカンプ(完成見本の画像)の数など。
- 含まれないもの(超重要)：サイト公開後の運用保守や、記事の執筆などは「対象外」であることを明記します。
- 前提条件(役割分担)：写真素材や原稿は発注者(自社)が用意する、など。
- 成果物の定義と修正回数：納品物はコードだけかマニュアルも含むか。デザインの修正は何回までか。
※これらを MVP(必要最小限の初期リリース版)と「第 2 フェーズ(後回しにするもの)」に分けて整理します。
スコープクリープ(炎上)を防ぐ運用の鉄則
スコープが曖昧だと、後から追加要望が無制限に膨らみ、プロジェクトが炎上します(これを「スコープクリープ」と呼びます)。「軽微な修正」や「適切な対応」のような解釈が分かれる曖昧な言葉は契約書から排除し、万が一スコープを変更する際の「追加見積もりのルール」を最初に決めておくことが重要です。
初心者が陥りがちな「4 つの落とし穴」
- 「言った・言わない」の認識ズレ：当然やってくれると思って依頼したら「それはスコープ外なので追加費用がかかります」と言われ、予算が足りなくなる。
- 業者の品質低下：契約後に自社が無理な追加要望を押し通した結果、業者が黙って(泣き寝入りして)作業を吸収し、結果的に見えない部分のコード品質などが著しく落ちる。
- 変更ルールの未整備：追加要望が出た際の承認フローが決まっておらず、誰が判断するのか揉めてプロジェクトが止まる。
- スコープの放置：途中で仕様が変わったのに、スコープ(要件定義書など)を更新せず、古い状態のまま開発を走らせてしまう。
言葉をよく利用する人
- Web 担当者(発注側)
- プロデューサー
- ディレクター
- 法務 / 契約担当
- プロデューサー
会話上での使用例
RFPのスコープ記述を法務と一緒に詰める場面
-
Web担当者
RFPのスコープ欄に「適切なSEO対応」と書いたんですが、これで大丈夫でしょうか。
-
法務／契約担当
「適切」という言葉は後で揉めますよ。タイトル、メタディスクリプション、構造化データ、sitemap.xml、robots.txtの実装、というように具体的に列挙してください。
-
法務／契約担当
あわせて、SEOの継続施策はこの契約には含まない、と一文で明記しておきましょう。
進行中に「これも込みですよね」と追加依頼が出た場面
-
Web担当者
メルマガ配信機能も、追加で実装をお願いできますか。
-
業者ディレクター
それはスコープ外になりますので、変更ルールに沿って追加見積を出させてください。
-
業者ディレクター
急ぎでなければフェーズ2の候補に回す選択肢もあります。どちらにせよ、変更の進め方は最初に握っておきましょう。