大内隆良（＠IT自分戦略研究所）
2006/9/26

プロジェクトはなぜ失敗するのか。危ないプロジェクトには、何か共通点はあるのか。自身も失敗プロジェクトを経験したITエンジニアの話から、成功するプロジェクトのヒントを探る。

　新しいプロジェクトに配属されたときに、嫌な予感はないだろうか。または何かおかしいと感じたことは？

　実際に多くのプロジェクトにかかわってきたITエンジニアに聞くと、次のような話をしてくれることがある。「プロジェクトに配属されたときから、何か変だと思ったんですよ」と。多くのITエンジニアは、このように本能で危険なプロジェクトを察知しているのだろうか。

　＠IT自分戦略研究所で「プロジェクトマネジメントスキル 実践養成講座」を執筆したスカイライトコンサルティングの�瘟ｪ（すぎおか）充宏氏に、プロジェクトマネジメントについて話を伺った。

■マネージャも失敗を何度も経験する

　まずは大きなプロジェクトの失敗経験を聞くと、「先日も同じような質問を受けたんですよ」と苦笑する。「まず思い出すのは、約10年前に携わったプロジェクトです」という。

スカイライトコンサルティングの�瘟ｪ（すぎおか）充宏氏

　そのプロジェクトは、ある企業の業務改革とシステム構築から成り、そこそこの規模を誇るプロジェクトだった。�瘟ｪ氏は、チームリーダーとして要件定義の段階から参画したが、完成したシステムはバグが多く（質が低く）、実装されるべき機能が実装されていないなど、到底ユーザー企業に納品できるレベルにはなかった。

　そのため、「改修に改修を重ね、使えるようにしました」（�瘟ｪ氏）とのこと。それでようやくユーザー企業に納得していただいたという。

　別の大きな失敗プロジェクトは、約3年前のものだという。ある企業におけるERPパッケージ導入による基幹システム刷新という大規模案件だった。すでにプロジェクトがスタートして数カ月たってから、�瘟ｪ氏はこのプロジェクトにアサインされた。半年でカットオーバーのはずが、要件定義がまとまらないまま。そこで�瘟ｪ氏が火消しマネージャとしての役割を担い、プロジェクトに参画したはずだった。

　�瘟ｪ氏は、「火消しの場合、火事よりも船に例えた方が分かりやすいかもしれません。沈みそうな船に乗り込んで問題を把握し、何とか修理して動くようにして操船しろ、ということだったのに、結局自分も一緒になって沈んでしまったのです」と語る。

■経験の浅い若手を大量投入

　この失敗プロジェクトの取りまとめ役は、某大手ITサービス企業。プロジェクトが危機に陥ると、「人員の大量動員」で乗り切ろうとした。しかしこの大量動員が結果としてプロジェクトの危機をさらに煽ることになってしまったという。

　人員の投入は悪いことではない。問題は、投入された人員の構成にあった。現場に投入されたのは、ほとんど上流経験のない、あるいはクライアントの業界、業務知識の浅いITエンジニアばかりだった。現場のITエンジニアには非はないのだが、彼らの多くは自分が何をやるべきか把握できず、現場でオロオロし、何度クライアントと打ち合わせをしても要件定義はまとまらず、時間は瞬く間に経過していった。そのため、プロジェクトは負のスパイラルへと陥った。

■プロジェクトを支配していたもの

　本当は、無理なプロジェクトだということを、もっと前の段階でクライアントに話し、プロジェクトを抜本的に考え直すべきだったのだろうと、�瘟ｪ氏は振り返る。「そもそも無理なレールの上に乗っているようなプロジェクトだったのです。プロジェクトを再検討すべきです」とプロジェクトの進ちょく会議で�瘟ｪ氏は提案したが、一蹴された。その雰囲気に�瘟ｪ氏も染まっていったという。そうなると、精神論的な掛け声ばかりが現場を覆う。そのような状態においては、ただの掛け声はメンバーのモチベーションを下げることには役立ったが、プロジェクトの建て直しは遠のいた。

　こうした混乱の中、プロジェクトリーダークラスの人間が、次々と戦線から離脱していった。失敗するプロジェクトは、このように人の入れ替えが激しい。しかし、新たに投入された人員は、プロジェクトの状況を把握していない。このような結果、現場はますます混乱に陥っていった。

　このプロジェクトを支配していたのは、後ろ向きの空気だった。次第にプロジェクトが危機に陥っていく中、メンバー間のコミュニケーションは崩壊していったという。あるメンバーがほかのメンバーに「ある項目の洗い出しのリストが欲しい」と電子メールを送っても返信がない。そこでじかに頼みに行くと、「そんな時間はない」といわれる始末。だが、問題はその人だけではなかった。実は皆、ほかのメンバーからの依頼メールを無視していたのだ。そして皆、なぜ自分のメールに返信しないのかと、イライラしていたのだ。デスマーチ化したプロジェクトでは、こうしたある意味漫画のような展開が本当にあったりする。

■失敗プロジェクトに共通するものは？

　�瘟ｪ氏に、失敗するプロジェクトの傾向について伺った。

　少し考えた後「失敗するようなプロジェクトでは、最新のスケジュールと課題が出てこないこと多いですね」という。失敗となりそうなプロジェクトでは、問題の対応に追われて、スケジュール管理と課題管理まで手が回らないのだという。

　各チームや個人単位では、スケジュールが存在することも多いそうだ。ただし、現場ごとにスケジュールのバージョンが異なっていたりする。それですべてのスケジュールを集めて全体のスケジュールを推察しようとすると、さまざまな矛盾が浮かび上がることがあるという。結局、全体スケジュールは、プロジェクト開始直後のまま更新されていないことが分かったりする。

　こんなことは、何もスケジュールの話だけではない。よくあるのはシステムの仕様だ。さまざまなフォーマットで仕様が存在し、それぞれの仕様で内容が微妙に違っていたりする。どれが最新の仕様かということを突き止めるのに、何度も会議を開かないと分からないという、これまた漫画のようなこともある。

■プロジェクトの成否は事前の段取りにある

　�瘟ｪ氏が問題と指摘するのは、コミュニケーションだ。�瘟ｪ氏が経験した失敗プロジェクトでもそうだが、コミュニケーション不全がプロジェクトを危機に陥れることが多いのだ。「問題プロジェクトでは、自分から話し掛けようとしない、黙っている人が多い」（�瘟ｪ氏）など、そもそもコミュニケーションの土台が崩れていることが多いと指摘する。

　さらに、プロジェクトマネジメントで�瘟ｪ氏が感じているのは、対応が後手後手に回っていることが多い点だという。例えばプロジェクトメンバーに「いま、何をやらないといけないかと質問する。すると、いまの問題や課題への対応、過去の問題への対応を話すようだとダメです」（�瘟ｪ氏）

　プロジェクトの多くは、問題が生じてから策を練り、対応することになる。こうしたプロジェクトでは、問題が起きたときに対処できる「反射神経がいい人」（�瘟ｪ氏）が求められる傾向がある。しかしこれでは、プロジェクトは常に問題が生じることを前提とした体制になってしまう。

　「プロジェクトは段取り八分です。つまり、事前の段取りでプロジェクトの成否が決まります。次のフェイズで何をすべきかを考え計画を立てるのが、プロジェクトマネージャの仕事です」と�瘟ｪ氏。本来のプロジェクト管理は、大きな問題が生じないようにリスク管理をする。しっかりとリスク管理を行うことで、クリティカルな問題が起きる可能性を低くするのだ。こうした取り組みがプロジェクトの王道だというのが、�瘟ｪ氏の結論だ。

　皆さんが取り組んでいるプロジェクトは、後手後手の対応になっていないだろうか。それとも、事前の段取りが十分になされ、リスク管理は徹底しているだろうか。そして何より、プロジェクトに参画しているメンバーのモチベーションが高く、コミュニケーションは活発だろうか。一度、チェックしてみることをお勧めしよう。

関連記事

プロジェクトマネジメントスキル 実践養成講座

出動！ 火消しエンジニア

プロジェクトマネージャならば理解しておこう

開発現場で学べること