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

ガイドの視点

 「プロジェクトが失敗する原因」シリーズの第二弾は、スコープ管理についてである。

 前回の第一弾は「プロジェクト管理上最悪のミスは何なのか?」についてで、主にスポンサーとのコンセンサスを取り続けることの重要性を述べたものであったが、今回はそれを受けての第二弾となっている。

 ここでは、スコープの定義の重要性と、スコープ変更についての注意点が述べられているが、規模の小さな開発においては、「スコープ」を「仕様」と読み替えてもよいだろう。

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

 プロジェクト全体の定義にかかるもので、成果物や仕事の境界線を定義する。

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

 プロジェクトの途中でスコープの変更があるのは誤りではない。完璧な要件定義はありえないと考えておくべき。変更せずに、そのまま役に立たない成果物ができても、誰の得にもならない。途中で変更があっても大丈夫なように、あらかじめスポンサーも交えて明確に変更の手順を定めておくべきである。

 ただし、どのように変更があってもよいわけでは勿論なく、その点について次のような注意も述べられている。

  • 小さな変更を担当者レベルで繰り返していると、いつの間にか膨大な追加作業が発生することがある。
  • スポンサーの了承を得ないまま、現場レベルで変更を決定してしまうのはトラブルの元になりやすい。
  • 変更が必要なときには、チームメンバーは速やかにプロジェクトマネジャーへ報告すべきである。

 このように、今回の記事の趣旨はスコープ変更、あるいは仕様変更を容認すべしという部分が目新しい。通常なら、こうした変更は、悪に近いものと受け取られていることが多い。もしかすると、これは米国と日本での考え方の違いもあるのかもしれない。

 ただし、少なくとも私が関わったプロジェクトでは、スコープ変更を容認するようなやり方は、発注側に有利に働きがちで、それがたとえば打ち合わせにば かり時間を取られたり、あるいは外注先に時間およびコスト面での負担を強いるといった好ましくない事態につながることが少なくなかった。

 また実際に、開発に入ってから発注側の要求が二転三転し、大幅な仕様変更が必要となる場合もある。もちろん、役に立つ成果物を作ることが目的であるのは言うまでもない。しかし、それで「完成が半年遅れても、予算は決まっているからコストも変わらない」と言われたら、「仕様変更には応じたくない」と感じるのが普通だろう。

 ポイントはここである。つまり、「仕様変更はあり得るもの」との前提で、「変更に必要な手順を決めておき、影響されるコストや納期についても、事前に解決可能としておく」ことになっていれば、上記のような被害を最小限に止められるのだ。

 最後に、あらためて繰り返すが、はじめに十分な調査をした上できちんと要件定義を行い、それでスコープ変更がないようにしておけば、さまざまな二度手間によるコストや時間もセーブでき、みんなハッピーになれることは間違いない。

監訳者(若田部、木村)
このコーナーでは米国TechRepublicから日本企業のITマネジメントに役立つ情報を日本人ガイドが厳選してご紹介しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今からでも遅くない

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

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

CNET Japanの記事を毎朝メールでまとめ読み(無料)

-PR-企画広告

企画広告一覧

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]