CaseStudy 6: プロジェクトの立て直し方(前編)

失敗は繰り返される?

JUASが毎年実施している『企業IT動向調査』の最新の結果を確認すると、特に500人月以上の大規模プロジェクトにおけるQCDに関するマイナス評価はほぼ横ばいである。

内訳をみると、コストおよび納期については『予定より超過』が約50%で前年とほぼ変わらず、品質についての『不満』は約35%であるが、前年よりも悪化している。日本国内におけるPMP 取得者は着実に増加しているにも関わらず、なぜ失敗プロジェクトは後を絶たないのだろうか?

特に経済状況が厳しさを増す昨今では、"選択と集中"を志向する多くの企業が多額の投資を必要とする大規模プロジェクトの実施判断を慎重に下している。減少傾向にある大規模プロジェクトの実施数に対し、各プロジェクトに託された期待や投資対効果は増加傾向にあると考えられ、リスクを回避し、プロジェクトを確実に成功に導くことが、これまで以上に強く求められている。

プロジェクトは唯一無二のものであり、全く同じものは存在しない。しかし失敗プロジェクトを学ぶことで、類似の落とし穴に陥るリスクを軽減することができる。

本連載の最後のケーススタディとしては、プロジェクトの成否の大部分を決めるといっても過言ではない『プロジェクトの立ち上げ』をテーマとし、その重要性を再確認するとともに、失敗の方向に進みつつあるプロジェクトの立て直し方について、具体的な実践ノウハウを紹介していこう。

プロジェクトは立ち上げが肝心

プロジェクトの成否はその準備で8割が決まる。準備とはプロジェクトの立ち上げ～計画策定までの範囲を示すが、特に方向性を定め第一歩を踏み出す『立ち上げ』が重要である。最初の一歩を間違えてしまうと、その方向転換に時間を要することは想像に難くない。

プロジェクト関係者に対してプロジェクトの目的やゴール、スコープや成果物を共有し、主要なマイルストーンと役割分担を合意し、会議体その他のコミュニケーション・プランを策定する。この一連の流れを確実かつスムーズに実施することができるかどうかで、プロジェクトの方向性と基本的なスピードが左右されることになる。

ここで注意しなければいけないのは、プロジェクトには『立ち上げ』が複数回存在する、ということである。多くの時間を必要とするプロジェクトは、通常、フェーズと呼ばれる複数の段階で構成されるが、『立ち上げ』はプロジェクト全体としての立ち上げに加えて、フェーズ毎にも存在する。

例えば、ITシステム開発プロジェクトであれば、構想策定フェーズ～システム化計画フェーズ～要件定義フェーズ～基本設計フェーズ……といった複数のフェーズが存在するが、プロジェクト全体としての『立ち上げ』に該当する構想策定フェーズに対し、構想策定フェーズ自体にも『立ち上げ』が存在するのである。

この例では『立ち上げ』の『立ち上げ』となり若干ややこしくなっているが、このフェーズ毎の『立ち上げ』に対する意識が希薄な場合、折角、上手く立ち上げたプロジェクトが迷走(あるいは空中分解)する恐れもある。プロジェクト全体を俯瞰しつつ、実行の単位となる各フェーズの繋ぎについては細心の注意を払う必要がある。

立ち上げを怠るとどうなる?

ではここで、フェーズの立ち上げが上手くいかなかった例を紹介しよう。

ITを活用した新事業を立ち上げるためのプロジェクトを開始した企業Aでは、まず構想策定フェーズを実施した。構想策定フェーズのゴールは、新事業のイメージを固め、目指す目標を定めた事業構想書を作成することである。このプロジェクトは自社の将来を案じた有志達が、半ば自主的に開始したもので、有志達は業務の合間や時間外を中心に事業構想書を練り上げていった。

そして半年後、完成した事業構想書は社内で評価され、プロジェクトの継続が正式に認められるにいたったのである。有志達は一時の達成感を味わいつつ、後続のシステム化計画フェーズの遂行には強化した新体制が必要と上申し、プロジェクトオーナー合意の元、新体制でプロジェクトが続行されることになったのである。

さて、いざシステム化計画フェーズが始まると、プロジェクトマネジャーは思ってもみなかった壁に遭遇した。構想策定フェーズの勢いそのままに、かつての有志達をチームリーダーに据えたが、日常業務においても貴重なリソースである彼らの専任は認められず、引き続き兼務でのプロジェクト遂行を余儀なくされてしまった。

そこで、各チームリーダーの業務量不足を補完する目的で、チームメンバーを全員専任にするとともに、余裕のある人数を配置し、チームとしてプロジェクトの目的を達成させようとした。

しかし、この布陣が見事に空回りしてしまう。定められたマイルストーンを遵守しようと気を吐くチームリーダーに対し、チームメンバー達にはやらされ感が漂い、両者の間に見えない壁が存在しているようだった。

兼務での参画となっていたチームリーダー達も、いつしか疲弊し、他のチームの進捗状況を盾に自分とチームを正当化するようになっていった。次第にプロジェクトマネジャーとプロジェクトオーナーの間の意思疎通ですらも上手くいかなくなり、いよいよプロジェクトは暗礁に乗り上げてしまうのである。

さてこのプロジェクトにおける問題点は何だったろうか? ここまでのストーリーから、その答えは後続フェーズにおける『立ち上げ』を怠ったことだろうと察しがつくと思うが、具体的に何が問題だったのだろうか? そしてこの状況からどのようにプロジェクトを立て直していけば良いのだろうか?

続く後編ではその答えをご紹介していく予定である。お楽しみに。

執筆者紹介

鷺島淳一(SAGISHIMA Junichi) - 日立コンサルティング マネージャー

外資系ソフトウェアベンダーにてSOAエバンジェリストとして、日本国内へのSOA啓蒙活動と共に、製造・サービス・流通業を中心としたSOA導入支援を実施。2007年より現職。コンサルティング活動に従事する傍ら、PMコミュニティの運営も担当し、PM方法論のブラッシュアップに貢献中。

監修者紹介

篠昌孝(SHINO Masataka) - 日立コンサルティング ディレクター

国内最大手のファイナンシャルグループで、BPRプロジェクトや、数多くのEコマース構築プロジェクトにて、PMを歴任。2001年に外資系大手コンサルティングファームに入社、主にERP導入や、SOA技術を駆使した大規模SIプロジェクトを成功に導いた。同社のパートナー職を経て、2007年より現職。