お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

プロジェクト管理上最悪のミスは何なのか?

2003/05/06 18:54
  • このエントリーをはてなブックマークに追加

ガイドの視点

 ITプロジェクトを成功に導く要因にはさまざまなものがあるが、プロジェクト管理にあたるマネージャにとっては、プロジェクトをよりよく管理することが求められる。だが、プロジェクト管理こそは「言うは易し、行なうは難し」の典型のひとつだろう。今回筆者が指摘している「よくあるプロジェクト管理の失敗例」は、その難しさを具体的に示すもので、次の5項目が挙げられている。

  1. 不適切なプロジェクト定義とプランニング
  2. スコープ変更管理の甘さ
  3. 作業計画を管理しない
  4. 不充分なコミュニケーション
  5. 品質管理の欠如

 いずれも「おっ」と思うようなタイトルだが、これらの中から、今回はもっとも重要な「不適切なプロジェクト定義とプランニング」について説明する。

 さて、その「不適切」とは何かといえば、これは「プロジェクトを進めるにあたり、まずはプロジェクトのスポンサーからコンセンサスを得るための、いわゆるプロジェクト定義をしっかり作っておかないこと」である。お金を出すスポンサーとプロジェクトの管理者であるあなたが、同じ目標と、その目標が生まれてきた背景にある発想を共有しないうちは、プロジェクトを開始すべきではない。それが本稿の趣旨である。そして、予算不足や納期の遅れ、途中からの方向修正がしにくいといった体質など、すべてがこのプロジェクト定義の甘さから来ているという。

 確かに、スポンサーあるいはクライアントは、自分たちにメリットがもたらされるとの前提でお金を出すわけだし、プロジェクトマネジャーとしては彼らのそうした考えを理解した上で進行しなくてはならない。だが、さまざまな要件が出てくるうちに本来の目標が見えなくなり、いつの間にかプロジェクトを進めること自体が目標に変わっている、というような本末転倒も起こりがちである。こうして最終的に出来上がったものは、誰のためのものかわからなくなってしまうのだ。

 そんな悲劇的結末を迎えないためには、プロジェクト進行中でも、一歩戻ってプロジェクト定義の一部あるいは全部を作り直す勇気が必要である、と筆者は述べる。ただし、経験に基づく実感としては、納期や予算の兼ね合いから、そんなことは許されないことが多いのも事実だと思う。そこで、事前のプロジェクト定義にしっかり時間をかけて、プロジェクトの中身を吟味することがなおさら重要になる。プロジェクトに関わった人たち全員がハッピーになれる結果を残すには、この定義をきちんと行うことが必須条件といえよう。

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

 「計画段階も、またも実装段階も、すべて完璧だった・・・」。そう思えるようなプロジェクトに、読者の皆さんが最後に参加したのは、いつのことだったろうか。予算、納期、品質ともに期待通りで、クライアントとの間には親密だけれどプロ同士のけじめもわきまえた協力関係がある。何ひとつ問題はない・・・。

 しかし、そんなプロジェクトは、運が良い人でせいぜい1つ、あるいは多くても2つくらいしか思いつかないだろう。

 大失敗に終わるプロジェクトも多い一方で、実際に成功を収めるプロジェクトもまた多くある。しかし、通常ほとんどのプロジェクトが、成功か否かのグレーエリア(あいまいな部分)で決着する。とりあえずプロジェクトは終わらせたけれど、納期に間に合わなかったり、予算を超過したり、クライアントが満足しなかったり、チーム間にいやな雰囲気が漂うといったことは常にある。プロジェクトをこうした結果に終わらせないためには、不適切な定義ならびにプランニングという、プロジェクト管理における最悪のミスを避けなくてはならない。

不適切なプロジェクト定義およびプランニング

 プロジェクトが終了し、それを総括する反省会に出席したことがある人は、「プランニングにもっと時間を割くべきだった」という言葉を耳にしたこと覚えがあるだろう。世の中には即刻ビジネス要件をまとめて、開発作業に突入しなくてはならないと考えているプロジェクト管理者も多い。彼らは、ビジネス要件さえ上手にまとめられれば、それで準備万端だと勘違いしている。勿論それは間違いで、プロジェクトの定義、そしてプランニングというプロセスをまず済ませておく必要があり、ビジネス要件をまとめるのは、実はその後で構わない。

 プロジェクトが実際に動きはじめる前に、プロジェクト管理者は、プロジェクトのスポンサーや主要な利害関係者に、開発作業の中身を正確に理解させ、彼らの同意を得ておかなくてはならない。プロジェクトの完了時点で、どんな納品物ができてくるのか、それをつくるコストはいくらか、誰が作業するのか、どんな手順で行なうのか、そしてどんなメリットを得られるのか等の点について、スポンサーや出資者との間で、期待するものにズレがないようにする必要がある。また、プロジェクトが大規模になるほど、これらの情報を正式な形で明確に説明しておくことが重要になる。どのプロジェクトにおいても、こうした事前準備をきちんと行い、先々に起こりえる問題を未然に防ぐべきである。

だめなプランニングが招く結果は

 開発スタート前の定義およびプランニングがまずいと、後々いろいろな部分で問題が起こる。以下は、そのうちの主だったのものである。

  • ビジネス側からの支援を得られない

 プロジェクトの主だった長所をあらかじめ定義しておかないと、主な利害関係者の間で期待するものがズレてしまうといった事態がよく起こる。スポンサーが初めに出してきた方向性を、そのまますべて受け付けていたとしても、そういうことが起こってしまう。プロジェクトの規模が大きくなるだけ、スポンサーが完成時の全体像を把握することも余計に難しくなり、成功に終わらせるためにどんなことをしておく必要があるのかも怪しくなってくる。また別の場合には、スポンサーがある完成形を頭のなかに描いていても、実はそれとは違った、もっと優れた現実性の高い完成形があるかもしれない。そんな競合し合うアイデアが後になって表面に現れると、プロジェクトは混乱し、やりなおしとなる場合もある。

  • いい加減な見積もり

 ふつうは、ビジネス要件の取りまとめが終わる前に、予算と納期を決めておく必要がある。だが、プロジェクトの定義とプランニングがきちんと済んでおらず、おかげでプロジェクトチームは十分なリソースや時間も与えられないまま、見切り発車で動き始めてしまう、といった場合も多くある。予算超過や納期遅れが起こり、本来なら成功していたプロジェクトが、失敗だったとみなされてしまうことも多い。こうした状況が起こる原因は、プロジェクト管理者が事前の計画をしないまま、低すぎる見積もり金額で契約を受けてしまう点にある。

  • あまいスコープ管理

 プロジェクト定義の主な仕事のひとつに、高いレベルからプロジェクトのカバーする範囲を定めるというのがある。このスコープについて合意を得ておかないと、プロジェクト期間全体を通じて、スコープ管理を効果的に行うことがとても難しくなる。

ミスを防ぐには

 事前に充分な時間をとって、プロジェクト定義とプランニングをきちんとしておくと、結局後でかかる手間が減り、プロジェクトの進行中に問題の修正に煩わされることも少なくなる。この問題を回避するには、プロジェクトを進める前に、次の2つの部分に集中して取り組むことが必要だ。

  • プロジェクトを定義する

 実際の作業を開始する前に、時間をとって、プロジェクトの目標、スコープ、前提事項、リスク、予算、時間枠、組織、そして全体のアプローチを定義すること。プロジェクト管理者のなかには、「そんなことは今更言われなくても判っている」という人もいるだろう。だが、この作業の目的は、プロジェクト管理者とプロジェクトのスポンサーやその他の関係者の間でコンセンサスがとれていることを確認することにある。たとえプロジェクトを進める立場の管理者とスポンサーの間で同意していても、違う意見を持つ利害関係者が他にいるかもしれない。主要な関係者間の意見の相違は、プロジェクトがスタートする前に解決しておかなければならない。

  • 開発計画をたてる

 プロジェクト管理者は、開発をスタートさせる前に、全体の作業プランを作成するべきだ。そうしておけば、プロジェクト全体で必要となる労力や期間の見積もりが楽になる。また、直近数カ月間の詳細な作業プランも併せて計画しておこう。それがあれば、プロジェクトが実際に動き出した後で、リソースが正しく割り当てられていることを確認できる。

 さらに、プロジェクト管理上の手続きについて関係者間で同意したものがあると、とても役に立つ。その手続きのなかには、プロジェクトの管理者が、スコープや問題、リスク、コミュニケーション、作業プラン等をどう管理するかも含まれる。利害関係者の期待するものを上手に管理するには、上記の項目すべてについて予め定義をしておくことが成功の鍵となる。たとえば、スコープの変更要求について承認を与える手続きを定め、それについての合意を得ておけば、後でずっと楽に変更ができるようになるはずだ。

プロジェクトが動き出してしまっている場合には?

 問題を解決する最善の方法は、それを見越して予防手段を講じること。だが、この選択肢がない場合は、いったいどうすればよいだろうか?すでにプロジェクトに着手していて、これまで述べたような箇所に、問題の兆候が見え始めているとする。例えば、プロジェクトが達成すべき目標に関して利害関係者が複数の異なる意見を出してきたものの、開発チーム側では以前に取り決めたビジョンに沿ってプロジェクトを進めていたという場合、何かよい手があるのだろうか・・・。

 問題箇所が1つ、2つだけの時には、簡易版のプロジェクト定義を再度行えばいい。たとえばプロジェクトのスコープを管理できていないことに気付き、その原因がそもそも事前に定義しておかなかったことにあるなら、その時点で時間をとり、スコープを定義して、関係者の合意を得ること。そのためには、スポンサーや利害関係者と改めて相談し、コンセンサスを得て、承認を受ける必要も出てくるだろう。

 プロジェクトの達成すべき目標に関して競合する考えが出てきたことに気付いたら、プロジェクトが進行中でも、振り出しに戻って定義プロセス全体をやり直す必要があるかもしれない。これは簡単ではなく、痛みさえ伴う行動だが、決して実行不可能というわけでもない。一歩後ろに下がり、目標、スコープ、役割、リスク等を定義し直す。現実的には無理な場合も多いけれど、それでも定義のプロセスが終わるまでは、開発作業をストップする必要があるかもしれない。

 すでに進行しているプロジェクトについて、その定義を平行して行うのは大変なことだが、それでも、問題を無視するよりはましである。プロジェクトを途中で止めると、後でやり直しが出て、そのための追加コストが生じ、納期遅れになってしまうこともありえる。だが、問題を無視して放っておいたら、せっかく完成したものが、納品を済ませた途端に、全く役に立たない、あるいは時代遅れの代物になってしまうかもしれないのだから。

  • このエントリーをはてなブックマークに追加
個人情報保護方針
利用規約
訂正
広告について
運営会社