プロジェクトスコープとは？8 つのステップで定義する方法

プロジェクトの範囲を明確に定め、成功へと導く管理手法「プロジェクトスコープマネジメント」について詳しく知りたい方は『プロジェクトスコープマネジメントとは何か』の記事をご覧ください。また、自由自在にカスタマイズできる Asana のスコープ管理テンプレートはこちらからご利用いただけます。

プロジェクトスコープとは？

プロジェクトスコープは、プロジェクトのいわば境目を明確にする手段であり、目指す目標、スケジュール、プロジェクトの成果物を明確に定義するものです。プロジェクトのスコープを明確にすれば、締め切りに遅れたり、働きすぎたりせずに、プロジェクトの中長期目標を達成できます。

プロジェクトスコープは単独で定義するものではありません。むしろ、重要なプロジェクト関係者 (ステークホルダー) と意見を一致させ、全員が共通認識を持てるようにする必要があります。たとえば、製品のマーケティングキャンペーンに取り組んでいるのなら、製品チームや、デザインチーム、コンテンツチームなど、社内の関連するチームの関係者と連携をとることが大切になります。プロジェクトの複雑さによっては、変更管理プロセスを定義することもおすすめします。その方法については後述します。

プロジェクトスコープの重要性

「プロジェクト」とは、目的を達成するための計画を指し、「スコープ」は範囲を意味します。そして「プロジェクトスコープマネジメント」とは、プロジェクトの範囲を明確に定め、成功へと導く管理手法のことです。  

プロジェクトが失敗してしまう原因は多々考えられます。しかし代表的な失敗原因は「スコープを定めていなかった」というものです。つまり、プロジェクトスコープマネジメントの失敗に由来するものです。  

目的を達成するために遂行すべき業務の範囲を明確にしていなければ、無理や無駄が生じ、結果的にプロジェクト全体が失敗に至ってしまうでしょう。スコープが曖昧では、担当者もどこからどこまで手をつけてよいのかわからず、本来必要のない作業をしてしまう恐れが強まるのです。  

プロジェクトのスムーズな達成には、遂行すべき業務の範囲を定め、そうしたリスクは軽減させることが重要です。このような理由から、プロジェクトスコープは「PMBOK (プロジェクトマネージメントのフレームワーク)」における、行うべきプロセスの1つとして組み込まれています。PMBOK は、プロジェクトマネージメントの世界標準です。そこへ 1 つの計画項目として定められていることからも、プロジェクトスコープの重要性が、国際的にも高く認識されていると理解できるでしょう。

プロジェクトスコープと成果物スコープとの違い

プロジェクトスコープは「やるべきこと」の範囲です。一方、成果物スコープ (プロダクトスコープ) は「何を作るか」を定めたものを指します。前者は作業範囲、後者は作るものの範囲と考えればわかりやすいのではないでしょうか。  

たとえば、自社で車を開発しようとしているのなら、基本コンセプト設計、テストカーの製作、製造、試乗テストなどが必要です。これらのプロセスをより細分化し、それぞれに必要な作業の内容をピックアップします。これがきちんとできていないと、無駄な作業の発生をはじめとしたさまざまなトラブルが発生しかねません。

では、このケースにおける成果物スコープは何なのでしょうか。テストカーの製作で考えれば、設計図や仕様書、テストカー本体などが挙げられます。何を作るかを決めておけば、現物でプロジェクトの進捗をチェックできることがメリットと言えるでしょう。

プロジェクトスコープ記述書とは？

プロジェクトスコープ記述書 (ステートメント) は、単純にプロジェクトスコープを書き出した文書です。プロジェクトの複雑さによって、プロジェクト計画書の一つのセクションであることもあれば、独立した文書であることもあります。また、社外のチームやエージェンシーと一緒に働いている場合は、ベンダーとの合意を固めるために、プロジェクトスコープ記述書を作業指示書 (SoW) として使ってもよいでしょう。

スコープクリープとは？

スコープクリープとは、プロジェクトの成果物がプロジェクトのスコープを超えて肥大化することです。

たとえば、プロジェクトスコープ記述書を書かずに、製品リリースに取り組んでいるとしましょう。プロジェクトの中間地点に差しかかると、ある関係者がプロジェクトの成果物にプレスリリースを追加します。その数日後には、また別の関係者が新製品に関するブログ記事を追加します。このように、プロジェクトチームが予想していなかった仕事や、対応する準備ができていない仕事が増えると、不要なストレスを感じたり、プロジェクトの元々の成果物の進行が遅れたりする場合があります。

プロジェクトでスコープクリープが発生すると、メンバーは予想外のタスクを実行することになります。結果、プロジェクトの遅れやオーバーワーク、成果物の質が落ちるという事態が発生します。

スコープクリープを回避する一番の方法は、堅実なプロジェクトスコープ記述書を前もって作成し、プロセスのできるだけ早い段階で関係者と共有することです。そうすると、関係者全員がプロジェクトの目的と対象外の事柄について共通認識を持てます。

プロジェクトスコープを定義するメリット

プロジェクトスコープの定義は、プロジェクト計画に欠かせません。明確なスコープステートメントがないと、プロジェクトはチームが対応できなくなるほど方向性がズレたり、肥大化したりして、プロジェクトの遅延やバーンアウトの原因になりかねません。プロジェクトスコープがあれば、プロジェクト全体のライフサイクルをイメージしやすくなり、達成可能な最終目標を掲げることができます。

具体的には、以下のようなメリットが挙げられます。

• すべての関係者がプロジェクトの境目を明確に把握できるようにする

• ステークホルダーの期待事項を管理し、同意を得る

• プロジェクトのリスクを抑える

• 予算、コストおよびリソース計画を適切に行う

• プロジェクトの照準をメインの目標に合わせる

• スコープクリープの発生を避ける

• 変更リクエストのプロセスを確立する (プロジェクトが複雑な場合)

プロジェクトスコープを定義する 8 つのステップ

それでは、プロジェクトスコープを定義していきましょう。スコープを定義するには、次のステップを順に踏んでいきます。

1. プロジェクトの目標を立てる

プロジェクトのスコープを定義する前に、まずは目標をまとめる必要があります。プロジェクトの目標とは、プロジェクトの終わりに納品するアセットです。プロジェクトスコープは、最終的には目標達成に導いてくれるものですが、まずは何を「目標」にするのかを知っておく必要があります。

2. リソース計画を立てる (まだない場合)

プロジェクトの目標に加え、どのリソースを使用できるのかという認識も必要になります。プロジェクトマネジメントにおけるリソースとは、プロジェクトの予算からチームの余力まで、あらゆるものを意味します。リソース管理計画を使って、自分のプロジェクトで使用可能なリソースとその用途を整理します。

プロジェクトスコープは、リソース管理計画を定義してから作成しましょう。そうすれば、使用可能なリソースがはっきりとわかった状態でプロジェクトスコープ記述書を書けるほか、リソースの有無に基づいてプロジェクトスコープを調整することもできます。

3. プロジェクトの要件をまとめる

クライアントや取引先など、プロジェクトに関わる関係者から要件の収集を行うプロセスです。収集するだけではなく、要求事項文書や要求定義書に文書化するまで、一連の流れとして実行します。  

プロジェクトを完遂するには、利害関係者のニーズを満たさなくてはなりません。関係者のニーズや要望を基に見積もりも行うため、コストにも大きく関わります。そうした理由からも、非常に重要なプロセスと言えるでしょう。  

利害関係者のニーズや要望を正確に汲み取り、プロジェクトへ反映させるには丁寧なヒアリングが必要です。そのため、実際の要件収集においては、インタビューや話し合いなどを通じて具体的な要望を抽出します。

プロジェクト初期計画にはさまざまな重要要素がありますが、この時点ではプロジェクトスコープに影響しうる要素に注目しましょう。プロジェクトスコープは、プロジェクトの境目や主要な目的、予算、リソース、成果物を定義し文書化する手段であることを忘れないでください。そうしたものに影響しうるもの、たとえば、プロジェクトタイムラインなどがあれば、このタイミングで集めておきましょう。

4. プロジェクトスコープ記述書のドラフトを作成する

利害関係者たちから汲み取った要望、ニーズに基づき、作業や成果物の範囲を明確に定義するプロセスです。ここですべての情報を 1 か所に書き出すわけですが、それがプロジェクトスコープ記述書となります。そこには、どのような作業を行い、どういったものを作るか、実行する事柄、しない事柄、その理由などを説明します。

プロジェクトの複雑さによって、プロジェクトスコープ記述書は箇条書きであることもあれば、長めのパラグラフや完全な SoW である場合もあります。どのような長さにする場合でも、プロジェクトスコープ記述書は、プロジェクトの目標からプロジェクトで実行する事柄や実行しない事柄までが書かれたものでなくてはいけません。

スコープの定義に困ったら、まずは次の問いに答えてみましょう。

• このプロジェクトを実行する目的は何ですか？最終的な目標と成果物は？

• どのような制限がありますか？予算やメンバーの数、リソースはどれだけありますか？どのチームメンバーが参加しますか？

• 成果物の締め切りはいつですか？どのようなタイムラインを達成する必要がありますか？

• プロジェクトのスコープ外にあるのは何ですか？

プロジェクトスコープ記述書の例

たとえば、会社のウェブサイトを再構築するとします。その場合、以下のようなプロジェクトスコープが考えられます。

• プロジェクトの目的: ページの表示速度と柔軟性を改善するために、ウェブサイトのバックエンドを CMS プラットフォームに移行する。

• リソース:

  • ウェブチーム (3 人)、30 時間 /週、6 週間

  • エンジニアリングマネージャー (1 人)、10 時間 /週、6 週間

  • IT & 法務によるレビュー (2 チーム)、5 時間相当の単発作業 /週

  • CMS の予算 100 万円

• 成果物:

  • コンテンツライター全員を対象とした研修を 2021年 5月後半に実施

  • 2021年 6月までにウェブサイト全体を新しい CMS に移行

• プロジェクトロードマップとタイムライン:

  • 4月 26日: CMS のスコーピング開始

  • 5月 10日: IT & 法務によるレビュー

  • 5月 17日～6月 3日: ウェブチームの移動

  • 5月 31日: コンテンツライター向け研修

  • 6月 4日: CMS を公開

• スコープ外:

  • 新規 DAM システム

  • 新しい CMS のカスタマイズ可能なウェブページ

5. 主な関係者から同意と承認を得る

プロジェクトスコープ記述書を承認する前に、必ずステークホルダーの同意を得るようにします。これは、変更を加えたり、プロジェクトの目標を考え直したり、プロジェクトのスコープに含めるもの、含めないものを決定したりするよい機会になります。一旦プロジェクトがスタートすると、プロジェクトスコープ記述書の要素は変更しにくくなるため、スコープの内容は関係者にしっかりと伝えておきましょう。

6. 必要に応じて変更管理プロセスを確立する

関係者が多い場合や、複雑なイニシアチブを管理している場合は、変更管理プロセスを作成するとよいかもしれません。大規模なプロジェクトや複雑なプロジェクトでは、必ずといっていいほど変更が必要になります。タイムラインの計画が楽観的すぎたり、新規顧客のフィードバックを受けて重要な成果物をいくつか変更する羽目になる可能性もあります。プロジェクトは、絶対に変更できないのもよくありませんが、誰でも気軽に変更できてしまっては、スコープクリープが発生しかねないので、それもよくありません。

変更プロセスは、関係者が変更内容を承認する前に実施する一連のプロセスです。変更管理プロセスを作成するには、一元管理された受領フォームを使うなど、プロジェクトチームや関係者が変更リクエストを提出する手段を確立します。そして、事前に選別されている重要な関係者たちが変更内容を審査し、変更のリクエストが追加するに値するほど重要かどうかを確認します。それに値すると判断されれば、スコープクリープの発生を防ぐ手段として、実行を計画していた作業をいくつか優先事項から外せないかどうかを確認します。

7. プロジェクトスコープ記述書をチームと共有する

関係者がプロジェクトスコープに目を通し、署名した後は、それをプロジェクトチームと共有します。すべての作業にアクセスできる、ワークマネジメントツールのようなワンストップショップをチームのために用意します。

8. プロジェクトの進行中にプロジェクトスコープ記述書を参照する

プロジェクトスコープを頻繁に読み返せば、仕事を順調に進められますし、スコープクリープのリスクも回避できるので便利です。変更管理プロセスを通していない新しい要素をプロジェクトに追加しようとするメンバーがいれば、プロジェクトスコープ記述書を参照して、そのアイデアをリクエストか「ファーストフォロー」として提出するようすすめてください。

また、スコープを定めても、その状態が継続されるとは限りません。初期段階では問題なくプロジェクトを進められていても、途中で問題が発生してしまうことは十分考えられます。

そのため、スコープを定めてからも作業の範囲や成果物の品質を監視し、状況に応じて変更を行いましょう。これをスコープコントロールと言います。計画時と作成段階での製品品質に差異が生じた状態でプロジェクトを進めても、クライアントのニーズを満たすことはできません。スコープコントロールを念頭にプロジェクトを進めましょう。

プロジェクトスコープ作成時の注意点

プロジェクトスコープを作成するにあたり、いくつかの注意点を把握しておきましょう。大切なポイントはいくつかありますが、特に重要なのは関係者間における目的共有と、スコープの可視化による情報共有です。

プロジェクト関係者と目的を共有する

プロジェクト関係者全員が満足して初めて、プロジェクトは成功したと言えます。成功へ導くには、関係者間における目的共有が大切です。

クライアントの要求を一番に考えるのは当然であり、素晴らしいことですが、もしかするとその要求は目的に適していないかもしれません。クライアントの知識不足や勘違いにより、目的に適さない要求を伝えてくる可能性は十分あるのです。

「クライアントの意見が第一だ！」とそのままプロジェクトを進めてしまうと、失敗してしまう恐れがあります。このようなことが起きないよう、クライアントの要求が目的に即したものかどうか、しっかり判断しなければなりません。プロジェクト関係者間で目的共有を入念に行い、そのうえでクライアントの真の目的、ニーズを導き出しましょう。

スコープを可視化してシェアする

プロジェクトに関わる作業者はもちろん、クライアントともスコープを共有しましょう。可視化することにより、要件や要望をその都度確認できるからです。可視化していない状態でプロジェクトを進めてしまうと、要件漏れが生じる恐れがあります。

初期段階で要件漏れに気づけば小さなダメージで済みますが、終盤にさしかかって気づくと大変です。場合によっては初期のプロセスからやり直しせざるを得なくなり、大幅にスケジュールが遅延してしまう恐れもあります。  これまでの作業が無駄になってしまう可能性もあり、再度最初からやり直しとなるとコストもオーバーしてしまうでしょう。このような事態を招かないためにも、スコープを可視化して関係者全員で情報を共有しなければなりません。

スコープを可視化するといっても、それほど難しいことではありません。きちんと文書にして、関係者が確認できる体制を整えればよいのです。機密性の高いプロジェクトなら、電子文書としてクラウド保存し、関係者だけにアクセス権を付与するとセキュリティ面でも安心です。  認識の食い違いや、要件漏れの早期発見を防ぐため、必ずスコープの可視化を心がけましょう。

まとめ

プロジェクトスコープの意味と特定するメリット、定義するときのステップについて解説しました。プロジェクトスコープは、プロジェクトを順調に進め、成功に導くのに必要不可欠です。プロジェクトチームを支え、燃え尽き症候群から守るのに適した方法でもあるので、プロジェクトマネージャーなら必ず定義付けすることをおすすめします。

しかし、プロジェクトスコープは効果的に伝えなければ効果を発揮しません。プロジェクトの早い段階でメンバーに公開し、プロジェクトを進行させながら頻繁に参照してください。