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

たとえばこんな場合を想像してみてください。あなたはプロジェクトと成果物の作成に懸命に取り組んでいます。すると突然、別部門の関係者から追加の成果物を頼まれました。予定外でしたが、それほど難しいことではなかったので了承しました。数日後、さらにまた別のメールが届きました。順調に進むはずだったプロジェクトが突如として遅れ、失敗に終わってしまいました。

これがスコープクリープです。そして、これは誰にでも起こり得ることです。この記事では、スコープクリープの原因とその防止策について解説します。

プロジェクト管理におけるスコープクリープとは？

プロジェクト管理では、プロジェクトスコープとはプロジェクトの要件と成果物の概要を指します。プロジェクトスコープは通常プロジェクト計画プロセスの最初に定義され、プロジェクト計画やロードマップ、プロジェクト概要といった形で表現されます。スコープクリープとは、要求や成果物がその事前に決定したプロジェクトスコープを超えてしまったときに発生する問題です。

なぜプロジェクトスコープの設定が重要なのか？

プロジェクトマネージャーは、スコープマネジメント計画を設定することにより、そのプロジェクトの関係者との共通理解を形成します。プロジェクトスコープを設定しないと、プロジェクトの成果物に何が含まれ、何が含まれないのかを明確に定義し、事前に承認した上でプロジェクトをコントロールすることができなくなります。

スコープクリープが無害な場合もあります。多少厄介ではあっても、結果として成果物が 1 つか 2 つ増えるだけで、プロジェクトに大きな影響を及ぼさない場合などです。しかし重大なスコープクリープが発生した場合、プロジェクト目標から注意がそれてしまい、プロジェクトの成功の妨げとなります。追加された要求や成果物に費やされた時間は、プロジェクトの本来の目標に費やされなかった時間でもあり、燃え尽き症候群や過労につながる恐れもあります。

プロジェクトスコープを明確にするには

つまり、スコープクリープを防ぐためには、まず明確なプロジェクトスコープが必要です。安心してください。それほど難しいものではありません。プロジェクトの要旨など、プロジェクトの初期に決定した他の文書の内容をもとにいくつかの項目について書き出すだけです。

プロジェクトスコープを明確にして決定するには、次の 5 つのステップに従ってください。

1. 「なぜ」から始めます。なぜあなたとチームはこのプロジェクトに取り組むのか？何を達成したいのか？達成したいことの規模や範囲を知ることで、プロジェクトスコープの定義が容易になります。

2. プロジェクト目標を取り入れます。プロジェクト目標とプロジェクトスコープは密接に関係しています。あなたの目標はプロジェクトの目標を定義していると同時に、プロジェクトスコープの範囲内に収まっている必要があります。

3. プロジェクトスコープを書き出します。たくさん書き出す必要はありません。プロジェクトスコープとは、プロジェクトの成果物と、それらの成果物がプロジェクト目標とどのように関連しているのかを明確にするためのものです。箇条書きでも構いません。

4. プロジェクトスコープを見直します。プロジェクト関係者の賛同を得ていること、プロジェクトの成果物、目標、範囲に関する全員の理解が一致していることを確認します。

5. 必要な場合は調整します。ステップ 4 で理解が得られなかった場合は、プロジェクトスコープを書き直す時間を取ります。確定する前にもう一度関係者に確認してもらい、賛同を得られるようにしましょう。

スコープクリープの 7 つの主な原因

できれば本来の目的を見失わず、プロジェクトを成功させたいものです。ここでは最も一般的なスコープクリープの原因と、その防止策を紹介します。

1. プロジェクトスコープがない

これは説明するまでもないかもしれませんが、どれだけ強調してもしすぎることはないポイントです。プロジェクトスコープがないと、共通理解を得る方法がなく、プロジェクトに関わる人々にプロジェクトの範囲を伝えることもできません。さらに外部のチームやエージェンシーも関わっていた場合は、関係者がプロジェクトに新たな要素を追加しようとしたときに提示する文書や作業指示書 (SOW) もないことになります。

プロジェクトの初めには必ずプロジェクトスコープを作成、定義するようにしましょう。また、それをプロジェクト計画やその他の初期文書に取り入れましょう。これにより、プロジェクトスコープのベースラインをすべてのプロジェクト初期文書に組み込むことができます。

2. コミュニケーション不足

プロジェクトスコープが用意できたら、共有しなくてはなりません。プロジェクトの早い段階で文書をうまく配布できなければ、関係者と情報を共有することができません。せっかく時間を取ってプロジェクトスコープを作成しても、その存在を全員が認識していなければ、理解のずれに苦しむことや、プロジェクトが失敗してしまうこともあり得ます。

プロジェクト計画やプロジェクト概要など、どのプロジェクト初期文書にも必ずプロジェクトスコープを取り入れるようにしましょう。そうすることで全員がプロジェクトスコープを確認でき、理解のずれがあればプロジェクトが始まる前に修正することができます。

3. 不明確なプロジェクト目標

そもそも、プロジェクトに取り組んでいるのは特定の成果物を出すためです。その成果やアセットが、プロジェクト目標です。

プロジェクト目標が明確な場合、あなたのプロジェクトチームは最終的にこのプロジェクトで成功を収めるには何が必要で、何が必要でないのかを簡単に把握することができます。そうすれば、生産的で優先度の高い作業に労力とエネルギーを集中させることができます。その一方で、プロジェクト目標が不明確な場合、チームメンバーはどの作業を優先するべきかわからず、プロジェクト目標の達成に寄与しないタスクに取り組んでしまうかもしれません。

不明確なプロジェクト目標の例: 会社のブログを改善し、読者が気に入るストーリーを取り上げる。

明確なプロジェクト目標の例: 第 1 四半期に、お客様の体験談、ヒント、新しい製品機能、チーム特集、ソートリーダーシップなど、最低でも 5 種類のブログ記事を作成する。新しいブログを投稿するたびにエンゲージメントを注意深くモニタリングして、それ以降の期間でクオリティを高めていく 3 種類のカテゴリを決定する。

4. 非現実的なプロジェクト目標

たとえプロジェクト目標が明確でも、チームが時間内で (そしてプロジェクトの範囲内で) 現実的に達成できるものではなかった場合、必然的にそのプロジェクトは失敗するか、スコープクリープが発生してしまいます。

チームのリソースを使って、期間内に目標が達成できるようにしましょう。プロジェクト目標とスコープ、プロジェクトのスケジュールを照らし合わせて、最終的にプロジェクトが成功するようにしましょう。プロジェクト開始時にプロジェクト目標とプロジェクトスコープの間にずれが生じていると、スコープクリープに対処することはほとんど不可能になります。

5. 関係者が多すぎる

皆がハンドルを握ろうとしてしまうと、プロジェクトの進行は非常に難しくなります。プロジェクトオーナー、つまりプロジェクトマネージャーが明確になっていなければ、作業が混乱し、スコープもわかりにくくなってしまいます。

プロジェクトには大勢の関係者や協力者がいますが、必ずすべてのチームに作業の進行責任者を務めるプロジェクトリーダーを置くようにしましょう。新しい役割を設ける際は、RACI チャート (RACI 図、RACI マトリックス) を作成するといいでしょう。RACI という名前はプロジェクト管理における以下の 4 つの役割から来ています。

• Responsible (責任者) プロジェクトを進行させる人です。現場での決定のほとんどは、責任者が行います。

• Approver (承認者) 時々、関係者からの承認が必要になるかもしれません。承認者が予算や目標、方針などを設定することがあります。

• Consulted (相談先) 相談先とは、意見や洞察、アドバイスなどを得るための相談相手となる人々です。最終的な決定権を持つのは責任者や承認者であり、通常はその分野の専門家が相談先となります。

• Informed (報告先) 報告先は、プロジェクトのことを知っている必要のある人々です。プロジェクトチームや複数部門の関係者、経営幹部のリーダーなどが当てはまります。

6. 効率の悪い変更管理プロセス

たとえ役割が明確に決められていたとしても、効果的な変更管理プロセスが必要になります。変更管理とは、プロジェクトスコープなど、プロジェクトにおいて重要または基礎となる要素を変更するプロセスです。変更管理プロセスには、プロジェクト変更の手順として一連のルールや規制が設けられており、関係者が自分で簡単に変更を加えることができなくなります。通常、チームメンバーや関係者が変更リクエストを送り、プロジェクトマネージャーや他の重要なプロジェクト関係者がそのリクエストを確認し、その後システムによってその変更が承認、却下、保留されるという流れになります。

変更管理プロセスは、どうしても必要な場合に新たなリクエストを追加できる柔軟性を持たせながら、プロジェクトのコントロールを取り戻すことを可能にする重要なプロセスです。変更管理プロセスがあれば、プロジェクトの詳細が変更になっても、常にそれは正当な理由に基づく変更であることを確認できます。

7. ギリギリの顧客フィードバック

顧客フィードバックは、新製品やマーケティングキャンペーンなど、顧客と接する仕事で重要となります。フィードバックを積極的に収集しなければ、プロジェクトの意図やスコープ、タイムライン、目標を 180 度変えてしまうような重要なフィードバックが、手遅れになってから手に入る可能性があります。すでに着手しているものが変更になってしまったり、新機能や新しい要件のために一からやり直しになってしまうことも考えられます。

あなたは人間であり、顧客も人間です。ギリギリの変更が発生することもあるでしょう。そして、残念ながらこれに関してはほとんどどうしようもありません。プロジェクトの大きな要素を変更しなければならなくなることもあるでしょうし、それを防ぐための手段もなかったかもしれません。

こういったことが発生する可能性を低くするには、多くの顧客フィードバックを早い段階で得ることです。ユーザーフィードバックを定期的に収集し、顧客フィードバックを積極的に集めるようにしましょう。無料ユーザーリサーチ用テンプレートもお試しください。

スコープクリープへの対処と防止策

すでにプロジェクトを始めていて、スコープクリープが心配なときは、どうすればいいでしょうか？

スコープクリープが発生しそうだと感じたら、いくつかできることがあります。

1. プロジェクトスコープを再度確認しましょう。プロジェクト関係者が別の新たな成果物に着手しているなら、もう一度プロジェクトスコープを持ち出して、何が含まれていて、何が含まれていないのか思い出させましょう。うまくいけば、プロジェクトチーム全体がプロジェクトの要件を再認識できるでしょう。

2. それがうまくいかなかった場合は、変更管理プロセスを試しましょう。準備しておいた変更管理プロセスを通して、リクエスターに変更リクエストを送信してもらい、プロジェクトの関係者とリクエストの内容を確認し、プロジェクトスコープを変更するだけの価値があるものかを判断しましょう。

3. スコープの変更が承認されたら、他の成果物の優先順位を下げることを検討しましょう。新たな仕事のために、後回しにできることや完全に省けることはありませんか？

4. 現在計画されている他の仕事の優先順位を下げることが不可能であれば、プロジェクトリソースを確認しましょう。リソース管理計画を使用して、プロジェクト目標達成の助けとなるリソースがないかチェックしましょう。

プロジェクトスコープ、目標、計画、すべてを把握し、明確に維持するためには、Asana のようなワークマネジメントツールを使用しましょう。Asana を使えば、ワークフロー全体を管理してプロジェクトチーム全体と共有できるため、全員に共通理解を持たせることができます。

スコープクリープとおさらば

「スコープクリープは起こるものだ」という意見もあるかもしれません。しかし、必ずしもそうではありません。明確なプロジェクトスコープと、わかりやすいプロジェクト計画、そして使いやすいワークマネジメントツールがあれば、プロジェクトスコープから外れることなく、プロジェクト目標は達成できます。

ワークマネジメントを始める準備はできましたか？Asana について、もっと詳しく知りましょう。