スコープが決まらないとプロジェクトは終わらない

PMBOK用語が定着しているもののひとつに「スコープ」という言葉が上げられます。最初は「スコープとはなんぞや?」と思ったものでした。

しかしこのスコープはプロジェクトの成功のカギを握る重要なものです。

PMBOKでも知識エリアのひとつですし、大量のページを使って説明をしています。PMP試験学習でも山場のひとつですね。

ではいつものとおり、ざっくり説明します。

スコープとは?

「スコープ」とは一体なんでしょうか?

それは『プロジェクトで作成する「プロダクト・作業」のすべてのこと』です。端折っていますがずれてはいないでしょう。

スコープは、2つに分類されます。

  • プロダクト・スコープ
  • プロジェクト・スコープ

すべてのプロダクト、すべての作業、とにかく「すべてのモノ」です。これは重要な概念ですね。

プロダクト・スコープ

プロダクト・スコープは、プロジェクトで作成する「モノ」の「すべての構成・機能・要件」を含むものです。

プロジェクト・スコープ

プロジェクト・スコープは、プロジェクトで作成するプロダクトを作成するために実施する「すべての作業」です。プロダクト・スコープも包含しています。

重要なことは、いずれも「定量的に計測ができる」という条件がつくというところです。

PMBOKでは?

PMBOKでは次のように説明しています。

スコープ

プロジェクトが提供するプロダクト、サービス、所産の総体。

プロダクト・スコープ

プロダクトやサービスや所産を特徴づけるフィーチャーと機能

プロジェクト・スコープ

規定されたフィーチャーと機能を有するプロダクト、サービス、所産を生み出すために実行される作業

相変わらず、PMBOKの説明は、何を言っているのかわかりにくいですね。

何が重要なのか?

すべてのものを含むこと

スコープとは「プロジェクトで作成するすべてのモノ」と書きました。すべてのモノが対象です。

繰り返しますが「すべてのモノを含んでいる」ということが重要です。

スコープを記述したものが「スコープ記述書」となり、さらに、スコープ記述書は2つの種類があります。

「プロダクト・スコープ記述書」と「プロジェクト・スコープ記述書」です。プロジェクト・スコープ記述書には、プロダクト・スコープ記述書も含まれます。

これは、プロジェクトマネージャが主体となって作成し、ステークホルダーに最終承認を得ます。

最終承認を得ることで、ベースラインのひとつである「スコープ・ベースライン」が完成するのです。

この最終承認された「スコープ・ベースライン」を使って、これ以降にプロジェクト活動で発生するスコープの増減を比較していきます。

スコープが固まるのはいつ?

設計工程で固まらせる

スコープが固まるのはいつでしょうか? 通常は、設計工程完了時点です。

設計工程完了で、製造工程以降の再見積りをするのが一般的になってきました。IPAの啓発のおかげですね。

ここで、2つのスコープが確定します。

さきほどから書いている「プロダクト・スコープ」と「プロジェクト・スコープ」です。

「どのようなモノをつくり、つくるためにはどのような作業が必要か」が確定します。PMBOK風にいうと、スコープ・ベースラインとしてステークホルダーに承認されたものです。

しかし現実は乖離(かいり)していく

そのような、重要なスコープ・ベースラインですが、いとも簡単にベースラインと乖離(かいり)していきます。みなさんもよくご存じのことでしょう。

PMBOKでは、示唆に富んだ注意書きをしています。それは「除外される作業、成果物も記述しておくこと」です。

これは重要です。「除外範囲、やらないこと、作らないこと」も明記しておけというのですから。

意外に「やることだけ」書いていますが、「やらないこと」も書いておくと、あとからもめることが減ります。

プロジェクトの完了はいつ?

プロジェクトの終わりはいつなのでしょうか? スケジュールで完了としているから、完了になるわけではありません。

完了の定義について、PMBOKでは次のように定義しています。さきほど「定量的に計測できること」と書いたのですが、まさにここで生きてくるのです。

完了の定義

プロジェクトの完了には2つの定義があります。

  • プロダクトの完了
  • プロジェクトの完了

プロダクトの完了

プロジェクトの作業で作成されたプロダクトが、計画時に作成したプロダクト要求事項と一致していなければ、プロダクトの完了になりません。

プロジェクトの完了

同じようにプロジェクトの完了も、プロジェクトマネジメント計画書に記載された完了基準を満たすことが必要です。何を持って基準をみたすかということですが、これが定量的に計測できることにつながります。

実際はどうか?

さてここが問題です。

納品してから、顧客から検収をもらいますが、ここで「要求事項と一致」していることはまれです。まれですと書くと語弊はありますが、何がしかの問題が発生します。

そもそも納品・検収時点より前に、問題が発生していることが多いのですが。

検収時の問題

プロジェクトの規模にもよりますが、納品・検収段階で問題が発生することは多々あります。条件付で検収をもらい、検収後も無償作業などという悲惨なこともありますね。

日本では、ベースラインの重みというものが、ステークホルダーに浸透していないことも原因でしょうね。

米国であれば「契約以外のことは作らない(作業しない)」と、はっきり言えるのでしょうけれど、日本では、なかなかそういうわけにはいきません。

ベンダー側のスキルが低い?

またわれわれベンダー側も「プロダクトを作成する上で必要なスキルが低いのでは?」と、感じることもあります。管理人も含めてですが。

これに関しては、別記事でも取り上げます。

まとめ

プロジェクトの特徴は有期性です。いつかは終わりにしないといけません。

終わりにするには、スコープの定義をきっちりしておく必要があります。

「きっちり」とは、ステークホルダーも含めて「これがプロダクトの完成版だ」ということを、合意しておかねばなりません。

IT系では、この問題に対する取り組みは、昔から行われてきています。しかし理論上はよくわかるのですが、実際の現場では「使いこなせない(スキルがない)」などで浸透していません。

アジャイル開発なども多少使われ始めていますが、大規模な基幹システム開発などではちょっと使えませんから。

PM

Posted by wpmaster