どんな企業の開発チームであっても、要件、要求、その他の作業がリリース日を延ばすことなく追加される、まるで独り歩きしているようなプロジェクトへの対応を迫られることがあります。
通常、プロジェクトの予定は、当初のスコープに含まれていなかった内容に対応するために多少の余裕を持って設定されますが、不測の追加が多すぎると、タイムライン、予算、生産性や品質管理の面で大きな問題となります。
この記事では、スコープクリープ(Scope creep)を回避し、プロジェクトのスコープを超えた予期せぬ追加や変更が大量にプロジェクトに入り込むのを防ぐための方法やヒントを紹介します。
プロジェクトスコープとは？
プロジェクト管理におけるスコープとは、プロジェクトの目標、成果物、タスク、コスト、予算、期限、タイムライン、プロジェクトを完了するために必要な作業やリソースをリストアップした計画の一部を指します。
プロジェクトのスコープは、プロジェクトの境界、チームメンバーの責任範囲、完成した作業のテスト、検証や承認に使用されるプロセスを定義するために使われます。
スコープクリープとは？
「スコープクリープ」とは、プロジェクトが当初の目標や境界を越えて膨張し始めたときに起こる現象を表す言葉で、チームがプロジェクトのスコープを把握していない場合や不測の「必須」機能が追加される際などに発生します。ステークホルダーが時間的制約や予算を無視して追加の機能や特性を要求してくる場合にも起こります。
プロジェクトが開始から完成まで途中で一切変更されることなく進むことはほぼありません。通常は、予定から外れずに小さな修正を途中で加えることができますが、あまりにも変更要請が多く、リソース、費用や時間の追加投入を迫られると、スコープクリープが深刻な問題を引き起こすことになります。
スコープにあらかじめ柔軟性を持たせる方法
ある程度のスコープクリープが発生するのは避けられないことが多いため、マイナーな変更に対応できるよう、スコープの定義の際には少し柔軟性を持たせるようにするとよいでしょう。スコープ、スケジュールや予算の変更自体を計画することはできないので、プロジェクトをどの程度まで変更できるか、境界線を決めておく必要があります。
このためには、3つの制約理論 (プロジェクト管理の三角形) を使いましょう。これは、1つの境界を変更する場合には、他の境界は制約として動かさないという考え方です。
例えば、スケジュールや予算に制約があって変更できない場合、スコープには変更の余地が必要になり、機能や性能面での要望を時間や予算と照らし合わていくことになります。特定の機能の追加のために資金や時間の追加投入が必要となる場合には、その機能は次のイテレーションで実装するよう先送りします。その新機能が必須の場合には、プロジェクトを期限内、予算内に収めるため、スコープから外せる他の機能を検討します。
スコープクリープが起きる主な原因
スコープクリープがプロジェクトに影響を及ぼす理由には、例えばスコープが文書で明確に定義されていない、「ノー」と言えないなど、さまざまな理由があります。一般に、顧客、経営陣、その他のステークホルダーの満足度を優先した結果であることが多いようですが、それでチームのストレスレベルが上がるようでは、プロジェクトの成功も危うくなります。
よりストレスフリーな環境で作業を進められるよう、スコープクリープが発生しやすい状況とその対策について見ていきましょう。
要件が不明確、または要件の定義が不十分
スコープや作業は、プロジェクトの開始時点で明確かつ詳細に定義されている必要があります。ただ、プロジェクト範囲記述書を作成するのは、プロジェクトで必要となる要件を定義してからにすることも重要です。
要件が十分に検討されていないと、スコープがステークホルダーのニーズよりも予測と曖昧な考えに基づいて決められることになり、スコープクリープの温床となります。こうなると、顧客、役員、マネージャー、チームメンバーがそれぞれ勝手にプロジェクトを定義し始めることになります。
スコープクリープを避ける方法 : 完全な要件分析が完了するまでプロジェクトを延期します。その後、詳細なプロジェクト範囲記述書かプロジェクト憲章を作成し、その中でスケジュール、予算、完了すべき作業、その作業をすべきチームメンバー、作業の完了に必要となるリソースなどを明確に定めます。
