プロジェクトを進めていると、こんな場面に遭遇します。
- 「この機能もやってほしいんだけど」
- 「このシステムは対象じゃないの？」
- 「え、それってスコープ外だったの？」
スコープが大事なのはわかっている。でも、どうやってスコープを切ればいいのかがわからない。
「対応するもの・しないものを決めればいいんでしょ？」とは思いつつも、いざ決めようとすると手が止まる。そんなPMや企画担当者は、少なくないのではないでしょうか。
実は、スコープ定義がうまくいかない原因の多くは、「どの切り口で整理するか」が定まっていないことにあります。
この記事では、スコープの基本的な考え方から、実務で使える切り口の選び方までを、具体例とともに解説します。
この記事でわかること
- スコープとは何か？（境界・スコープ内・スコープ外）
- なぜスコープ定義が必要なのか？
- スコープの決め方と、よく使う切り口
なぜスコープ定義が必要なのか？
まず押さえておきたいのは、スコープ定義は「対象範囲を決める作業」だけではないということです。
スコープ定義の本質は、対応する・しないの判断基準を作ることです。
もしスコープが決まっていないと、どうなるでしょうか？
- 「この機能も追加でやってほしい」という要望が際限なく出てくる
- 「このシステムは対象じゃなかったの？」と後から指摘される
- 対応する・しないを都度判断することになり、判断基準もブレる
こうした状態が続くと、プロジェクトのQCDに直撃します。
- Q（品質）：対応範囲が曖昧なまま進むと、ヌケモレが発生する
- C（コスト）：追加対応が積み重なり、工数が膨れる
- D（納期）：スコープが膨らんだ分だけ、スケジュールが押される
つまり、スコープが決まっていないということは、プロジェクトの判断基準が定まっていないということです。判断基準がなければ、追加要望が来るたびに振り回されることになります。
こうしたことを防ぐために、プロジェクト計画の段階でスコープを定義しておくことが重要なのです。
スコープとは何か？
そもそも、スコープとは何でしょうか？
スコープとは、プロジェクトで対応する範囲のことです。
もう少し噛み砕くと、スコープを決めるということは、対応するもの・しないものの間に境界線を引くことです。
この境界線を引くことで、次の3つが定まります。
- 境界：対応する・しないを分ける線
- スコープ内：プロジェクトで対応するもの
- スコープ外：プロジェクトで対応しないもの
ここで重要なのは、スコープ内だけでなく、スコープ外も定義することです。
「対応するもの」だけ決めて「対応しないもの」を決めていないプロジェクトは少なくありません。でも、「ここはやりません」を明示しておかないと、追加要望が出やすくなります。この点は、後ほどNGパターンでも触れます。
スコープの決め方
ここからは、具体的なプロジェクト例を使って、スコープの決め方を解説します。
プロジェクト例
- 営業支援ツールの改修プロジェクト
- 利用者は自社の営業社員と、営業代理店の担当者
- 追加する機能は、自社営業向けのダッシュボード拡張
STEP1：切り口（観点）を決める
スコープを決めるには、まずどんな切り口でスコープを定めるかを決めます。
スコープはあらゆる観点で定めることができます。だからこそ、どの切り口で整理するかがポイントです。
切り口の例としては、ユーザー、機能、システム、業務、データなどがあります（よく使う切り口は後述します）。
今回の例では、利用者が2種類（自社営業・代理店）いて、機能追加が目的なので、ユーザーと機能の2つの切り口でスコープを定義します。
STEP2：スコープ内を決める
定めた切り口を使って、プロジェクトで対応する範囲を決めます。
今回の場合は、以下をスコープ内とします。
- ユーザー：自社の営業社員
- 機能：業績ダッシュボード
STEP3：スコープ外を決める
併せて、プロジェクトでは明示的に対応しないものを決めます。
今回の場合は、以下をスコープ外とします。
- ユーザー：代理店の担当者
- 機能：業績ダッシュボード以外の機能
このように、切り口を決める → スコープ内を決める → スコープ外を決めるという流れで整理すると、スコープを構造的に定義できます。
スコープ定義の3ステップ
- 切り口（観点）を決める
- スコープ内（対応するもの）を決める
- スコープ外（対応しないもの）を決める
よく使うスコープの切り口
「切り口を決めるのが大事なのはわかったけど、どんな切り口があるの？」と感じた方もいると思います。
ここでは、実務でよく使うスコープの切り口を紹介します。
| 切り口 | 説明 | 使いどころ |
|---|---|---|
| 業務 | 全体の業務プロセスのうち、どこを対象にするか | 業務プロセスに紐づいたシステム改修や、業務プロセスを変更する場合 |
| システム | 関連システムのうち、どれを対象にするか | 複数システムをまたぐ改修の場合 |
| 機能 | 複数機能のうち、どれを対象にするか | 単一システムの改修の場合 |
| ユーザー | 利用ユーザーのうち、誰を対象にするか | 複数のユーザーがシステムを利用している場合 |
| 商品・サービス | 扱う商品・サービスのうち、どれを対象にするか | 複数商品を扱うシステムで、特定商品のみが影響を受ける場合 |
| データ | 扱うデータのうち、どのデータを対象にするか | データ移行など、データに着目したい案件の場合 |
| 要件種別 | どのような要件を含めるか | セキュリティ対応、業務改善など複数観点の要件が混在する場合 |
| 工程 | プロジェクト工程のうち、どこまでを対象とするか | 上流工程のみなど、プロジェクトの一部を切り出す場合 |
これらをプロジェクトの特性に合わせて選び、複数の切り口を組み合わせてスコープを表現することがポイントです。
1つの切り口だけでは、スコープが曖昧になりやすい。複数の切り口で多面的に境界線を引くことで、より明確なスコープ定義ができます。
実体験：セキュリティプロジェクトでのスコープ定義
ここで、私自身の経験を紹介します。
以前、セキュリティ対応を目的としたプロジェクトを担当したことがあります。3つのシステムを改修する必要があり、マルチベンダー体制。企画部署も3部署の合同という、なかなかの複雑さでした。
このプロジェクトでは、対象システムや業務、ユーザーでスコープを定義するのは当然として、「要件種別」でもスコープを切るという判断をしました。
なぜ「要件種別」で切ったのか
もともとこのプロジェクトで改修するシステムは、使いにくいと言われていたシステムでした。そのため、プロジェクトが始まれば「ついでに使いやすくしてほしい」「業務効率を上げる改修もしてほしい」という要件が出てくる気配がありました。
しかし、プロジェクトの目的はあくまでセキュリティへの対処です。3システム×マルチベンダー×3部署という複雑な体制の中で、スコープを広げれば炎上リスクが一気に高まります。
だからこそ、セキュリティに関連する要件のみを対象とし、業務改善系の要件は受け付けないというスコープ定義を行い、あらかじめプロジェクトオーナーと合意しました。
その結果どうなったか
案の定、追加要望は出てきました。特に多かったのは要件定義フェーズです。さらに、要件を落とし込む設計フェーズでも「具体的な画面が見えてきたタイミング」で、「この画面、ついでにもう少し使いやすくできませんか？」といった声が上がりました。
具体が見えてくると、「せっかくだからこれも」という気持ちが出てくるのは自然なことです。でも、スコープを事前に定義しておいたことで、対応はシンプルでした。
「その要望はスコープ外なので、リリース後に別プロジェクトか保守開発で対応しましょう」
この一言で整理がつきました。事前にプロジェクトオーナーと合意済みなので、現場レベルでの「やる・やらない」の議論にならず、スムーズに却下できたのです。
もしスコープが曖昧なままだったら、追加要望が出るたびに関係者を集めて「やるのか・やらないのか」を議論することになっていたはずです。3システム×3部署の体制で、それをやっていたらプロジェクトの推進力は大きく削がれていたと思います。
この実体験のポイント
- 一般的な切り口（システム・業務・ユーザー）に加えて、プロジェクト固有の切り口（要件種別）を追加した
- POと事前に合意しておくことで、追加要望への対応コストを大幅に下げた
まとめ
この記事では、スコープの基本的な考え方から、切り口の選び方、実務での活かし方までを解説してきました。
改めて、スコープ定義の流れを振り返ります。
スコープ定義の3ステップ
- 切り口（観点）を決める — どの切り口でスコープを定めるか
- スコープ内を決める — プロジェクトで対応するもの
- スコープ外を決める — プロジェクトで対応しないもの
スコープ定義で一番大事なのは、どの切り口で境界線を引くかを意識することです。
切り口が定まれば、スコープ内・スコープ外は自然と整理できます。逆に、切り口が定まらないまま「対応するもの」だけをリストアップしても、境界が曖昧なままになってしまいます。
プロジェクトの特性に合わせて切り口を選び、複数の観点でスコープを表現する。この意識を持つだけで、スコープ定義の精度はぐっと上がります。
ぜひ、現場で試してみてください！
おまけ：NGパターン
最後に、スコープ定義でよくある失敗パターンを紹介します。
NG① スコープが決まっていない
スコープを明確に定義しないままプロジェクトを進めてしまうケースです。
- 「このシステムも対象じゃなかったの？」と途中で指摘される
- 「この機能も追加でやってほしい」という要望が次々と出てくる
スコープが決まっていないということは「判断基準がない」ということです。その結果、追加要望への対応を都度判断することになり、判断基準もブレていきます。
ヌケモレがあればコスト・納期に影響し、追加要望を受け入れ続ければスコープは膨らみ続けます。
対策：プロジェクトの序盤で、切り口を決めてスコープ内・スコープ外を明文化する
NG② スコープ外が定義されていない
「対応するもの」は決まっているけれど、「対応しないもの」が明示されていないケースです。
- スコープ内は決めたが、スコープ外は決めていない
- 「ここはやりません」が提示されていない
この状態だと、追加要望が出たときに「スコープに含まれていないけど、スコープ外とも言われていないから対応すべきでは？」というグレーゾーンが生まれます。
結果として、追加要望を断りにくくなり、スコープが徐々に膨張していきます。いわゆるスコープクリープです。
対策：スコープ定義では、スコープ内だけでなくスコープ外も必ずセットで明示する。「やらないこと」を宣言しておくことで、追加要望への対応工数を削減できる
関連記事