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

プロジェクトスコープマネジメントについて詳しく知りたい方は『プロジェクトスコープマネジメントとは何か』の記事をご覧ください。

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

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

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

プロダクトスコープとの違い

プロジェクトスコープとよく聞かれるビジネス用語に、プロダクトスコープがあります。作業範囲を定義するプロジェクトスコープに対し、プロダクトスコープは、成果物を定義します。プロジェクト管理においては、どちらも重要な要素となります。

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

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

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

プロジェクトスコープでしっかりと境目を引きましょう

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

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

プロジェクトを計画するときは、祝日がすでに入力されているカレンダーを使って効率的に行いましょう。詳しくは『2023年カレンダーを活用してプロジェクトカレンダーを作る』記事をご覧ください。