特集企画

プロジェクトマネジャーに贈るプロセス改善事例　第2回

「完ぺきな」プロジェクト計画書に潜む失敗の落とし穴

プロジェクトの開始直前、予定していたエンジニアがアサインできない事態に遭遇した経験はないだろうか。今回は、実態に合わないプロジェクト計画が原因でプロジェクトの失敗を招いたY社の改善事例を紹介する。

[堀江弘志，豆蔵]

　プロジェクトを開始するとき、多くのプロジェクトマネジャーはプロジェクトを計画し、その成果物として「プロジェクト計画書」を作成する。しかし会社や対象部門、プロジェクトなどによって、計画の進め方、計画書の形式や内容はさまざまであり、実態に合わない計画を立てたことが原因でプロジェクトが失敗してしまうこともある。

プロジェクト計画書は「絵に描いたもち」？

　Y社は官公庁など公共機関のシステム構築を得意とするシステム開発会社である。大規模プロジェクトを扱うことが多いため、プロジェクトマネジメントを重要視しており、社内でマネジメントプロセスの標準化がなされている。

　2007年、Y社はある地方自治体の工事管理システムを受注し、同様のシステム開発経験を持つA氏をプロジェクトマネジャーに任命した。A氏は顧客が作成した提案依頼書などを基にプロジェクト計画書を作成し、社内と顧客の承認を得て無事プロジェクトをスタートさせた。

　ところが、1カ月もたたないうちにプロジェクトは迷走を始めた。

• 計画していた主要メンバーが社内の別プロジェクトに引き抜かれ、アサインできなかった
• 計画段階では見えていなかったステークホルダーが存在し、仕様の決定に時間を要した

など、プロジェクトの実行に影響を及ぼす問題が立て続けに発生したのだ。

　さらに、この後も計画段階では予期しなかったさまざまな問題に直面。結局、このプロジェクトは当初の計画よりも3カ月の稼働遅延、50％のコスト超過となり、社内では“失敗プロジェクト”と評価されてしまった。

　プロジェクトはなぜ失敗したのか。A氏が実施した計画プロセスは社内のマネジメントプロセスに従って進められており、プロジェクト計画書もひな型を利用して作成した。また、100ページに及ぶプロジェクト計画書は社内上層部や顧客の承認も得ており、手続き上でも何ら問題はないように思われた。

　しかし、発生した問題の中には計画段階で把握していれば回避できたものも含まれていた。A氏が作成したプロジェクト計画書の内容は、書式などの体裁には問題がなかったが中身を伴ったものではなく、実効性の低いものであったことが分かった。

　国際標準のプロジェクトマネジメントのための知識体系「PMBOK（Project Management Body Of Knowledge）」では、Y社が直面した問題をリスクとしてとらえるために、計画時のプロセスとして、リスクの識別と分析および対策の実施検討を定義している。その概要は以下の手順となっている。

PMBOKにおけるリスクマネジメントの手順

1. ブレーンストーミングやチェックリストなどでリスクを識別する
2. リスクを発生確率と影響度の観点から分析する
3. リスクを基にスケジュール、コスト、スコープなどの現実的な目標を設定する
4. リスクへの対応計画を検討する

　しかし、経験豊富なプロジェクトマネジャーでもこれらのプロセスを実行することは簡単ではない。なぜなら、実効性のあるリスクマネジメントを行うためには、プロジェクトを深く理解する必要があるからだ。

失敗原因、それはプロジェクトの理解不足にあった

　ここで、Y社が直面した問題を順番に振り返ってみる。

1. 計画していた主要メンバーが社内の別プロジェクトに引き抜かれ、アサインできなかった
2. 計画段階では見えていなかったステークホルダーが存在し、仕様の決定に時間を要した

　まず、（1）の原因は要員計画の失敗にあるといえる。「恐らくアサインできるだろう」など希望的な観測をもって要員計画をすると、このような問題に陥る可能性が高い。

　プロジェクトマネジャーは、「社長肝いりの“優先度の高い”プロジェクトはないか」「問題が発生してリカバリを必要としている“緊急性の高い”プロジェクトはないか」など、社内のほかのプロジェクト状況を把握しておく必要がある。

　また、社内のリソースは有限であり、特に優秀なエンジニアは奪い合いになる可能性がある。担当するプロジェクトだけではなく、組織や会社全体を考慮して開発メンバーをアサインする必要がある。

　次に、（2）について。表面的に見えているステークホルダーだけを特定して計画を立ててしまうと、このような問題に陥ることがある。また、対象組織の中には特定の業務や技術などに深い知識を持つエキスパートも存在し、彼らは仕様の意思決定に大きく関与する可能性がある。こうした隠れたステークホルダーの存在も見逃せない。そのため、プロジェクトマネジャーは、顧客企業全体の組織体制やその役割、プロジェクトへの関与などを網羅的にとらえておく必要がある。

　このように、今回の失敗原因はプロジェクトの初期段階での情報収集に問題があったといえる。

プロジェクトを知る！　プロジェクトアセスメント

　プロジェクトマネジャーにとって、計画を策定する前にプロジェクトを正しく理解しておくことは非常に重要である。

　Y社では今回の失敗を受け、計画プロセスの前に「アセスメントプロセス」を追加し、プロジェクトマネジメントのプロセス改善を実施した。アセスメントプロセスでプロジェクトに関する情報を収集して分析することで、より現実的なプロジェクト計画の立案を目指した。

新しいマネジメントプロセス

（1）プロジェクト情報の収集

　プロジェクトの情報は提案依頼書などの形ですぐに入手できる。しかし、プロジェクトを成功させるためには、ドキュメントに表現されている静的な情報だけではなく「生きた情報」の収集も必要である。

　生きた情報とは、「顧客企業内のキーパーソンや意思決定者は誰なのか」「組織間のパワーバランスはどうなっているのか」「プロジェクトに懸けるステークホルダーの思いや意気込みはどれくらいなのか」など、提案依頼書などのドキュメントには記載されない情報のことである。

　プロジェクトマネジャーは、顧客や自社内の組織など、プロジェクトに関係すると思われるステークホルダーに対して、自らインタビューを申し出て情報収集に当たる必要がある。「プロジェクトを成功させる」という強い意志を持ち、できる限り多くのステークホルダーの協力を得ておくことが、その後のプロジェクト運営にも好影響を与えることにつながるのだ。

　このプロセスで収集すべき情報として、「プロジェクトの背景や目的」「プロジェクトの目標」「顧客組織やステークホルダー、社内組織の状況」などが挙げられる。これらの情報を収集する際には、「可能な限り広範囲でプロジェクトをとらえること」が重要となる。

　プロジェクトマネジャーは、「プロジェクト分析シート」をあらかじめ用意して、情報の網羅性を高める必要がある。以下にプロジェクト分析シートの例を示す。

（2）プロジェクト情報の分析

　次に、プロジェクトマネジャーは「その情報がどこまで正確なのか」「根拠が薄く個人の思いや希望や期待から出された情報（仮定情報）ではないか」など、情報の正確性について吟味し、その分析結果をプロジェクト分析シートに追記しておく必要がある。

　収集した情報には、確実な情報もあれば不確実な情報も存在する。また、複数のインタビュー結果から矛盾した情報を得ることもあるだろう。この時点では、整合性の取れた正確な情報を得ることは難しいので、インタビューの結果に対する未確定事項の分析が重要である。

　アセスメントを実施する際には、プロジェクトマネジャーは以下の点に注意する必要がある。

• あら探しのような“ネガティブ”なインタビューをしない

　インタビュー中、ついあら探しをしてしまい、相手の心象を悪くするような場合がある。プロジェクトの成功を目的とした前向きなインタビューを実施しなくてはならない。

• 自身の過去の経験や知識によって、事実を曲げて解釈しない

　経験豊富なプロジェクトマネジャーほど、過去の経験や自身の知識にとらわれて、事実を曲げて解釈する傾向がある。常に新たな視点を持つことと、冷静な情報分析が求められる。

• アセスメントにはある程度の妥協が必要

　アセスメントは時間とコストを掛ければ、より深く詳細に情報を得ることができる。しかし、目的を逸脱した過度の実施は避けなければならない。

（3）基本戦略の策定

　最後に、分析された情報を基に基本戦略を策定する。

などを検討しておくことで、この戦略を基に具体的かつ実効性のある計画を作成することが可能となる。

プロジェクトアセスメントプロセスの概略

プロジェクトレビューの雰囲気が変わった

　Y社では、改善したプロセスを新たに受注した公共機関の発注管理システムへ適用した。今回もA氏がプロジェクトマネジャーを担当した。

　A氏は新しいプロセスに従って、顧客や社内関係者へのインタビューを申し入れ、積極的にプロジェクト情報を収集していった。その中で「対象システムが将来、ほかの自治体との共同利用を構想している」という情報を得た。この件に関しては、顧客側では将来的な構想であることから提案依頼書には明確に記載しておらず、開発側との対象システムについての解釈に違いがあることが分かった。

　この結果を基にA氏は、システムの共同利用に関するプロジェクトでの取り扱い範囲を先行して合意するという計画を立てた。開発コストや仕様に大きな影響を及ぼさない範囲で共同利用を考慮に入れて開発することで、将来、システムの共同利用が具体化した際にシステムへの影響度を極力少なくできると考えたからだ。

　こうして作成されたプロジェクト計画書を基に、プロジェクトレビュー会が開催された。これまでのレビュー会では計画書の目次に従って順に説明を行い、簡単な質疑応答がなされて終了するなど、形式的なものが多かった。

　しかし、A氏は今回、プロジェクト計画書の内容を基にプロジェクトを成功させるための自らの考えをプレゼンテーションした。その結果、レビュー参加者全員が、プロジェクトの目的や、目標を達成するための具体的な実行イメージを頭に描くことができ、プロジェクトに対する理解を深める結果となった。

　さらに、プロジェクトマネジャーが早期に多くのステークホルダーと会話したことで、互いの協力関係が生まれてプロジェクトが進めやすくなるという効果もあった。

　ともすればプロジェクトはさまざまな思惑や事情で、そのベクトルが分散しやすいものである。しかし、Y社ではプロジェクトアセスメントを導入したことで、ステークホルダー間でプロジェクトに対する共通認識が生まれ、プロジェクトの成功に向けて団結することができた。

　この後、プロジェクトは計画の通りのスケジュールで稼働を迎えることになった。Y社は今回の教訓を踏まえ、すべてのプロジェクトにアセスメントプロセスを適用する予定である。

計画プロセス改善

　最後に、計画プロセスの改善ポイントをまとめておく。

• 形式主義では実効性の高い計画書は作れない

　PMBOKの浸透もあり、Y社のように何らかの形でマネジメントプロセスを標準化している会社は多い。プロジェクトの開始から終了までのプロセスや主要なドキュメントのひな型を定義し、プロジェクトマネジャーに利用を義務付けている。しかし、過度な標準化はプロジェクトマネジャーの思考停止を生んでしまう。その結果、形式上は問題ないが実効性の低い計画書を作成し、プロジェクトが失敗することになる。

　Y社では標準化の危うさに気付き、プロジェクトアセスメントプロセスを追加することで問題を回避したのである。

• 戦略がなければプロジェクトは動かない

　Y社ではアセスメントプロセスの中に基本戦略の検討を追加し、実効性の高い計画書の作成につなげることに成功した。

　一般的に、プロジェクト計画書が顧客や社内上層部の承認を得なければプロジェクトを開始できない。手続き上必要なことに疑いはないが、承認を受けることが目的化しているプロジェクトマネジャーも中にはいる。

　このような場合、承認を得るために数百ページにわたる大量のドキュメントを作成してしまうことがある。計画書の本来の目的は、プロジェクトマネジャーがプロジェクトをどのように推進して成功へ導いていくかを描くことであり、戦略やプロジェクトの推進方針が端的かつ明確に示されていることが最も重要なのである。

• 計画段階から多くの人を巻き込む

　Y社では、プロジェクトアセスメントの実施によって多くの人に計画段階から参加してもらうことで、プロジェクトへの参加意欲を高める効果を得た。

　プロジェクトマネジメントは困難の連続であり、当初の計画通りに進むプロジェクトはほとんどないだろう。しかし、さまざまな問題を乗り越えてプロジェクトを成功に導くためには、プロジェクトマネジャー自身の腕だけに頼るのではなく、周囲の人々からの協力を多く得ることが重要である。

　今回のように、プロジェクトの失敗がきっかけとなってプロセスを見直す場合は多い。しかし、多くの人の思惑や事情があり、見直しが必ずしもうまくいくとは限らない。Y社が成功した要因について、連載第1回で説明した「プロセス改善を実効性のあるものにする3つの要素」に当てはめて考えてみよう。

Y社のプロセス改善が成功した要因

• 知識：プロジェクトを成功に導くためには、実効性の高いプロジェクト計画書が必要であることを突き止めた
• スキル：計画を立てる前にアセスメントプロセスを導入することで情報を収集・分析し、プロジェクトを正しく理解して実効性の高い計画書を作成した
• やる気：プロジェクトを二度と失敗させたくないという、プロジェクトマネジャーをはじめとした多くのステークホルダーの強い意欲があった

　上記の3点があったからこそ、Y社は計画プロセスの改善を成功に導いたといえる。