「これも今回のスコープですよね？」「それ、要件定義書のどこに書いてありました？」
Salesforce導入プロジェクトの終盤で何度も交わされてきたやり取りです。最も手戻りが起きやすいのは「スコープの線引き」と「時間軸の設計」で、ここが曖昧なまま実装に入ると、後半で高い確率で炎上します。この2点を独立して深掘りします。
スコープを明文化する単位
要件を機能名で語ると曖昧になります。以下の単位で線引きすることが有効です。
- オブジェクト単位
- 例：「商談・取引先・リードは対象。契約・請求は次フェーズ」
- プロセス単位
- 例：「新規商談プロセスは対象。既存顧客のアップセルプロセスは対象外」
- ユーザー単位
- 例：「営業部門は対象。カスタマーサポート部門は対象外」
- データ単位
- 例：「今後発生するデータは対象。過去データの全件移行は対象外（直近1年のみ）」
- 連携単位
- 例：「Salesforce内部の構築が対象。基幹システムとのAPI連携は次フェーズ」
原則は、In Scope（含むもの）だけでなくOut of Scope（含まないもの）を要件定義書に明記することです。「言った／言わない」の争いは大抵、Out of Scopeが書かれていないことで起きます。
ここで一つ、先に反論しておきます。「含まないものまで書き出すのは、要件定義書を無駄に長くするだけでは」と思うかもしれません。手間が増えるのは事実です。ですが、Out of Scopeが書かれていない要件定義書は、白紙の契約書に近い状態です。書かれていない部分は「対象外」ではなく「未定義」として扱われ、後から言った言わないの余地を残します。
MoSCoW法での優先度分離
- Must
- これがないと成立しない。初回スコープに必ず含める
- Should
- 重要だが代替手段がある。初回スコープに入れば理想だが、なくても運用可能
- Could
- あれば良い。次フェーズ以降に回す候補
- Won't（この期間は）
- 今回は対象外と明言し、Out of Scopeとして文書化する
現場ヒアリングでは大抵すべてが「Must」として語られます。「これがないと業務が止まるか、それとも回避策（手動運用）があるか」で問い直し、Should以下に降格できるものを見つけることが実務上のコツです。
現場から出てきた要件を1件ずつ優先度分類していくフォーマットです。
| 要件 | 優先度（Must／Should／Could／Won't） | 判断理由（業務停止するか／回避策の有無） |
|---|---|---|
| 記入例既存顧客のアップセルプロセスの自動化 | 記入例Could | 記入例手動運用で当面回避可能。次フェーズに回す |
Big Bang vs フェーズドロールアウト
- Big Bang（一括導入）
- 組織規模が小さい、業務プロセスがシンプル、旧システムの並行運用コストが高い場合に向く。移行時の業務停止・混乱の影響範囲が大きいリスクがある
- フェーズドロールアウト
- 組織規模が大きい、部門・地域ごとに業務プロセスが異なる、チェンジマネジメントの負荷を分散したい場合に向く。移行期間中、新旧システムの並行運用コストがかかる
判断基準は「導入が一度に失敗した場合の影響範囲」です。全社一斉導入で失敗すると業務全体が止まるなら、フェーズドを選びます。
MVPとロードマップの型
MVP（最初のフェーズ）は「動くものを早く見せる」ためではなく、「価値検証に必要な最小構成」として定義します。典型的な初回フェーズ構成は、商談プロセスの基本実装＋データ移行（直近データのみ）＋基本レポートです。CPQ・複雑な承認フロー・他システム連携は多くの場合、次フェーズに回せます。目安として、Phase 1（1〜3ヶ月）でMVP、Phase 2（次の2〜4ヶ月）で自動化強化・他システム連携、Phase 3（以降）でCPQ／AI機能等の高度活用、という3段階の型が業種・規模を問わず流用できます。
商談プロセス基本実装・データ移行・基本レポートのMVP
自動化強化・他システム連携
CPQ／AI機能等の高度活用
あわせて、要件定義後に追加要望が出るのは前提として、変更管理プロセス（誰が判断し、追加コスト・期間影響をどう合意するか）を最初に決めておくことが、無償対応の既成事実化を防ぎます。
例えば、「過去データは全件移行してほしい」という要望を精査せずに受け入れると、移行コスト・期間が大幅に膨らむことがあります。「分析・監査で必要な最小期間」を確認し、直近1〜2年分に絞れないかを検討するだけで、スコープと期間の両方を現実的な範囲に収められることが少なくありません。引っ越しのたびに何年も開けていない段ボールまで運ぶかどうかを、荷造りの段階で一度は聞かれるはずです。「念のため全部」は安全に見えて、実際には運搬コストと置き場所の両方を圧迫します。
よくある質問
- 現場が「これは全部Must」と言ってきたらどう対応すべきですか
- 「これがないと業務が止まるか、それとも回避策（手動運用）があるか」で問い直すのが実務的な対処法です。現場ヒアリングでは大抵すべてが「Must」として語られますが、この問い直しでShould以下に降格できるものが見つかることが多いです
- Big Bang導入とフェーズドロールアウト、どちらを選ぶべきですか
- 判断基準は「導入が一度に失敗した場合の影響範囲」です。全社一斉導入で失敗すると業務全体が止まる規模・複雑さの組織なら、フェーズドロールアウトで段階的にリスクを分散するのが一般的です
- MVPのスコープはどこまで含めればいいですか
- 典型的な初回フェーズ構成は、商談プロセスの基本実装＋データ移行（直近データのみ）＋基本レポートとされています。CPQ・複雑な承認フロー・他システム連携は多くの場合次フェーズに回せます。「動くものを早く見せる」ではなく「価値検証に必要な最小構成」という定義で絞り込みます
問い
今進行中の案件の要件定義書に、Out of Scopeの欄はどのくらい埋まっているでしょうか。In Scopeばかりが並んでいて、Out of Scopeの欄がほぼ白紙だとしたら、その空白は将来「言った／言わない」の火種になりかねません。