プロジェクトが“簡単に頓挫する”3つの要素：デジタルワークスタイルの視点

そもそもなぜプロジェクトは失敗するのか――。前回、まずは1人でプロジェクトマネジメントをしてみようという話を書きましたが、プロジェクトを成功させるためのテクニックに入る前に、“失敗”を考えてみたいと思います。

[徳力基彦，ITmedia]

　前回も書いたようにプロジェクトマネジメントというと、何だか小難しい印象を受けますが、基本的には複数のメンバーで実行するプロジェクトといえど、個人のタスクリスト管理の延長にあります。

　まずは、プロジェクトが失敗する要素を押さえることで、成功のためのポイントを見つめなおしてみましょう。プロジェクトが失敗する要素――というと、いかにもたくさんありそうに思えるかもしれませんが、実はプロジェクトを失敗させる要素は大きく分けると3つしかないのです。

プロジェクトが簡単に頓挫する3つの要素

• 無茶な計画
• メンバーのやる気
• 変化を認めない

最初に無茶な計画を立てる

　プロジェクトを失敗させる最も簡単な方法は、最初に無茶な計画を立てることです。多くの人が「そんなこと分かっているよ」と思うかもしれませんが、実際に失敗するプロジェクトのほとんどが、最初の計画の失敗から始まります。

　「顧客に値切られたために、当初の予定よりも人員を少なくせざるを得なかった」「盛り込む機能が決まっているのに、決算の都合でリリースを1カ月前倒しにせざるを得なくなった」などです。この手の「だから最初から無理だと言ったのに」という計画で実施されているプロジェクトは残念ながらなくなりません。

　計画全体から1割程度のぶれであれば、根性論や休日出勤でカバーできる面もあるでしょうが、最初の計画が明らかに無茶な計画である場合、それを成功させるのは至難のワザ。締め切り間際で奇跡がおきて、全てが上手くいくなんて都合の良い話は映画やマンガの中だけなのです。

　最初からプロジェクトの計画が無茶なのであれば、プロジェクトを成功させることよりも、まずは失敗をいかに小さくするかに集中したほうが良いというケースもあるでしょう。

メンバーのやる気

　もし、計画がある程度妥当なものであるとして、そのプロジェクトを計画通りにメンバーがこなしてくれれば、プロジェクトは成功するはずです。

　ただ、話はそんなに簡単ではありません。まず重要なのは、そのプロジェクトを実際に実行するメンバーです。メンバーといっても、メンバーの能力の話ではありません。メンバーの能力が足りないのであれば、事前にそれを見込んで計画を立てる必要があるという話ですから、それはどちらかという計画の話になるわけです。

　個々の能力よりも大きな失敗の要素となるのがメンバーの「やる気」。各メンバーの能力を計算に入れて、見積上は実行可能なプロジェクトを計画していたとしても、実際にメンバー見込みどおりに仕事をしてくれなければ簡単にプロジェクトは頓挫します。

　さらに難しいのは「やる気」がないという状態は、誰にでもいつでも起こりうるという点です。

　他人の話ではなく、自分の話として考えてみてください。作業に集中できて異様なほど仕事が順調に進むときもあれば、ほかのことが気になって仕事に集中できなかったり、理不尽な上司や先輩に腹が立って仕事をやる気にならなかったりすることがあるはず。特に、土木工事のように進捗が見た目にも分かりやすいプロジェクトであれば、やる気がなさそうな人を見つけるのも比較的容易ですが、ホワイトカラーの仕事は進捗が把握しづらい仕事がほとんどです。

　やる気があると思っていたメンバーが、何かのきっかけで急速にやる気を失い、気がついたら予定が大幅に遅れていたというのも、意外によくある話です。もちろん、プロジェクトマネージャーが細かくメンバーの進捗を把握するという手もありますが、過度の進捗確認がメンバーのやる気をそぐこともありえるというのが、また悩ましいところでしょう。

変化を認めない

　プロジェクトの計画も無難、メンバーもやる気があるから一見問題ない――という場合に、失敗の要因となるのが「変化」です。

　例えば、予定していたのとは異なる作業が増えた場合です。「メンバーが病気になって数日休んでしまった」「サーバトラブルが発生して復旧作業に人手がとられてしまった」「そもそも見積もりが甘かったために初期作業に予想以上に時間がかかった」など、プロジェクトに途中で変化の要素が加わることは日常茶飯事。にもかかわらず、途中で発生した変化を無視した状態で、締め切り間際までそのままプロジェクトが進行する、というのは実によくある話です。

　もちろん、若干の遅れであれば、遅れの原因となった人がカバーするべく努力するなり、最後の最後で他のメンバーがフォローすることで対応できることもあります。

　ただ、事前の見積もりが厳密であればあるほど、発生した遅れを取り戻す余裕がどこにも存在しないため、様子を見るつもりがそのまま締め切りに響くことになりかねません。

　これは変化を認めないプロジェクトでよく発生するケースです。リリース日は決まっているのだから、途中でプロジェクトに変化が発生しても、プロジェクトのリリース日は死守。そんなプロジェクトに限って、変化が発生した段階では特に対応をせずに、締め切りギリギリまで根性に任せて様子を見るケースが多くあります。

　根性で乗り切れないケースは人生にはたくさんあります。結局、奇跡でも起きない限り、最終的には締め切り直前に地獄を見ることになるわけです。

プロジェクトの失敗要素はシンプル

　このように失敗の要素を3つに分解すると、プロジェクトの失敗を構成する要素自体は、実は意外にシンプルだということが分かると思います。

　計画をしっかり作成し、メンバーにやる気を出してもらい、変化に対応すれば、プロジェクトマネジメントは成功するということですから。

　逆にこの「計画」「やる気」「変化」というプロジェクトマネジメントを構成する要素はシンプルでも、それぞれに問題が発生しないようにコントロールするのが至難の業。土木工事のように過去の蓄積があるために「計画」も立てやすく、メンバーの「やる気」もはた目に分かりやすく、予想外の「変化」も比較的発生しにくいプロジェクトであれば、まだ対応の方法はあるかもしれません。

　ところが、ホワイトカラーの仕事は、毎回“初体験”のようなプロジェクトで正確な「計画」を立てるのが不可能に近く、「メンバー」の作業効率も把握しにくい上に、プロジェクトに変更や変化が頻繁に発生します。ある意味プロジェクトマネジメントは失敗するのが当たり前と考えたほうがいいかもしれません。

　そこで次回はこの前提に立って、変化の激しい仕事では、どのようなプロジェクトマネジメントが最適なのか考えてみたいと思います。

筆者プロフィール　徳力基彦（とくりき・もとひこ）

NTT、ITコンサルを経て、現在はアリエル・ネットワーク株式会社プロダクト・マネジメント室マネージャ。ビジネスパーソンの生産性向上のためのソフトウェアの企画・開発やコンサルティング業務に従事するほか、グループウェアやブログ、仕事術などに関する執筆・講演活動を行っている。ブログは「ワークスタイル・メモ」と「tokuriki.com」