システム開発プロジェクトでは、「スコープ」を決めてからプロジェクトがスタートしていきます。スコープはプロジェクトの範囲のことを指します。これを明確に決めておかないと、範囲が広がったことに気づかずプロジェクトの予算が膨れ上がってしまったり、スケジュールが遅れてしまったりなどしてシステム開発の失敗に繋がりかねません。
そこでこの記事では、システム開発プロジェクトのスコープについて詳しく解説します。スコープとは何か、管理方法と手順、管理のポイントを紹介します。
スコープ管理（＝スコープマネジメント）は主にシステム開発会社側が率先して行うため、受注者向けの記事内容ですが、発注側もスコープとは何か、管理手順や流れを抑えておくことでスムーズにシステム開発が進行するかと思います。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
スコープとは
システム開発プロジェクトのスコープとは、「そのプロジェクトで何をするのか・何をしないのか」範囲を定義するものです。プロジェクトの要求や目標、そしてそれを達成するために必要な作業やタスクを明確に定義します。何をするのか＝スコープに入れるもの、何をしないのか＝スコープ外のものとして扱います。
スコープを設定する目的は、プロジェクトの変更時は成果物が期限内に納品され、かつ作業がうまく進むよう作業人員を調整して予算内に収まるように管理するためです。
システム開発のスコープは、プロジェクトスコープ（作業スコープ）とプロダクトスコープ（成果物スコープ）の2つに分かれます。
プロジェクトスコープ（作業スコープ）……どんな作業をするか、どこまで作業するか
プロダクトスコープ（成果物スコープ）……何を作るか、何を作らないか
プロジェクトスコープとプロダクトスコープは繋がっています。これを作るためにはどんな作業が必要か、というようにスコープを定義していきます。
例えば「バレンタインに向けて、チョコレート入りのギトギトラーメンを作って欲しい」と新作ラーメンプロジェクトが発足したとします。
完成品（新作チョコレートラーメン）を作るために、途中でできる成果物（チャーシューやスープなど）と、成果物を作る際の作業を書き出します。スコープは以下の図のようなイメージです。
スコープは、プロジェクトのステークホルダー（ここでは特に顧客、開発チーム、組織の上層部などの関係者を指します）と協議して決定され、プロジェクトのスコープステートメント（スコープ記述書）として文書化されます。スコープステートメントについては後述の「スコープマネジメントの手順」内で解説します。
スコープマネジメント（スコープ管理）とは
スコープは、なにをするか（作るか）、なにをしないか（作らないか）明確な作業と成果物の範囲を定義するものとお話ししました。しかし、スコープは最初に定義したから終わり、ではありません。プロジェクトの要求や目標が変更された場合には、スコープの変更も適切に管理すること（スコープマネジメント）が必要です。
スコープマネジメントでは、プロジェクトに変更があった場合にスコープも必要に応じて変更し、管理を行います。
- プロジェクトの目標を達成するために必要な成果物と作業を定義する
- プロジェクト期間を通じて、必要に応じてスコープ定義を見直していく
- 必要な成果物と作業が完成されていることを保証する
スコープマネジメントは、プロジェクトの達成に必要なリソースやスケジュールを管理するために重要な役割を果たします。管理を適切に行うことによって、スコープクリープを早期発見し、プロジェクトのスケジュールやコストが膨れ上がるのを防ぎます。スコープクリープについては後述します。
具体的な活動としては、要件の洗い出し、スコープステートメントの作成、WBS（作業分解図）の作成、成果物の検証などがあげられます。活動内容については後述の「スコープマネジメントの手順」で解説します。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
スコープクリープとは
スコープクリープとは、スコープ（範囲）を超えてしまうことです。プロジェクトのスコープが予期せぬ方向に拡大し、当初のスコープを超えるような要求やタスクが追加され肥大していくことを指します。
スコープクリープは、プロジェクトの達成に向けた共通の目標を曖昧にし、スケジュールやコストを増大させる原因となります。また、スコープクリープはプロジェクトのクオリティにも悪影響を与えることがあります。
スコープクリープの原因として、以下のようなものが挙げられます。
- スコープの定義不足（不明確な定義や目標である）
- スコープの管理不足（変更を把握しきれていない）
- ステークホルダーとのコミュニケーション不足
- プロジェクトに関わる人が多すぎる（複雑化してしまうと上記3つが発生しやすくなる）
スコープクリープを防ぐためには、プロジェクトのスコープを明確に定義し、ステークホルダーの間で共通の目標を共有することが重要です。また、スコープの変更管理を適切に行うことで、スコープクリープが発生した場合には早期に対応し、スケジュールやコストの影響を最小限に抑えることができます。
スコープマネジメントの手順
スコープマネジメントは以下のように進めていくのが一般的です。
1.計画を立てる
まずはスコープマネジメント計画を立てます。ステークホルダーと話し合い、合意を取った結果を元に作成していきます。
- プロジェクトの目的
- 主な成果物はなにか
- 主な作業はなにか
- 主なマイルストーン
- スケジュール
- 制約（時間や資金、リソースなどプロジェクトに影響するもの）
- プロジェクトのルール
マイルストーン（中間目標）、プロジェクトの各要素を完成させる期日を決めておきましょう。作業が予定通り進んでいるか把握し、チームのコミュニケーションを円滑にするのに役立ちます。
ここではスコープは明確に定義せず、要件の収集・洗い出しの後に決めるとスムーズです。ここで定義すると要件が揃ったあとに再度スコープを定義し直すことになり、二度手間になってしまいます。
2. 要求の収集・要件の洗い出し
プロジェクトメンバーやステークホルダーから引き出した情報を元に、要件を洗い出します。ステークホルダーへのインタビューやグループの話し合い、アンケートなどからプロジェクトの要求を理解し、要件として洗い出して「要求事項文書」として文書化します。
この工程ではステークホルダーのさまざまな部署の人から「あれがやりたい、これが欲しい」とアイデアが浮かんでくるため、キリがなくなってしまうことが多い傾向にあります。期限を決めた上で取り組むと効率的です。
3. スコープの定義づけ、スコープステートメントの作成
スコープステートメント（スコープ記述書）とは、プロジェクトの要件や目標、そしてそれを達成するために必要な成果物と作業を明確に定義した文書のことです。ここに記述された定義が、プロジェクトのすべての活動のベースとなります。プロジェクトの要件を記したすべての文書（要求事項文書など）とプロジェクト憲章、スコープマネージメント計画を基に作成します。
スコープステートメントは、プロジェクトのスコープを明確に定義するために使用されます。これにより、プロジェクトのステークホルダーが共通の目標を共有し、予期せぬ変更やスコープクリープを防ぐことができます。
スコープステートメントには、以下のようなものが含まれます。
- プロジェクトの背景や目的
- 要件
- 除外事項
- 制約
- 成果物のスコープ定義（プロダクトスコープ）
- 作業のスコープ定義（プロジェクトスコープ）
- スケジュール
- コスト
- 品質など
これらの情報はプロジェクトの計画・実行・監視・制御に必要であり、プロジェクトの成功に向けてチーム全員が共通理解を構築するために重要です。
スコープステートメントが完成したら、必要なステークホルダー全員に署名してもらいます。もしもプロジェクト進行中にスコープ変更申請があった場合に、その人がプロジェクト開始時の条件に同意したことを文章で示すことができるからです。
スコープステートメントは、プロジェクトの進行に伴って変更される可能性があります。それに対応するためにスコープの変更管理も適切に行う必要があるので、完成したら終わりではないことを念頭に置いてください。
4. WBS（作業分解図）の作成
スコープ記述書には、プロジェクトで何をすべきか、どのような成果物を生成すべきかが定義されますが、具体的な作業レベルまでは定義されていません。
そこで、このプロセスでプロジェクト・スコープをスケジュールやコストの見積もりが可能な作業の単位にまで分解し、WBS（作業分解図）を作成します。WBSは全作業を漏れなく洗い出す目的で作られ、プロジェクトをスムーズに完遂するために重要な項目を担っています。
細かすぎると時間がかかってしまうため、成果物の品質を担保できるレベルで分解できていればよいかと思います。最初に出したラーメンで例えると、このような感じで作業を分解していきます。
ラーメンの場合は出汁のアクを取らないと味が落ちてしまうため、さらに細かい作業として書き込みました。
5. スコープの検証
ここでは成果物の検査と評価を行い、成果物が完成したか、またはさらに見直しが必要かを確認します。具体的には以下の2点を行います。
- 成果物がスコープのとおり作成されているか
- 計画と現状に乖離がないか
成果物がスコープ通りでない場合、改善するための処置が必要となります。計画と現状に乖離がある場合（予定していたマイルストーンに辿り着いていないなどの場合）は、スコープに変更を加えなければなりません。計画して終わりではなく、常に状況を監視しながらスコープと作業を調整しましょう。
6. スコープの管理
各スコープが機能しているか、実際のパフォーマンスはどうかなどを要件と比較しながら、プロジェクトマネジメントに必要なリソースの確保や変更の意思決定などをサポートします。また、プロジェクトに変更があった場合に目標達成に影響を与えないように管理を行います。
スコープマネジメントのポイント
スコープマネジメントのポイントを紹介します。
1.可視化して共有する
スコープステートメントやWBSを作成し、チームやステークホルダーと共有することで認識を揃えることができます。
可視化することで要件漏れをなくす意味合いも兼ねています。
2.チームで話し合う
1人で背負うのはとても大変です。抜け漏れや偏りが起きることもあります。
メンバー1人ひとりの知識を活用してチームで作業を進めましょう。自分では気づけない別の視点の意見を聞いて、メンバーの意見を組み込みながら文章を作成していきます。
3.要求事項のマネジメントを確実に行う
要求収集の際、ステークホルダー（顧客）は「あれもやりたい、これも欲しい」とさまざまな要求を提示してきます。そして、これらの要求は必ずしも一定の方向性に基づいているとは限りません。
すべてを受け入れてしまうとスコープクリープが発生し、コストが増えスケジュールも遅延します。さらに品質の劣化などを引き起こしてしまい、結果、顧客を満足させることができずにプロジェクトは失敗に終わってしまいます。
このような事態を避けるため、プロジェクトマネージャーは、プロジェクトの目的に向けて要求を収束させ、実現すべき要求事項を確定させるための活動である「要求事項マネジメント」を行う必要があります。開発チーム側で要求事項からスコープに入れるものと入れないもの、スコープの優先順位を決めて管理しましょう。
そのために要求事項とスコープは分けて文書化しておくとよいでしょう。具体的には、「要求事項文書」を顧客の言葉で記述し、実装されるものとして最終決定された要求事項から「スコープステートメント」を作成します。
4.真のニーズを引き出せるようにする
顧客の要望の背景や業務のフローを理解した上で要件を整理したり、実務に詳しい関係者の意見を取り入れたりして、顧客の真のニーズを引き出しましょう。
少し難しいですが、顧客が頭の中で描いているものを図示、文書化して明確にするように心がけるとよいかと思います。ニーズが引き出せるようになると双方にメリットがあります。
顧客側…ニーズが満たされた満足度の高いシステムが得られる
受注側…作業が明確になり、余計な作業や手戻り作業が減る
ラーメンの例えでいうならば、顧客の真のニーズが「変わったギトギトラーメンを作りたい」であれば問題はありませんが、「美味しいギトギトラーメンを作りたい」ならば、チョコレートではなく別のものに変えた方がニーズに寄り添えるかもしれないと気づくことができます。
ニーズを引き出し、目的を明確にできるように心がけましょう。
5.承認を得る
プロジェクトがスタートすると、プロジェクトスコープ記述書の変更がしにくくなります。また、プロジェクトが進み顧客に完成品を見せた時に「思い描いているものと違った」と言われることもありえます。
スコープの内容と変更がしにくくなる旨をステークホルダーにしっかり伝えて、承認をもらい、ステークホルダーと開発チームが同じ認識を持てるようにしましょう。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
システム開発プロジェクトのスコープとは？まとめ
システム開発ではスコープの定義は重要です。定義が明確でないと、コストやスケジュールが膨れ上がり、いつまでもシステムが完成しない原因につながります。
スコープマネジメントは主にシステム開発会社側がメインで行いますが、発注側も把握して同じ認識を持っていることが重要です。認識ズレをなくすために文書によく目を通していただき、わからないことがありましたら気軽に質問いただき、ご理解いただいた上で承認いただけましたら幸いです。
やること、やらないことを明確に決めて開発をスムーズにすすめましょう。
