スコープクリープ | セルコムネット

スコープクリープとは

スコープクリープとは、プロジェクトが進行するにつれて、スケジュール・予算・資源を調整することなく、スコープが少しずつ肥大化することです。
プロジェクトは進行していく中で、新たな要件が発生したり、状況が変化することにより、スコープの変更が発生する可能性があります。
スコープの変更はプロジェクトのさまざまな面に影響するため、適切にマネジメントする必要があります。
しかしながら、現場では「少しぐらいなら」と報告・連絡・承認を経ずにスコープを勝手に変更してしまう事があります。
これが繰り返されると当初の計画（スケジュール・予算・資源）と現実のスコープが乖離して、現状を把握できなくなり、プロジェクトは次第に修羅場と化していきます。

スコープとは

スコープとは「何をやるか」「何を作るか」という範囲のことです。プロジェクトスコープについては、関係者全員で認識をあわせる必要があります。
スコープには、作業スコープと成果物スコープがあります。
・作業スコープ：「何をやるか」を決めます。
・成果物スコープ：「何を作るか」を決めます。
勝手な思い込みは大変危険です。細かなことはプロジェクトの途中で決めても良いですが、大枠で最終的なイメージがぶれないように、最初にスコープをしっかりと定義しなければなりません。
プロジェクトにおいては、早い段階でスコープの合意形成を取る必要があります。
定義したスコープが曖昧であったり、間違っていたり、過不足があると、後でもめる原因となります。
プロジェクト後半のスコープの変更は、スケジュール・コスト・品質に大きな影響をもたらします。

スコープクリープ発生の原因

スコープクリープ発生の原因には次のようなものがあります。

要件定義が不完全
要件の理解不足
ユーザーヒヤリングが浅い
最終的なイメージまで認識が共有されていない
要件の過不足・誤りがある
要件の優先順位が理解されていない
要求の不整合に気付かない
目的に合わない機能まで対象としている
費用対効果が検討されていない
顧客が要求仕様の全てを伝えていない。または誤って伝えている
作業を進めるにつれ実装の複雑性や予期せぬ依存関係が明らかになる
ユーザーからのフィードバックで機能性能を変える必要があることが分かる
市場環境が変化し異なる機能セットが必要となる
影響範囲を調査することなく開発したため、他機能と連携が取れなくなる
顧客から「これくらいついでにやってよ」と言われ、断るのが困難になってきた。
客の強い立場を利用して、仕様凍結後も無理難題をふっかける。（モンスター顧客）

スコープクリープ発生を防ぐには

スコープクリープ発生を防ぐには以下のような注意が必要です

プロジェクトメンバー、顧客双方で、スコープについて合意する。
口頭での変更要望は受け付けず、必ずドキュメント化したもので受け付ける。
変更管理の仕組みをルール化する。
変更する場合は影響範囲を確認する。スケジュール・コスト・資源の調整をする。
仕様漏れや要件モレのレベルだと、他機能・他システムへの影響が必ず発生するので、設計＆レビューから見直す。
変更した場合は、再テストをきちと行う（省略しない・簡略化しない）
定期的に顧客と情報共有する場を設ける。
スコープ変更の場合、現場レベルで勝手に判断しないようにする。
プロジェクトメンバーが障害、トラブルを報告しにくい雰囲気にしない。

発生した問題を、設計者が隠蔽し、勝手に修正すると、プロジェクトはコントロールできなくなります。
スケジュール・コスト・資源の調整がされないまま修正に着手すると、余裕が無く小手先のテクニックでどうにかしようとします。また、影響範囲を見極めずに修正してしまうことが多いのでさらに傷口を広げてしまいます。
システムテストの段階でスコープクリープが発生してしまうと、今まで担保してきたテスト品質を破壊することになってしまいます。
プログラムの修正を行った場合は、単体テスト、結合テストなどの再テストを漏れなく実施しなければなりません。
プロジェクト後半での修正は、被害が大きくなります。初期段階で精緻な要件定義を行うことが、プロジェクト成功の秘訣です。

プロジェクトの初期フェーズでは、後工程での手戻りを少なくするために、要件定義書を作成し、業務フローに従って画面モックアップでウォークスルーレビューを実施します。
スコープの合意が形成されたら、成果物と作業を要素分解し、WBSを作成します。
プロジェクトの途中で要件の変更・追加が生じる場合は、必ずドキュメント化したもので受け付け、スケジュール・コスト・資源の調整を行います。
プロジェクトの途中で利用部門が「これじゃ使えない」「こんな機能が絶対に必要だ」と騒ぎ出すことは頻繁にあることです。
弱腰で無理無体の要求を受け入れてしまうとプロジェクトの大炎上が決定的となり、プロジェクトチームはデスマーチを歩かなければならなりません。
客の強い立場を利用して、仕様凍結後も無条件で要件変更を要求してくるモンスター顧客に対しては、初期フェーズで文書化した合意事項を元に、断固たる態度で臨む必要があります。
スコープコントロールできないプロジェクトは必ず失敗します。
スコープクリープが発生しないように、細心の注意を払う必要があります。

Follow me!