アトラシアン本社の情報サイト『WORK LIFE』から新着コラム。ライターのハローナ・ブラック(Halona Black)と、編集長のローレン・パーカー(Lauren Parker)が、開発プロジェクトで起こりがちな「スコープクリープ」を抑制する方法について解説する。

本稿の要約を10秒で

  • 「スコープクリープ」とは、プロジェクトの3大要素である「スコープ(範囲)」「コスト(予算)」「スケジュール(時間)」のうち、スコープが当初の計画よりも大幅に拡大してしまう現象を指す。この現象は、開発プロジェクトにおいて発生しがちな問題である。
  • 情報の共有や適切なチェンジマネジメントによってスコープクリープによる悪影響を最小限に抑えることができる。ただし、スコープクリープの発生を完全に回避するのは難しい。
  • スコープクリープは「絶対悪」ではなく、場合によっては、プロジェクトに創造性や革新性をもたらしたり、当初の計画よりも良いプロダクトを生み出す動力になったりする。

「スコープクリープ」とはそもそも何か

本稿の主眼は「スコープクリープ」と呼ばれる現象を抑制する方法を示すことにある。その方法を明らかにする前に、「スコープクリープとはそもそも何か」について説明しておきたい。

プロジェクトには3つの大きな要素がある。それは「スコープ(範囲)」と「コスト(予算)」、そして「スケジュール(時間)」だ。この三大要素のうちスコープとは、プロジェクトがカバーすべき「範囲」を意味している。例えば、プロダクトの開発プロジェクトであれば、そのプロダクトが満たすべき要件(機能要件やビジネス要件)がスコープに当たる。

そして「スコープクリープ」とは、プロジェクトのライフサイクルの中で、プロジェクトチーム(ないしは、開発するプロダクト)が満たすべき要件が、想定以上に拡大してしまう現象を指している。この現象は、スケジュールの遅れや予算の超過、リソース不足といった問題を引き起こし、他のプロジェクトのスケジュールや予算、リソースにも悪影響を及ぼすことがある。

言うまでもなく、スコープクリープは、プロジェクトマネージャーやプロジェクトメンバーにとって好ましい現象ではない。その発生は、プロジェクトメンバーにストレスを与え、成果物の品質低下も招きかねない。それゆえに、スコープクリープは一般的に、プロジェクトにおける「絶対悪」とされ、是が非でも回避すべき対象とされている。ただし、スコープクリープは絶対悪ではなく、プロジェクトチームやチームが開発するプロダクトにプラスの効果をもたらすこともある。

スコープクリープはなぜ起きるのか

スコープクリープが起きる要因は大きく以下の2つに分けることができる。

要因① 計画不足、ないしは不測の事態

プロジェクトマネージャーは、プロジェクトの計画を策定するに際して、さまざまな要素を念入りに検討しなければならない。具体的には、プロジェクトのスコープや予算をはじめ、「予算管理の方法」や「タイムライン(行動計画)の設定」「スケジュール管理の方法」「プロジェクトの要員」「要員のチーム化」といった事柄を入念に検討して設定していく必要がある。

これら要素のうち1つでも検討をおろそかにすると、プロジェクトの始動後にスコープクリープが発生するリスクが高まる。

とはいえ、プロジェクトマネージャーは超能力者ではなく、未来を完璧に読むことはできない。ゆえに、いくら入念に計画を立てても、不測の事態の発生によってプロジェクトの置かれた状況が一変し、計画の大幅な変更を余儀なくされることがある。

また、メンバー同士の連携がスムーズな、スピード感に溢れたチームでも、予想外の障壁に突き当たり、作業をなかなか前に進められなくなることがある。さらに、予期せぬ技術的トラブルが発生し、作業が一定期間ストップしたり、協力会社の問題によって予算の大幅な見直しを迫られたりすることもある。

したがって、プロジェクトマネージャーには「計画性」や「優れたチームを組織する能力」に加えて、不測の事態に速やかに対応・対処できる「柔軟性」や「俊敏性」、さらにはプロジェクトにくるいが生じ始めた兆候を見逃さない「観察力」が求められる。

要因② コミュニケーション不足

スコープクリープが発生するもう一つの要因は、コミュニケーション不足である。

例えば、プロジェクトマネージャーが綿密な計画を立てたとしても、プロジェクトメンバー全員とのコミュニケーションを通じ、計画内容についての理解と同意を得なければ、マネージャーが立てた計画どおりに物事は進まない。

実際、プロジェクトにおける自分の責任範囲や問題が起きたときの対処法、あるいは、対処のために使える予算の上限などを知らないプロジェクトメンバーが一人でもいれば、綿密な計画を立てた意味は希薄化してしまう。

加えて言えば、プロジェクトメンバー各人に計画の意思決定に関与し、その内容に同意したとの実感がない場合には、メンバーは計画どおりに作業を進める意欲を保てない。結果として、綿密な計画が無力化してしまうリスクも膨らむのである。

また、新しく結成されたプロジェクトチームや、特定のプロジェクトを推進するために一時的に組織されたチームは、メンバー同士がお互いのコミュニケーションスタイルをよく理解できていない。そのため、相互の意思疎通・連携がスムーズにとれず、結果として、チームワークのパフォーマンスがプロジェクトマネージャーの想定を下回ってしまうことがある。ゆえに、プロジェクトマネージャーは、チーム内における情報の透明性や可視性、さらには心理的安全性を確保するための術(すべ)を確立しておく必要がある。

なお、スコープクリープの抑制に役立つコミュニケーションのあり方については後述するが、アトラシアンの「Team Playbook」では、顧客、あるいは利用者にプロダクトを届けるまでの複雑に入り組んだ物事の流れを整理し、プロジェクトかかわるチームメイトやステークホルダーを同じ情報のページに集めるテクニックが紹介されている。こちらも併せて参照されたい。

実例:悪名高きデンバー国際空港のスコープクリープ

スコープクリープの実例として、米国で最も悪名が高いものといえるのが、1995年にデンバー国際空港(以下、デンバー空港)で起きた「自動手荷物運搬システム」の騒動だ。

このシステムは、旅客の手荷物を自動的に処理するための大規模な仕組みであり、空港のオペレーションを効率化する画期的なソリューションとして期待を集めていた。ところが、システムの開発は当初の予定より16カ月も遅延し、予算超過分の開発費だけで5億6,000万ドルに上った。しかも、紆余曲折のすえに出来上がったシステムは、当初の設計よりもはるかに小さな規模になったのである。

なぜ、このような事態が発生したかの分析は、2008年に公開された文書(英語)で詳しく行われている。その分析結果を簡単に言えば「開発の責任者が、プロジェクトの複雑さを極端に過小評価していたこと」や「開発チームがステークホルダーのフィードバックを取り入れなかったこと」など、一連の間違った行動が、大規模なスコープクリープの発生へとつながったようだ。