突然プロジェクトを頓挫させてしまうものは？

　プロジェクトの定義を行い計画を立てるのは、プロジェクトマネジメントを成功に導くための第一歩に過ぎない。計画立案の次は「計画通りにプロジェク トを進める」番だ。プロジェクトマネジャーたるもの、決められた時間および予算内で約束した仕事を確実に完了させなくてはならない。しかし、いったんプ ロジェクトが動き出すと、クライアントが当初に取り決めた以上の、あるいは取り決めとは異なる作業をするよう求めてくることがよくある。この避けようの ない現実に備えることも「計画通りにプロジェクトを進める」プロセスの一部だ。プロジェクトマネージャーは、こうしたクライアントの要望にあわせてスコー プ（仕事の範囲）を変更しなければならない。スコープ変更への備えがなければ、当初に取り決めた以上の作業を、元の予算枠のなかで完了させようと、悪戦 苦闘することになるだろう。

スコープ管理は仕事の範囲の定義から

　プロジェクトのスコープ（仕事の範囲）を定義することは、プロジェクトの定義という準備作業において最も重要な部分だ。このプロジェクトの成果物は何 か、また、プロジェクトでは何をし、何をしないかの境界線をはっきりと知らなければ、そのプロジェクトが成功する見込みはない。スコープ管理はプロジェ クト管理のなかで最も大切な部分といえよう。そして、スコープの「定義」ができなければ、スコープを「管理」することなどできるはずがない。

　スコープを「定義」する目的は、これから取り掛かろうとするプロジェクトについて、その論理的な境界線を明確に定め、それについての合意を得ること だ。そして、プロジェクトのカバーする範囲内にある事柄は何か、またこの境界から外れるのは何かを定義する。これには、スコープステートメント（スコー プ定義書）という文書が使われる。この文書にプロジェクトのスコープに関してできるだけ多くの点を盛り込むほど、そのプロジェクトはうまく進むといって いいだろう。次に挙げる各項目を頭に入れておくと、スコープ定義の際にとても役に立つ。

• プロジェクトの範囲に含まれる成果物と含まれない成果物には、それぞれどのようなものがあるか（例：ビジネス用件定義書、現状評価報告書など）
• 主要な作業工程のなかで、プロジェクトの範囲に含まれるものと含まれないものは、それぞれどの部分か（例：分析、設計、テスト）
• プロジェクトの範囲に含まれるデータとそうでないデータには、それぞれどのようなものがあるか（例：財務データ、売上データ、従業員に関するデータ）
• データソース（データベース）のうち、プロジェクトの範囲に含まれるものと含まれないものは、それぞれどのようなものか（例：請求データ、一般的な帳簿データ、給与データ）
• プロジェクトの範囲に含まれる組織と含まれない組織は、それぞれ何か（例：人事部門、製造部門、ベンダー部門）
• 主要な機能のうち、プロジェクトに含まれるものと含まれないものとは、それぞれなにか（例：意思決定支援機能、データ入力機能、管理レポート機能）

実行可能なスコープ変更プロセスを準備しておく

　プロジェクトマネージャーおよびチームのメンバーは、「途中でスコープを変更するのは何ら間違ったことではない」という点をよく理解しておくこと。誰かがスコープ変更を言い出したとしても、それを邪悪な提案だと受け止めなくてもいい。実際のところ、途中で変更を加えたほうがよいことも多い。なぜなら、多くのクライアントは、最終的に納品される成果物に求めるすべての要件や機能を、あらかじめ定義することができないからだ。また、きちんと要件や機能を定義できたとしても、はじめにそれを求めたビジネスが時とともに変化するので、プロジェクトに求められる要件もそれに合わせて変わるのが当然だからだ。

　このような変更を受け付けなければ、納品物は当初想定されていたものより価値の低いものになりかねない。あるいは、まったく使い物にならないものとなってしまうこともある。これを避けるために、プロジェクトが進行中であっても、必要に応じてクライアントがスコープを変更をできるようにしておこう。だが、この際にプロジェクトマネージャー側がスコープ変更を管理できる態勢にないと問題が起きる。だから、どのプロジェクトでも効率的にスコープを変更するためのプロセス（手順）を取り決めておこう。このスコープ変更プロセスには、変更箇所の特定、変更のビジネス的価値の算定、変更がプロジェクトに与える影響の算定、そしてその結論をプロジェクトのスポンサー（予算の決裁権を持っている人）に評価してもらう、といった手順を含めるべきだ。こうすれば、スポンサーはスコープ変更を行うべきかどうかを判断することができる。変更を行うときには、それがプロジェクトに与える影響をスポンサーにも理解してもらい、必要な追加の予算と時間を割り当てもらおう。

スコープ変更についてのよくある問題

　スコープ変更を管理していく際に、プロジェクトチームがよく遭遇する問題には、次のようなものがある。

じわじわと変わり続けるスコープ

　大きなスコープ変更であれば誰でも気づくが、小さなスコープ変更は気づきにくい。小さな変更だと、あまり深く考えず、ちょっとした追加作業をすれば済むと考えがちである。けれど、そうした細かな変更が積み重なると、結果として大量の追加作業が発生する。そして、予算を超過し、納期が守れない羽目に陥る。

スポンサーの承認を得ていない変更要求

　プロジェクトマネジャーはエンドユーザー、利害関係者、クライアント側のマネジャーなどから、数多くのスコープ変更要求を受けることがある。その人たちがみなクライアント企業の人間だからといって、その要求を受け入れなければならないと考えるの間違いだ。エンドユーザーはスコープの変更を言い出すけれど、その変更を承認する権限を持ってはいない。クライアント側のマネジャーでさえ、こうした変更を承認する権限を持っていないことがある。スコープ変更を承認できるのは、プロジェクトのスポンサーだけだ（ただしスポンサーが、別の人間に権限委譲していると場合もある）。クライアントの誰かが言い出した変更要求が、すでに承認を得ているものと思いこんで作業を進め、後になって実は肝心のスポンサーがその変更に同意していなかったとわかり、それでトラブルになることがよくある。

プロジェクトメンバーの報告義務

　プロジェクトチームのメンバーはクライアントと接する機会が多いので、スコープ変更の要求を聞く機会が多くなる。そのため、プロジェクトチームの全員がスコープ変更管理の大切さについて理解しておかなくてはならない。メンバー全員がスコープ変更に敏感であるべきだ。そして、スコープ変更に気づいたときは、プロジェクトマネジャーに報告する義務がある。プロジェクトマネージャーに報告をせず、メンバーが個々に追加の作業を引き受けてしまうと、彼らの担当分の完了が遅れ、プロジェクト全体が危険にさらされることになる。

今からでも遅くない

　もし、あなたが関わっているプロジェクトが予算オーバーし、スケジュールを超過しているようなら、その原因を見つけ出してみよう。単に当初に合意した以上の作業をしているのが原因という場合がほとんどだと思う。そうならないために、スコープ変更プロセスを取り決めておこう。これを定めるベストなタイミングは、実際にプロジェクトが動き出す前だ。なので、プロジェクト開始前に、スコープ変更プロセスについても決めてしまおう。だが、プロジェクト開始前にスコープ変更プロセスを取り決めていなかったという場合には、今からでも遅くない、すぐに「待った」をかけ、スコープ変更要求の必要な箇所を特定し、承認を得るためのプロセス（スコープ変更プロセス）について、クライアントと話し合おう。また、そこで決まったスコープ変更プロセスを、プロジェクトメンバー全員に周知することも大切だ。

　こうした努力にも良い面があるとすれば、それはプロジェクトが危機に陥っているため、チームメンバーおよびクライアントが、スコープをきちんと管理しておかない場合に生じる悪影響を、すでに身をもって知っている点だ。彼らもスコープ変更管理の目的をよりよく理解し、その後はもっときちんとプロセスを守るようになってくれるはずだ。