スコープクリープとは：原因と防ぎ方、要件追加を変更管理と追加見積で扱う契約の要点

スコープクリープとは、システム開発やプロジェクトの途中で、正式な承認や費用・納期の見直しを経ないまま作業範囲が少しずつ広がっていく現象です。一つひとつは「画面に項目を1つ足すだけ」の軽い依頼でも、積み上がると予算超過と納期遅延の主因になります。この記事では、スコープクリープの定義と原因、変更提案書から変更契約までの変更管理の流れ、無償で受ける範囲と追加見積の基準を整理しました。後半では、請負と準委任でのスコープの扱いの違い、IPAのモデル契約が定める変更管理の条項、取適法で発注者が注意すべき点まで、契約で押さえる要点を発注者と受託側の両方の立場から解説します。

まとめ：スコープクリープは変更の手続と追加見積の基準を契約前に決めて防ぐ

スコープクリープの原因は、要望が出ること自体ではなく、要望を「誰が、何を見て、受けるか決めるか」が決まっていないことです。追加をゼロにするのではなく、変更として扱う通り道を用意します。

押さえるのは3つの取り決めです。1つ目は、仕様書の変更は変更提案書と変更管理書を経てしか行わないという手続。2つ目は、無償で受ける軽微な変更の上限を工数で決め、超えた分は追加見積にするという基準。3つ目は、費用や納期に影響する変更は変更契約を結んで初めて確定させるという契約上の扱いです。

この3点が契約書と運用ルールに入っていれば、追加の依頼は「断るか、黙って吸収するか」の二択ではなくなります。影響を見積もり、発注者が予算・納期と天秤にかけて選ぶ判断に変わります。

スコープクリープとは：承認を経ない要件追加が予算と納期を食う仕組みと類似語

スコープクリープの定義と、承認済みのスコープ変更との違いを分ける基準

スコープとは、プロジェクトで作る成果物と、そのために行う作業の範囲です。クリープ（creep）は「忍び寄る」「じわじわ進む」という意味で、スコープクリープは作業範囲が気づかないうちに膨らむ状態を指します。要件クリープ、フィーチャークリープと呼ばれることもあります。

注意したいのは、スコープが変わること自体は悪ではない点です。業務の変化や法改正で要件を変えるのは普通のことです。

分ける基準は1つで、変更に見合う費用・納期・人員の見直しを関係者が承認したかどうかです。承認と見直しを経た変更は「スコープ変更」、経ていない追加が「スコープクリープ」になります。同じ機能追加でも、手続を通したかどうかで呼び名が変わります。

ゴールドプレーティングやフィーチャークリープとの違いと、発生源による区別

スコープクリープと混同されやすい言葉に、ゴールドプレーティングがあります。違いは、追加を言い出したのが誰かです。

ゴールドプレーティングは受託側の判断で起きるため、費用を発注者に請求できず、受託側の利益を削ります。しかも、作り込んだ機能にもテストと保守が必要になる。開発チームの内側で起きるので、発注者からは見えにくいという厄介さもあります。どちらも、仕様書にない作業を承認なしに足すという点では同じ問題です。

小さな追加が積み上がると工数がどう膨らむか、軽微な修正10件の計算例

スコープクリープが怖いのは、1件ごとの見積もりが小さく見えることです。「入力項目を1つ足す」はプログラムの修正だけなら0.5人日で済むかもしれません。

実際には、設計書の修正、画面とデータベースの変更、関連する帳票やCSV出力の確認、テスト仕様書の更新と再テストが連なります。仮に修正0.5人日に対して周辺作業が1人日かかるとすると、1件で1.5人日です。これが10件積み上がれば15人日、ほぼ1人の作業者の3週間分になります。

テスト工程の終盤に入ってからの変更は、通った試験のやり直しも伴います。後半ほど1件が重くなるわけです。こうした追加が積み上がり、スコープを戻せず納期と予算の見通しが崩れた後の立て直し手順は、炎上プロジェクトの兆候と原因、発注者側の立て直し手順で整理しています。

スコープクリープの原因：要件定義の曖昧さと「ついでに」の依頼が通る体制

要件定義書に「含まない範囲」を書かなかったことで起きる解釈のずれ

最も多い原因は、要件定義書に「やること」だけが書かれ、「やらないこと」が書かれていないことです。たとえば「受注データをCSVで出力する」とだけ書くと、項目の並び替えや出力条件の保存、既存の会計システム向けの形式変換まで含むのかどうかで、発注者と受託側の解釈が分かれます。

書かれていない範囲は、後から追加か否かで必ず揉める。要件定義書には対象外とする業務・機能・データの章を設け、「本開発の範囲外」と明記してください。要件定義で作る成果物と進め方は要件定義の目的・進め方・成果物と失敗を防ぐポイントで整理しています。

発注者の現場担当と決裁者が別で、定例の場で口頭の追加が通ってしまう構造

発注者側の体制にも原因があります。定例会議に出てくるのは利用部門の担当者で、予算を握る決裁者は出席していない。この形だと、担当者が「ついでにこれも」と頼み、受託側のリーダーが「それくらいなら」と受け、決裁者が知らないまま範囲が広がります。

防ぐには、変更を承認できる人をプロジェクトの開始時に名前で決めておくことです。担当者が出した要望は「要望」として記録するだけにし、受けるかどうかは承認者が判断する、と線を引きます。体制と役割分担は、プロジェクト計画書の段階で文書にしておくと後で揉めません。書く項目はプロジェクト計画書の書き方と、発注者と受託側の分担にまとめています。

受託側が値引きや関係維持を優先して追加を断れない請負契約の事情

受託側にも、追加を断れない事情があります。次の案件や保守契約の継続を考えると「それは追加費用です」と言いにくく、少額なら黙って吸収する判断が積み重なります。

吸収した分は、テストの手薄さや担当者の入れ替えという形で品質に跳ね返るので、発注者にとっても損です。追加の依頼に費用と納期の影響を添えて返すのは、関係を壊す行為ではありません。

変更管理の仕組み：変更提案書と影響評価、承認から変更契約までの4段階

IPAモデル契約の第34条〜第37条が定める変更提案書と変更管理書の記載事項

変更管理の手続を一から作る必要はありません。IPA（情報処理推進機構）が公開している情報システム・モデル取引・契約書（第二版）のひな型に、そのまま使える条項があります。

ひな型の第34条は、仕様書などの変更が必要だと考えた側が、変更の内容と理由を書いた「変更提案書」を相手に渡して提案できると定め、変更は第37条の変更管理手続によってのみ行えるとしています。第37条は、変更提案書を受け取った側が所定の日数以内に「変更管理書」を交付し、連絡協議会で変更の可否を協議すると定めます。変更管理書に書く事項は次の8つです。

• 変更の名称と提案の責任者、年月日
• 変更の理由
• 変更に係る仕様を含む変更の詳細事項
• 変更のために費用を要する場合はその額
• 検討期間を含めた変更作業のスケジュール
• その他、作業期間・納期・委託料・契約条項などの契約条件に与える影響

協議の結果、双方の責任者が変更管理書を承認して記名押印すると変更が確定します。ただし、委託料や納期など契約条件に影響する場合は、第33条に基づく変更契約を締結した時点で確定する、とされています。口頭やメールの「了解しました」では、費用と納期の変更は確定しないという設計です。

変更要求を受けてから承認されるまでの流れと、各段階で誰が何を判断するか

モデル契約の条項を実際の運用に落とすと、次の4段階になります。

1. 受付：要望を出した人が変更提案書（社内では変更要求票と呼ぶことも多い）に、内容・理由・希望時期を書いて提出する。この時点では作業に着手しない
2. 影響評価：受託側が、工数・費用・納期・既存機能への影響・テストのやり直し範囲を見積もり、変更管理書の案を作る。期限は受付から5営業日など、契約で日数を決めておく
3. 承認：定例会議（モデル契約でいう連絡協議会）で、発注者側の承認者が、受ける・見送る・次期に回すのいずれかを決める
4. 確定：費用や納期が変わる場合は変更契約を結び、仕様書・WBS・テスト計画を更新してから着手する

手続を重く感じる場合は、段階を減らすのではなく、軽微な変更の扱いを別に決めます。どこまでを軽微とするかは次章で扱います。

変更管理台帳の列設計と、課題管理表や不具合管理表と分けて持つ理由

変更提案は1件ずつ番号を振り、変更管理台帳で一覧にします。最低限の列は次のとおりです。

課題管理表に変更要求を混ぜると、「解決すべき問題」と「受けるかどうかを決める要望」が同じ一覧に並び、残件数が実態を表さなくなります。不具合は仕様どおりに動かないものなので費用は受託側の負担、変更は仕様そのものを変えるので原則として発注者の負担、と費用の扱いも逆です。表を分けておくと、ある指摘が不具合か変更かで揉めたときに、どちらの台帳に載せるかという形で論点がはっきりします。課題管理表の項目と使い分けは課題管理表の作り方とステータス設計で解説しています。

追加見積の扱い：無償で受ける範囲と有償にする基準を事前に合意する方法

軽微な変更の線引きを工数で決める基準と、累計で上限を設ける運用

すべての変更に変更契約を結んでいると、文言の修正一つで1週間かかるような事態になります。現実的なのは、無償で受ける軽微な変更の範囲を、言葉ではなく工数で決めておくことです。

たとえば「1件あたり影響評価込みで0.5人日以内、かつ既存の画面・帳票の文言・配置の変更に限る」と決めます。データ項目の追加や、他システムとの連携に影響する変更は工数が小さくても対象外にする。テストのやり直し範囲が読めないからです。

累計の上限も決めます。1件0.5人日以内でも、20件受ければ10人日です。「軽微な変更の累計が5人日に達したら以降は有償」と決め、変更管理台帳で累計を毎週報告しておけば、追加見積を出したときに驚かれません。

追加見積の算定方法：人日単価×工数と、既存の成果物への影響工数の積み上げ

追加見積は、契約時の見積もりと同じ単価と算定方法で出すのが原則です。人月単価を120万円（1人日6万円）で契約しているなら、追加分も同じ単価で計算します。単価を変えると、追加の妥当性ではなく単価の交渉になってしまうからです。

工数は、新しく作る部分だけでなく、既存の成果物への影響を積み上げます。

• 新規の設計・製造・単体テスト
• 既存の設計書・テスト仕様書の修正
• すでに完了した結合テスト・総合テストのやり直し
• データ移行や操作マニュアル、利用者向け研修資料への反映

発注者側が確かめるべきは、テストのやり直しが入っているかどうかです。製造工数だけの安い見積もりで受けると、テストが省かれるか、後から再度の追加見積が出てきます。見積書の内訳の見方はシステム開発の見積書の見方と相見積もりの比較を参照してください。

予備費を予算に持つ場合の割合と、使うときに誰の承認を要するか

発注者側の予算に、追加要望のための予備費を持っておく方法もあります。割合は発注時点の要件の固まり具合で決め、画面と帳票まで確定済みなら少なめ、要件定義から一括で発注するなら厚めに積みます。

予備費を受託側や利用部門に「使える枠」として伝えてはいけません。枠が埋まるまで要望が出続けるからです。発注者の社内で管理し、変更管理書の承認時に決裁者が予備費から出すかを判断します。

契約で押さえる点：請負と準委任の違い、変更協議が調わないときの扱い

請負契約では仕様書が完成の基準になり、変更管理の条項が費用負担を左右する理由

民法第632条は、請負を「仕事を完成することを約し、相手方がその仕事の結果に対して報酬を支払う」契約と定めています。システム開発の請負では、何をもって完成とするかの基準が仕様書です。

このため請負では、仕様書を変える手続がそのまま費用の手続になります。変更管理の条項が無い、または運用されていない請負契約では、追加が「仕様の解釈」の名目で無償のまま流れ込み、受託側の赤字か納期の崩れに行き着きます。

民法第641条により、注文者は完成前ならいつでも契約を解除できますが、受託側の損害の賠償が条件です。費用が膨らんで開発を止める場合も、それまでの作業分は支払いが要る。見積もりの誤差を契約形態ごとに誰が負担するかは見積もりの誤差で赤字になる仕組みと契約形態別の負担で計算例とともに扱っています。

準委任契約とアジャイル開発ではスコープを固定せず優先順位で入れ替える運用

準委任（民法第656条）は、仕事の完成ではなく事務の処理を委託する契約です。作業時間や人数に対して報酬を払うので、請負のように「仕様書の範囲を超えたら追加費用」という構図にはなりません。

その代わり、準委任ではスコープクリープが「期間内に作り終わらない」という形で表れます。要望を足せば、同じ期間・同じ人数で作れる機能が減るだけです。アジャイル開発では、この性質を前提に、要望をプロダクトバックログに積み、優先順位の高いものから作ります。新しい要望を入れるなら、同じ大きさの別の要望を外す。追加ではなく入れ替えで扱うのが、準委任でスコープを管理する基本です。契約形態の違いと使い分けは準委任契約と請負・派遣の違い、システム開発での使い分けにまとめています。

取適法の「不当な給付内容の変更」と、受託側が中小事業者のときに発注者が負う注意

2026年1月1日に下請法が改正され、取適法（製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律）に変わりました。プログラムの作成を委託する取引も対象で、資本金や従業員数の区分で適用対象になる取引では、発注者（委託事業者）に禁止行為が課されます。

公正取引委員会の委託事業者の禁止行為のページは、中小受託事業者に責任がないのに発注内容を変更したり、受領後にやり直しをさせたりして利益を不当に害することを違反としています。取適法のよくある質問のQ129は、発注時に明示していない事項について無制限にやり直しをさせることはできず、想定外の費用が生じる場合は合理的な負担割合を協議して決める必要があると説明しています。

受託先が中小の開発会社なら、「仕様の範囲内だから」と追加作業を無償で押し付けることは法令違反になり得る。発注者側こそ、変更管理書と変更契約の記録を残す理由があるわけです。

変更協議が不調のときの中断・解約条項と、旭川医大事件で問われた協力義務

協議がまとまらない場合の扱いも契約に入れておきましょう。モデル契約のひな型の第37条第4項は、発注者からの中断要請など特段の事情がある場合、受託側は協議が調わない間、業務を中断できるとしています。第38条では、協議不調で発注者が続行をやめるとき、未了部分を解約し、それまでの委託料と受託側の損害を支払う形です。B案には、続行が客観的に困難な場合に受託側から書面で中止を提言できる条項も入っています。

要件追加が止まらずに訴訟になった例として、旭川医科大学の病院情報システム開発をめぐる事件が知られています。2017年の札幌高裁判決は、仕様を凍結した後も追加要望が出され続けた経緯を踏まえ、発注者である大学側の協力義務違反を認めました。発注者にも、要望を整理し期限内に決めるという義務がある。スコープクリープは受託側の管理だけの問題ではない、ということを示した事件です。

スコープクリープを防ぐ判断：変更を受ける場面と、断る・次期へ回す場面

法改正や業務停止に直結する要望は、納期を動かしてでも今回の範囲に入れる判断

追加要望をすべて次期に回せばよいわけではありません。今回の範囲に入れるべきなのは、入れないと稼働日にシステムが使えない要望です。具体的には、稼働日までに施行される法令・制度への対応、取引先との連携形式の変更、それが無いと現行業務が止まる機能の3種類が該当します。

これらは費用と納期の調整をしてでも受けます。逆に「今の画面より使いやすく」「この集計も見たい」といった改善要望は、稼働を遅らせてまで入れるものではありません。判断に迷ったら、「この要望が無い状態で稼働日を迎えたら、業務は止まるか」と問います。止まらないなら、今回は入れないと決めます。

稼働後に回すべき要望と、次期開発の候補リストで管理する運用方法

断るときに効くのは、「やらない」ではなく「次期でやる候補に載せる」という返し方です。変更管理台帳の判定欄に「次期」を設け、見送った要望を消さずに残します。

稼働から1〜3か月たつと、使った利用者から新しい要望が出てきます。開発中の「次期」の要望と並べると、運用の工夫で不要になったものも少なくありません。次期の範囲はこの時点で優先順位を付け直して決めます。

発注者側でスコープを守る体制を作れないときに外部PMOを入れる判断

変更の承認者を決めても、その人が日常業務に追われて影響評価を読み込めない、ということはよく起こります。受託側から出てきた変更管理書の工数が妥当か、本当に今回入れるべき要望か、発注者の社内だけでは判断しきれない場合もあります。

開発規模が数千万円を超える、利用部門が3つ以上に分かれていて要望の窓口が一本化できない、社内に開発経験のある担当者がいない。こうした条件が重なる案件では、受託側とは別に、発注者の側に立つPMOを置く選択肢があります。一創の要件定義・RFP作成・PMO支援では、要件定義の段階で範囲外の機能を明文化するところから、変更管理書の工数の読み解き、定例での変更判定の支援まで、発注者側の立場で関わっています。

よくある質問：スコープクリープとスコープ変更・アジャイル開発との関係

スコープクリープについてよく寄せられる質問に、本文の内容を踏まえて答えます。

スコープクリープとスコープ変更は何が違いますか？

違いは、費用・納期・人員の見直しを関係者が承認したかどうかです。要件を追加・変更すること自体は同じでも、変更提案書と影響評価を経て、承認者が予算や納期の調整とともに認めたものはスコープ変更として正当な手続になります。承認を経ず、定例の場の口頭の依頼や「ついでに」の作業として範囲が広がったものがスコープクリープです。同じ機能追加でも、手続の有無で扱いが変わります。

アジャイル開発ならスコープクリープは起きませんか？

起きにくくはなりますが、起きないわけではありません。アジャイル開発では要望をバックログに積み、優先順位で入れ替えることを前提にしているため、追加そのものは想定内です。ただ、スプリントの途中で作業を割り込ませる、外す要望を決めずに追加だけを積む、といった運用をすると、期間内に作り終わらない形でスコープクリープが表れます。入れたら同じ大きさのものを外す、というルールを守れるかどうかで決まります。

スコープクリープが起きてしまったプロジェクトはどう立て直しますか？

最初に、すでに受けた追加を洗い出して変更管理台帳に後から登録し、件ごとの工数を見積もり直して、予算と納期への影響を数字で示します。そのうえで決裁者を交えて、追加費用を払う、納期を延ばす、一部を次期に回す、のどれか（または組み合わせ）を決めます。以降の要望は変更提案書を通す運用に切り替え、過去分の扱いと今後の手続は変更契約や議事録で確定させてください。

スコープ管理とは何をすることですか？

スコープ管理とは、プロジェクトで作る成果物と作業の範囲を決め、その範囲を守り、変えるときは手続を通す一連の管理です。範囲を決める段階では要件定義書やWBSで成果物と作業を洗い出し、範囲外とするものを明記します。実行段階では、成果物が範囲どおりかを確認し、追加や変更は変更管理の手続で扱います。スコープクリープは、このうち「変えるときは手続を通す」が抜けたときに起きる現象です。

受託側から追加費用を切り出すと関係が悪くなりませんか？

切り出し方次第です。作業が終わってから請求すると、発注者は「無償だと思っていた」と受け取り、関係がこじれます。依頼の時点で工数・費用・納期への影響を変更管理書の形で返し、受けるかどうかを発注者に選んでもらえば、追加費用は発注者自身の判断になる。無償の上限と累計を契約時に合意して定期的に報告しておけば、上限超過後の追加見積も受け入れられやすくなります。

関連記事

• 要求定義と要件定義の違いとは？責任範囲・成果物・契約の分界点を解説：要件の範囲と責任の分界点を契約でどう切るか
• WBSとは？書き方・作り方の5ステップとシステム開発の例、ガントチャートとの違い：スコープを作業単位に分解して範囲を固める方法
• アジャイル開発の要件定義とは？進め方の5ステップとウォーターフォールとの違い：優先順位で要望を入れ替える開発での要件の決め方
• PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断：変更管理を含むプロジェクト管理を外部に任せる判断
• システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】：スコープ管理を含む管理領域の全体像