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

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

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

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

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

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

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

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

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

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

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

• いい加減な見積もり

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

• あまいスコープ管理

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

ミスを防ぐには

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

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

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

• 開発計画をたてる

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

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

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

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

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

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

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