「やらないこと」を決めておくと本当にやるべき仕様が見えてくる
「今回のプロジェクトは世界で展開して、あれもやりたいし、これもやりたいよね！」といったセリフを聞くことありませんか？
仕様書にあれもこれも盛っていると、「この仕様の本質ってなんだろう？」と、
内容がブレることがあります。
「やらないこと」を決めることで、仕様のブレがなくなり、
後から変更要求が沢山出る、仕様が増大してしまう、といった現象を抑えることが出来ます。
スコープクリープを防ごう
スコープってなんでしょう？
スコープとは、タスク(アクティビティ)などより、上部のもので、
「プロダクトスコープ」と「プロジェクトスコープ」の２種類が存在します。
プロダクトスコープとは、作る製品やサービスの機能や特徴を分解したもの。
プロジェクトスコープとは、製品やサービスを作るために必要な作業を分解したものと、
捉えておけばよいかと思います。
スコープが正しい変更手順を経由せずに増大していくと、
スコープがコントロールできなくなることがあります。
これをスコープクリープといいます。
スコープクリープが発生すると、
「え？聞いてないよ。いつの間に増えたの？その仕様」といったような事態が発生します。
スコープクリープが発生した際に、関係者(ステークホルダー）が多いと、
伝達不足などをはじめとした、大きな変更の影響に悩まされることになります。
その結果、予期せぬコストの増大や、納期の延長など、さまざまな問題が発生します。
また、スコープクリープが発生すると、
そもそも変更管理プロセスがしっかり機能していない可能性もあるため、
デスマーチに突入する事態に陥ることもあります。
徐々に増大することもあれば、ある日突然謎の仕様が追加されることもあります。
さまざまな原因が考えられますが、
一言でいえば「プロジェクトをコントロール出来ていない」ために発生します。
変更管理のプロセスをしっかり定義する、
コミュニケーションマネジメントをしっかり行う等、
対策方法はさまざまですが、
今回は「プロジェクトスコープ記述書」をしっかり書くことで予防していく方法を紹介します。
プロジェクト・スコープ記述書を用意しよう
PMBOKでは、プロジェクトにおける要求を収集するプロセスを行ったあと、
「スコープを定義する」プロセスを行います。
このプロセスを行うことで、
プロダクトの受け入れ基準や「どこまで作るの？」といった、
プロダクトの境界を定義することが出来ます。
スコープの定義プロセスでは、「プロジェクト・スコープ記述書」をアウトプットします。
プロジェクト・スコープ記述書とは、
プロダクトやサービスの主要な成果物や、前提条件や制約条件を記述します。
PMBOKでは、このプロジェクト・スコープ記述書に、
「やるべき作業と、やらなくてよい作業」をどれだけ詳細に記述できるかによって、
プロジェクトのスコープ全体がコントロール出来るかどうかを決めることに役立つ。
と記述されています。
プロジェクト・スコープ記述書には以下の項目を記述します。
- プロダクト・スコープ記述書
- プロダクトのスコープを記述したもので、段階的に詳細にしていきます。
- 成果物
- プロジェクトを完了する為に必要な成果物を記述します。
例えばこの「プロジェクト・スコープ記述書」も成果物に含まれます。
最初は概要レベルでどういった成果物があるのか記述しておき、
段階的に詳細化していきます。
- プロジェクトを完了する為に必要な成果物を記述します。
- 受け入れ基準
- 成果物を受け入れる為に必要な事を記述します。
品質のチェックを行う必要がある、
受け入れチェックを特定の部署にやってもらうなど、
成果物を受け入れるために必要な基準を記述します。
- 成果物を受け入れる為に必要な事を記述します。
- プロジェクトからの除外事項
- 「このプロジェクトではやりませんよ～。」といった除外事項を記述します。
やらないことを明示的に記述しておくことで、
関係者（ステークホルダー）との認識の齟齬がなくなり、
スコープクリープの発生を軽減することが出来ます。
- 「このプロジェクトではやりませんよ～。」といった除外事項を記述します。
こういった「プロジェクト・スコープ記述書」を作り、
関係者（ステークホルダー）と合意をとっていくことで、
本当に作るべき製品、サービスが明確になっていきます。
ここでは割愛しますが、
PMBOKには、「プロジェクト・スコープ記述書」を作成する為の「スコープの定義」プロセスで、
行うべきツールとテクニックに関する記述もあるので、参考にすると良いでしょう。
スコープクリープの発生を予防するために、しっかり、このプロセスを行うということが大切です。
そして、最初から全部盛り込むのではなく、段階的に詳細にしていくことも大切です。
本当にやるべき仕様を決めるため、「やらないこと」を決めておこう
今回伝えたいことは、「プロジェクトからの除外事項」を決めることです。
よく、「除外事項を決めるのは後ろ向きじゃないか？ 今からその可能性を塞ぐのはどうかと思う！」と言われることがあります。
しかし、除外事項を決めることで、「この製品の特長、お客様に伝えたいところ」が何なのか？、
製品として大事な「コア」が浮彫りになってくることがあります。
「この製品って結局何を作ろうとしてたんだっけ？ 何が魅力何だっけ？」と迷ったら、
一度「やらないこと」を決めて、合意をとってみるプロセスを行ってみてはいかがでしょうか？
参考：プロジェクトマネジメント知識体系ガイド PMBOK®ガイド 第６版
