# スコープクリープとは

当初合意した作業範囲が、明示的な判断を経ないまま少しずつ広がる状態です。変更の件数ではなく、費用と納期への影響を確認しないまま追加が積み上がる点が問題になります。

## スコープクリープとは

開始時点で合意した作業範囲が、明示的な判断を省略したまま徐々に増大する状態です。
範囲は成果物の一覧と、その作成に必要な作業で示します。

引っ越しの見積もりに含まれない作業を、その場の判断で少しずつ依頼していく状態に似ています。
個々の追加は軽微でも、合計すると当初の想定を超えます。

要求の側でも同じことが起きます。要求が認識されないうちに増大し、当初の想定より高価で複雑なシステムになることを[要件クリープ](https://www.nasa.gov/reference/6-2-requirements-management/)と呼びます。
スコープクリープが作業範囲の増大を指すのに対し、要件クリープは要求の増大を指し、どちらも後から費用と納期に影響します。

委託開発に限らず、社内のシステム改修や業務改善の施策でも同じように発生します。


## なぜ起きるか

原因は1つではありません。
仕様の曖昧さ、受付の分散、手続の煩雑さが複合して発生します。


- 仕様が決め切られていない部分が存在し、後から当初の範囲に含まれるという解釈が生じる
- 発注側の担当者が開発の担当者へ直接依頼し、正式な受付を経由しない
- 1件あたりの影響が軽微なため、変更の手続を省略して開発の担当者が対応してしまう
- 追加に同意する時点で、納期と費用を変更する交渉をしない
- 開発側が期待に対応しようとして、依頼のない機能を追加する

仕様書の記述が不十分だと、[解釈の違いから当初の範囲の外の作業が生じる](https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675)ことがあります。
あわせて、発注側と開発チームが管理されずに直接やり取りする点、手続が煩雑なために開発の担当者が手続の外で依頼を受理する点を、別の原因として挙げています。


![仕様の曖昧さ、受付の分散、手続の煩雑さが重なって、依頼が当初の範囲の外で受理されることを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-scope-creep-fcdee5f7ccbeda70b134c3904d433300dcedc5388e1e28bfb114718f00d0f30a.png)

## 何が起きるか

追加は承認済みの作業の時間を圧迫する形で処理されます。


![当初の作業範囲に、承認を経ない軽微な追加が複数積み上がり、合計が当初の範囲と予備を超える関係を示す図](https://media.marketing.kdotdev-tunnel.org/glossary-scope-creep-0271ebc42a8a101c18844d47b17dc0d9df3e51453516d6e21e25a2f1ac8e9ebb.png)

- テストや例外処理の確認に充当する時間が減少し、不具合が稼働後に発見される
- 費用と納期が当初の見積もりと相違し、請負では追加費用の負担に関する協議になる
- 誰が何を決定したかの記録が欠落し、後から範囲の解釈を再現できない
- 予備が尽きると障害や遅延に備える原資がなくなる
- 変更が後の工程で判明するほど、設計とテストのやり直しの範囲が広がる

管理されない追加に時間を充当すると、[承認済みの機能の完成が遅れるか、時間と費用が超過する](https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675)ことになります。
設計が進んだ段階の変更は、[費用と日程への影響が大きくなる](https://www.nasa.gov/reference/6-2-requirements-management/)傾向があります。


## 防ぐ仕組み

変更を禁止するのではなく、変更の可否を判断する仕組みを構築します。
判断の材料と場を先に決定しておくと、追加のたびに再交渉する必要がありません。

判断の記録を保存しておけば検収のときや次の案件の見積もりで、どこまでが合意済みかを説明できます。


![追加の依頼が1か所の受付窓口に集まり、費用、納期、他の機能への影響を確認したうえで、実施するか次のリリースへ移行するかに分かれる流れを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-scope-creep-a37951637cf861f73abbe1607cca0d8d6c0bf6b656a5c9dc64c8a3422f77f0c0.png)

### 受付窓口を1か所に絞る

依頼の受付は発注側と開発側の間の1か所に限定します。
開発の担当者が直接受けると作業が開始されてから初めて範囲の拡大が判明します。

日常的な要請や指示の受理は、[原則として主任担当者を通じて行う](https://www.ipa.go.jp/digital/model/model20201222.html)形がひな形にあります。
変更の提案は書面で行い、理由、費用、納期、契約条件への影響を記載した変更管理書を作成します。
定例の連絡協議会は、発注側と開発側の責任者が集まる場で、ここで変更の可否を協議します。


### 予備を1〜2割確保する

当初の範囲とは別に、金額または工数の1〜2割を予備として確保することが多いです。
請負は成果物と金額を固定する契約、準委任は作業量に応じて支払う契約です。予備は請負では見積の内側に、準委任では期間の余裕として持ちます。

変更は、[予算と技術の余裕の範囲内かを判断し、範囲外なら承認しない](https://www.nasa.gov/reference/6-2-requirements-management/)のが基本です。
予備は追加専用の枠ではなく、障害や遅延にも充当する原資です。
使用した分を記録しないと残量が不明なまま判断することになります。


### 費用、納期、他の機能の影響で判断する

判断は隔週か月次の定例で行います。依頼した側が費用、納期、他の機能への影響の3点を提示し、決定は予算と納期を承認できる責任者が行います。
判断の場に参加するだけの担当者に決定させると、後から覆ることがあります。
1つの追加が他の機能の前提を変更する場合、追加そのものの工数より修正の範囲が拡大します。

変更ごとに、[機能への影響とシステム全体への波及を評価する](https://www.nasa.gov/reference/6-2-requirements-management/)必要があります。


### 軽い変更は事後共有にする

すべての追加を会議の議題にすると手続が煩雑になり、開発の担当者は手続の外で依頼を受理します。

総工数の1%以下か、2人日、つまり2人が1日で終える量までの追加は、事前の承認を省略して月次の一覧で共有することが多いです。
影響が軽微な変更を事後の共有に集約し、判断を要する変更に時間を配分します。


仕組みの運用には、判断に参加する担当者の時間と、変更の一覧を維持する手間が継続的に生じます。

予備を確保すると、その分だけ当初の見積もりは高額な印象になります。
閾値は案件の規模と変更の頻度に応じて調整します。


## 起きたときの扱い

拡大した範囲を確認したうえで計画を再構築します。
最初に、未完了の作業、使用した予備、未処理の追加を1枚に集約します。

変更を承認したら、[基準の文書を更新して関係者に周知する](https://www.pmi.org/learning/library/scope-creep-not-necessarily-bad-thing-3352)必要があります。
記録がなければどこからが追加かを説明できません。


追加は次の4つに分類します。


- 当初の範囲に含まれる作業
- 追加として承認する作業
- 次のリリースへ移行する作業
- 実施しない作業

追加をすべて禁止する必要はありません。
当初は想定できなかった要求の一部は環境の変化によるもので、[無視できない](https://www.nasa.gov/reference/6-2-requirements-management/)ものがあります。

計画を再構築したら、原因の特定まで行います。仕様の曖昧さ、受付の分散、手続の煩雑さのうち、実際に当てはまるものを1つ選んで手続を改修します。
3つのうちどれかが残ると、同じことが起こります。

請負で契約金額を変更できない場合は、追加する範囲を縮小するか納期を変更します。


![判明した追加を、当初の範囲に含まれる作業、追加として承認する作業、次のリリースへ移行する作業、実施しない作業の4つに分類することを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-scope-creep-63a58f459d93660e16848def0639b18bab2faaf6def68a8f4317cb082388cb27.png)

## よくある誤解

### 追加が頻発するとスコープクリープになる

承認を得た追加はスコープクリープとは異なります。
承認された範囲の拡大は、[スコープクリープとは区別されます](https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675)。
ここでの問題は追加の量ではなく、判断と記録がないことです。


### 追加はすべて拒否すべき

事業環境の変化で必要になった追加はあります。
すべてを拒否するのではなく、判断の場に提示し、優先順位を設定して一部を次のリリースへ移行します。


### 現場の意識で防げる

開発の担当者の我慢だけでは防止できません。
手続が煩雑だと、[開発の担当者が手続の外で依頼を受理する](https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675)ことがあります。
受付と判断の設計を変えるほうが、現場の意識に頼るより再発を抑えられます。


### すべての案件で範囲を固定すべき

探索を目的とする試作や調査では、範囲を先に確定せず、追加を前提に実施するほうが適切です。
この場合は期間と費用の上限だけを決定し、成果物の範囲は固定しません。


防止の中心は追加の作業を開始する前の受付です。
開始後に範囲の拡大が判明してから計画を再構築すると、設計とテストのやり直しを含みます。
受付で費用と納期を提示して判断する運用を先に設計しておくと、判断が後戻りしません。