クイックガイド: 8 個のステップでプロジェクトスコープを定義

Julia Martins 寄稿者の顔写真Julia Martins2021年1月22日00
facebooktwitterlinkedin
プロジェクトスコープ記事バナー画像 Asana

プロジェクト管理において、プロジェクトの規模は、大きすぎても、小さすぎてもよくありません。プロジェクトのすべての成果物を包含できるほど大きく、かつ達成可能な目標として扱えるほど小さい、ちょうどいいサイズをおすすめします。

そのために、プロジェクトスコープを定義します。プロジェクトのスコープを定義すれば、プロジェクトの成果物を予定通りに、予算内で、しかもチームのオーバーワークを避けながら、完成させることができます。この記事では、プロジェクトスコープの定義と管理に必要なすべての知識について解説します。

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

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

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

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

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

スコープクリープとは?

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

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

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

記事: スコープクリープの 7 つの主な原因とその防止策

早い段階でプロジェクトスコープを定義するメリット

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

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

  • 関係者の期待事項を管理し、同意を得る

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

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

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

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

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

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

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

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

記事: 効果的なプロジェクト中期目標の書き方 (実例付)

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

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

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

記事: 初めてのリソース管理ガイド

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

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

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

ここで、これまで集めてきたすべての情報を 1 か所に書き出します。プロジェクトスコープ記述書として、実行する事柄としない事柄、その理由などを説明します。

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

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

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

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

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

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

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

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

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

リソース:リソース:

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

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

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

  • CMS の予算 $7,000

成果物:成果物:

  • コンテンツライター全員を対象とした研修を 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. プロジェクトの進行中にプロジェクトスコープ記述書を参照する

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

プロジェクトスコープで健康的な境目を引きましょう

プロジェクトスコープ記述書は、プロジェクトを順調に進め、成功に導くのにもってこいのツールです。プロジェクトチームを支え、燃え尽き症候群から守るのに適した方法でもあります。しかし、プロジェクトスコープは、効果的に伝えなければ効果を発揮しません。プロジェクトスコープは、プロジェクトの早い段階でメンバーに公開し、プロジェクトを進行させながら頻繁に参照してください。

関連記事

記事

New to cost management? Start here.