スコープ・クリープの発生を防ぐためには
PMBOKガイドには、スコープ・クリープという耳慣れない言葉が登場します。
管理人もこの名前は知りませんでした。しかし、意味を知れば皆さん、よくご存じの内容です。
今回は実務的な観点でこの内容について触れていきます。知れば知るほど、危険な現象です。
スコープ・クリープとは？
PMBOKガイドから抜粋します。
時間、コスト、および資源を調整することなく、プロダクトまたはプロジェクトのスコープをコントロールせず拡大すること。
ノーコントロールで、勝手にスコープの拡大（機能追加や変更など）を行ってしまうことですね。
スコープ・クリープの例
具体的には、このようなシーンが該当しそうです。
現在総合テスト工程に入っている。ｘｘ入力の設計SEは、顧客との機能テストを行っていた。
そこで、顧客から、この画面のｘｘ部分をｘｘｘに変更して、DB更新時には、ｘｘｘテーブルのｘｘｘ項目をｘｘｘにするよう修正してくれないか？ との依頼を受けた。
本来ならば、統合変更管理を経なければならない内容である。
しかし、設計SEは、他の障害の件もあって、顧客に引け目を感じていた。
設計SEは、やむなくその変更を受け入れることにして、プログラムの改修をメンバーに指示した。
大体このような話にはオチがあります。それは次のような内容です。
- 影響範囲を調査することなく修正したため、他機能と連携が取れなくなり、大幅な改修が必要になった。
- メンバーの作業工数がオーバーして、コストが悪化した。
- 顧客から「あれやってくれたんだから、これもやってよ」といわれるようになり、断るのが困難になってきた。
あまりいい結果になることはありません。
一番怖いのが、総合テスト（システムテスト）でスコープ・クリープが発生することです。
この段階で発生する問題の内容は、プログラム的な障害ではなく、仕様的な障害であったり、要件モレなどの致命的な問題であることがしばしばです。
現場レベルでの対応はしてはいけない
発生した問題を、設計者が隠蔽（いんぺい）してしまい、勝手に修正を始めることがあります。そうなるとトラブルプロジェクトへまっしぐらです。
時間も工数もない中での修正なので、小手先のテクニックでどうにかしようとする傾向があります。また、影響範囲を見極めずに修正してしまうことが多いのです。
総合テスト（システムテスト）の段階で発生してしまうと、今まで担保してきたテスト品質を破壊することになってしまいます。
当然ですが、プログラムの修正を行った場合は、単体テスト、結合テストを踏まなければなりません。
そもそも、その修正設計を行うことで、本当に問題ないかの確認をすっ飛ばしている可能性が高いのです。
また、仕様漏れや要件モレのレベルだと、他機能・他システムへの影響があるはずです。それを確認せず修正することはあってはならぬことです。
そして、「コントロールされず」ということは、現場レベルで勝手に進めていることなので、PMが知らない場合があります。現場も知られないよう事を進めているので、本当にわかりません。
PMがそれを知るときは、たいていトラブル化した後です。手に負えない事態になるときもあります。
担当者も、隠蔽（いんぺい）はほどほどにしないと、自分の首を絞めることになりかねません。
PMもそれを知らなかった（気づけなかった）ということで、責めを負います。
スコープ・クリープの発生を防ぐためには？
変更管理の方法を徹底することが必要です。どう徹底するかというと次の点があげられます。
簡単に言えば、可視化（見える化）ですね。一般的な内容ですが次の通りです。
- 変更管理の仕組みを図式化する。
- プロジェクトメンバー、顧客双方で、手順について合意する。
- 合意した内容を守ってもらう努力をする。
- 口頭での変更要望は受け付けず、必ずドキュメント化したもの（インシデント発行）で受け付ける。
- 口頭のみの場合でも、プロジェクトメンバーが代理でインシデントを発行するようにする。
- インシデントの管理者を決める。（プロジェクトメンバー、お客の双方で決めます）
- 定期的に顧客と内容を共有する場を設ける。
- プロジェクトメンバーが障害、トラブルを報告しにくい雰囲気にしない。
まずは、顧客からの「変更要望」を見える化します。「インシデント未発行の要件は対象にしない」ということを、宣言して、きっちり励行してください。
これはプロジェクトマネージャの義務です。
プロジェクトメンバーにも、お客から直接口頭で言われた場合でも、すぐにインシデント発行の手続きをするよう指導します。
以前聞いた話ですが、付箋に書かれた顧客からの要望・トラブル事象が2000枚もあって、実際の管理台帳にはそのうちの150件しか記載されていなかったという恐ろしい出来事がありました。（管理人はそのプロジェクトには関係ありませんでした）
インシデントの対処については、顧客と交渉していくしかありません。
事前に内容をすべて把握しておけば、それなりの対処方法や、シナリオを検討しておくこともできます。
まとめ
スコープ・クリープという言葉は、PMBOKガイドではちょっとだけ出てきます。
「クリープ」の例が、車のオートマチック車が勝手に動き出すことと説明されていました。間抜けな例だと思いました。
しかし、よくよく内容を理解してみると、プロジェクトの成功を阻害する大きな要因ではないか？ と思いました。
知らないものが後から出てくることほど恐ろしいことはありません。すぐに打つ手を見つけられませんから。
管理人も打ち合わせの場で、いきなりスコープ・クリープがあった事実を顧客から知らされたときほど、窮地に立たされることはありませんでした。
そうならないように、事前にきっちりと顧客・プロジェクトメンバーに釘を刺しておきましょう。
そして、センサーをフル稼働させて、スコープ・クリープの予兆を発見してください。
発見したら芽が小さいうちに摘み取ってしまいましょう。