2015年11月23日月曜日

システムにおける失敗プロジェクトの考察(見積り編)



良くある失敗項目

私がITプロジェクトで失敗しているなー、と感じている流れを整理してみました。

見積りから始まる失敗事例

まずは、見積りの失敗から始まる失敗パターンです。

さあ、新しいプロジェクトが始まります。
まずは、見積りを作成して交渉するのですが、
高いといわれ続け、値下げしていきます。
(最初から損をするような見積りをする人はいません)


費用が無ければ、必要な人員や機材を確保できません。
が、何かの理由で、この採算の取れない案件を受注してしまいます。
プロジェクト計画書を作りますが、理想論しかかけず、
その理想を遂行するためのビジョンが描けない状態です。
(要はまったく出来る気がしない状態です)


必要な人員や機材を確保できないので、品質や納期および生産性に影響が出る。
上流工程では、ドキュメントだけなので騙し、騙しでドキュメントを完成させるが
内容について要件漏れや、矛盾があるような状況です。
このごまかしが、製造工程で泥沼を引き寄せます。
(ここで、悪循環の種を植え付けてしまいます)

当然、今後の泥沼を回避するためのアイデアなんて考えている暇はありません。


常に進捗遅れ状態、間に合わないから残業をするけど、焼け石に水
このころになると、具体的な施策より、精神論が横行しだす。
また、あわてて人を入れるが、当然何も知らないド素人が入るので
新しく入った要員の対応に追われるが、思った成果は出ない。


品質が悪いので不具合が大量に発生する。
対応に追われ、さらに進捗の遅れが悪化する。
また、残業もさらに増えて徹夜なんてことも

不具合の対処も当然ですが、他にも横展開などの対策にも追われるハメになる。

当然不具合に対する、想定も当初の計画には盛り込まれていなかったりするし
単純な誤りが目立ち、外部からもにらまれる。
(リーダーの精神状態が心配になります)


突然会社に来なくなる人や、うつ病になる社員が出る。
ひどい場所では、リーダーが逃げるといった話も聞く。


サービスインに持っていっても
瑕疵だの言われながら、サービスイン後の不具合の改修
を続け、新しい案件にメンバーを回せない。
瑕疵では無いと抵抗をしたいところだが、今まで出した不具合やそもそも
そういった戦いを行う体力さえも無い状態

どうでしたか、皆さんのイメージと同じでしょうか?
「ある、ある」と感じた人がほとんどではないでしょうか。

大きな失敗をしているプロジェクトの大半が、見積り誤りです。
いろんな手法の見積りが出ていますが、あくまで参考に出来るだけで、IT業界では未だに、経験に勝る見積りは無いと感じています。
あらゆる見積り手法は、相手を納得させるための道具と割り切り、自分の経験に近い見積りを出すようにしましょう。
もちろん自分が蓄積してきた実績に基づく数値を使うのであれば問題はありませんが、他の会社が持ち込んだ指標は全くあてになりませんし、要員により大きく変わります。
今まで私が読んできた書籍でも、優秀な社員とそうではない社員の差は100倍あるとも書かれていますし、製造の生産性と言う意味では、人によっては、達成できないというケースもあり、100倍どころではない状況に追いやられたこともあります。
といっても、本当に理想的な体制は作れないものです、まずは理想から何が妥協できるかを考えるようにしましょう。

それでも受注するの?

 時には会社の戦略として、採算が取れなくても、受注しなくてはならないケースもあるでしょうがその際は、どうか、引け目を感じず、最初の初期投資はしっかり行うことをお奨めします。
 途中で安定してくれば、そのタイミングで要員を削るという手もありますが、途中で人を入れるのはランニングコストが高くつき、どんなに優秀な人でも力を発揮するのは難しい状況になります。
 この場合は、費用のことは考えず、プロジェクト達成するためのどうしたらいいかということに集中するべきと考えます。(立ち上がったら要員は返却するなど適当なことを言ってでもいったんキープした方が良いです。もし泥沼になれば、それが分かっていても要員を引っこ抜くような冷徹な人は私は少ないと信じています。)


十分な体制が取れなかったらますます酷くなります。
マスターマインド、同じ志を持つ仲間と十分に議論し、達せしいたプロジェクトに関しては問題が起きたことは今までありません。