スコープクリープとは

スコープクリープとは、プロジェクトでやること（スコープ）の範囲が、正式な合意や変更の手続きを経ないまま、少しずつ広がっていくことです。「クリープ（creep）」は、這うようにじわじわ進むという意味の英語です。一つひとつは小さな追加なので止めにくく、気づいたときには、計画した期限や予算では収まらなくなっています。

私も取得しているPMP（プロジェクトマネジメントの国際資格）の土台になっている知識体系でも、スコープの管理は大きな柱の一つとして扱われています。なぜそこまで大事なのかは、プロジェクトの成果を掛け算で考えると分かりやすくなります。

私のセミナー資料では、プロジェクトの成果を「スコープ×品質」で表しています。

  • あるべき姿：スコープ10点×品質10点＝100点
  • よくある実態：途中で範囲が広がり、相手の期待はスコープ12点×品質10点＝120点に上がる。一方で、広がった範囲に手が回らず、品質は8点に下がる。届けられる成果は10点×8点＝80点

点数は説明のための仮のものです。作る側は「80点まではやった」と思っていても、相手は120点を期待している。この差が、そのまま相手の不満になります。スコープクリープの怖さは、作業が増えることそのものより、相手の期待と届けられる成果の差が、誰にも気づかれないまま開いていくことにあります。

私は豊田自動織機で物流エンジニアリングのSEとして働き、その後コンサルタントとして、立場を変えながらプロジェクトに関わってきました。スコープクリープは、誰かが怠けた結果ではありません。良かれと思って引き受けた「ついで」の積み重ねで起きるものだと私は考えています。

出典・制度の確認先

スコープ管理の基本：成果物スコープと作業スコープ

スコープ管理とは、プロジェクトでやることの範囲を決め、関係者と合意し、途中の変更を管理していく取り組みです。そのとき、スコープを2種類に分けて考えると、話が整理しやすくなります。

  • WHY（プロジェクト目標）：何のためにこのプロジェクトをやるのか
  • WHAT（成果物スコープ）：最終的に生み出すもの。資料、仕組み、製品やサービスと、その中身や機能
  • HOW（作業スコープ）：その成果物を作るために、実際にやらなければならない作業

社内で事業計画を作るプロジェクトを仮の例にすると、2つのスコープは次のように対になります。

成果物スコープと作業スコープの対応（仮の例）
成果物スコープ（何を作るか）作業スコープ（どう作るか）
事業の概要経営陣へのインタビュー、ビジネスモデルの分析
全社の戦略財務三表・KPIの分析、経営陣とのワークショップ
事業ごとの戦略と施策部門ごとのワークショップ
数値計画財務シミュレーションのモデルづくり
施策とアクションプラン部門との調整、プロジェクト推進会議
進み具合を確かめる仕組み会議体と報告の形の設計

※ 仮の例です。実際の対応は、プロジェクトの目的や体制によって変わります。

作業スコープだけで合意すると、「インタビューは予定どおり実施した」のに、出来上がった資料の中身でもめることがあります。逆に成果物スコープだけで合意すると、どこまで分析するかの手間が読めず、作業がいくらでも膨らみます。2つを対にしておくと、追加の要望が来たときに「どの成果物の、どの作業が増えるのか」で話ができます。

事業計画の策定体制や進め方については、事業計画の策定体制とは？プロジェクトの進め方と、失敗しやすい6つの型で詳しく書いています。私は、スコープの話は「何を作るか」から始めるのが良いかなと思います。作業から話し始めると、作業を減らす議論になりやすく、目的とのつながりが見えにくくなるからです。

スコープクリープが発生する原因

スコープクリープが起きる原因は、大きく五つあります。

一つ目は、プロジェクト目標があいまいで、優先順位をつけられないこと。 何のためのプロジェクトかがはっきりしないと、出てきた要望がどれも大事に見えます。

二つ目は、要件があいまい、または要件の定義が足りないこと。 「分かりやすい資料」「使いやすい仕組み」のままで進めると、途中で中身を詰めるたびに範囲が広がります。誰にとって、どんな場面で分かりやすいのか。そこまで言葉にしておかないと、相手が思い浮かべている完成形と、作る側の完成形がずれたまま進みます。

三つ目は、関係者を早い段階から巻き込めていないこと。 最初の打ち合わせにいなかった部門が、途中から「自分たちの業務も入れてほしい」と言ってくる。よくある形です。

四つ目は、プロジェクトの後半になって、相手から意見が入ること。 形が見えてから初めて、相手は「思っていたのと違う」と気づきます。後半の手直しほど、影響は大きくなります。

五つ目は、プロジェクトリーダーが「No」と言えないこと。 相手との関係を気にして、すべての要望をその場で引き受けてしまう状態です。

五つのうち、いちばん根が深いのは一つ目だと私は見ています。目的という物差しがないと、要望を断る理由も、受ける理由も説明できません。リーダーが「No」と言えないのも、本人の気の弱さより、判断の物差しを持たされていないことの方が大きいのかなと思います。

スコープクリープの例

仮の例で、スコープクリープが起きる流れを見てみます。

ある会社で、全社の3か年計画を作るプロジェクトが始まりました。検討の途中で、ある部門長から「せっかくなら、部門別の計画も作ってほしい」と声がかかります。次の会議では「競合の分析を、もう少し厚くできないか」。さらに「月次で追える管理表もあると助かる」。

どれも筋の通った要望で、一つずつなら半日ほどで済みそうに見えます。そのため、担当者はその場で引き受けていきます。ところが積み重なると、全社の計画を取りまとめるはずだった時間がなくなり、いちばん大事な全社戦略の議論が浅いまま期限を迎えてしまいます。

この例で、追加の要望そのものは悪くありません。問題は、要望を受けるたびに「どの成果物が増えるのか」「その分、何を後ろに回すのか」を誰も確かめていないことです。

範囲は、相手の要望だけで広がるわけではありません。作る側が「この分析も入れておいた方が喜ばれるはず」と、頼まれていないものを自分から足していくこともあります。プロジェクトマネジメントでは「ゴールドプレーティング（金めっき）」と呼ばれる状態です。善意から出たものでも、合意のない追加である点はスコープクリープと同じで、そのぶん期限や品質に響きます。足したくなったときは、作る前に相手に「これは必要ですか」と一度聞く。それだけで、余計な作業の多くは防げます。

スコープクリープの対策

スコープクリープの対策は、大きく四つです。

  1. 最初に、プロジェクト目標を言葉にする。 「この計画は、誰が何を判断するために使うのか」まで書いておくと、要望の優先順位をつける物差しになります。
  2. 成果物スコープと作業スコープを対で合意し、文書に残す。 このとき、「今回は入らないもの」も一行書いておきます。入らないものを書いておくと、後からの追加に気づきやすくなります。
  3. 追加の要望は一覧にして、優先順位を決める。 その場で受けるか断るかを決めず、いったん一覧に入れます。受けるなら、代わりに何を外すか、期限や費用をどう変えるかをセットで決めます。誰がその判断をするのかは、あらかじめ決めておきます（RACI図とは？責任と権限の決め方）。
  4. 早い段階で関係者を巻き込み、形にして見せる。 後半に入る意見を、前半に寄せるためです。

「No」の伝え方にも工夫ができます。「それはできません」ではなく、「入れるなら、こちらを外すか、期限を延ばす必要があります。どちらにしますか」と、選択肢で返す。相手に判断を委ねることで、要望を出した側も、範囲が広がる重さを一緒に考えてくれるのかなと思います。

私自身も、事業承継を支援するAI「アトツギ・ナビ」を開発していたとき、機能が増え続けたことがあります。そこで、税理士と経営者の会話をストーリーにし、それを業務フローに落としてから、AIで簡単なモックを作りました。それを関係者に見てもらい、話を聞きながら、機能を削ぎ落としていきました。必要な機能は、会議室で考えるより、使う人の場面に戻して確かめた方が見えてきます。

スコープ管理は、決めて終わりにしない

スコープは、最初に決めたら終わりではありません。プロジェクトが進めば、相手の理解も深まり、要望は変わります。変わること自体は自然なことで、大事なのは、変わったことを関係者が同じように知っている状態を保つことです。

プロジェクトマネージャーの仕事は、決めた範囲を守ること（コントロール）だけではありません。相手の期待がいまどこにあるかを確かめ、範囲と期待のずれを小さいうちに埋めていくこと（マネジメント）も含まれます。最初に紹介した「80点と120点」の差は、ある日突然開くのではなく、確かめ合わない日が続くうちに少しずつ開いていきます。

そのために、定例会では次の三つを確かめます。

  • 成果物の一覧に、変更はないか
  • 追加の要望の一覧で、まだ判断していないものはないか
  • 判断したものが、スケジュールと担当に反映されているか

成果物と作業が決まったら、誰がいつまでに何をやるかに落とします。行動計画への落とし方は、アクションプランとは？書き方と作り方にまとめています。

計画は、作って終わりではありません。スコープも同じで、日々の判断に使われて初めて意味があります。