目次 ／ 制作・開発ディレクション ／ プロジェクトマネジメント

スコープ管理・仕様変更対応

項目番号 071

10秒でわかる！要点まとめ

• 仕様変更そのものは悪ではない。管理されていない仕様変更が悪
• 「ちょっとだけ」の積み重ねでプロジェクトは死ぬ。これをスコープクリープと呼ぶ

• 断るのではなく「見積もります」と返す。判断するのはクライアント自身

  1. 概要：増えていく要望を、記録し、値付けし、合意する

  スコープ管理とは、要件定義で確定した作業範囲を基準として、そこから外れる要望が出たときに、影響（工数・費用・スケジュール）を明示し、実施可否をクライアントと合意して進める業務です。 Web制作では、進行中に必ず新しい要望が出ます。ビジネス環境が変われば当然のことであり、それ自体を止めることはできません。ディレクターの仕事は変更を禁止することではなく、変更を「見えるところに出して、値段をつけて、決めてもらう」仕組みを回すことです。

  2. なぜ重要なのか：利益とチームの両方が削られる

  管理されない仕様変更は、まず利益を削ります。1件30分の「ちょっとした修正」でも、20件溜まれば10時間、丸1人日以上が無償で消えます。見積もりの利益率が20%の案件なら、これだけで赤字に転落します。 次に削られるのはチームです。「言えばやってくれる」と学習されると要望は加速度的に増え、デザイナーやエンジニアは終わらない修正に疲弊し、品質が落ち、離職につながります。スコープを守ることは、数字を守ることであると同時に、一緒に働く人を守ることです。

  3. 実務のポイント：断らずに「可視化」する

  1. 変更管理表をつくる：日付・依頼者・内容・想定工数・費用・対応可否・決定日を1行で記録します。Excelでもタスク管理ツールでも構いません。記録が残っている、と相手が知っている状態がいちばん効きます。
  2. 「できません」と言わない：「その変更は可能です。工数が3日増えるため、費用が〇〇円、納期が1週間後ろ倒しになります。実施されますか？」と返します。判断をクライアントに戻すのが基本形です。
  3. 無償対応の線引きを決めておく：「明らかな不具合の修正は無償」「文言の誤字修正は無償」「レイアウト変更や機能追加は有償」など、社内の基準を先に決めます。都度その場で判断すると、担当者ごとにブレます。
  4. 溜めずに、その場で出す：変更の話は発生した週に伝えます。納品直前にまとめて請求すると、金額の大きさに驚かれ、こじれます。

     4. スキルアップのヒント：「変更ゼロ」を目指さない

     経験の浅いうちは、仕様変更を「自分の要件定義が甘かった失敗」と捉えがちですが、実務では変更が出ることを前提に設計するほうが健全です。見積もり段階で予備工数（バッファ）を10〜20%積んでおく、要件定義書に「変更が生じた場合は別途お見積もり」と明記しておく——といった備えが効きます。 また、過去の案件で実際にどれくらいの変更が発生したかを数えてみてください。「うちの案件は平均で工数が15%増える」と数字で言えるようになると、見積もりの精度も、クライアントとの交渉の説得力も一段上がります。