連載
» 2008年01月21日 00時00分 公開

プロジェクトはなぜ失敗するのか(3):営業の押し込み案件は失敗への扉

皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。

[落合和雄,@IT]

 IT業界は競争が激しく、なかなか適正な見積金額では受注できない場合が多い。その場合は値引きをしてでもプロジェクトを受注することがある。これは、商売としては至極当然のことであるが、問題は、この場合のプロジェクト予算の立て方である。

プロジェクトはなぜ失敗するのか 各回のインデックス

第1回 システム化範囲がぶれていれば失敗する

第2回 破たんした見積もりはプロジェクト失敗への近道

第3回 営業の押し込み案件は失敗への扉を開く

第4回 デフォルトの契約内容は、失敗への招待状


 多少赤字ではあっても、その仕事を取ることが会社にとってメリットがある場合も多い。代表的なものは、以下のようなケースである。

(1)その仕事をやることによりノウハウが蓄積でき、そのノウハウの横展開が期待できる。

(2)その企業に食い込むことにより、今後、多くの受注が期待できる。

(3)仕事が不足しており、人員が遊んでいるので、稼働率を高める必要がある。

 このような理由で受注したプロジェクトの赤字は、(1)と(3)は会社全体で持ち、(2)は営業の部署で負担するのが理由から考えて筋である。

 ところが多くの企業は、この負担をSE(システムエンジニア)の部門に押しつけて、「採算が苦しいけど、何とか頑張ってくれ」という精神論でプロジェクトを引き受けさせようとする。要領のいいSEはこの状況をいち早く察知し、理由をつけて巧みにこのような割の悪い仕事を避けようする。

 そうすると、結局人のいいSEにこの仕事が回って来ることになる。そして採算の悪いプロジェクトと悪戦苦闘する羽目に陥ることになる。

 このような状況でも、人のいいSEは予算内で何とかこのプロジェクト完成させようとそもそも無理な計画を立てて、このプロジェクトをスタートさせることになる。

無理が通れば道理引っ込む

 しかしプロジェクトにおいて、最初から無理な計画がそのとおり実行できた例はほとんどない。プロジェクトにはリスクが付きものであり、必ず予期しない工数やコストがかかるものである。従って、適切な予備を確保して、余裕を持った計画を立てなくてはならない。これはプロジェクトの基本原則である。それを最初から無理な計画でスタートすれば、途中で計画が破たんすることは目に見えている。

 このように無理な計画のままプロジェクトがスタートすると、あまりに目標達成までが遠いために、途中からメンバーの目標を達成しようという意欲がなくなり、ずるずると納期が遅れ、コストもかさむことになる。

 例えば5000万円の見積もりの仕事を営業上の理由で4000万円で受注したとしよう。このときに実際の受注額である4000万円でシステムを完成させるように、プロジェクトマネージャに頑張らせるとする。

 最初は何とかこの目標を達成しようとプロジェクトマネージャは右往左往しながらも頑張るだろうが、目標達成が難しい状況になってくると、あきらめが生じてしまうことになる。

 人間は、目標に対して90%ぐらいの達成率だと、100%まで何とか目標を達成しようと頑張ろうとするが、これが80%を切るとあきらめが出て頑張らなくなり、生産性は大幅に落ちてしまうことがある。

 この結果、当初の4000万円の予算のプロジェクトのコストはずるずると膨らみ、下手をすると倍の8000万円近くかかってしまうことになる。これに対して、最初から5000万円の予算でプロジェクトを実施すれば、何とか予算を守ろうとする意欲が働き、5000万円の予算で収まる可能性が高くなる。

無理な受注をしたときの対応策は?

 無理な受注をしたときに、それをSEに押しつけて無理な計画を作らせることは、決して得なことではない。

 プロジェクト成功の極意は、無理な計画を立てないことである。プロジェクトは必ず予期しないリスクが発生するものであるから、最初から無理な計画を立てていると、この予期しないリスクが発生した場合に対応の取りようがなくなってしまう。本来であれば、少し余裕を持って計画を立てることが望ましいのである。

 それでは、このような無理な受注をした場合には、どのような対応を取ればよいのであろうか。

(A)価格と予算の分離

 第1に考えなくてはいけないことは、顧客に提示する価格と、プロジェクトの実行予算を分離することである。その場合、次の考え方を捨てなくてはならない。

プロジェクト予算=価格×(1−利益率)

 この考え方を捨てないと、SEは赤字を営業のせいにするだけである。価格には他社との競争条件や、会社の戦略などいろいろな要素が入り込む。

 これに対してプロジェクト予算は、できるだけ正確な数字をはじき出す努力をする必要がある。従って、価格とプロジェクト予算との間に、必ずしも一定の関係が成り立つはずはないのである。

 価格とプロジェクト予算の関係は、適正な価格を出す際に、次のいずれかの式を使うところまでである。

価格=プロジェクト予算÷(1−利益率)

価格=プロジェクト予算×(1+利益率)

 この後の価格は顧客との交渉で変わってしまうことがあるので、その価格とプロジェクト予算とを連動させてはいけないのである。

(B)赤字の負担部署

 (A)を実現させるためには、価格がプロジェクト予算を下回ったときの負担部門を明確にする必要がある。この負担部門は本来明確なはずである。会社全体の経営戦略として赤字プロジェクトを実施するのであれば、その負担は本社部門が持つべきである。

 営業戦略として赤字プロジェクトを実施するのであれば、その負担は営業部門が持つべきである。この原則を崩して、この赤字をプロジェクト実行部門に負担させてはいけない。

(C)適正なプロジェクト予算算出の仕組み

 このようなことをいうと、よく心配されるのは、この仕組みではSE部門が上乗せした余裕を持った見積もりばかり出すのではないかという点である。

 これは2つの仕組みで防ぐことができる。

 1つは、客観的な見積もり算出手順を確立することである。ファンクションポイント法などの合理的な見積もり手法を導入すれば、ファンクション数が決まればおのずと見積金額は決まる。

 もう1つは、営業分門、SE部門双方から独立した、仲裁組織を持つことである。もし、営業部門とSE部門で見積金額について、食い違いがあり、調整がつかない場合には、この仲裁部門が裁定を行うことにすればよいのである。

◆編集部からのお薦め関連記事

 本連載のほか、プロジェクトマネジメントに関連する記事が@IT自分戦略研究所にはいくつかある。ここでそのいくつかを紹介したい。

 プロジェクトマネージャやプロジェクトリーダーではないが、これからプロジェクトマネジメントを学習したいという人にお薦めしたいのが、次の連載である。

 PMBOKの第3版については、次の記事を参考にしてほしい。

 実際に経験した体験から、ほかのITエンジニアにも役立つような事例などを紹介する連載。プロジェクトマネジメントのヒントになりそうな記事もある。

 現場でありがちなシチュエーションを考え、そこからプロジェクトマネジメントに必要なことを学んでいこうという連載。本連載に登場する矢見雲マネージャと出来杉マネージャにも注目したい。準拠しているPMBOKは2000年版だが、現在でも十分利用できる内容だ。

 本連載は、あるプロジェクトで起こるさまざまな問題などを通して、ITエンジニアが学べることを提供してくれる。

著者プロフィール

落合和雄

1953年生まれ。1977年東京大学卒業後、新日鉄情報通信システム(現新日鉄ソリューションズ)などを経て、現在経営コンサルタント、システムコンサルタント、税理士として活動中。経営計画立案、企業再建などの経営指導、プロジェクトマネジメント、システム監査などのIT関係を中心に、コンサルティング・講演・執筆など、幅広い活動を展開している。主な著書に、『ITエンジニアのための【法律】がわかる本』(翔泳社)、『実践ナビゲーション経営』(同友館)、『情報処理教科書システム監査技術者』(翔泳社)などがある。そのほか、PMI公式認定のネットラーニングのeラーニング講座「ITプロジェクト・マネジメント」「PMBOK第3版要説」の執筆・監修も手掛けている。



Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。